[Java-gnome-developer] Java-Gnome: jni or cni

Boehm, Hans hans.boehm@hp.com
Mon Mar 15 14:58:00 GMT 2004

My impression is that you need some restrictions on CNI to really
make it usable with a fully type accurate collector.  But it's
unclear to me whether that matters.

If I understand the current CNI rules correctly, the intent is that
you should be able to store a reference to a Java object:

1+) anywhere (in a suitably typed field?) on the stack,
2+) In a suitably typed field of a Java object, or
3+) In a suitably typed static field of a Java or CNI class.

You may not store an object reference:

1-) In a statically allocated C++ variable (though that happens to
   work at present), or
2-) A heap allocated non-CNI C++ object.
3-) In a thread stack of an unattached thread.
4-) Directly by one thread onto another thread stack without passing
through the heap.(?)  (This is a tricky one, in that a few Java collectors
rely on this property of Java, which is not shared by C/C++.  It 
doesn't matter for the current gcj implementation.)

(I don't know anyplace where this is written down.  If it's correct,
it no doubt should be.)

But there are issues with (1+) and a fully type accurate
collector.  In particular:

a) What happens if you have a Java reference
in a C union?  You can't really know whether that location contains
a pointer or not.  (It's nearly impossible to have the compiler add tags
to C unions, since you can construct pointers to an individual field
of a union, and thus the compiler can't tell when a union field is
being updated.)

b) How does the collector get a consistent stack snapshot?  Do we 
know the stack layout at each instruction?  Are there "safe points"?
What about pointers to the interior of a Java object?

(A) pretty much implies that the collector needs to be at least very
mildly conservative, in that union fields have to be treated conservatively.
And a small amount of additional conservativism in the collector goes a
long way in addressing (B).

It's less cleat to me that requiring small amounts of conservativism
for native code would significantly impact other JVMs.  JNI already supports
Get...ArrayElements routines which benefit greatly from a collector that
can at least pin a small set of objects.  (I have no idea which VMs actually
do that.  The GetPrimitiveArrayCritical hack suggests that perhaps not all do.)

I know of no results about the performance impact of being able to pin a few
objects.  I suspect it's small.


> -----Original Message-----
> From: java-owner@gcc.gnu.org 
> [mailto:java-owner@gcc.gnu.org]On Behalf Of
> Tom Tromey
> Sent: Friday, March 12, 2004 1:04 PM
> To: Cedric Berger
> Cc: GCJ mailing list
> Subject: Re: [Java-gnome-developer] Java-Gnome: jni or cni
> >>>>> "Cedric" == Cedric Berger <cedric@berger.to> writes:
> [ followups trimmed ]
> >> How about asking Sun to support CNI then ?
> Cedric> Bleah
> Cedric> They technically cannot support it.
> Cedric> CNI doesn't work with precise copying collectors, AFAIK.
> CNI requires modifications to your C++ compiler to work.
> There's no technical reason that one couldn't modify a C++ compiler
> to also work with a precise copying collector while you're at it.
> That's not to say it might not be hard.  For GCC it looks basically
> unfeasible.  I suspect nobody will ever make the effort.
> Perhaps this is a distinction without a difference?  Sometimes I find
> it interesting to contemplate CNI's definition as separable from its
> current implementation.
> Tom

More information about the Java mailing list