Current Status

Jon Olson
Wed Feb 17 17:07:00 GMT 1999

On Wed, 17 Feb 1999, Per Bothner wrote:

>> 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.

Since a minority of Java objects are actually synchronized, a hash table
or sparse array might be better than wasting a pointer per object.  Really
depends on how many sync'd objects you have.

>> 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.

Yeah, I agree that compiled code quality goes way down if you need
to fetch an indirection pointer for every field access. The advantage it
gives you is more precise garbage collection (since you only ever have
references to a small object table) and the ability to use simpler more
predictable copying collectors.  Java is really a `new' hungry language that
stresses a collector. I've never really seen a working implementation of a
truly generational or incremental conservative GC.

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

I'm not convinced that this is the case.  It just changes gjavah and native
methods a bit.  For example:

	class Foo_fields : public FooSuper_fields
		// All the fields for a `Foo' object
	class Foo : public FooSuper
		Foo_fields *fields;	// this->fields can move during GC.
		// All the methods for a `Foo' object

All this does is split a Java class into two class heirarchies.  The actual
Java object contains only a `vtable' and a reference to its fields.
The `fields' objects mirror the inheritance of the Java objects, but
contain no methods, only fields.  Accessing a field from C++
would require using `fields->name' instead of just `name'.

Note that at this point I'm not actively advocating this.  It involves alot
of work and adversely impacts code quality.  I'm just considering the
fact that it doesn't have enormous impact on native methods and would
allow the use of copying collectors to eliminate memory fragmentation and
provide more precise and determinstic GC.

Jon Olson, Modular Mining Systems
	   3289 E. Hemisphere Loop
	   Tucson, AZ 85706
PHONE:     (520)746-9127
FAX:       (520)889-5790

More information about the Java mailing list