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