From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26402 invoked by alias); 26 Nov 2012 17:03:59 -0000 Received: (qmail 26390 invoked by uid 22791); 26 Nov 2012 17:03:56 -0000 X-SWARE-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_GC,TW_IB,TW_WG X-Spam-Check-By: sourceware.org Received: from mail-ie0-f175.google.com (HELO mail-ie0-f175.google.com) (209.85.223.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Nov 2012 17:03:38 +0000 Received: by mail-ie0-f175.google.com with SMTP id qd14so11567538ieb.20 for ; Mon, 26 Nov 2012 09:03:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.178.10 with SMTP id cu10mr12140686igc.17.1353949418259; Mon, 26 Nov 2012 09:03:38 -0800 (PST) Received: by 10.50.40.71 with HTTP; Mon, 26 Nov 2012 09:03:38 -0800 (PST) In-Reply-To: References: <1353097280.505328435@f161.mail.ru> <50A67667.7020600@ubuntu.com> <1353099257.140499471@f123.mail.ru> <50A6EE27.4000605@ubuntu.com> <50ABADE0.9000305@redhat.com> <50B385C5.6010004@ubuntu.com> Date: Mon, 26 Nov 2012 17:03:00 -0000 Message-ID: Subject: [Gc] Re: boehm-gc merge for GCC From: Bryce McKinlay To: GCC Java Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes 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: 2012-11/txt/msg00004.txt.bz2 2012 at 3:07 PM, Matthias Klose wrote: > I had a look at the merge this weekend, but didn't get that far. It's an > "interesting" merge after seven years. Hey Matthais, Thanks very much for working on this! If its any help, my experience from back in the day suggests that these merges always look much worse than they actually are. So don't get too discouraged :) > Then enabled java, and experimented until it did build. Some observations: > > - the suspend functions/patches (r114869, r124081) were never part > of upstream boehm-gc (GC_is_thread_suspended, GC_suspend_thread, > GC_resume_thread). This is what Ivan means with Th"ere is a problem > is thread suspend/resume - bdwgc does not have such API but OTOH > suspend/resume is deprecated part of Java threads". > However is libjava able to deprecate this? IIRC, we implemented these as part of debugging (JVMTI) support in libgcj. The deprecated Java-level Thread.suspend(), etc, functions have never been implemented in libgcj. I don't think libgcj's JVMTI ever fully worked anyway, so IMO although these would be "nice to have", they are not required. They could likely be re-implemented later without too much hassle if anyone wants to resurrect JVMTI. > - gc_local_alloc.h and the GC_LOCAL_*MALLOC* macros and associated > functions > are removed in bdwgc trunk. What kind of functions should be used > instead? I think this was just there to force thread-local allocation, and to make it possible to switch thread-local on and off. It looks like in the modern bdwgc, thread-local allocation is used by default if the collector is built with THREAD_LOCAL_ALLOC enabled. So presumably, this can be removed and the standard allocator functions used. > - Ivan writes about "some gcj files should be changed to reflect > the changes in bdwgc API (e.g., thread registration)". It did > still build, without changing anything further. libgcj doesn't do anything special here (afaik), except for foreign threads attached from outside libgcj via CNI/JNI. It just relies on threads being registered by the GC's pthread_create(), etc, intercepts. It doesn't look like much has changed here in bdwgc? > - configure.ac, Makefile.am, */*.am: build the convenience library, > and changed names to not install anything, added multilib bits. > Maybe the renaming of libgc.a to libgcjgc.a isn't needed anymore. Yeah, the name doesn't matter too much since it's only built as a convenience library. > - bdwgc now depends on another library (libatomic-ops). Shouldn't GCC > be able to use it's atomic builtins for some supported targets at > least? Yes, but it sounds like far more effort than its worth to go and change it just for the sake of using builtins. Maybe libatomic-ops itself could be made to use the builtins when available. > So if the merge looks that problematic, maybe restart with trunk, maybe > check it in as bdwgc, and have toplevel configury to decide which one to use > until the update is stable, and then just drop the boehm-gc directory? I'm not sure it's worth making it configure-time switchable. I'd just put it on a branch, make sure it's working on the major platforms, and then merge to trunk once the GCC tree goes back in to stage 1. Bryce