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

Andrew Haley aph@redhat.com
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.


More information about the Java mailing list