Garbage Collector freeing objects that are still in use

Wed Sep 3 13:38:00 GMT 2008

Hello,
I have a problem with the GCJ (4.3) Garbage Collector (boehm-gc): it
seems to free my Java objects even when they are still in use.
For some reason the GC seems to think these objects are no longer in
use and 'randomly' frees the objects. Obviously the rest of my code
doesn't like this :)
I must be doing something wrong, so let me describe my usage:
I have a (binary) 3rd party JAR library, that I compile - with some
glue - into my own shared library, which I then use from a C++
program. The glue also implements some system-dependent low-level
interfaces that the JAR exports (filesystem access, graphics, etc).
This all works quite well and as long as I don't use too much memory,
everything is fine. The trouble starts when the GC kicks in to free up
memory.
I have two types of cases in C++ code that uses Java objects:
Case 1: 'new' Java objects in C++ code:
a = new MyObj();
Where MyObj is a Java class defined in the JAR (and in the
gcjh-generated MyObj.h)
Variable a is the pointer used in the C++ code. This one gets 'magically' freed.
Case 2: 'new' Java objects inside JAR, API of JAR returns the pointer.
Item* new_item = instance->view->items->addItem();
if (new_item)
{
 // Add newly created item to our table.
 ItemKey key(new_item);
 instance->item_table.insert(std::make_pair(key, new_item));
 ...
}
Here, new_item gets freed (after some time, at a completely different
point in the code), even though I still have it inside the table and
still need it.
I have a feeling this may have to do with Java variables and C++
variables and the GC not being able to detect that a non-Java variable
has a reference to a Java object (or something like that).
Does that come close? Any ideas on how to solve this for my use-cases?
Any help is greatly appreciated. I'm working on ARM EABI by the way
(not that I think that matters much).
It will be hard for me to post a full example (since I'm not allowed
to publish the JAR), so that is why my code snippets are a bit
vague... I hope you get the idea though.
Regards,
Matthijs van de Water