class gc

Godmar Back
Fri Feb 26 18:21:00 GMT 1999

> On Fri, 26 Feb 1999, Godmar Back wrote:
> >I don't see how any of these suggestions would work.
> >The problem is not walking the class objects, the problem is marking
> >class objects when following references.  These references may or may not 
> >refer to objects that were allocated on the heap.  In most cases, they're not,
> >and if you can help it, you don't want to check every time, or at least
> >make the check as cheap as possible (cheaper than what Boehm's or Kaffe's
> >gc does to find out whether an address points to an object in the heap.)
> >
> If you know that a reference indeed points to a class object, and all class
> objects have the same format (ie. that layed out by the gcj compiler).  Just
> add a bit to the `accflags' to indicate that a particular class is dynamically
> allocated.  This bit would be zero for statically allocated classes generated
> by the compiler, but non-zero for dynamically generated classes, like
> [Ljava/lang/Object; allocated by the run-time environment.

I'm not sure how adding a flag to the class would help since I do not
know whether a given reference actually points to a java.lang.Class object.
I only know it for variables of type Class, and for elements in java.lang.Class
arrays.   I do not know it for variables of type Object or for elements
in java.lang.Object arrays.

Consider walking an object that is laid out like this:
	class A {
	    Object o;
A.o may point to a java.lang.Class object or it may not.  If it does,
the class object may be dynamic or not.  If the latter information were
stored in the java.lang.Class field, I would have to first check whether
A.o is an instance of java.lang.Class, and then cast to a java.lang.Class
object, check the accflags you're proposing and proceed accordingly.

In this case, I'm probably better off using the gc's check to determine
whether A.o is on the heap or not.

Now what would work is to put a flag in every gcable object that would
say whether the object is dynamically allocated or not.
(This is essentially my earlier proposal of faking a gc header before
a statically allocated object.)

> In the case of a word which may or may not be a pointer (ie. one which is
> being conservatively scanned), you'll need to do the typical conservative
> heap checks anyway.

True.  But minimizing the frequency of this check brings a huge performance 
improvement, as I witnessed when I implemented precise heap walking for Kaffe.

	- Godmar

More information about the Java mailing list