Two quick GC questions [was Re: [REVIVED: PATCH PR42811,4.5 regression] java.lang.ExceptionInInitializerError in ecj1]

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

On 18/02/2010 15:56, Dave Korn wrote:

>>> Running /gnu/gcc/gcc/libjava/testsuite/libjava.loader/loader.exp ...
>>> FAIL: /gnu/gcc/obj-pr42811-3/i686-pc-cygwin/libjava/testsuite/TestEarlyGC.exe output - /gnu/gcc/obj-pr42811-3/i686-pc-cygwin/libjava/testsuite/TestEarlyGC.exe
>> *sigh*, and it turns out to be because some memory is getting released by the
>> garbage collector when its still in use.  I'm busy trying to learn how the GC
>> works real fast so I can figure out what's going wrong.

  Well, it turns out to be fairly straightforward: there is no code to
register the .data and .bss sections of the main executable as static data
regions with the GC, so it has no idea there's a live pointer to an object(*)
in there, and happily frees it up.

  This leads me to two quick questions about the GC:

1- There's no call to GC_INIT anywhere under libjava/, and I can't find
anything in boehm.cc that even looks suitable for the purpose.  Does anyone
know how the main exe's data/bss sections are supposed to get registered on a
posixy system?

2- Libgcj statically links its own personal private copy of boehm-gc, rather
than using a shared library; does anyone know why it was designed this way?

>   I'm now very sure that the problem is a side-effect of the libgcj DLL being
> rebased at runtime, and not related to the clearing of memory in
> _Jv_GetJVMTIEnv (which isn't even called in this testcase).

  This remains the case, btw.

    cheers,
      DaveK
-- 
(*) - The object in question happens to be the jstring "C" passed as a name to
defineClass, and next time through the loop it's been replaced by a hashmap
object and defineClass throws when it finds it has the wrong object type as an
argument.