Re: GCJ 3.4.3 and 3.3 classloading problem

[Bryce McKinlay <bmckinlay at gmail dot com>]

On Thu, Sep 10, 2009 at 4:52 AM, Craig Vanderborgh
<craigvanderborgh@gmail.com> wrote:

> Until you suggested that GC might be involved I did not really think
> about that possibility. ?Well, further testing reveals that it is.
> The crash happens not when GC is invoked generally, but the first time
> that GC is invoked AND the heap is expanded during GC. ?And this is
> absolutely consistent. ?Is this what "inappropriate collection" could
> look like? ?Is it possible that the classloaded objects are different
> in some (incorrect) way, such that objects or parts of objects might
> be getting garbage collected when they are still needed? ?Is this what
> you're suggesting?

When you say "Classloaded objects", are you loading interpreted
classes? Or classes loaded at runtime from DLLs?

java.lang.Class objects are a special case for the garbage collector.
They are marked via the custom mark function _Jv_MarkObj in boehm.cc.
If for some reason this mark function is not working or not being
called correctly, Compiled class objects in the base application would
likely work anyway because they are present in the application's
static data area which is conservatively scanned. On the other hand,
interpreted classes and code built with -findirect-classes are
allocated at runtime and depend on the mark function.

> If so, any suggestions on how I could constructively proceed from here?

It's hard to say without more information, but I'd look carefully at
which objects which are being prematurely collected. Look at where
they ought to be reachable from, and see if any obvious patterns
emerge. As David suggests, getting a heap dump and stack traces of the
crash would be invaluable.

Bryce