Re: gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken

[Stephen Crawley <crawley at dstc dot edu dot au>]

Mark Wielaard <mark@klomp.org> 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
> time.)

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.

-- Steve