Finalization and CNI

Thu Jun 12 15:49:00 GMT 2003

> That should work. Just be careful not to leave pointers to 
> Java objects 
> in the C++ heap, as while objects allocated there are not 
> eligible for 
> collection, they will be scanned for pointers by the collector.

Just to clarify: The garbage collector tries NOT to scan the C/C++ new/malloc
heap. On some platforms, notably win32, it tends to scan it anyway because
it's hard to distinguish the C/C++ heap from static data. But this is viewed
as a defect, and the collector is getting better at it. Thus:
1) You should never rely on pointers from the c/C++ heap to retain garbage-
collected memory. (You can currently use GC_malloc_uncollectable for that,
but I'm not sure there's a _Jv_ analog for it.)
2) As Bryce stated, you shouldn't rely on the opposite behavior either, since
it may introduce leaks. Once 6.2 is integrated, this may become less of an
issue, but we're lacking experience with it.
Hans
>> As an alternative, consider using GCJ's _Jv_AllocBytes: see 
> http://gcc.gnu.org/onlinedocs/gcc-3.3/gcj/Object-allocation.html
>> For example:
>> char *alloc = (char *)_Jv_AllocBytes(1024 * sizeof(char))
>> will give you a garbage-collected "alloc" whose contents is 
> not scanned 
> by the collector. You should only store "native" data in an object 
> allocated by this function - not reference to Java objects - or the 
> collector could end up freeing Java objects that are still reachable 
> from your CNI code.
>> Bryce.
>