Current Status

[Per Bothner]

> Lately, I've been contemplating how difficult it would be to add a level
> of indirection to objects such that object references were fixed handles
> to an object table to better support more precise copying collectors.  Would
> be cool to provide this as a compile time option to both `gcj' and `gjavah'. 
> The idea would be that Java objects would exist as two separate
> objects.  The first object would be a two word object containing a vtable
> and a pointer to the object field data.  This object would be fixed in size
> and location for the life of the object.  The second object would be variable
> in size and movable to support memory compaction.

This is an old idea.  Both the original Smalltalk *and* the original
Java (JDK 1.0) did this.  I don't know what Sun currently does.

> In reality, this wouldn't
> add any to the storage requirements, because all Java objects currently
> contain a `vtable' and `sync_info' in their object header.

But you still need the sync_info somewhere.

> The main trick
> is making `gcj' and `g++' recognize the volatility of the reference to the
> field data and never cache it.  Similarly, the object mobility would give
> preemptive multi-threading fits since it could only preempt at known safe
> points.  Oh well, for now it's just an idea....

The other downside is that you always get an extra level of indirection.
One extra memory reference can really hurt.

Plus you kill Java/C++ compatibility, which libjava depends on.

There are actually some vestiges in jc1 of an attempt to support
this model (look for "handle" and "HANDLE").  I don't see any
real benefits to this idea, except perhaps in very unusual situations.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner