Re: Compiling java without boehm-gc

[Andrew Haley <aph at redhat dot com>]

On 09/03/2010 02:38 AM, NightStrike wrote:
> On Sat, Jul 17, 2010 at 9:30 PM, Dmitrijs Ledkovs
> <dmitrij.ledkov@ubuntu.com> wrote:
>> On 17 July 2010 18:44, Andrew Haley <aph@redhat.com> wrote:
>>> On 07/16/2010 09:54 PM, Dmitrijs Ledkovs wrote:
>>>> On 16 July 2010 21:44, David Daney <ddaney@caviumnetworks.com> wrote:
>>>>> On 07/16/2010 12:58 PM, Dmitrijs Ledkovs wrote:
>>>>>>
>>>>>> Is it supported to build java without gc?
>>>>>
>>>>> I don't think so. &nbsp;Even if it were, it wouldn't be very useful.
>>>>>
>>>>> Probably a better use of time would be to fix whatever problem is keeping
>>>>> the GC from working for you.
>>>>
>>>> Thanks for the heads up.
>>>>
>>>> This boils down to boehm-gc being not upto-date with boehm CVS.
>>>>
>>>> The last try from nightstrike to try to get someone to merge a newer
>>>> one stalled in 2006.
>>>
>>> 2009, actually: exactly a year ago. &nbsp;I think he wanted x86_64-*-mingw*
>>> support, but no-one volunteered to do any of the work to get it into
>>> gcc. &nbsp;We could try to get the process re-started.
>>>
>>> Is there a platform that you are using that isn't supported by the
>>> version of the GC in gcc sources?
>>>
>>
>> x86_64-*-mingw* =)))))
>>
>> Right here is what i did:
>>
>> 1) import all available boehm tarballs into git
>> 2) import boehm cvs into git
>> 3) take gcc-git import and filter-branch boehm-gc dir
>> 4) using graft points made "import boehm-gc 6.6" of the gcc branch to
>> have only one parent which is boehm-gc 6.6 tarball import
>> 5) using graft points made cvs initial commit to have parent boehm gc
>> 7.0alpha5 tarball import
>>
>> At this point I have 3 branches with common history =)))))
>>
>> next I took gcc & cvs branches and smashed them together =)))) hoping
>> git will manage.
>>
>> Now ignoring:
>>
>> 1) All new upstream files, and auto-resolved paths
>> 2) Configury changes (for now)
>> 3) Docs & readme
>>
>> The unmerged bit is not that large:
>>
>> # Unmerged paths:
>> #   (use "git add/rm <file>..." as appropriate to mark resolution)
>> #
>> #       both modified:      darwin_stop_world.c
>> #       both modified:      dbg_mlc.c
>> #       both modified:      dyn_load.c
>> #       both modified:      finalize.c
>> #       both modified:      gcj_mlc.c
>> #       both modified:      include/gc.h
>> #       both modified:      include/gc_config_macros.h
>> #       both modified:      include/private/gc_locks.h
>> #       both modified:      include/private/gc_pmark.h
>> #       both modified:      include/private/gc_priv.h
>> #       both modified:      include/private/gcconfig.h
>> #       both modified:      include/private/pthread_support.h
>> #       both modified:      mark_rts.c
>> #       both modified:      misc.c
>> #       both modified:      os_dep.c
>> #       deleted by them:    powerpc_darwin_mach_dep.s
>> #       both modified:      pthread_stop_world.c
>> #       both modified:      pthread_support.c
>> #       both modified:      ptr_chck.c
>> #       both modified:      win32_threads.c
>> #
>>
>> Now the idea is to fetch the offending commits put them up in an
>> instance of rietveld code review and start analysing them one by one
>> by studying code, pinging commiters, searching mailing lists.
>>
>> And / or possibly doing this distributed via sharing of git's rerere
>> files =))))) it doesn't look that much work to get gcc up to speed
>> with boehm cvs trunk =))))))
>>
>> ps. full git status during merge conflict is attached.
>> ps. tar of the working directory with confict and the git repo is
>> available here:
>>         people.ubuntu.com/~dmitrij.ledkov/boehm-merge.tar.xz
> 
> This thread died, much like my aforementioned previous attempts.
> 
> Did anyone update the in-tree boehm-gc?  Andrew, can you help with
> this task if not?

Sure.  But you need to send the patch against gcc trunk to gcc-patches.

Andrew.