--- a/ObjMem.st Wed Nov 23 00:02:57 1994 +0100
+++ b/ObjMem.st Mon Nov 28 21:34:28 1994 +0100
@@ -31,7 +31,7 @@
COPYRIGHT (c) 1992 by Claus Gittinger
All Rights Reserved
-$Header: /cvs/stx/stx/libbasic/Attic/ObjMem.st,v 1.20 1994-11-22 14:27:17 claus Exp $
+$Header: /cvs/stx/stx/libbasic/Attic/ObjMem.st,v 1.21 1994-11-28 20:33:10 claus Exp $
'!
!ObjectMemory class methodsFor:'documentation'!
@@ -52,7 +52,7 @@
version
"
-$Header: /cvs/stx/stx/libbasic/Attic/ObjMem.st,v 1.20 1994-11-22 14:27:17 claus Exp $
+$Header: /cvs/stx/stx/libbasic/Attic/ObjMem.st,v 1.21 1994-11-28 20:33:10 claus Exp $
"
!
@@ -91,12 +91,23 @@
IOInterruptHandler gets SIGIO unix signals (from VM)
CustomInterruptHandler gets custom interrupts (from VM)
- AllocationFailureSignal signal raised when a new fails (see Behavior)
IngrementalGCLimit number of bytes, that must be allocated since
last full garbage collect to turn on incremental
collector.
Dependents keep my dependents locally (its faster) for
all those registries
+ LowSpaceSemaphore a semaphore signalled whenever the system is
+ running in low memory (i.e. the memory manager
+ ran into memory shortage and feels that it
+ may soon be no longer grant allocation requests).
+ You can have a process waiting on this semaphore
+ which starts to remove (i.e. nil-out) objects
+ or preform other cleanup actions.
+
+ AllocationFailureSignal signal raised when a new fails (see Behavior)
+ When this signal is raised, the meomory manager
+ is really in trouble (i.e. above feelings where
+ correct)
"
!
@@ -213,20 +224,28 @@
'IncrementalGCLimit': the ProcessorScheduler will perform incremental GC steps
if the total space used by objects allocated since the last full collect exceeds
this number. Its default is set in ObjectMemory>>initialize and can be changed in
- your startup 'smalltalk.rc'-file. Setting it to nil will turn incremental GC off.
+ your startup 'smalltalk.rc'-file.
+ Setting it to nil will turn incremental GC off.
For example, setting this limit to 500000 will start the background collector
whenever 500k bytes have been allocated - usually very seldom. Setting it to some
small number (say 10000) will have it run very often.
+ Setting it to a small number (i.e. running it often) should not hurt the
+ performance of your other smalltalk processes, since the IGC only runs at
+ idle times. (there are some delays in event processing, since the IGC's steps
+ may take up to some 100ms.) However, if you are not alone on your machine
+ (i.e. a timesharing system) or you have other Unix processes to run, you
+ should not run the IGCLimit too often, since it may hurt other users.
Since this collector only runs at idle times, even a low priority background process
- will prevent it from doing its useful work. You may want to start a somewhat
+ will prevent it from doing its work. You may want to start a somewhat
higher priority background collect (say at prio 4), which also preempts these
background processes. (see ObjectMemory>>startBackgroundCollectorAt:).
hints & tricks:
- normally, there is no need to call for an explicit garbage collection;
- the memory system should adapt reasonable and provide good performance
+ normally, there is no need to call for an explicit garbage collection, or
+ modufy the default parameters.
+ The memory system should adapt reasonable and provide good performance
for a wide range of allocation patterns (see Example3 below for an exception).
However, there may be situations, in which hints and/or explicit
@@ -237,19 +256,20 @@
or bad uses of collections. A typical error that is made is to
create large collections using the #, (comma) concatenation method,
which shows square behavior, since it allocates many, many temporary
- collections. Also, look out for #copyWith:, #add: etc.
+ collections. Also, watch out for #copyWith:, #add: etc.
All of these create a new collection. Remember, that most collections
offer methods to preallocate some space; for example, 'Set new:' creates
an empty set, but preallocates some space.
- if you are going to allocate huge data structures, think about
optimizing space. For example, if you allocate a million instances of
- some object, each added instance variable makes up 4Mb of aded memory need.
+ some object, each added instance variable makes up 4Mb of additional
+ memory need.
Also, for Byte-valued, Integer-valued and Float like objects, special
collections are provided, which store their values directly inside (instead
of a reference to the object). A FloatArray consisting of 1 million floats
- requires about 4mb of memory, while an array of floats requires 4mb PLUS
- 20Mb for the floats.
+ requires about 4mb of memory, while an Array of Floats requires 4mb for the
+ references to the floats, PLUS 20Mb for the floats themself.
- check if you really need fast access to all of these objects; you may
try to only keep some subset in memory, and use binary storage or
@@ -1229,10 +1249,10 @@
IncrementalGCLimit := aNumber
"
- ObjectMemory incrementalGCLimit:500000
- ObjectMemory incrementalGCLimit:100000
- ObjectMemory incrementalGCLimit:10000
- ObjectMemory incrementalGCLimit:nil
+ ObjectMemory incrementalGCLimit:500000. 'do incr. GC very seldom'
+ ObjectMemory incrementalGCLimit:100000. 'medium'
+ ObjectMemory incrementalGCLimit:10000. 'do incr. GC very often'
+ ObjectMemory incrementalGCLimit:nil. 'never'
"
!