From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24555 invoked by alias); 18 Feb 2010 04:28:52 -0000 Received: (qmail 24534 invoked by uid 22791); 18 Feb 2010 04:28:51 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from ey-out-1920.google.com (HELO ey-out-1920.google.com) (74.125.78.150) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Feb 2010 04:28:46 +0000 Received: by ey-out-1920.google.com with SMTP id 26so1619348eyw.46 for ; Wed, 17 Feb 2010 20:28:44 -0800 (PST) Received: by 10.213.104.80 with SMTP id n16mr267558ebo.54.1266467324060; Wed, 17 Feb 2010 20:28:44 -0800 (PST) Received: from ?192.168.2.99? (cpc2-cmbg8-0-0-cust61.cmbg.cable.ntl.com [82.6.108.62]) by mx.google.com with ESMTPS id 28sm22913801eye.7.2010.02.17.20.28.40 (version=SSLv3 cipher=RC4-MD5); Wed, 17 Feb 2010 20:28:41 -0800 (PST) Message-ID: <4B7CC61E.1050709@gmail.com> Date: Thu, 18 Feb 2010 04:28:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Bryce McKinlay CC: Dave Korn , Java Patches , GCC Patches Subject: Re: [REVIVED: PATCH PR42811,4.5 regression] java.lang.ExceptionInInitializerError in ecj1 References: <4B6C9B26.3010106@gmail.com> <4B6D0C67.5030500@gmail.com> <4B78BA6D.5000603@gmail.com> <7230133d1002150504r23738e28if92303426c349661@mail.gmail.com> In-Reply-To: <7230133d1002150504r23738e28if92303426c349661@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org X-SW-Source: 2010-q1/txt/msg00037.txt.bz2 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