Current Status

Wed Feb 17 14:25:00 GMT 1999

> 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