harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Some questions about the architecture
Date Mon, 31 Oct 2005 21:25:10 GMT
Archie Cobbs wrote:
> Tim Ellison 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.
> Right.. so the question boils down to this: should an application's
> unreferencing some object be considered as good as close()ing it (or
> hatever) with respect to this lifecycle? Guess that's open to debate.
> It's not clear that it actually can be even if you wanted it to.

Agreed, finalization is not a substitute for an explicit disposal.

> At least, the behavior should be documented with the class, as
> it's a pretty subtle point.

Sure.  The wikipedia entry on finalization does a prety good job of
explaining the point:


> -Archie
> __________________________________________________________________________
> Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com


Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

View raw message