[Gc] Re: boehm-gc merge for GCC

[Gc] Re: boehm-gc merge for GCC

[Bryce McKinlay]

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

Re: [Gc] Re: boehm-gc merge for GCC

[Andrew Haley]

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.

RE: [Gc] Re: boehm-gc merge for GCC

[Boehm, Hans]

> 
> > - 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

Re: [Gc] Re: boehm-gc merge for GCC

[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.

  Matthias

Re: [Gc] Re: boehm-gc merge for GCC

[Matthias Klose]

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