This is the mail archive of the
mailing list for the Mauve project.
Re: gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken
- From: Stephen Crawley <crawley at dstc dot edu dot au>
- To: Mark Wielaard <mark at klomp dot org>
- Cc: Stephen Crawley <crawley at dstc dot edu dot au>, Noa Resare <noa at resare dot com>, Mauve Discuss <mauve-discuss at sources dot redhat dot com>, crawley at piglet dot dstc dot edu dot au, crawley at piglet dot dstc dot edu dot au
- Date: Mon, 11 Oct 2004 10:49:44 +1000
- Subject: Re: gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken
Mark Wielaard <email@example.com> wrote:
> We had a problem with real programs that open lots of files quickly
> (gjdoc does this for example, a jar tool or a webserver might be another
> good example) and don't explicitly close these files, but let the
> file/stream just get garbage collected since the program structure
> doesn't explicitly define a "owner" for the file/stream object (which
> isn't that uncommon since that is what you normally do with random
> allocated objects, long life the garbage collector!).
Java programs that rely on the GC to find / close file handles are
non-portable and (IMO) broken. A portable program cannot depend on
the GC running soon enough to get around a problem with running
out of file descriptors. Indeed, it cannot even reliably cause the
VM to run the garbage collector, because the VM is allowed to treat
a call to java.lang.System.gc() as a "hint" ... and ignore it.
[For the record, Kissme is currently implemented to only respect
calls to java.lang.System.gc() when it is launched with the "-gc"
command line option.]
> What I think should be tested is whether a program can open lots of
> files. And that the systems notices that stale file handle resources can
> be removed so that a program can keep opening files if needed. (As long
> as there are no large number of life file handles open at the same
The trouble is that you cannot write a portable / reliable testcase for
this. Even if you could, I do not believe that a Java VM should be
required to be able to run programs that leak file descriptors like this.
> Since I have seen multiple systems get this wrong in various ways I want
> to have an explicit test for this situation. It might be that this test
> does not simulate a real world program correctly, so if there are
> alternatives I would like to hear them instead of just deleting the test
> since some systems fail it.
I think the solution is to test for behaviour that is not required by
the Java 'specification' in a VM-specific test suite ... not in Mauve.