[Bug libgcj/10746] [3.3/3.4 regression] [win32] garbage collection crash in GCJ

["hans_boehm at hp dot com" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10746



------- Additional Comments From hans_boehm at hp dot com  2003-09-16 18:03 -------
Subject: RE:  [3.3/3.4 regression] [win32] garbage colle
	ction crash in GCJ

My guess is that it eventually would.

Basically callee-save (preserved) registers are not being scanned by the
collector in the thread that initiates the collection.  But very often,
especially on X86, they will accidentally get scanned anyway, since they
happen to be saved by some GC routine between the client code and the
stack marking code.  Thus I would have expected this bug to rarely manifest
itself on X86, which has so few registers that spills to the stack are
very common.  It turns this doesn't show up on a number of other platforms
either, because they often use other methods for doing this, or don't optimize
mach_dep.c.

If this is actually the cause of the observed bug, then there is apparently
one rarely executed path through the GC code on mingw32 on which one of the
preserved registers is not saved.  The Linux code is sufficiently different
that such a path might not exist.  (For example, thread-local allocation
is enabled on Linux, so that the allocation path looks very different.)
But this doesn't prevent some future version of gcc from 
breaking it on Linux, too.

Yet another example of why I tend to trust multi-platform code more than
single-platform code ...

> -----Original Message-----
> From: oyvind dot harboe at zylin dot com
> 
> Why doesn't this problem manifest itself under Linux?
> 
> Øyvind
>