harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Shimansky" <gshiman...@gmail.com>
Subject Re: [drlvm] finalizer design questions
Date Tue, 26 Dec 2006 14:42:20 GMT
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]
> This is a very good investigation, looks like this is exactly the way
> > that production VMs follow with finalizers.
> >
> > One last thing that is unclear to me is if an application creates many
> > objects of a class which have long running (never ending) finalize
> > method, it may cause out of memory condition because objects wouldn't be
> > removed from heap. Is it true with this approach?
> I ran some more tests.  I created 10,000 finalizable objects.  Then I
> "newed" enough empty arrays to cause the GC to shove the 10,000
> finalizable
> objects into finalization queue.  The finalize() method contains exactly
> the
> same while(true){ busy} workload as before.
> As far as I can tell, only the first object on the finalize queue is ever
> executed. The other 9,999 objects remain in the queue until the first
> object's finalizer returns (which it never does.)   Supporting evidence is
> that when I change the workload so that the finalize() method finishes
> after
> 100M loops, the JVM then move onto the next finalizable object in the
> queue.
> In other words, as far as the JVM is concerned the Java app programmer can
> legitimately create a situation where the JVM is flooded with objects
> requiring finalization and these objects chew up all availiable Java heap.
> And the Java app programmer can legitimately create a situation where a
> finalizer never finishes and it hogs 97% of available CPU.  It looks to me
> like one of those unavoidable situations where the java app will crash and
> burn.  Its much the same situation as intentionally creating an infinite
> link-list of live objects.  Its easy to build an app that does this.  And,
> yes, the JVM will run out of heap and exit.  Its probably best to tell the
> app programmer, "just don't do this".

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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message