Re: Compiling java without boehm-gc

[NightStrike <nightstrike at gmail dot com>]

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?