harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [drlvm] finalizer design questions
Date Wed, 27 Dec 2006 01:30:20 GMT
On 12/27/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>
> 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
> > NFS
> > mount.  I suspect the answer is no.
>
> Right.
>
> >
> > 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
> ran.

Yes, it's encouraged not to use finalizer at all  in Java app, or
discouraged to use it. The idea to put resource management in
finalizer then give up the control is problematic. At the same time,
the finalization subsystem takes all the responsility of resource
management and works to avoid all the app design issues is unfair. It
is ultimately impossible unless the finalization system deeply
involves with the app activity (such as what Pavel Afremov said to
identify the "good" app threads), but then the finalization subsystem
knows too much about the app internals, and virually part of the app
in semantics. If that's the only way to make the finalization
subsystem really work, I would choose to manage the resources in app
directly, not to use finalizers at the beginning.

If in very rare cases some apps indeed have undesirable finalizer
behavior, we can take two actions at the same time with priority
order: 1. to tell the programmer that his design has some unexpected
finalizers and suggest to change the design, 2. if the app is
important, we can afford some time to study its behavior and think of
some solution in our VM.

Thanks,
xiaofeng

> geir
>
>

Mime
View raw message