From harmony-dev-return-2340-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Mon Oct 31 17:27:52 2005 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 77410 invoked from network); 31 Oct 2005 17:27:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 31 Oct 2005 17:27:51 -0000 Received: (qmail 47665 invoked by uid 500); 31 Oct 2005 17:27:46 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 47588 invoked by uid 500); 31 Oct 2005 17:27:45 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 47577 invoked by uid 99); 31 Oct 2005 17:27:45 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 31 Oct 2005 09:27:45 -0800 X-ASF-Spam-Status: No, hits=2.6 required=10.0 tests=RCVD_IN_SORBS_WEB,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: 217.158.94.220 is neither permitted nor denied by domain of t.p.ellison@gmail.com) Received: from [217.158.94.220] (HELO cirrus.purplecloud.com) (217.158.94.220) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 31 Oct 2005 09:27:41 -0800 Received: (qmail 2007 invoked from network); 31 Oct 2005 17:27:22 +0000 Received: from blueice2n1.uk.ibm.com (HELO ?9.20.183.166?) (195.212.29.75) by smtp.purplecloud.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 31 Oct 2005 17:27:22 +0000 Message-ID: <436653F9.5030309@gmail.com> Date: Mon, 31 Oct 2005 17:27:21 +0000 From: Tim Ellison User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: harmony-dev@incubator.apache.org Subject: Re: Some questions about the architecture References: <30269045.1129820928256.JavaMail.root@elwamui-polski.atl.sa.earthlink.net> <51950.66.181.12.81.1129838884.squirrel@sqmail.anu.edu.au> <4358209F.2030609@dellroad.org> <1130593101.11930.20.camel@localhost.localdomain> <4365145E.50403@dellroad.org> In-Reply-To: <4365145E.50403@dellroad.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Archie Cobbs wrote: > Mark Wielaard wrote: > >> On Thu, 2005-10-20 at 17:56 -0500, Archie Cobbs wrote: >> >>> Off tanget, but IMHO this is not strictly true: it depends on whether >>> VM native code relies on finalize() to free up its (non-heap) memory. >>> Here's an exmaple of this: >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4797189 >> >> >> That problem doesn't occur with GNU Classpath since our zip >> implementation is written in java itself. But we have a similar example >> in the mauve testsuite (one that I also observed while getting JBoss to >> work with GNU Classpath and JamVM). There is a test that opens lots of >> FileInputStreams and then expects the garbage collector to finalize >> these and free up the open file descriptors. gcj explicitly handles this >> by forcing a garbage collect and finalization pass when it cannot create >> a new file descriptor. We currently don't have any convention for >> marking VMObjects or finalizers as (scarce) holding native resources or >> make the native code signal the runtime to do a finalization of such >> objects. > > > Right, and so this is a bug (although in a different form than > the ZIP example above) in Classpath too. It could be fixed I think it is unfair to describe this as 'a bug'. The FileInputStream has a lifecycle (from open() to close()) that users are expected to follow. While in this case you could image a VM knowing about the file handle resources and trying to free them using finalization, such a fix only inches you towards a fuller automatic resource management. There are still many other areas (SQL cursors, window handles, etc.) that have to be explicitly managed by the application. In this case, it is reasonable to perform a safety-check on finalization, but there are lots of reasons already well documented why you should not rely on finalization. Just my 2c. Regards, Tim > by creating a new VM method e.g. VMRuntime.runFinalizers() > that would "try hard" to run finalizers.. then the other thread > could loop, calling this method each iteration. There might still > be some more subtlety to this (finalizers have not guarantee of > returning quickly, etc.) > > -Archie > > __________________________________________________________________________ > Archie Cobbs * CTO, Awarix * http://www.awarix.com > -- Tim Ellison (t.p.ellison@gmail.com) IBM Java technology centre, UK.