Re: [REVIVED: PATCH PR42811,4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[Dave Korn <dave.korn.cygwin@googlemail.com>]

On 15/02/2010 13:04, Bryce McKinlay wrote:
> On Fri, Feb 5, 2010 at 10:26 PM, Dave Korn wrote:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811

>>  In this PR, ecj1 is failing (on Cygwin, presumably MinGW as well) owing to
>> unintended fallout from building libgcj as two separate DLLs.
>>
>>  There are only static dependencies (i.e. unresolved symbols in the ecj.o
>> object) for ecjx to pull in the main libgcj at linktime, so only that DLL gets
>> loaded into memory at runtime.  But the class loader wants to load something
>> from the subsidiary (-noncore) DLL, and it's not present in memory, so it
>> fails.  (IIUC this is what the class definition data that is stored in .jcr
>> sections and made available to the class loader through a a .ctor-like
>> mechanism in the crtbegin code is all about.)
>>
>>  In this patch, I add an arbitrary undef to the link spec, against a fairly
>> randomly chosen symbol (my only criterion was that the org.ietf.jgss namespace
>> is probably fairly stable) from the -noncore part of the library.  This
>> sufficed to build an ecjx that links against and hence loads both DLLs, and it
>> doesn't throw the exception shown in the PR anymore.
> 
>> libjava/ChangeLog:
>>
>>        PR java/42811
>>        * configure.ac (libgcj_spec_lgcj_override): Add undefined reference
>>        to arbitrary symbol in noncore library.
> 
> Hi Dave

  Hi Bryce, thanks for getting back to me on this one.

> I'm not sure if this sounds like the right fix. Isn't it the point of
> libgcj-noncore that applications which only want "core" classes can
> link a smaller libgcj without having to distribute or load the
> "noncore" classes? Doesn't adding a dependency from libgcj to
> libgcj-noncore defeat this?

  Yes, it does defeat that, but no, it's not the point.  The real driving
motivation behind breaking the library up into two parts is that it's simply
too big and exceeds system limits when compiled as a monolithic shared library
on some systems; specifically, it has ~82000 exported functions, and a windows
DLL can export no more than 65535.

  It would certainly be a nice benefit if it was possible to load just one or
the other individually, but it's only a nice-to-have; the subdivision itself
is necessary simply for correctness on the affected targets.

> If ecj needs something from -noncore, shouldn't it be ecj that
> explicitly links it?

  Apologies in advance if I'm about to say something dumb, I'm no java
specialist, but AIUI ecj (and other java apps) don't have to explicitly link
against "things they need" in general, they call the class loader and it gets
them either from a jar file on disk or by instantiating one of the built-in
classes that were recorded in the .jcr section, right?  Any app will assume
that it can classload all of the standard library classes without having to do
anything special, and I want it so that the subdivided library transparently
behaves the same as the monoloithic one.

  So, nice though it might be, I just can't see any way of avoiding the
necessity to load both libraries all the time everywhere (in order that all
the .jcr sections get loaded and so all the expected classes are registered
with the classloader), and that's what the effect of this patch should be.


>>        * jvmti.cc (_Jv_GetJVMTIEnv): Fix use of uninitialised memory
>>        exposed by the above change.
> 
> This part is fine.

  Well: it appears to have caused a regression (investigating which is the
reason why I took a while to respond to you).  I'm now seeing:

> 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.  I was surprised to
discover that the test executable links its own entirely separate copy of the
GC library in addition to the one that's in the libjava DLL(s), is that
supposed to happen?

    cheers,
      DaveK