Squeak
  links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Garbage Collector Parameters
Last updated at 12:30 pm UTC on 17 January 2006
On March 20, 2004 John McIntosh wrote to the following message to the list, which effectively defines the "low level" garbage collector parameters:

Mmm I'm wondering here if you need to adjust the garbage collector.
Right now the VM (unix/mac/windows) will
grow memory by a set amount, or the amount needed plus slack. Once it's
grown and we exceed a threshold it
and memory in new space comes free we will shrink things. This is
controlled by vmParameter 24 and 25.

Bad choices lead to overhead as we grown/shrink memory allocated to the
VM. Not that we point out what our 'good' choices are
in any case.


> Smalltalk vmParameterAt: 25 put: 24*1024*1024. "grow headroom"
> Smalltalk vmParameterAt: 24 put: 48*1024*1024. "shrink threshold"


The other magic numbers are 5 & 6 which control when a incremental GC
is created, and when we tenure objects.
So for example if I know I'm going to create a bunch of points
(100,000+) I might consider changing this to at 5 put: 50,000
at 6 put 40,000. The trade off here is how long it will take to trace
50,000 live objects. Although machines are so fast
now perhaps we need to revisit this. {I'm sure for years now I've
considered rewriting the logic a bit so we can adapt the values
to machine characteristics, since these values were chosen to give
25mhz mac 68040 machines minimal igc times so that music
playback would work without stuttering}

Since I'm speak on this topic at Smalltalk Solutions 2004 perhaps it's
time for some coding...

Defaults found in the image

SmalltalkImage current vmParameterAt: 5 put: 4000. "do an incremental
GC after this many allocations"
SmalltalkImage current vmParameterAt: 6 put: 2000. "tenure when more
than this many objects survive the GC"


I will note I looked at this last summer and found for the base image,
and what people normally do, altering the current values
doesn't perhaps buy you anything. The values chosen, are reflective of
the work you are doing.

Plus of course is how we look at the remember table. Old objects that
point to new Objects. If you get a large collection into that logic
we spin thru all the elements (millions?) when an igc occurs. This can
be solved by either: rewritting the GC logic, or doing a full GC
in the right place so things get tenured. Mind having adaptive feedback
from the GC logic watching for this would work too {See John's list of
things to do someday}

I'll suggest if you can create all your objects, do a full GC, then do
the computations, that might improve things.

Summer 2005. John notes:
See
http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-February/087657.html

a) Take a test image and file in
JMMGCMonitor.4.cs see ftp://ftp.smalltalkconsulting.com/squeakGarbage/

b) Run this altered image with
Squeak 3.8.6Beta4.app or higher, or any VM created in june/july of 2005 using the
latest VMMaker.

c) in a work space do

GCMonitor run.

"do your test here"

GCMonitor stop. "When you stop your testing"


This will produce a file "gcStats.txt" which contains statistical data collected from the GC logic every 100 milliseconds. Please email file to johnmci@mac.com with a bit of explanation of what you tested, please archive the file so it's zipped to reduce the size of it.

Now to test with some active tuning, please re-run your test but do

Smalltalk setGCBiasToGrowGCLimit: 16*1024*1024.
Smalltalk setGCBiasToGrow: 1.
GCMonitor runActive.

"do your test here"

GCMonitor stop. "When you stop your testing"
Smalltalk setGCBiasToGrow: 0.

I will note you must save a copy of the gcStats.txt before you do the runActive because it will overwrite any previous results, say the earlier results of doing "run". Please email the file and note this was the result of runActive, also note any observations about
pauses or odd behavior.



VM parameters are numbered as follows: (Starting Summer of 2005 based on changes by John McIntosh

"parameterIndex is a positive integer corresponding to one of the VM's internal
parameter/metric registers. Answer with the current value of that register.
Fail if parameterIndex has no corresponding register.
VM parameters are numbered as follows:
1 end of old-space (0-based, read-only)
2 end of young-space (read-only)
3 end of memory (read-only)
4 allocationCount (read-only)
5 allocations between GCs (read-write)
6 survivor count tenuring threshold (read-write)
7 full GCs since startup (read-only)
8 total milliseconds in full GCs since startup (read-only)
9 incremental GCs since startup (read-only)
10 total milliseconds in incremental GCs since startup (read-only)
11 tenures of surving objects since startup (read-only)
12-20 specific to the translating VM
21 root table size (read-only)
22 root table overflows since startup (read-only)
23 bytes of extra memory to reserve for VM buffers, plugins, etc.

24 memory threshold above which shrinking object memory (rw)
25 memory headroom when growing object memory (rw)
26 interruptChecksEveryNms - force an ioProcessEvents every N milliseconds, in case the image is not calling getNextEvent often (rw)
27 number of times mark loop iterated for current IGC/FGC (read-only) includes ALL marking
28 number of times sweep loop iterated for current IGC/FGC (read-only)
29 number of times make forward loop iterated for current IGC/FGC (read-only)
30 number of times compact move loop iterated for current IGC/FGC (read-only)
31 number of grow memory requests (read-only)
32 number of shrink memory requests (read-only)
33 number of root table entries used for current IGC/FGC (read-only)
34 number of allocations done before current IGC/FGC (read-only)
35 number of survivor objects after current IGC/FGC (read-only)
36 millisecond clock when current IGC/FGC completed (read-only)
37 number of marked objects for Roots of the world, not including Root Table entries for current IGC/FGC (read-only)
38 milliseconds taken by current IGC (read-only)
39 Number of finalization signals for Weak Objects pending when current IGC/FGC completed (read-only)
40 VM word size - 4 or 8 (read-only)"