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

["Boehm, Hans" <hans dot boehm at hp dot com>]

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

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

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

...
>  > 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.  It's not clear to me
that a native code interface that can't be used to call arbitrary native code
is that useful.  (More realistically, you would end up adding a layer that converted
Java pointers to handles, which could be passed to arbitrary native code.  I
suspect the result would look a lot like JNI for the hard cases, though you
can still take shortcuts in many common cases.)

Hans