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. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/
signature.asc
Description: This is a digitally signed message part
