From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16592 invoked by alias); 19 Feb 2010 07:04:11 -0000 Received: (qmail 16584 invoked by uid 22791); 19 Feb 2010 07:04:09 -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 mail-ew0-f209.google.com (HELO mail-ew0-f209.google.com) (209.85.219.209) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Feb 2010 07:04:05 +0000 Received: by ewy1 with SMTP id 1so583193ewy.16 for ; Thu, 18 Feb 2010 23:04:02 -0800 (PST) Received: by 10.213.24.13 with SMTP id t13mr4991005ebb.46.1266563042773; Thu, 18 Feb 2010 23:04:02 -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 7sm10873337eyg.41.2010.02.18.23.04.00 (version=SSLv3 cipher=RC4-MD5); Thu, 18 Feb 2010 23:04:01 -0800 (PST) Message-ID: <4B7E3C07.6030806@gmail.com> Date: Fri, 19 Feb 2010 07:04:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Boehm, Hans" CC: Dave Korn , GCC Java Subject: Re: Two quick GC questions [was 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> <4B7CC61E.1050709@gmail.com> <4B7D631B.8030401@gmail.com> <4B7DA9FA.1020307@gmail.com> <238A96A773B3934685A7269CC8A8D0425784FAA73B@GVW0436EXB.americas.hpqcorp.net> In-Reply-To: <238A96A773B3934685A7269CC8A8D0425784FAA73B@GVW0436EXB.americas.hpqcorp.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00008.txt.bz2 On 18/02/2010 22:05, Boehm, Hans wrote: >> From: Dave Korn >> 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. >> 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. Thanks Hans, I think I've got it now. The cygwin target ends up using the generic GC_register_data_segments() implementation, which registers the minmax range of the data and bss segments. That did the job when cygwin was only able to use libjava statically linked and everything was ending up in one monolithic executable, but now we can build a shared libjava it only registers the static data areas in the libgcj DLL, naturally. There's no definition for GC_register_dynamic_libraries at all, either, it uses the empty definition that defines GC_no_dynamic_loading. I could either adapt the "parse /proc/self/maps file" strategy, or try making the win32 stuff work; either way, it'll have to take care of registering the main exe's data sections - which I guess is how things probably end up working on *nix hosts too, when they parse the maps file. >> 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. Ah. Well, when I'm building libjava as two separate sublibraries, I now have the problem that each gets its own separate copy of the GC; that's obviously liable to be disastrous. One solution would be to build a single shared GC library for them both to reference, but I don't know what I'd have to do to get the runtime config correct. Another alternative would be to export the GC functions from the main libgcj dll, for the benefit of the libgcj-noncore dll. That's a little ugly because we don't really want to expose those APIs to the user, but they shouldn't be linking anything against them anyway, so we could just call it a private interface between the two dlls and not worry about breaking binary compatibility (or even removing altogether it in favour of an external shared lib gc) in future. This would probably be a safer change this close to the release of 4.5.0, so unless any of the java maintainers have a fundamental objection or can see a serious flaw in the suggestion, I'll go ahead and prepare a patch that resolves the clash that way. cheers, DaveK