RE: Java Object allocation from C++ and references?

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

Even in the heap allocated object case, I think the problem is currently avoidable
by either

(1) Letting the collector also manage the C++ objects, or

(2) Explicitly allocating and deallocating the C++ objects in the GC heap
(with GC_malloc_uncollectable() and GC_free()).

The GC distribution contains some headers (e.g. STL allocators) to facilitate this.
This assumes

- Gcj continues to use the current GC strategy, and

- You are willing to do some minor tweaking (either registering roots or changing
a flag) when gcj decides to stop scanning all statically allocated variables as
roots.  (Actually, this only applies to (1), not (2).)


Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org 
> [mailto:java-owner@gcc.gnu.org]On Behalf Of
> Andrew Haley
> Sent: Wednesday, February 04, 2004 6:23 AM
> To: Mohan Embar
> Cc: Ben Martin; java@gcc.gnu.org
> Subject: Re: Java Object allocation from C++ and references?
> 
> 
> Mohan Embar writes:
>  > Hi Andrew,
>  > 
>  > >Mixing C++ classes and gcj classes isn't impossible, but 
> I'd not say it was a
>  > >good idea.
>  > 
>  > My C++ helper classes _Jv_Win32TempString, WSAEventWrapper 
> (win32.h)
>  > and _Jv_TempUTFString (jvm.h), which rely on stack-based 
> destructors to
>  > free resources, have all come running to me with 
> frightened looks in their eyes
>  > asking me to ask you what you mean by this.... :)
> 
> Oh, don't worry.  I was just talking about the conflict between C++
> dynamic allocations schemes like reference counting and libgcj's
> garbage collection.  A problem occurs when a C++ struct that the gc
> doesn't know about includes a reference to a Java object that gets
> reclaimed.  Stack allocated structs won't be a problem, because we
> conservatively scan the stack.
> 
> Andrew.
>