* [Gc] Re: boehm-gc merge for GCC [not found] ` <CALUNu-p3muXCwGV9sRSF550EvyM2=f0=mbEzDEhtf=BdhUJKMQ@mail.gmail.com> @ 2012-11-26 17:03 ` Bryce McKinlay 2012-11-26 17:50 ` Andrew Haley ` (2 more replies) 0 siblings, 3 replies; 5+ messages in thread From: Bryce McKinlay @ 2012-11-26 17:03 UTC (permalink / raw) To: GCC Java 2012 at 3:07 PM, Matthias Klose <doko@ubuntu.com> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Gc] Re: boehm-gc merge for GCC 2012-11-26 17:03 ` [Gc] Re: boehm-gc merge for GCC Bryce McKinlay @ 2012-11-26 17:50 ` Andrew Haley 2012-11-27 1:09 ` Boehm, Hans 2012-12-01 20:50 ` Matthias Klose 2 siblings, 0 replies; 5+ messages in thread From: Andrew Haley @ 2012-11-26 17:50 UTC (permalink / raw) To: Bryce McKinlay; +Cc: GCC Java On 11/26/2012 05:03 PM, Bryce McKinlay wrote: > 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. That sounds very sensible. Andrew. ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [Gc] Re: boehm-gc merge for GCC 2012-11-26 17:03 ` [Gc] Re: boehm-gc merge for GCC Bryce McKinlay 2012-11-26 17:50 ` Andrew Haley @ 2012-11-27 1:09 ` Boehm, Hans 2012-12-01 20:50 ` Matthias Klose 2 siblings, 0 replies; 5+ messages in thread From: Boehm, Hans @ 2012-11-27 1:09 UTC (permalink / raw) To: Bryce McKinlay, GCC Java; +Cc: Ivan Maidanski > > > - 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. > Libatomic_ops should eventually be configurable to just use C11/C++11 atomic operations. That hasn't happened yet, but should be fairly easy. Or, if we wait long enough, we could just use the C11 primitves directly. Historically libatomic-ops preceded and influenced the C11/C++11 interface, but the C11/C++11 interface is a much better design (another iteration, a lot more careful thought by many more people, etc.) Hans ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Gc] Re: boehm-gc merge for GCC 2012-11-26 17:03 ` [Gc] Re: boehm-gc merge for GCC Bryce McKinlay 2012-11-26 17:50 ` Andrew Haley 2012-11-27 1:09 ` Boehm, Hans @ 2012-12-01 20:50 ` Matthias Klose 2012-12-02 2:51 ` Matthias Klose 2 siblings, 1 reply; 5+ messages in thread From: Matthias Klose @ 2012-12-01 20:50 UTC (permalink / raw) To: Bryce McKinlay; +Cc: GCC Java Am 26.11.2012 18:03, schrieb Bryce McKinlay: > 2012 at 3:07 PM, Matthias Klose <doko@ubuntu.com> wrote: >> 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. ok. so I'll use - branches/boehm for the import of the bdwgc branch - branches/gcj/bdwgc-20121125-merge for the merge proposal I'll start with what I currently have, and probably leave the libjava build on the branch broken for some time. At least its stage1 material. Instead I'll give the classpath merge priority, still considering it worth having for the 4.8 release. Matthias ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Gc] Re: boehm-gc merge for GCC 2012-12-01 20:50 ` Matthias Klose @ 2012-12-02 2:51 ` Matthias Klose 0 siblings, 0 replies; 5+ messages in thread From: Matthias Klose @ 2012-12-02 2:51 UTC (permalink / raw) To: GCC Java; +Cc: Bryce McKinlay, Tom Tromey Am 01.12.2012 21:50, schrieb Matthias Klose: > Am 26.11.2012 18:03, schrieb Bryce McKinlay: >> 2012 at 3:07 PM, Matthias Klose <doko@ubuntu.com> wrote: > >>> 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. > > ok. so I'll use > > - branches/boehm for the import of the bdwgc branch > - branches/gcj/bdwgc-20121125-merge for the merge proposal > > I'll start with what I currently have, and probably leave the libjava build on > the branch broken for some time. At least its stage1 material. Instead I'll > give the classpath merge priority, still considering it worth having for the 4.8 > release. now committed all patches, which I think were ready for commit. an outstanding hack is Index: boehm.cc =================================================================== --- boehm.cc (Revision 194043) +++ boehm.cc (Arbeitskopie) @@ -53,9 +53,24 @@ #ifdef THREAD_LOCAL_ALLOC # define GC_REDIRECT_TO_LOCAL -# include <gc_local_alloc.h> +# if 0 +# include <gc_local_alloc.h> +# else +# if 0 +# define GC_MALLOC(s) GC_LOCAL_MALLOC(s) +# define GC_MALLOC_ATOMIC(s) GC_LOCAL_MALLOC_ATOMIC(s) +# ifdef GC_GCJ_SUPPORT +# undef GC_GCJ_MALLOC +# define GC_GCJ_MALLOC(s,d) GC_LOCAL_GCJ_MALLOC(s,d) +# endif +# endif +# endif #endif + int GC_is_thread_suspended (pthread_t); + void GC_suspend_thread (pthread_t); + void GC_resume_thread (pthread_t); + // From boehm's misc.c void GC_enable(); void GC_disable(); plus, there are a few more undefined references when built from the branch. Most likely some bits locally to GCC and not upstreamed: libtool: link: /home/packages/gcc/svn/build2/./gcc/gcj -B/home/packages/gcc/svn/build2/x86_64-linux-gnu/32/libjava/ -B/home/packages/gcc/svn/build2/x86_64-linux-gnu/32/libjava/ -B/home/packages/gcc/svn/build2/./gcc/ -B/home/packages/gcc/svn/install2/x86_64-linux-gnu/bin/ -B/home/packages/gcc/svn/install2/x86_64-linux-gnu/lib/ -isystem /home/packages/gcc/svn/install2/x86_64-linux-gnu/include -isystem /home/packages/gcc/svn/install2/x86_64-linux-gnu/sys-include -m32 -ffloat-store -fomit-frame-pointer -Usun -g -O2 -m32 -m32 -o .libs/gij -shared-libgcc -L/home/packages/gcc/svn/build2/x86_64-linux-gnu/32/libjava/.libs -L/home/packages/gcc/svn/build2/x86_64-linux-gnu/32/libjava ./.libs/libgij.so /home/packages/gcc/svn/build2/x86_64-linux-gnu/32/libjava/.libs/libgcj.so -lpthread -ldl -lrt -Wl,-rpath -Wl,/home/packages/gcc/svn/install2/lib/../lib32 -Wl,-rpath -Wl,/home/packages/gcc/svn/install2/lib/../lib32/gcj-4.8.0-14 /home/packages/gcc/svn/build2/x86_64-linux-gnu/32/libjava/.libs/libgcj.so: undefined reference to `GC_pthread_create' /home/packages/gcc/svn/build2/x86_64-linux-gnu/32/libjava/.libs/libgcj.so: undefined reference to `GC_gcj_malloc' /home/packages/gcc/svn/build2/x86_64-linux-gnu/32/libjava/.libs/libgcj.so: undefined reference to `GC_resume_thread' /home/packages/gcc/svn/build2/x86_64-linux-gnu/32/libjava/.libs/libgcj.so: undefined reference to `GC_pthread_sigmask' /home/packages/gcc/svn/build2/x86_64-linux-gnu/32/libjava/.libs/libgcj.so: undefined reference to `GC_gcj_debug_kind' /home/packages/gcc/svn/build2/x86_64-linux-gnu/32/libjava/.libs/libgcj.so: undefined reference to `GC_suspend_thread' /home/packages/gcc/svn/build2/x86_64-linux-gnu/32/libjava/.libs/libgcj.so: undefined reference to `GC_is_thread_suspended' /home/packages/gcc/svn/build2/x86_64-linux-gnu/32/libjava/.libs/libgcj.so: undefined reference to `GC_gcj_kind' /home/packages/gcc/svn/build2/x86_64-linux-gnu/32/libjava/.libs/libgcj.so: undefined reference to `GC_dlopen' /home/packages/gcc/svn/build2/x86_64-linux-gnu/32/libjava/.libs/libgcj.so: undefined reference to `GC_local_malloc_atomic' /home/packages/gcc/svn/build2/x86_64-linux-gnu/32/libjava/.libs/libgcj.so: undefined reference to `GC_local_gcj_malloc' /home/packages/gcc/svn/build2/x86_64-linux-gnu/32/libjava/.libs/libgcj.so: undefined reference to `GC_init_gcj_malloc' collect2: error: ld returned 1 exit status make[5]: *** [gij] Error 1 I'll leave the state of the branch as it is now, focusing on the classpath merge. please feel free to commit fixes to the merge branch including a mail to java-patches. Thanks, Matthias ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-12-02 2:51 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1353097280.505328435@f161.mail.ru> [not found] ` <50A67667.7020600@ubuntu.com> [not found] ` <CAF1jjLucRudE2a3gCZq6erkJKfs1nC+DicM+4f4moXJ5HPy9g@mail.gmail.com> [not found] ` <1353099257.140499471@f123.mail.ru> [not found] ` <CAF1jjLsA1nzLaJejMiAfzqZZ8btw37n0B3H7_qz-UrLvNQGqzA@mail.gmail.com> [not found] ` <50A6EE27.4000605@ubuntu.com> [not found] ` <50ABADE0.9000305@redhat.com> [not found] ` <50B385C5.6010004@ubuntu.com> [not found] ` <CALUNu-p3muXCwGV9sRSF550EvyM2=f0=mbEzDEhtf=BdhUJKMQ@mail.gmail.com> 2012-11-26 17:03 ` [Gc] Re: boehm-gc merge for GCC Bryce McKinlay 2012-11-26 17:50 ` Andrew Haley 2012-11-27 1:09 ` Boehm, Hans 2012-12-01 20:50 ` Matthias Klose 2012-12-02 2:51 ` Matthias Klose
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).