This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Small example of livelock regression in garbage collector forGCJ3.3 under Win32
- From: Ranjit Mathew <rmathew at hotmail dot com>
- To: java-patches at gcc dot gnu dot org
- Cc: java at gcc dot gnu dot org
- Date: Thu, 22 May 2003 13:08:49 +0530
- Subject: Re: Small example of livelock regression in garbage collector forGCJ3.3 under Win32
- References: <16074.27934.715273.274532@cuddles.redhat.com> <SM74YVOKA5YV9XTQO1VOIA3Y2YFCOM.3eca896b@p733> <3ECB0D18.8000709@hotmail.com> <16075.19193.792072.251418@cuddles.redhat.com> <3ECBC4DA.2A135D40@hotmail.com> <16075.51664.269422.701640@cuddles.redhat.com>
> > > >>You need -fuse-divide-subroutine and -fcheck-references. Ranjit ahd a
> > > >>look at using Windows' structured exception handling to cope with
> > > >>these problems, but I don't think that it's done yet.
> > >
> > > Andrew, if I understand this correctly, you are suggesting that
> > > we use these options for the time being till such a time
> > > that we can fix the SEH stuff.
[...]
> How does the following look (tested only on Win98 so far)? It's
> against 3.3 sources:
That looks fine. If it solves =?iso-8859-1?Q?=D8yvind_Harboe?='s
problem I'll be happy. However, he's not building his own libgcj but
using one from Mohan, so we'll have to wait until Mohan does a rebuild
with this patch. Pretty please, if you would...
I must mention that even with Mohan's current build, if
I compile my "double-real-null" test program with
"-fcheck-references" it doesn't hang on Win2K as it does
(*consistently*) otherwise.
I'm attaching the test program with this message for everyone's
reference. On Win2K (and possibly on WinXP and WinNT4, but not
on Win98), this program *hangs* after printing "Strike 1!"
if compiled with Mohan's current snapshot as is, but prints
an additional "Strike 2!" and exits normally if compiled with
"-fcheck-references".
Of course beyond such trivial programs, the whole of libgcj
will have to be built with these flags for things to be
consistent.
BTW, these flags get added to "libgcj.spec" - now when I
build the GCJ cross compiler, I --disable-libgcj (to save
1 hour from the build time!) so no such file is created - does
that mean that the crossed-native GCJ/libgcj that is built
using this cross compiler will *not* be compiled using
these flags?
If yes, I need to look at some other way to propagate
these flags to the GCJ cross-compiler without having to
build the whole of libgcj.
Ranjit.
--
Ranjit Mathew Email: rmathew AT hotmail DOT com
Bangalore, INDIA. Web: http://ranjitmathew.tripod.com/
public class DNull
{
public static void main( String[] args)
{
Object p = null;
try
{
System.out.println( p.toString( ));
}
catch( NullPointerException e)
{
System.err.println( "Strike 1!");
}
try
{
System.out.println( p.toString( ));
}
catch( NullPointerException e)
{
System.err.println( "Strike 2!");
}
}
}