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

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

[Matthias Klose]

[CCing java-patches and Andrew too]

I'm currently striving for something for the 4.8 release. Not sure if relying on
an external library is the right thing to do for the 4.8 release.

Currently boehm-gc is linked to libgcj as a convenience library. I remember that
trying to link boehm-gc as a shared library did cause some performance
regressions (although I think I did only check this in the early 4.x times).

Please could you elaborate on the API changes in gcj?

There is also a second user of boehm-gc in GCC, when you configure with
--enable-objc-gc. I didn't check yet which changes are needed for that.

Would it be possible to create a branch in the GCC svn, and then prepare the
merge, and libjava and libobjc changes there?

  Matthias

Am 16.11.2012 22:14, schrieb NightStrike:
> I think changing the gc to be like gmp/mpfr/mpc requires buy-in from
> Andrew Haley, if I'm not mistaken.
> 
> Kai, is my statement correct?
> 
> On Fri, Nov 16, 2012 at 3:54 PM, Ivan Maidanski <ivmai@mail.ru> wrote:
>> Hi NightStrike,
>>
>> In my understanding, I've done bdwgc ready for gcj but some gcj files should
>> be changed to reflect the changes in bdwgc API (e.g., thread registration).
>> There is a problem is thread suspend/resume - bdwgc does not have such API
>> but OTOH suspend/resume is deprecated part of Java threads. Regarding
>> integration bdwgc into gcj, I think it's better to have bdwgc as a separate
>> module (similar to libmpfr).
>>
>> I have an intention to do the work but this requires significant efforts to
>> make it perfect,  so I gave up due to lack of time.
>>
>> Any volunteers?
>>
>> Regards,
>> Ivan
>>
>> 16 11 2012 15:28:34 from NightStrike <nightstrike@gmail.com>:
>>
>> Are there any plans to get current boehm-gc into gcc? Ivan, can you do this?
>>
>> On Fri, Nov 16, 2012 at 3:21 PM, Ivan Maidanski <ivmai@mail.ru> wrote:
>>> Hi Matthias,
>>>
>>> I think yes, all patches (may be with some modifications) from Kai are in
>>> master.
>>> I myself also reviewed difference between gcc/boehm-gc
>>> (https://github.com/ivmai/bdwgc/tree/gcc_boehmgc) and gc6.8.
>>>
>>> Regards,
>>> Ivan
>>>
>>> 16 11 2012 18:22:47 Matthias Klose <doko@ubuntu.com>:
>>>
>>> Hi Ivan,
>>>
>>> in
>>>
>>> http://old.nabble.com/RFC%3A-Updating-boehm-gc-to-verion-7.2-(alpha-5)-td31293737.html
>>>
>>> Kai said that he did some patches upstream / to you about changes
>>> collected
>>> in
>>> the GCC copy of boehm-gc. Are these integrated in your branch/trunk, or
>>> could
>>> you forward these to me? I didn't get any feedback from Kai this week,
>>> therefor
>>> asking you directly.
>>>
>>> Thanks, Matthias

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

[NightStrike]

On Fri, Nov 16, 2012 at 3:53 PM, Matthias Klose <doko@ubuntu.com> wrote:
> Would it be possible to create a branch in the GCC svn, and then prepare the
> merge, and libjava and libobjc changes there?

Making a branch and working in it should be trivial.  If I understand
the GCC commit rules correctly, anyone with commit privs can do it,
followed by an email to the gcc list explaining the purpose of the
branch.

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

[Andrew Haley]

On 11/17/2012 01:53 AM, Matthias Klose wrote:
> [CCing java-patches and Andrew too]
> 
> I'm currently striving for something for the 4.8 release. Not sure if relying on
> an external library is the right thing to do for the 4.8 release.

Probably not.

> Currently boehm-gc is linked to libgcj as a convenience library. I remember that
> trying to link boehm-gc as a shared library did cause some performance
> regressions (although I think I did only check this in the early 4.x times).
> 
> Please could you elaborate on the API changes in gcj?
> 
> There is also a second user of boehm-gc in GCC, when you configure with
> --enable-objc-gc. I didn't check yet which changes are needed for that.
> 
> Would it be possible to create a branch in the GCC svn, and then prepare the
> merge, and libjava and libobjc changes there?

Certainly.

Andrew.

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

[Matthias Klose]

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