GCC and boehm-gc

GCC and boehm-gc

[NightStrike]

Given the recent issues with libffi being so drastically out of synch
with upstream, I was curious about boehm-gc and how that is handled.
In getting gcj to work on Win64, the next step is boehm-gc now that
libffi works just fine.  However, the garbage collector is in terrible
shape and will need a bit of work.  Do we send those fixes here to
GCC, or to some other project?  Who handles it?  How is the synching
done compared to other external projects?

Re: GCC and boehm-gc

[David Daney]

NightStrike wrote:
> Given the recent issues with libffi being so drastically out of synch
> with upstream, I was curious about boehm-gc and how that is handled.
> In getting gcj to work on Win64, the next step is boehm-gc now that
> libffi works just fine.  However, the garbage collector is in terrible
> shape and will need a bit of work.  Do we send those fixes here to
> GCC, or to some other project?  Who handles it?  How is the synching
> done compared to other external projects?
> 

Your analysis of the situation is essentially correct.

Hans (now CCed) is good about merging changes to the upstream sources,
but we haven't updated GCC/libgcj's copy in quite some time.  A
properly motivated person would have to import a newer version of the
GC checking that all GCC local changes were either already merged, or
if not port them to the new GC (those that are not upstream should
then be evaluated to see if they should be).

David Daney

Re: GCC and boehm-gc

[NightStrike]

On Thu, Jun 18, 2009 at 12:27 PM, David Daney<ddaney@caviumnetworks.com> wrote:
> NightStrike wrote:
>>
>> Given the recent issues with libffi being so drastically out of synch
>> with upstream, I was curious about boehm-gc and how that is handled.
>> In getting gcj to work on Win64, the next step is boehm-gc now that
>> libffi works just fine.  However, the garbage collector is in terrible
>> shape and will need a bit of work.  Do we send those fixes here to
>> GCC, or to some other project?  Who handles it?  How is the synching
>> done compared to other external projects?
>>
>
> Your analysis of the situation is essentially correct.
>
> Hans (now CCed) is good about merging changes to the upstream sources,
> but we haven't updated GCC/libgcj's copy in quite some time.  A
> properly motivated person would have to import a newer version of the
> GC checking that all GCC local changes were either already merged, or
> if not port them to the new GC (those that are not upstream should
> then be evaluated to see if they should be).

So it seems that boehm-gc is in the exact state as libffi.

This is yet another example of why we shouldn't duplicate sources...

Hans, would you be willing to bring boehm-gc up to speed so that we
can start getting it to work for Win64?  Without this, we obviously
cannot add gcj to our list of supported compilers.

Re: GCC and boehm-gc

[Andrew Haley]

NightStrike wrote:
> On Thu, Jun 18, 2009 at 12:27 PM, David Daney<ddaney@caviumnetworks.com> wrote:
>> NightStrike wrote:
>>> Given the recent issues with libffi being so drastically out of synch
>>> with upstream, I was curious about boehm-gc and how that is handled.
>>> In getting gcj to work on Win64, the next step is boehm-gc now that
>>> libffi works just fine.  However, the garbage collector is in terrible
>>> shape and will need a bit of work.  Do we send those fixes here to
>>> GCC, or to some other project?  Who handles it?  How is the synching
>>> done compared to other external projects?
>>>
>> Your analysis of the situation is essentially correct.
>>
>> Hans (now CCed) is good about merging changes to the upstream sources,
>> but we haven't updated GCC/libgcj's copy in quite some time.  A
>> properly motivated person would have to import a newer version of the
>> GC checking that all GCC local changes were either already merged, or
>> if not port them to the new GC (those that are not upstream should
>> then be evaluated to see if they should be).
> 
> So it seems that boehm-gc is in the exact state as libffi.

No, it's not.  The problem with libffi is that it was updated in gcc and
upstream; that is much less of a problem with boehm-gc.

Andrew.

Re: GCC and boehm-gc

[David Daney]

Andrew Haley wrote:
> NightStrike wrote:
>> On Thu, Jun 18, 2009 at 12:27 PM, David Daney<ddaney@caviumnetworks.com> wrote:
>>> NightStrike wrote:
>>>> Given the recent issues with libffi being so drastically out of synch
>>>> with upstream, I was curious about boehm-gc and how that is handled.
>>>> In getting gcj to work on Win64, the next step is boehm-gc now that
>>>> libffi works just fine.  However, the garbage collector is in terrible
>>>> shape and will need a bit of work.  Do we send those fixes here to
>>>> GCC, or to some other project?  Who handles it?  How is the synching
>>>> done compared to other external projects?
>>>>
>>> Your analysis of the situation is essentially correct.
>>>
>>> Hans (now CCed) is good about merging changes to the upstream sources,
>>> but we haven't updated GCC/libgcj's copy in quite some time.  A
>>> properly motivated person would have to import a newer version of the
>>> GC checking that all GCC local changes were either already merged, or
>>> if not port them to the new GC (those that are not upstream should
>>> then be evaluated to see if they should be).
>> So it seems that boehm-gc is in the exact state as libffi.
> 
> No, it's not.  The problem with libffi is that it was updated in gcc and
> upstream; that is much less of a problem with boehm-gc.
> 

