Using Java objects from C++

Mon May 3 20:44:00 GMT 2004

I think it's worth thinking carefully about this API.
- Presumably references to known Java objects fron the stack
will always be implicitly traced, even if they reside in C++ frames.
This is certainly true now. We had a prior discussion
about whether Java pointers stored in a "void *" on the stack
are guaranteed to be traced, i.e. whether you can safely call
qsort on an array of Java pointers. There were arguments both ways,
mostly depending on whether you want to preserve the possibility of
a nonconservative GC.
- Do you want to register a Java object, or do you want to
register the address of a pointer variable that might refer
to one? If the latter, do you want to do this explicitly,
or through the smart pointer mechanism that's planned anyway?
Given that we're not dealing with references from the stack,
I think the latter is more convenient, though less JNI compatible.
Is it possible to do the latter without making the
"smart pointer" mechanism much more heavyweight, by forcing it
to make a runtime decision about whether something is on the stack?
- Should there be a way to allocate traced and/or collectable
memory from C/C++ through libgcj interfaces? I think you can currently
call GC_malloc_uncollectable to get uncollectable but traced memory.
That yields an easy, though not very clean, way to register references.
Hans
> -----Original Message-----
> From: java-owner@gcc.gnu.org 
> [mailto:java-owner@gcc.gnu.org]On Behalf Of
> Dave Menendez
> Sent: Monday, May 03, 2004 12:50 PM
> To: Bryce McKinlay
> Cc: java@gcc.gnu.org
> Subject: Re: Using Java objects from C++
>>> On Mon, 2004年05月03日 at 15:03, Bryce McKinlay wrote:
> > Dave Menendez wrote:
> > 
> > >I do have one nagging problem, though, and although I've 
> searched this
> > >mailing list several ways, I can't seem to find a 
> definitive answer to
> > >this question: can I instantiate a Java object from (pure) C++ and
> > >somehow indicate to the JVM that I have retained a reference to it
> > >(i.e., I want to store a pointer to the Java object in a C 
> struct or as
> > >a C++ instance member, but I don't want the GC to get rid 
> of the object
> > >until I say I'm done with it)?
> > > 
> > >
> > 
> > A very good question. Currently we are lacking an API to register a 
> > reference from CNI. I think we need one. How about 
> something like the 
> > following?
> > 
> > JvNewGlobalRef(jobject)
> > JvDeleteGlobalRef(jobject)
>> > I'll go ahead and implement something like this if others 
> agree its a 
> > good idea.
> > 
>> I would be ecstatic if something like this were available. I know it
> places just a bit more burden on me, the programmer, to make 
> sure I call
> JvDeleteGlobalRef(jobject) when I'm done with it, but it's no more
> painful than having to remember to delete C++ objects or free 
> malloc'ed
> memory.
>> I'm not familiar with the release cycle of GCC. Would we have to wait
> for the next formal GCC release for this added functionality, or since
> we have the source code, could a patch be posted whenever this is
> ready? Just curious - I'm not trying to make demands of 
> anyone's time.
>> > >A co-worker suggested perhaps creating a very simple Java 
> object that
> > >simply stores references to other Java objects, and 
> instantiating one
> > >static, global instance of this object in C++. That would 
> mean if I
> > >wanted to keep a Java object around in C++, I'd just have 
> to add it to
> > >this static Java object, and then remove it when I'm done 
> with it. It's
> > >kludgy, but might it work?
> > > 
> > >
> > 
> > This will work, since static data areas currently are 
> scanned by the GC. 
> > We've talked about changing this behaviour, however, and requiring 
> > explicit registration of static roots, in order to improve 
> performance 
> > and the possibility of porting to different collectors. So 
> it might not 
> > be a good idea to rely on this behaviour for new CNI code.
> > 
>> I see. Is explicit registration of static roots something that is
> already available or something you would be planning to add in? I may
> just have to dig around the header files some more if it's already
> something I should be doing with the 3.4.0 GCC release.
>> > >P.S. One more thing, I was a bit mystified when I read in 
> the mailing
> > >list that even though I use "new" to allocate a Java 
> object from C++,
> > >I'm not supposed to call "delete" to get rid of it, but 
> that it somehow
> > >automagically gets collected by the GC. If someone could provide a
> > >brief description of how the GC decides what is eligible 
> for collection
> > >or point me to a document to help me understand the logic, 
> that would
> > >also be much appreciated.
> > > 
> > >
> > 
> > "new" is overloaded by java::lang::Object. So when you 
> allocate a Java 
> > object, "new" actually calls the GC allocator, not the 
> standard C++ one.
>> Maybe I need to read up on allocators in general - I 
> understand that the
> GC allocator gets used instead, but I wasn't sure how the GC detects
> that one particular object I instantiated from C++ is no longer in use
> if I didn't add it to some other Java object. Is it automatically
> "dereferenced" somehow when the block containing the variable 
> holding it
> ends?
>>>