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

 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 
> 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: 
> >>> 
> /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?
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.

Hans
> 
> >   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.
> 
>