GC performance - was Re: [gclist] GC topics

[Stefan Monnier]

> My overall non-expert opinion is that using a GC and allocating
> everything (without even using a stack) on a GC-ed heap is worth
> it. The advantage of reifying call frames (as continuations or
> closures) is significant for other reasons (call/cc, powerful control
> structures, ease of debugging, etc), so even a 25% penalty is IMHO
> acceptable.

I agree in that the simplicity of the heap-allocation makes it very attractive.
But the 25% estimate you quote can be misleading: depending on your cache
architecture, the slowdown can get much higher because of cache misses.
Also the predictability of stack allocation makes it very attractive when
it comes to real-time environments. I know that there are real-time GCs,
but their cost is usually fairly high: Kevin will probably correct me since
I haven't followed his research recently, but I seem to remember that even his
hardware-supported GC's write-access time guarantee is twice as high as the
"normal" write-access time. And the GC-startup time during which the system
is frozen is non-negligible either: it's still real-time and very useable
because the average slowdown is very low, but the noticeable increase in
worst-case time of basic operations is still annoying. If by simple static
analysis you can prove that such and such objects's allocation can be handled
by a stack (or any other predictable allocation mechanism), I consider it
as a desirable optimisation even if it doesn't provide an actual speed
increase.

One more thing: Appel's paper (as well as most others advocating heap-allocated
activation frames) deals with mostly functional languages. For instance his
analysis of the cost of heap-allocation is heavily influenced by his argument
about smart activation-frame layout (where you don't have a linked list
of activation frames, but rather have either a flat environment or some
hybrid) and this argument cannot be easily applied to a language where local
variables are mutable.

Also the problem mentionned by John about the memory requirements of GC
systems is not negligible. My use of computers makes me more sensitive to
memory than to CPU. I can totally deal with a slow machine, but not with one
that thrashes. Having a GC around allows you to use sharing more heavily
which should potentially reduce memory usage. But this potential advantage
is easily destroyed by other factors such as "double space for the two
generations of a copying collector" or the space used up by dead objects.
Has anybody tried to avoid most of the space cost of copying collection by
having several old generations and only collect one at a time (and hence
only need 1 additional such old generation, which can be chosen much smaller
than the typical 50% of the whole memory). I feel like this would pose
interesting problems to reduce inter-generation references.


	Stefan