harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm] finalizer design questions
Date Wed, 27 Dec 2006 00:09:56 GMT

On Dec 26, 2006, at 10:53 AM, Weldon Washburn wrote:

> On 12/26/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
>> 2006/12/26, Weldon Washburn <weldonwjw@gmail.com>:
>> >
>> > On 12/25/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
>> > >
>> > > Weldon Washburn wrote:
>> > > > On 12/24/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
>> > > >>
>> > > >> On Sunday 24 December 2006 16:23 Weldon Washburn wrote:
>> [snip]
>> Thanks for an interesting investigation, it is really valuable. It  
>> shows
>> that production VM which you've used does not create any new  
>> threads for
>> finalization. I was thinking about some legitimate scenario which  
>> could
>> lead
>> to a jammed finalizer queue and therefore may lead to OOME  
>> eventually. But
>> later I realized that the whole java process would just hang.
> The scenario which I was thinking of is if an application has a  
> class with a
>> finalizer that deals with file IO, like closing a file. On Unixes  
>> when a
>> file is located on NFS filesystem, and this filesystem is  
>> disconnected,
>> then
>> file IO with such file (usually, depending on NFS mount options)  
>> stops the
>> process. I think it is a whole process, not just one thread  
>> (correct me if
>> I
>> am wrong), so it wouldn't be just finalization queque which would  
>> wait for
>> NFS IO, it would be all VM threads, so OOME would not happen.
> hmm... there are probably several orthogonal issues in what you  
> describe
> above:
> 1)
> Would the above issues be any different if finalizers were not  
> involved?
> For example, the app manually determines when to close a file on an  
> mount.  I suspect the answer is no.


> 2)
> Does it make sense for a particular java app to be dependent upon  
> an NFS
> mount?  This is something that is best addressed by someone who  
> knows the
> app environment.  Stuff like service uptime agreements, network
> topology/traffic , how loaded servers are, etc.  In other words,  
> the app
> programmer.  The JVM designer should be aware of these issues and  
> know what
> falls in the domain of the JVM vs. the app.
> 3)
> What would an app do if an NFS mount point suddenly disappeared  
> while file
> I/O is in flight?  If its really mission critical, often times the  
> file I/O
> is part of a two-phase commit transaction.  At a higher level, the
> transaction aborts thus no damage is done.

This is dependent upon app design.

> 4)
> What do other JVMs do when an NFS mount point disappears?   
> Obviously this
> far away from the original topic, finalizer design.  But at some  
> point,
> someone needs to run controlled tests and tell dev list what the  
> results
> are.

It's not clear that the VM has a clue that a mount point is NFS vs  
local disk.  It will probably get some fault from the OS and that  
would be that.  Same thing if you unplug a disk drive...

> 5)
> How are real java apps designed?  What do they really use finalizer  
> for?

I don't believe that people use them anymore.  When I was writing  
real things in Java, I never used them - I made sure that resource  
management and such was deliberate, and not dependent upon when and  
if (and even where - it can run in any thread, right?) the finalizer  


View raw message