Helen writes
> My experience is that the performance penalty is not all one suffers with automatic
> garbage collection in POPLOG.
> POPLOG may well collect up garbage and free the memory for it's own use, but it does
> not appear to be very altruistic with respect to other processes running on the
> machine. When making a garbage collection, POPLOG actually INCREASES the total
> amount of memory it is using, so forcing other processes running on the machine
> into an "out of swap space" situation and crashing them.
You can force Poplog to do an in place garbage collection REF * system/pop_gc_copy
pop_gc_copy -> BOOL [variable]
BOOL -> pop_gc_copy
If this variable is true (the default), then garbage collections
use a 'copying' algorithm, which temporarily requires the
allocation of extra memory in which to copy all non-locked heap
structures; otherwise (or if the required extra memory is not
available), a 'non-copying' algorithm is used.
The non-copying algorithm is generally 25% - 50% slower than
the copying one (although in some situations it may be faster,
and therefore worth setting this variable <false>). (Note
however that at certain times the system needs to be able to
shift heap structures up in memory, and requires the copying
algorithm to do this; thus copying collections may still occur
when -pop_gc_copy- is <false>.)
> Further to this; I have found that POPLOG's own behaviour becomes somewhat
> unpredictable and irrational when swap space runs low, with a distinct tendency
> for conditional branches to default to the else path regardless of the evaluation
> performed, and without signalling any error.
Can you give an exampe of this ?
> Allowing the programmer to manage the utilisation of resources herself, can save
> an awful lot of heartache!
You can reduce the amount of garbage created by use of the procedures
sys_grbg_list and sys_grbg_destpair (REF * fastprocs/sys_grbg_list ).
Cheers
Anthony.Worrall@Reading.ac.uk
PS. can we have an occasional newline in text :-).
|