Sophie has a SophieMemoryPolicy instance that also checks for  
abnormal number of root related scans and forces a tenure. This fixes  
the problem when a large slot based object
starts being scanned as part of the root lookup logic.

	(statMarkCount ) > (statAllocationCount*2)
		ifTrue: [[Smalltalk forceTenure] on: Error do: [:ex | ]].  "Tenure  
if we think too much root table marking is going on"

It also btw had code in SophieMemoryPolicy >>calculateGoals that  
adjusted Smalltalk vmParameterAt: 5 and 6 to target a 1 ms  
incremental GC time. A singleton instance wakes up every 5 seconds  
and peeks at the GC statistical data. However I've not been doing  
this adjustment.

I used Smalltalk gcBiasToGrowLimit:  32MB since that seemed to be a  
reasonable value for doing minor amounts of user interaction when I  
last looked at it, and I just doubled the vmParms 5/6  which as you  
point out is inadequate.

I'll lastly note you must apply JMM-fixBiasToGrow.1.cs to your  
VMMaker image to ensure the "growSize :=  growHeadroom*3/2 - (self  
sizeOfFree: freeBlock)." has the missing period
otherwise as noted earlier this year then the entire statement is  
dropped by SLANG and then causes the bias to grow logic to work  
incorrectly.  I don't believe Tim has added this
fix to VMMaker yet?


On May 17, 2007, at 10:59 PM, Andreas Raab wrote:

> Hi Folks -
>
> I spent the last two days in a bit of optimization mode for Qwaq  
> Forums and one of the things that I found is that the memory  
> settings Squeak ships with by default are abysmal for anything  
> resembling 21st century memory sizes and processor speeds. I'm  
> interested in an exchange with people who have been tweaking these  
> settings to see what they come up with. For Forums, I have found  
> the following to be significant:
>
> * IGC counts: I have found that I could speed up forums by about  
> 30% simply by reducing the number of IGCs and tenures via the  
> following settings:
> 	Smalltalk vmParameterAt: 5 put: 40000. "default: 4000"
> 	Smalltalk vmParameterAt: 6 put: 10000. "default: 2000"
> The effect of these changes is that we only do 1/10th of the  
> frequency of incremental GCs.
>
> * Total memory sizes: I have found that insufficient free space is  
> a major source of slowdowns (factor of 2-3). This can be avoided by  
> biasing the VM to grow instead of collect (thanks John!) and ensure  
> that there is enough headroom at all times:
> 	Smalltalk gcBiasToGrow: true. "default: false"
> 	Smalltalk gcBiasToGrowLimit: 8*1024*1024. "default: n/a"
> What I'm curious about is what settings other people with "21st  
> century loads" on their applications have found to make a  
> difference. The above seem to work out well for forums,  
> significantly increasing the frame rate on small machines (up to  
> 30%) but without having individual IGCs to be too slow for real- 
> time processing (voice chat and rendering in our cases).
>
> Cheers,
>   - Andreas
>

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===