Re: Patch: FYI: gcj3.1 status update

[Andrew Haley <aph at cambridge dot redhat dot com>]

Andrew Haley writes:
 > Tom Tromey writes:
 >  > >>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:
 >  > 
 >  > Rainer> Testsuite results are below, the patch results mostly in an
 >  > Rainer> improvement:
 >  > 
 >  > Great.
 >  > 
 >  > Rainer> The only problem is that building libgcj.so with
 >  > Rainer> -fcheck-references breaks FileHandleGcTest on Solaris.  It
 >  > Rainer> doesn't make a diffeence whether or not the test itself is
 >  > Rainer> built with this flag.  Tru64 UNIX is unaffected.
 >  > 
 >  > Rainer> What shall we do about this?
 >  > 
 >  > Sorry I didn't reply to this sooner.
 >  > How does the test fail?  I'm surprised this happens.
 > 
 > Me too.  I should give this a whirl myself.

I did, and it failed in the way I expected: it ran out of file
handles.  This is because our implementation of System.gc() doesn't
actually work.  Well, that's not true -- it does work eventually, but
it returns before garbage collection is complete.  When
natFileDescriptorPosix.cc (java::io::FileDescriptor::open) does this:

  if (fd == -1 && errno == EMFILE)
    {
      // Because finalize () calls close () we might be able to continue.
      java::lang::System::gc ();
      java::lang::System::runFinalization ();
      fd = ::open (buf, flags, mode);
    }
 
it fails.  We could fix this by spinning in this routine for a while
waiting for a file handle.

Better though to fix System.gc() so that it doesn't return until a
grabage collection cycle has really happned.  There are deadlock
problems with this, as I mentioned before.  I guess we could work
around that problem with a fairly short timeout.

This is a pretty important bug to fix, in my opinion, because it
critically affects web servers.

Andrew.