Re: Array marking

[Tom Tromey <tromey at cygnus dot com>]

Bryce> Runtime-generated vtables are allocated as atomic
Bryce> (pointer-free) memory, so they wont be scanned, but it seems to
Bryce> me that this will prevent the class object being marked when
Bryce> using bitmap marking descriptors - definatly a bad thing in the
Bryce> case of a runtime-allocated class.

One thing we need is a nicer interface to the GC.  Ideally it would
let us set up an easy way to tell the GC how to mark random objects we
might need to create in the runtime.

Ideally this interface would be easy to port to other GCs.  Supporting
pluggable GC is still a (long term) goal.

Bryce> However, I certainly havn't noticed my array class objects
Bryce> mysteriously vanishing during collections, but I think I know
Bryce> why: in libgcj each class object has a "next" field that forms
Bryce> a chain of all loaded classes. Marking this field will mark all
Bryce> loaded classes, preventing class GC from occuring.

Good point.  We don't mark this slot with the mark procedure, but then
we don't need to.

Bryce> To avoid this, the mark descriptor generation code in the
Bryce> compiler will need to special-case java.lang.Class so that this
Bryce> field does not get marked.

I think we just need to change the compiler and the runtime to
indicate that "RawData" fields should not be marked.  Then we can
change the compiler to think that the "next" field is a RawData.

Bryce> - given that the first bit (ie the vtable pointer bit) of the
Bryce> mark descriptors generated by the compiler is currently allways
Bryce> `1', the gc may be trying to scan statically created vtables
Bryce> (?) - wasted cycles. This could easily be changed to allways be
Bryce> `0', but in that case:
Bryce> - the gc needs to know to mark the Class object pointed to by
Bryce> the first word of the vtable.

Isn't it the case that we only have to scan the Class if it is
dynamically allocated?  That is, we know that the Class object for a
compiler-compiled class will not point to dynamically allocated
memory.

I think this is true, but I'm not positive.

Tom