Java Object allocation from C++ and references?
Boehm, Hans
hans_boehm@hp.com
Wed Feb 4 18:41:00 GMT 2004
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.
>
More information about the Java
mailing list