From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28279 invoked by alias); 11 Oct 2004 00:50:05 -0000 Mailing-List: contact mauve-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: mauve-discuss-owner@sources.redhat.com Received: (qmail 28262 invoked from network); 11 Oct 2004 00:50:04 -0000 Received: from unknown (HELO piglet.dstc.edu.au) (130.102.176.1) by sourceware.org with SMTP; 11 Oct 2004 00:50:04 -0000 Received: from dstc.edu.au (credence.dstc.edu.au [130.102.105.137]) by piglet.dstc.edu.au (8.12.10/8.12.10) with ESMTP id i9B0nLQQ008866; Mon, 11 Oct 2004 10:49:21 +1000 (EST) Message-Id: <200410110049.i9B0nLQQ008866@piglet.dstc.edu.au> To: Mark Wielaard cc: Stephen Crawley , Noa Resare , Mauve Discuss , crawley@piglet.dstc.edu.au, crawley@piglet.dstc.edu.au Subject: Re: gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken In-Reply-To: Message from Mark Wielaard of "Fri, 08 Oct 2004 12:05:25 +0200." <1097229925.1087.10.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Oct 2004 00:50:00 -0000 From: Stephen Crawley X-Spam-Score: 2.818 X-Scanned-By: MIMEDefang 2.39 (DSTC) X-SW-Source: 2004-q4/txt/msg00008.txt.bz2 Mark Wielaard 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