From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22944 invoked by alias); 26 Nov 2012 15:08:14 -0000 Received: (qmail 22932 invoked by uid 22791); 26 Nov 2012 15:08:12 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,TW_BJ,TW_GC,TW_IB,TW_WG X-Spam-Check-By: sourceware.org Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Nov 2012 15:08:01 +0000 Received: from dslb-088-073-118-008.pools.arcor-ip.net ([88.73.118.8] helo=[192.168.42.216]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1Td0Hv-0002x2-HE; Mon, 26 Nov 2012 15:07:59 +0000 Message-ID: <50B385C5.6010004@ubuntu.com> Date: Mon, 26 Nov 2012 15:08:00 -0000 From: Matthias Klose User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: GCJ-patches CC: Andrew Haley , NightStrike , Ivan Maidanski , Boehm GC , Kai Tietz Subject: Re: [Gc] Re: boehm-gc merge for GCC References: <1353097280.505328435@f161.mail.ru> <50A67667.7020600@ubuntu.com> <1353099257.140499471@f123.mail.ru> <50A6EE27.4000605@ubuntu.com> <50ABADE0.9000305@redhat.com> In-Reply-To: <50ABADE0.9000305@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2012-q4/txt/msg00040.txt.bz2 Am 20.11.2012 17:20, schrieb Andrew Haley: > On 11/17/2012 01:53 AM, Matthias Klose wrote: >> Would it be possible to create a branch in the GCC svn, and then prepare the >> merge, and libjava and libobjc changes there? > > Certainly. I had a look at the merge this weekend, but didn't get that far. It's an "interesting" merge after seven years. Basically I did get the 6.6 release (the last one imported into GCC), and current GCC and bdwgc trunks, tracked moved files, and tried a three way merge on the ones where a simple patch showed conflicts, and still had some hundred conflicts on about 20-30 files. The two-way diffs show only very few chunks, because with tab expansion in comments and code, and the removal of the pre ansi function decls, there's a lot for change. Is there any better way to do the merge? As an alternative, I removed everything in GCC, copied the bdwgc trunk and re-added the configury. Then verified that I could build a biarch compiler with --enable-objc-gc, and had a basic testcase running, plus the bdwgc tests succeeding. 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? - 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? - minor issue in boehm.cc: int _Jv_SetGCFreeSpaceDivisor (int div) { - return (int)GC_set_free_space_divisor ((GC_word)div); + GC_set_free_space_divisor ((GC_word)div); + return (int)GC_get_free_space_divisor (); } - minor issue in gnu/gcj/util/natGCInfo.cc: GC_GCJ_SUPPORT needs to defined before including dbg_mlc.h. - 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. - Plus renamed some bdwgc header files to what libjava expects. Changes in bdwgc included: - 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. - Renamed config.h.in to gc_config.h.in (could that be done upstream)? - bdwgc now has a tests subdir, however with test cases not in the same places as testsuite in GCC. How should that be dealt with? Test cases were upstream'd, however the dejagnu directives are missing. - bdwgc now has it's own ChangeLog file. Renamed the GCC one to ChangeLog.gcc. - 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? So a new library would need adding (bdwgc is prepared to add it in a subdir too). - Dropping of some arch specific files like mips_*. So maybe trunk did drop support for some archs, which the boehm-gc in GCC still supports. Didn't check that further. 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? Matthias