See the discussion in the mailing list for context, but long story short ... when operating with a large TOC, it is possible that when a gemserver goes idle, a significant amount of toc space will consume real memory that would normally be returned to the os if a mark sweep was run ... @marianopeck finds that the following does a good job of ensuring that idle gems consume the minimum amount of real memory:
"This thread is needed to handle the SigAbort exception, when the primary
thread is blocked on an accept. Assuming default 60 second
STN_GEM_ABORT_TIMEOUT, wake up at 30 second intervals."
[
| count minutesToForceGemGC |
count := 0.
minutesToForceGemGC := 30.
[ true ] whileTrue: [
(Delay forSeconds: 30) wait.
count := count + 1.
(count \\\ (minutesToForceGemGC * 2)) = 0 ifTrue: [
System _generationScavenge_vmMarkSweep.
Transcript show: 'Gem GC forced'; cr.
count := 0.
].
].
] forkAt: Processor lowestPriority.
An extra scavenge and marksweep every thirty minutes will add a significant load on the system
See the discussion in the mailing list for context, but long story short ... when operating with a large TOC, it is possible that when a gemserver goes idle, a significant amount of toc space will consume real memory that would normally be returned to the os if a mark sweep was run ... @marianopeck finds that the following does a good job of ensuring that idle gems consume the minimum amount of real memory:
An extra scavenge and marksweep every thirty minutes will add a significant load on the system