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

Tue Mar 16 12:52:00 GMT 2004

Boehm, Hans writes:
 > > -----Original Message-----
 > > From: Andrew Haley
 > > 
 > > 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.
 > I think it's important to pin down the definition here.
 > 
 > I don't think there's any way to avoid pointers to a java object
 > in a compiler-generated temporary. Thus those would need to be handled.
 > And theoretically, they could be
No great problem, I think. MEM rtxes in the compiler can be tagged
with attributes, and every MEM can inherit from its source. It's just
one boolean attribute, "Java reference".
 > But I think there is a crucial design choice about when it's
 > acceptable to pass a pointer to a Java object as a "void *"
 > parameter to some Java -unaware code. I think this is important in
 > that it affects the reusability of existing code in a Java
 > implementation.
 > 
 > Currently the (implementation-specific) answer is
 > 
 > "Almost always, so long as you do any null-pointer checks
 > explicitly, and the Java pointers aren't stored in malloc'ed data
 > structures." (And the latter restriction could be eliminated with
 > a suitable replacement malloc. And there should probably be an
 > option to do so.)
Okay, that's true. At the present time, that will work.
However, I don't believe that "don't keep a pointer to a Java object
in a void*" is so very much more of a restriction than "don't keep a
pointer to a Java object in a heap-allocated area of memory." In
practice it would make no difference whatsoever to existing CNI code.
 > If/when we switch to not scanning static roots by default, there
 > will be an added restriction that either the "legacy" code doesn't
 > save the pointer in a static location, or you turn on full static
 > root scanning. With smart pointers, presumably you will have to do
 > a bit of extra work, but you can still convert to a regular pointer
 > if you do the explicit null checks?
I don't know who you mean by "you" in this context. Can a user
convert a smart pointer to something like a void*, delete all live
references to the same object, and reasonably expect the object not to
be garbage collected?
As I see it, we're talking about something like this:
extern ref<java::lang::Object> myclass::foo;
...
 void *swizzle = (void *) myclass::foo;
 myclass::foo = NULL;
...
and still expect the object referenced by foo not to be collected?
 > I think if you change this to an answer of "never", we're back to something
 > that's perhaps closer to JNI than to the current CNI.
Oh, I don't know. CNI has notational and efficiency advantages over
JNI, and that won't change.
 > ...
 > > > 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 say that. (And my impression is that Microsoft's "Managed
 > C++" does take this approach.) But then you've also said that you
 > can't call arbitrary C++ code with a Java reference, even if you
 > recompile it. 
Well, no, you can't do that at the moment, because Java objects are
not laid out in memory the same way as C++ objects. So arbitrary C++
code can't do anything with a Java reference, even if you give it one.
Andrew.