Using Java objects from C++

Tue May 4 14:57:00 GMT 2004

While you hash out the API for (de)registering references from CNI, I
thought I'd take a look at your suggestion for using
GC_malloc_uncollectable. It seems pretty easy, but let me double check
that I understand what I'd need to do.
Would I simply have a structure which could contain, among other things,
one or more Java pointers, and instead of using malloc, I would use
GC_malloc_uncollectable? Then I assume when I'm done with the struct, I
just call GC_free with the struct's address, and I don't have to do
anything specific with the Java pointers themselves (they'll get
collected later if no other references are found by the GC).
And a final question I have is how I get access to
GC_malloc_uncollectable and GC_free. I see they are macros in
boehm-gc/include/gc.h, but the boehm-gc header files were not installed
with the rest of GCC. Did I configure GCC incorrectly?
On Mon, 2004年05月03日 at 16:44, Boehm, Hans wrote:
> 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?
> > 
> > 
> >