[gclist] collector optimization

[David Chase]

At 06:12 PM 3/10/2001 -0500, Ji-Yong D. Chung wrote:
>   Does anyone know if there are application specific 
>optimizations I can try with Boehm's collector? 
>More specifically, I am wondering if there are parts of Boehm's 
>code that are known to be hackable for application
>specific optimization  -- I mean no disrespect to 
>Boehm or to Boehm's collector, here  :)
>
>    I do not mean just changing values of the tuning 
>hooks that are provided, as I have done much of that.

Depends upon what you mean by application-specific.
Long ago, when I used the BW collector for a Modula-3
implementation, I took care (in compiler-generated
code) to use "gc_malloc_atomic" for pointer-free
data structures.  We got bit once when someone
loopholed pointers into an array of integers; the
collector recycled the memory, and it was quite
confusing.

Another possibility is to open-code the free list
selection code, for allocations of constant size.
Not a gigantic win, but every little bit helps.

Another "hack" you can apply, again through a
compiler, is to use the predict-free call (if it
still exists).  The reason for this is that if
the collector is reliably informed about how much
free space it might expect to reclaim, it can more
sensibly choose between collecting and simply
growing the heap.  If you do this, you must do it
pretty well, else you just waste memory, but if
you do it right, you avoid the thrashing that
some systems will give you when you grow big
data structures -- before they are willing to
expand the heap, they do an expensive and useless
collection (everything is still live), and repeat
that until the heap is large enough for the data
structure being built.

David Chase