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:50:11 GMT
On 12/26/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> 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".

Exactly. We'd admit some apps are not badly written. We need some
tradeoff in our JVM design so that it can tolerate certain degree of
undesirable app behavior, but the tolerance has a bottomline that: "It
runs fast with good apps; it keeps functional with bad apps; it
strikes with terrible apps and warns the author." :-)

> Assuming the app programmer creates only short running finalizable objects,
> the scheme I described earlier should exhibit appropriate "automatic gain
> control" properties.  In other words,  once the finalizers start running,
> they take priority over the normal java app.  This starves out the java app
> threads that are clogging the heap with finalizable objects.  If there are
> exactly the same number of finalizer threads as CPUs in the box,  all CPUs
> will be busy executing finalizers.  Once all the finalizers are executed,
> the JVM/OS will automatically schedule the java app threads which, in turn,
> will fill up the finalizer queue.  This describes a full cycle.

Good design, and two additions:
1. The priority of finalizer threads might not be necessary to be
higher. But I agree that it's would be usually better to make it
higher. It will help to release the resources quickly.
2. The finalizable queue can be act as a scheduling queue like CSP
(communication sequential process) does. If the queue is fully filled,
the app that creats finalizer objects can not produce more.


> If you run your test with many finalizable objects which cannot be
> > finalized quickly, can you see the number of application threads in task
> > manager increasing?
> >
> > --
> > Gregory
> >
> >
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division

View raw message