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.
At least, the behavior should be documented with the class, as
it's a pretty subtle point.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
