[gclist] Fast-allocating non-copying GC's

[David Ungar]

Paul writes:

>Then you're ahead of us by one word.  It's not clear to me that that's
>usually the critical factor.

Again, you can dismiss space overhead-per-object as a critical
factor if you want to, but in so doing you are probably
ruling out applications that would tend to create
lots 'o small objects, or ones that live on the hairy edge of thrashing.


>
>>Secondly, IMHO fragmentation is a big concern.
>>At ParcPlace, it seemed to be the way that most real ST apps
>>really stressed the memory system.
>
>Interesting.  More info would be very welcome.  What was the underlying
>allocator?  Fragmentation can be very dependent on the choice of
>allocator?  (e.g., Best Fit or address-ordered first fit usually has
>an order of magnitude less fragmentation than next fit.)

>
>>From the data I've seen, the fragmentation problem is overrated---picking
>a good allocator can help a *lot*.   I don't know if the data are
>representative, though.
>

It was just a simple contiguous allocator. I believe in
compacting storage systems and contiguous allocators.
IMHO, the effort invested in a compacting storage system
pays off much better than effort expended
in a non-compacting storage system
with a first/best-fit free-list wobulator allocator.


Have you been studying these other approaches
because of the desire to be applicable to C and the difficulty of
a compacting storage system for a non-pointer-safe language?
If so, I understand, but would be very wary of generalizing results
about what works well in the C arena to languages that facillitate
compacting collection.


>Another issue is that we haven't clearly separated out the issue of
>"nonmoving" from "non-copying."  It take it you're advocating a moving
>(sliding compaction) GC for the old data, not a copying GC.  Copying
>is a huge lose for big volumes of data that barely fit in memory.

Yes, I am advocating motion--copying is only critical for the young
objects.


>
>>So, I would take issue with the statement that
>>"For *most* apps, non-copying GC is a win"
>
>Well, I'll take issue with your taking issue.  Now we can argue interminably
>about how to figure out what "most" means.  Or I can just defend the
>thesis that "it depends".  E.g., on:
>
> ....
>
>My claim (for which the evidence is admittely scanty, but I think generally
>on my side) is that non-copying GC is good for most apps, taking lots
>of considerations into account.
>


I don't understand. Are you saying "it depends"?
I completely agree.
Or are you saying "non-copying GC is good for most apps"?
Seems hard to defend to me, unless you state lots of assumptions.

- Dave


-- Dave