From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19466 invoked by alias); 18 Feb 2010 22:06:56 -0000 Received: (qmail 19374 invoked by uid 22791); 18 Feb 2010 22:06:55 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from g1t0026.austin.hp.com (HELO g1t0026.austin.hp.com) (15.216.28.33) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Feb 2010 22:06:51 +0000 Received: from G6W0641.americas.hpqcorp.net (g6w0641.atlanta.hp.com [16.230.34.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0026.austin.hp.com (Postfix) with ESMTPS id 3AA45C59A; Thu, 18 Feb 2010 22:06:50 +0000 (UTC) Received: from G3W0055.americas.hpqcorp.net (16.232.1.152) by G6W0641.americas.hpqcorp.net (16.230.34.77) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 18 Feb 2010 22:05:59 +0000 Received: from GVW0436EXB.americas.hpqcorp.net ([16.234.32.153]) by G3W0055.americas.hpqcorp.net ([16.232.1.152]) with mapi; Thu, 18 Feb 2010 22:05:58 +0000 From: "Boehm, Hans" To: Dave Korn , GCC Java Date: Thu, 18 Feb 2010 22:06:00 -0000 Subject: RE: Two quick GC questions [was Re: [REVIVED: PATCH PR42811,4.5 regression] java.lang.ExceptionInInitializerError in ecj1] Message-ID: <238A96A773B3934685A7269CC8A8D0425784FAA73B@GVW0436EXB.americas.hpqcorp.net> References: <4B6C9B26.3010106@gmail.com> <4B6D0C67.5030500@gmail.com> <4B78BA6D.5000603@gmail.com> <7230133d1002150504r23738e28if92303426c349661@mail.gmail.com> <4B7CC61E.1050709@gmail.com> <4B7D631B.8030401@gmail.com> <4B7DA9FA.1020307@gmail.com> In-Reply-To: <4B7DA9FA.1020307@gmail.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2010-02/txt/msg00005.txt.bz2 =20 > -----Original Message----- > From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org]=20 > 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=20 > PR42811,4.5 regression] java.lang.ExceptionInInitializerError in ecj1] >=20 > On 18/02/2010 15:56, Dave Korn wrote: >=20 > >>> Running=20 > /gnu/gcc/gcc/libjava/testsuite/libjava.loader/loader.exp ... > >>> FAIL:=20 > >>>=20 > /gnu/gcc/obj-pr42811-3/i686-pc-cygwin/libjava/testsuite/TestEarlyGC. > >>> exe output -=20 > >>>=20 > /gnu/gcc/obj-pr42811-3/i686-pc-cygwin/libjava/testsuite/TestEarlyGC. > >>> exe > >> *sigh*, and it turns out to be because some memory is getting=20 > >> released by the garbage collector when its still in use. I'm busy=20 > >> trying to learn how the GC works real fast so I can figure=20 > out what's going wrong. >=20 > Well, it turns out to be fairly straightforward: there is=20 > no code to register the .data and .bss sections of the main=20 > executable as static data regions with the GC, so it has no=20 > idea there's a live pointer to an object(*) in there, and=20 > happily frees it up. >=20 > This leads me to two quick questions about the GC: >=20 > 1- There's no call to GC_INIT anywhere under libjava/, and I=20 > can't find anything in boehm.cc that even looks suitable for=20 > the purpose. Does anyone know how the main exe's data/bss=20 > 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 th= at 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 ot= her cases, GC_register_dynamic_libraries does it, and GC_register_main_stat= ic_data() returns false, avoiding the call the GC_register_data_segments. >=20 > 2- Libgcj statically links its own personal private copy of=20 > boehm-gc, rather than using a shared library; does anyone=20 > 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 conf= iguration. Hans >=20 > > I'm now very sure that the problem is a side-effect of the libgcj=20 > > DLL being rebased at runtime, and not related to the clearing of=20 > > memory in _Jv_GetJVMTIEnv (which isn't even called in this=20 > testcase). >=20 > This remains the case, btw. >=20 > cheers, > DaveK > -- > (*) - The object in question happens to be the jstring "C"=20 > passed as a name to defineClass, and next time through the=20 > loop it's been replaced by a hashmap object and defineClass=20 > throws when it finds it has the wrong object type as an argument. >=20 >=20