[Gc] Extend win32 static root handling to Cygwin targets.
hans.boehm at hp.com
Fri Mar 19 15:31:22 PST 2010
Many thanks for the patch. I suspect that this has been causing a variety of problems for a while. I unfortunately don't know how to get around the libtool issue. (But I'm hoping that by highlighting it again somebody else will speak up.)
Thank you for checking this in. It looks like the current patch installs the test library? That's not good. But I think it's no reason not to at least check in the test programs themselves. We should probably hold off on the tests.am changes until we figure out how to solve this problem.
> From: Ivan Maidanski
> Fri, 19 Mar 2010 15:34:43 +0000 письмо от Dave Korn
> <dave.korn.cygwin at googlemail.com>:
> > Hi Hans and list,
> > Hans, you may remember giving me some help with GCC
> PR42811 on the
> > libjava list a month or so ago. This patch follows on from that
> > investigation; Andrew Haley asked me to run the GC changes past you
> > when he reviewed it, so I've up-ported it to your current CVS HEAD.
> Looks good (and works).
> I've checked in your patch (cygwin-mem-registration.diff)
> slightly modified (to suppress warnings).
> Hans -
> should I add the suggested test files?
> > The problem arising in the GCC PR is that none of the static
> > data/bss areas of the main executable get registered with
> the GC. The
> > libjava DLL registers its own data and bss, because it is
> the one that
> > calls GC_init; but if it returns a pointer to an allocated
> object to
> > the main executable (that it does not also retain a copy of
> in its own
> > registered root areas), that pointer is then invisible to GC and it
> > thinks the object is unreferenced and may release it and reallocate
> > the space. I solve this by adding the win32 dynamic
> registration code
> > into the mix(*), which should thoroughly take care of
> detecting all program and library data areas and malloc heaps.
> > The attached patch switches the Cygwin target to use the same
> > dynamic registration used on the native win32 targets.
> I've built it
> > on cygwin and verified that the testsuite shows no
> regressions. I've
> > also created a testcase that illustrates the problem,
> loosely based on
> > the trace test. It FAILs with current HEAD and PASSes
> after applying
> > the cygwin-mem-registration diff.
> > bdwgc/ChangeLog:
> > ...
> > There is one slight hiccup that I'm not sure what to do about: I
> > couldn't figure out how to get libtool to build a
> > shared-but-not-installed library, because libtool assumes that any
> > library you aren't planning to install will only be needed as a
> > convenience (i.e. static archive) library. There might be
> a way round
> > that, or you might want not to check in the testcase but
> just use it to verify the problem I've identified and fixed
> in the patch.
> > Any comments or advice? Anything I should bear in mind when
> > implementing this in the slightly-old version of the GC in libjava?
> > cheers,
> > DaveK
> > --
> > (*) - Although it is win32-ish rather than posix-ish, it
> relies only
> > on using VirtualQuery to determine properties of allocated memory
> > ranges, which is a perfectly safe thing to do under cygwin.
> We still
> > use posix interfaces for malloc/free/pthread stuff.
> > ATTACHMENT: text/x-c (cygwin-mem-registration.diff)
More information about the Gc