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

[Andrew Haley <aph at redhat dot com>]

Boehm, Hans writes:
 > 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.

The fact that you can store an object reference anywhere on the stack
(even in an integer!) is surely an accident of the current
implementation, not a design requirement.  We should be able to switch
to a precise scan of the stack using unwinder data and CNI programs
shouldn't break.

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

I would say that you can't do that with CNI.

 > 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"?

We can certainly tag stack slots that contain object references if
needs be.

 > What about pointers to the interior of a Java object?

Oh yeah.  :-)

We could persuade the compiler to add stack annotations to help the
collector, but I'm not sure it's really worth all the bother.  We'd
have to keep track of every reference to a Java object in every stack
slot and make stack annotations for them.

But really this has nothing to do with the design of CNI at all: it's
to do with a particular implementation.

Andrew.