Compiling java without boehm-gc

[Dmitrijs Ledkovs]

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.  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.  I think he wanted x86_64-*-mingw*
> support, but no-one volunteered to do any of the work to get it into
> gcc.  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

> Andrew.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: git-status-after-merge.txt.gz
Type: application/x-gzip
Size: 2314 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-help/attachments/20100718/27dcad6a/attachment-0001.bin>