[gclist] why malloc/free instead of GC?

[Boehm, Hans]

> -----Original Message-----
> From: Arlie Davis [mailto:arlie@sublinear.org]
> 
> Microsoft's CLR (.Net Framework) does a good job on "large" objects.
> Objects above a certain threshold (20k, I believe) are allocated in a
> traditional malloc/free heap, but their lifetime is still tracked
> through GC.  Also, since the CLR has access to all type 
> information, it
> only scans memory locations that are known to be pointers.
> 
> This is an elegant solution, because it shows that object lifetime
> (explicit free vs. GC) can be separated from allocation mechanism
> (contiguous heap w/compaction vs. fragmentable heap).
Agreed.  But it doesn't solve the fundamental (and unsolvable) problem.  If you allocate a 1MB object, that will still need to be considered by the GC triggering heuristic, and thus move you much closer to the next GC.  If it didn't, allocating many such objects in a row would cause unacceptable heap growth.
> 
> The same approach could easily be adopted by other GC implementations.
Since ours doesn't move objects, there's no real performance distinction between allocating something in the GC heap and the malloc/free heap, and it doesn't matter.  The real benefit of such a technique is that you avoid copying/moving large objects, if the collector otherwise does so.  I think many copying collectors use a similar technique.

Hans