Memory Settings
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
).
- fastMoreOldSpaceAllocation - boolean
if on, the memory manager will quickly allocate more oldSpace
up to the limit defined by the fastMoreOldSpaceLimit,
without perforing a garbage collect first. Above that amount of allocated
memory, a garbage collect is performed before more oldSpace is allocated.
a useful setup is fastMoreOldSpaceAllocation:true
and fastMoreOldSpaceLimit:80000000
- fastMoreOldSpaceLimit - number
the limit - see description above.
- maxOldSpace - number
defines the absolute maximum amount of oldSpace memory, which ST/X
will ever allocate. If more memory is ever required, further object
allocations will fail and return nil.
A value of nil (which is the default) allows unrestricted memory allocation
However, the operating system may refuse further allocations, depending
on the amount of swap space or any user limits.
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 $