[Gc] Basic questions

Boehm, Hans hans_boehm@hp.com
Mon, 12 May 2003 11:33:52 -0700

I think we concluded that the problems here were:

1) A bad comment in gc.h.  (I fixed that.  Thanks.  I also fixed another bug in the vicinity.  Interior pointer recognition is now an initialization-time option.)

2) The pointer that should have been recognized, but wasn't, pointed just past the end of the object in question.  As Fergus pointed out, this can't easily be made to work correctly.  The preferred workaround is to allocate the object slightly larger.  This is not a bug in the GC.

> While I'm at it, I'm not sure to understand when I should be 
> using `GC_malloc' vs
> `GC_malloc_ignore_off_page' in my case where I have 
> `GC_register_displacement(8)'
> only.
The story there is not as clean as I would like.  In general, GC_malloc_ignore_off_page is preferred if:

a) The allocated object may be large, e.g. > 100KB in size, and

b) You know that it will always be referenced by a pointer near the beginning, e.g. because there is a volatile pointer stored somewhere as long as it's live, or because you control the code generator, and know it won't optimize away the last reference to the beginning, or ...

The fact that you recognize only two pointer displacements improves matters a bit, in that interior pointers stored in the heap or static data will be ignored anyway, and hence there is less need for GC_malloc_ignore_off_page.  (Typically, you can probably ignore it for objects < 1MB in size.)  However, interior pointer recognition for pointers from the stack is still enabled, since disabling it would make the collector much more susceptible to clever compiler optimizations that eliminate the last bas reference.  Thus the issue doesn't go away completely.

I believe gcj currently always uses GC_malloc variants and never GC_malloc_ignore_off_page, and seems to get away with it.  I suspect nearly all other clients do the same, unless/until they start seeing warning messages from the collector.