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

[Bryce McKinlay]

On Thu, Feb 18, 2010 at 8:58 PM, Dave Korn
<dave.korn.cygwin@googlemail.com> wrote:
> 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?

GC_init_gcj_malloc() is called from boehm.cc:_Jv_InitGC(), and that in
turn calls GC_init() if required.

> 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?

Early on, the GC actually was in its own shared library (as was
libffi). The main reason to put these into libgcj was that it avoids
weird, hard-to-debug problems if you accidentally end up with the
wrong version of one library or the other. That's probably not such a
big deal now, but (windows limitations aside) I think its generally
better to have less shared libraries rather than more.

In theory, there could also be a performance advantage to having a
single library because a smart linker / linker script could optimize
internal calls to things like GC_malloc, speeding up the allocation
path by avoiding PLT indirection.

Bryce