[Gc] Re: boehm-gc merge for GCC

[Bryce McKinlay <bmckinlay@gmail.com>]

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