[Gc] Merge with gcc?
aph at redhat.com
Thu Aug 13 09:10:18 PDT 2009
Ivan Maidanski wrote:
> Andrew Haley <aph at redhat.com> wrote:
>> Ivan Maidanski wrote:
>>> Andrew Haley <aph at redhat.com> wrote:
>>>> Ivan Maidanski wrote:
>>>>> Andrew Haley <aph at redhat.com> wrote:
>>>>>> Ivan Maidanski wrote:
>>>>>>> Andrew Haley <aph at redhat.com> wrote:
>>>>>>>> Is this a good time to merge the gc into gcc downstream?
>>>>>>>> People are asking for Win64 support.
>>>>> Could you explain (at least to me) the meaning of "merge the gc
>>>>> into gcc downstream"?
>>>> The version of gc in gcc is old; I want to update it from the
>>>> current gc tree.
>>> You can't update gcc/boehm-gc without fixing, at least, gcj boehm.cc
>>> (because GC API has changed and because gcc/boehm-gc has some
>>> private extensions over the gc it had been forked from (v6.6)).
>> OK. We really need to get those merged back from gcc to the boehm gc
>> tree. I can assure you that gcj does not want private extensions!
> Good. When why not detach gc from gcc (i.e. have libgc (of any
> supported version) as a prerequisite like libmpfr or libgmp)?
It's a possibility. I'm not sure it would help anyone very much,
> Anyway, as I see you need back-ported:
> - include "config.h" (for libgc building only, I guess) is not currently in CVS (pending in my diff116);
> - have GC_suspend/resume_thread() and GC_is_thread_suspended() for pthreads (it's interesting what Hans is thinking of these API entries).
Hmm. We already suspend and resume threads, so I'm not sure what that
would do for me.
> Required changes for gcj boehm.cc:
> - GC_register_my_thread(), GC_get_thread_stack_base() protos changed;
> - GC_finalize_all() should be invoked in a separate thread.
>>> You doubt this is a good time to start working on boehm.cc
>>> changes. What are the reasons?
>> Because I have no idea what state the boehm gc tree is in. For example,
>> I don't know if it is stable at the moment.
> I guess the tree is not stable (I even want Hans to move some rearly
> used .c files to an "extra" folder - he didn't mind (at least last
> year) but a bit busy with other patches). You may wait until GC v7.2
> final but without your efforts the things you need to back-port will
> not emerge in it. The API You need is stable (except for
> GC_finalize_all those semantics has been changed since last alpha
> I think most of GCC/GCJ users will NOT appreciate if you completely
> remove your current gcc/noehm-gc tree and fill it with an alpha
> release or a cvs snapshot.
Maybe not. But I see no reason not to put it into gcc trunk now, with
a view to updating it before gcc is released, as long as it's not
> But, I think, the "enthusiasts" (like mingw-w64 folks) should have a
> way to try out GCC with a standalone libgc (for this, you should
> have a retargetable boehm.cc and back-port the changes).
If I make the boehm.cc changes, surely that will be enough.
More information about the Gc