It may be less of a problem, but running svn log boehm-gc shows several 
non-configure changes since Bryce imported version 6.6 in r110222.

David Daney

Re: GCC and boehm-gc

[NightStrike]

On Thu, Jun 18, 2009 at 12:58 PM, Andrew Haley<aph@redhat.com> wrote:
> NightStrike wrote:
>> On Thu, Jun 18, 2009 at 12:27 PM, David Daney<ddaney@caviumnetworks.com> wrote:
>>> NightStrike wrote:
>>>> Given the recent issues with libffi being so drastically out of synch
>>>> with upstream, I was curious about boehm-gc and how that is handled.
>>>> In getting gcj to work on Win64, the next step is boehm-gc now that
>>>> libffi works just fine.  However, the garbage collector is in terrible
>>>> shape and will need a bit of work.  Do we send those fixes here to
>>>> GCC, or to some other project?  Who handles it?  How is the synching
>>>> done compared to other external projects?
>>>>
>>> Your analysis of the situation is essentially correct.
>>>
>>> Hans (now CCed) is good about merging changes to the upstream sources,
>>> but we haven't updated GCC/libgcj's copy in quite some time.  A
>>> properly motivated person would have to import a newer version of the
>>> GC checking that all GCC local changes were either already merged, or
>>> if not port them to the new GC (those that are not upstream should
>>> then be evaluated to see if they should be).
>>
>> So it seems that boehm-gc is in the exact state as libffi.
>
> No, it's not.  The problem with libffi is that it was updated in gcc and
> upstream; that is much less of a problem with boehm-gc.

That's what David just described -- that there are both GCC local
changes and upstream changes.

Regardless, someone with the knowledge and background needs to do this merge.

Re: GCC and boehm-gc

[David Daney]

NightStrike wrote:
> On Thu, Jun 18, 2009 at 12:58 PM, Andrew Haley<aph@redhat.com> wrote:
>> NightStrike wrote:
>>> On Thu, Jun 18, 2009 at 12:27 PM, David Daney<ddaney@caviumnetworks.com> wrote:
>>>> NightStrike wrote:
>>>>> Given the recent issues with libffi being so drastically out of synch
>>>>> with upstream, I was curious about boehm-gc and how that is handled.
>>>>> In getting gcj to work on Win64, the next step is boehm-gc now that
>>>>> libffi works just fine.  However, the garbage collector is in terrible
>>>>> shape and will need a bit of work.  Do we send those fixes here to
>>>>> GCC, or to some other project?  Who handles it?  How is the synching
>>>>> done compared to other external projects?
>>>>>
>>>> Your analysis of the situation is essentially correct.
>>>>
>>>> Hans (now CCed) is good about merging changes to the upstream sources,
>>>> but we haven't updated GCC/libgcj's copy in quite some time.  A
>>>> properly motivated person would have to import a newer version of the
>>>> GC checking that all GCC local changes were either already merged, or
>>>> if not port them to the new GC (those that are not upstream should
>>>> then be evaluated to see if they should be).
>>> So it seems that boehm-gc is in the exact state as libffi.
>> No, it's not.  The problem with libffi is that it was updated in gcc and
>> upstream; that is much less of a problem with boehm-gc.
> 
> That's what David just described -- that there are both GCC local
> changes and upstream changes.
> 
> Regardless, someone with the knowledge and background needs to do this merge.
> 

Or someone willing to acquire such knowledge and background by 
attempting to do the merge and presenting the results of their efforts 
for review.

David Daney

Re: GCC and boehm-gc

[Hans Boehm]

On Thu, 18 Jun 2009, NightStrike wrote:

>
> So it seems that boehm-gc is in the exact state as libffi.
>
> This is yet another example of why we shouldn't duplicate sources...
>
> Hans, would you be willing to bring boehm-gc up to speed so that we
> can start getting it to work for Win64?  Without this, we obviously
> cannot add gcj to our list of supported compilers.
>
I think win64 in the upstream sources is in reasonable shape.

