Memory Settings

Help index


NewSpace Size

Defines the amount of memory where new objects are created. The memory manager uses a generation scavenging mechanism, where objects are allocated in newSpace (also called eden space) and promoted to the so called oldSpace after a while.
Objects in newSpace are quickly reclaimed (actually, the cost for reclamation is zero - its the survival of new objects, which generates some overhead).

Choosing a size for the newSpace is a trade between GC overhead (as percentage of the total CPU time) vs. maximum pause time due to scavenging operations.
The default of 400k leads to a maximum pause time of about 20-60ms on average machines (this heavily depends on the CPU and especially the memory access times).

Maximum Memory Limit

This is the maximum size of the oldSpace memory area. Notice, that if a copying (Baker-) garbage collection mechanism is used, the virtual memory requirements might be twice this amount during a copying garbage collection.

Quick Allocation Limit

Up to this amount of memory, the system will not try to compress memory when the allocated memory becomes used; instead, more memory is quickly allocated and the oldSpace size therefore increased.

Incremental GC Allocation Trigger

The incremental background garbage collector (IGC) reclaims oldSpace objects in the background, usually without noticable pauses.
This number defines the allocation trigger value for the IGC to start: whenever that amount of memory has been allocated since the last collection, it starts a reclamation cycle.

Notice, that the IGC runs as a smalltalk thread; by default, at low priority. If higher priority processes are active, it may not complete a reclamation cycle early enough, leading eventually to a blocking garbage collect.
In some situations, it may be useful to raise the background collectors priority.

Incremental GC FreeSpace Trigger

This number defines the freeSpace trigger value for the IGC to start: whenever the amount of free memory drops below this number, it starts a reclamation cycle.

Incremental GC Amount

This number defines the amount of memory which is supposed to be free after an incremental GC cycle completes; of it is not, more memory is allocated in order to fill the freeLists up to that amount.
In other words: this defines a reserve for peak allocation requests, which the memory system tries to keep.

Oldspace Increment

This number defines the amount by which the oldSpace is increased when running of memory. The memory is requested from the OS in chunks of (at least) this size.

Oldspace Compress Limit

The memory manager will perform 2-pass compressing garbage collects, if more than this amount of memory is in use. If this number is 0 or less then this amount of memory is used, one-pass compressing garbage collects are performed.
The one-pass compress algorithm needs twice the amount of currently used memory during the collect, but is faster as long as enough physical memory is available. Use this variable to avoid paging when doing a compress of large images.

Stack Limit

The runtime system will trigger an error, whenever a threads stack grows above that number. The stack is used for the context chain and for local storage in primitive code.
Be aware, that some primitives require a huge amount of stack (especially, primitives, which use the Xlib bitmap-image display functions).
Therefore, all threads which perform display operations should be provided with a minimum stack of roughly 250k bytes.

Dynamic Code Limit

This defines the amount of memory which is used as a cache for dynamically compiled bytecodes.
The runtime system may temporarily allocate more memory, however, the garbage collectors will flush old methods whenever more code cache space is in use.
Code for an active method is never flushed from the cache.

If no limit is set, the code cache is only flushed for recompiled (i.e. accepted) methods.

Dynamic Code GC Trigger

Start a background collector whenever this amount of dynamic code has been generated. Can be set to some non-zero value, to force flushing of recently unused code.

Additional Settings (Not available in the Settings Menu)

The following additional settings allow further fine tuning/control over the memory managers behavior. These are not found in the launchers settings menu and must be changed by evaluating expressions in a workspace (also, see the comments in the corresponding methods in ObjectMemory).

Further Reading

For more information, read "garbage collection".


Copyright © Claus Gittinger Development & Consulting, all rights reserved


Doc $Revision: 1.6 $ $Date: 2003/08/29 12:51:45 $