Two quick GC questions [was Re: [REVIVED: PATCH PR42811,4.5 regression] java.lang.ExceptionInInitializerError in ecj1]
Thu Feb 18 22:06:00 GMT 2010
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com]
> On Behalf Of Dave Korn
> Sent: Thursday, February 18, 2010 12:59 PM
> To: GCC Java
> Cc: Dave Korn
> Subject: Two quick GC questions [was Re: [REVIVED: PATCH
> PR42811,4.5 regression] java.lang.ExceptionInInitializerError in ecj1]
> On 18/02/2010 15:56, Dave Korn wrote:
> >>> Running
> /gnu/gcc/gcc/libjava/testsuite/libjava.loader/loader.exp ...
> >>> FAIL:
> >>> exe output -
> >>> 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?
The GC normally does that internally, whether or not GC_INIT is called. GC_init_inner() does not need to get called, but the collector tries to do that automatically when it can, though IIRC gcj should call GC_init()directly, possibly not through the GC_INIT() macro.
In the simplest case, GC_init_inner calls GC_register_data_segments. In other cases, GC_register_dynamic_libraries does it, and GC_register_main_static_data() returns false,
avoiding the call the GC_register_data_segments.
> 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?
Way back when, it needed a custon GC configuration. But those options have generally become runtime configurable, so I suspect that's no longer true, though it may need to make some initialization calls to get the right configuration.
> > 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
> This remains the case, btw.
> (*) - 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.
More information about the Java