I generally haven't been doing a great job in keeping up with patches to 
the upstream source, because I often just haven't had time.  But I think
I have mostly kept up with patches originating from gcc.  I'm not sure the
upstream sources are missing much.

What has been a problem is that while the 6.8 -> 7.0 changes cleaned
up the code substantially, and a lot of contributed patches since then
have done a lot more of that, that step also introduced a fair amount of
instability.  I think we're largely over that now.  But 7.1 is fairly old,
so the merge would either have to use the CVS trunk or wait for 7.2 (which
I'm trying to find time to get out real soon now).

On the positive side, 7.1+ also have a bunch of substantial functional
improvements.

One additional minor complication is that I have a bunch of changes that 
haven't yet made it into the upstream CVS repository, that provide initial 
support for the C++0x GC support API, but touch some of the core GC 
datastructures.  Maybe those should wait for a leter merge anyway?

Hans

Re: GCC and boehm-gc

[NightStrike]

On Thu, Jun 18, 2009 at 5:25 PM, Hans Boehm<Hans.Boehm@hp.com> wrote:
> What has been a problem is that while the 6.8 -> 7.0 changes cleaned
> up the code substantially, and a lot of contributed patches since then
> have done a lot more of that, that step also introduced a fair amount of
> instability.  I think we're largely over that now.  But 7.1 is fairly old,
> so the merge would either have to use the CVS trunk or wait for 7.2 (which
> I'm trying to find time to get out real soon now).

Can you bring gcc up to speed with cvs HEAD?

Re: GCC and boehm-gc

[Andrew Haley]

NightStrike wrote:
> Given the recent issues with libffi being so drastically out of synch
> with upstream, I was curious about boehm-gc and how that is handled.
> In getting gcj to work on Win64, the next step is boehm-gc now that
> libffi works just fine.  However, the garbage collector is in terrible
> shape and will need a bit of work.  Do we send those fixes here to
> GCC, or to some other project?  Who handles it?  How is the synching
> done compared to other external projects?

When people post patches I always send ask them to send to the
gc@napali.hpl.hp.com list.

Andrew.

Re: GCC and boehm-gc

[NightStrike]

On Thu, Jun 18, 2009 at 2:02 PM, Andrew Haley<aph@redhat.com> wrote:
> NightStrike wrote:
>> Given the recent issues with libffi being so drastically out of synch
>> with upstream, I was curious about boehm-gc and how that is handled.
>> In getting gcj to work on Win64, the next step is boehm-gc now that
>> libffi works just fine.  However, the garbage collector is in terrible
>> shape and will need a bit of work.  Do we send those fixes here to
>> GCC, or to some other project?  Who handles it?  How is the synching
>> done compared to other external projects?
>
> When people post patches I always send ask them to send to the
> gc@napali.hpl.hp.com list.

Does that mean that you work on this, too?  Can you handle getting
everything in the gcc trunk to a point at which we can start working?
I'd greatly appreciate it.

Re: GCC and boehm-gc

[Andrew Haley]

NightStrike wrote:
> On Thu, Jun 18, 2009 at 2:02 PM, Andrew Haley<aph@redhat.com> wrote:
>> NightStrike wrote:
>>> Given the recent issues with libffi being so drastically out of synch
>>> with upstream, I was curious about boehm-gc and how that is handled.
>>> In getting gcj to work on Win64, the next step is boehm-gc now that
>>> libffi works just fine.  However, the garbage collector is in terrible
>>> shape and will need a bit of work.  Do we send those fixes here to
>>> GCC, or to some other project?  Who handles it?  How is the synching
>>> done compared to other external projects?
>> When people post patches I always send ask them to send to the
>> gc@napali.hpl.hp.com list.
> 
> Does that mean that you work on this, too?  Can you handle getting
> everything in the gcc trunk to a point at which we can start working?

You'd be much better advised to make your changes upstream first.

Andrew.

Re: GCC and boehm-gc

[Michael Meissner]

On Thu, Jun 18, 2009 at 12:10:53PM -0400, NightStrike wrote:
> Given the recent issues with libffi being so drastically out of synch
> with upstream, I was curious about boehm-gc and how that is handled.
> In getting gcj to work on Win64, the next step is boehm-gc now that
> libffi works just fine.  However, the garbage collector is in terrible
> shape and will need a bit of work.  Do we send those fixes here to
> GCC, or to some other project?  Who handles it?  How is the synching
> done compared to other external projects?

I have the following patch that is waiting for approval.  I sent mail to the
list Tom Tromey mentioned in the followup, but I haven't seen a reply yet.
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01094.html

-- 
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meissner@linux.vnet.ibm.com