This is the mail archive of the
java-discuss@sourceware.cygnus.com
mailing list for the Java project.
Re: Array marking
- To: minyard at acm dot org, java-discuss at sourceware dot cygnus dot com, "Boehm, Hans" <hans_boehm at hp dot com>
- Subject: Re: Array marking
- From: Bryce McKinlay <bryce at albatross dot co dot nz>
- Date: Fri, 28 Apr 2000 16:16:22 +1200
- References: <3900EAAE.D9221332@albatross.co.nz> <m2ln1yx6eo.fsf@c469597-a.grlnd1.tx.home.com>
Corey Minyard wrote:
> You still have to mark the klass pointed to out of the vtable,
> otherwise the array class object will be collected (Bad Thing). I
> actually tried this (with a GC that I am working on) and it died
> horribly.
>
> Other than that, you are probably right. You could allocate the
> vtable for a conservative scan, but I don't think scanning the vtable
> is a good idea, probably more waste than gain.
Hmm, this raises a good point. The existing marking procedures in libgcj
know that we don't want to mark/scan the vtables themselves, but that we do
want to mark the Class object pointed to by the first word in the vtable.
Runtime-generated vtables are allocated as atomic (pointer-free) memory, so
they wont be scanned, but it seems to me that this will prevent the class
object being marked when using bitmap marking descriptors - definatly a bad
thing in the case of a runtime-allocated class.
However, I certainly havn't noticed my array class objects mysteriously
vanishing during collections, but I think I know why: in libgcj each class
object has a "next" field that forms a chain of all loaded classes. Marking
this field will mark all loaded classes, preventing class GC from occuring.
To avoid this, the mark descriptor generation code in the compiler will need
to special-case java.lang.Class so that this field does not get marked.
Hans, can you comment on these statements? :
- given that the first bit (ie the vtable pointer bit) of the mark
descriptors generated by the compiler is currently allways `1', the gc may
be trying to scan statically created vtables (?) - wasted cycles. This could
easily be changed to allways be `0', but in that case:
- the gc needs to know to mark the Class object pointed to by the first word
of the vtable.
> If the collector had a
> way to scan a big area of memory conservatively, it would probably be
> a pretty good way of handling this. I haven't check the Boehm
> collector, it might already have a way to do this. Mark the
> sync_info, mark the klass, then mark the big chunk of the array.
> That's what I did with my collector and it works well.
regards
[ bryce ]