RE: FYI: Linker & Verifier fixes (really GC mark procedures)

["Boehm, Hans" <hans dot boehm at hp dot com>]

> This is slightly off topic, but could you put the bitmap 
> descriptor as 
> the last field in the Class object?  Then make a variable length bit 
> string with the high (or perhaps low) order bit indicating if 
> there was 
> another segment of bit string following?
> 
> One word of bit string would mark the first 31 (or 63) 
> fields, then if 
> the high bit were set there would be another word for the next 31 (or 
> 63) fields...
> 
Theoretically it could.  But it doesn't match well with the way the GC
does things.  And I also don't think it would be a measurable win.

The GC understands descriptor words associated with an entire page of
objects.  That word may be a descriptor that tells the GC to look in the
object itself for the real descriptor, or to indirect twice through a
"vtable pointer" to find it.  This is all reasonably clean so long as
all descriptors fit in a word.  (Actually it's unclean in one very
subtle respect, which might get even more complicated with
variable-length descriptors.  The issue has to do with false pointers to
objects with garbage descriptors.)

The reason for doing all of this, instead of just calling mark
procedures from the collector, is largely to avoid a procedure call (and
associated startup costs dealing with got-tables, etc.) for every marked
object.  The only place it fails is for objects that are longer than 30
or 62 words long and don't qualify for a length descriptor.  But those
generally require enough work to trace that the procedure call is likely
to be in the noise anyway.

So long as we get the mark procedure(s) to behave correctly, I think
we're fine.  Class objects aren't likely to make up a large fraction of
the heap anyway, I hope.

Hans