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

[Boehm, Hans]

[Comments are inserted into Andrews (abbreviated) message.]

> -----Original Message-----
> From: Andrew Haley [mailto:aph@redhat.com]
> Sent: Monday, March 15, 2004 10:38 AM
> To: Boehm, Hans
> Cc: 'tromey@redhat.com'; Cedric Berger; GCJ mailing list
> Subject: RE: [Java-gnome-developer] Java-Gnome: jni or cni
> 
> 
> Boehm, Hans writes:
>  > 
>  > 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".
It's certainly a solvable problem.  But the information needs to be
propagated through the register allocator etc., since we also care
about register contents and spill locations.  And if you want to
identify all pointers (e.g. for moving objects), you either need
to constrain optimizations or keep track of which base pointer a
derived pointer corresponds to. 
> 
>  > 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.
It prevents you from, for example, invoking qsort on the body of a
Java primitive array.  I agree that the restriction on Java pointers in the
C heap is equally unfortunate.  But it is currently possible to get around that
restriction, if you try hard enough.
> 
>  > 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?
Currently that's certainly fine.  Note that if this weren't fine
it's not clear that this would be OK without the NULL assignment either,
since the compiler may decide that myclass::foo is dead before you're
done with swizzle.

> 
>  > 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.
I agree that it will stil be easier in the easy cases, which constitute
the majority of cases.
> 
>  > ...
>  > >  > 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.
> 
If you can't convert a Java reference to a void *, I agree.  At the
moment I believe you can do that and pass it through legacy code that
doesn't try to interpret it.

Hans