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

[Matthias Klose <doko@ubuntu.com>]

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