Herbert König wrote:
Do I have to learn from this, that when creating lots of objects I intend to keep for a while, it's good to force a GC instead of waiting that time will move my objects to old space?
What you need to learn from this is that when you have non-trivial workloads you need to adjust the GC parameters to fit your application needs. For example, we use the following settings for Qwaq Forums:
initializeMemorySettings "Initialize the memory and GC settings to be more in line with QF requirements"
"The following settings affect the rate incremental GCs and tenuring"
"Limit incremental GC activity to run every 40k allocations" Smalltalk vmParameterAt: 5 put: 40000. "allocations between GCs (default: 4000)" "Limit tenuring threshold to only tenure w/ > 10k survivors" Smalltalk vmParameterAt: 6 put: 10000. "tenuring threshold (default: 2000)"
"These settings affect overall memory usage"
"Only give memory back to the OS when we have more than 16MB free" Smalltalk vmParameterAt: 24 put: 16*1024*1024. "default 8MB" "Try to keep 8MB headroom at all times" Smalltalk vmParameterAt: 25 put: 8*1024*1024. "default 4MB"
"These settings describe what to do when we're close to running out of free space"
"Tell the VM that we'd rather grow than spinning in tight GC loops" Smalltalk gcBiasToGrow: true. "default: false" "Tell the VM to do a fullGC for good measure if the above growth exceeded 16MB" Smalltalk gcBiasToGrowLimit: 16*1024*1024. "default: 0"
Cheers, - Andreas