You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/12/22 03:32:04 UTC
[drlvm] finalizer design questions
The existing VM finalizer system has something called a Work Balancing
System. It would be good to know the motivation for this feature. If this
feature was built for specific workloads, please tell us which ones.
Thanks
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm] finalizer design questions
Posted by Weldon Washburn <we...@gmail.com>.
On 12/27/06, Pavel Afremov <pa...@gmail.com> wrote:
>
> Oh. I see. In your proposal threads quantity isn't changed. It's a
> difference. I see.
>
> So on Intel Core 2 Quad, for example, VM will have 4 permanent high
> priority finalaser threads. Is it correct?
Yes. That is the proposal for this stage of Harmony JVM development. I
suggest that this is good enough until we get an app like SPECjAppServer
fully running and can really stress finalizers. Only then will we know what
the real finalizer performance issues are.
Re: [drlvm] finalizer design questions
Posted by Pavel Afremov <pa...@gmail.com>.
Oh. I see. In your proposal threads quantity isn't changed. It's a
difference. I see.
So on Intel Core 2 Quad, for example, VM will have 4 permanent high
priority finalaser threads. Is it correct?
BR
On 12/27/06, Weldon Washburn <we...@gmail.com> wrote:
>
> On 12/26/06, Pavel Afremov <pa...@gmail.com> wrote:
> >
> > Hi.
> >
> > On 12/19/06, in "[drlvm][gcv5] finalizer design" thread I wrote,
> > that "WBS
> > should increase relative finalization performance by following steps:
> >
> > - Increase number of finalizer threads while them quantity is less
> > then processors number.
> > - Using locks for stopping user threads. I have some ideas how to do
> > this without deadlock.
> > - Increase priority of finalizer thread. Or reduce priority of user
> > threads which generate finalizable objects, because finalization
> > activities
> > shouldn't stop "good" threads which don't create fianalizabe object."
>
>
> hmm.... I am not sure how a JVM would determine which java app
> thread(s) will generate finalizable objects at specific rates. In other
> words, how would the JVM anticipate which thread(s) in the future are
> "good"
> and which one(s) are bad?? I vote for a simple design (with less
> deadlocks
> to debug and dodge.)
>
> As I understand "independent" investigation provided by Weldon, which
> > discussed here, reaches the same results. So this design can be
> considered
> > as approved by Harmony community.
>
>
> hmmm.... OK. Just to confirm we are on the same page. The design I
> suggest is to have exactly one finalizer thread for each CPU in the box.
> These finalizer threads are to be created during JVM initialization.
> No finalizer threads are added or killed once JVM initialization
> completes. The priority of each of these finalizer threads is set slightly
> above the highest priority of the Java app threads. The finalizer
> queues have synchronized access. All threads must grab the queue's lock
> to
> enqueue/dequeue objects. Is this what you are thinking?
>
> BR
> >
> > Pavel Afremov.
> >
> >
> >
> >
> > On 12/26/06, Gregory Shimansky <gs...@gmail.com> wrote:
> > >
> > > 2006/12/26, Weldon Washburn <we...@gmail.com>:
> > > >
> > > > On 12/25/06, Gregory Shimansky <gs...@gmail.com> wrote:
> > > > >
> > > > > Weldon Washburn wrote:
> > > > > > On 12/24/06, Gregory Shimansky <gs...@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.
> > >
> > > --
> > > Gregory
> > >
> > >
> >
> >
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>
>
Re: [drlvm] finalizer design questions
Posted by Weldon Washburn <we...@gmail.com>.
On 12/26/06, Pavel Afremov <pa...@gmail.com> wrote:
>
> Hi.
>
> On 12/19/06, in "[drlvm][gcv5] finalizer design" thread I wrote,
> that "WBS
> should increase relative finalization performance by following steps:
>
> - Increase number of finalizer threads while them quantity is less
> then processors number.
> - Using locks for stopping user threads. I have some ideas how to do
> this without deadlock.
> - Increase priority of finalizer thread. Or reduce priority of user
> threads which generate finalizable objects, because finalization
> activities
> shouldn't stop "good" threads which don't create fianalizabe object."
hmm.... I am not sure how a JVM would determine which java app
thread(s) will generate finalizable objects at specific rates. In other
words, how would the JVM anticipate which thread(s) in the future are "good"
and which one(s) are bad?? I vote for a simple design (with less deadlocks
to debug and dodge.)
As I understand "independent" investigation provided by Weldon, which
> discussed here, reaches the same results. So this design can be considered
> as approved by Harmony community.
hmmm.... OK. Just to confirm we are on the same page. The design I
suggest is to have exactly one finalizer thread for each CPU in the box.
These finalizer threads are to be created during JVM initialization.
No finalizer threads are added or killed once JVM initialization
completes. The priority of each of these finalizer threads is set slightly
above the highest priority of the Java app threads. The finalizer
queues have synchronized access. All threads must grab the queue's lock to
enqueue/dequeue objects. Is this what you are thinking?
BR
>
> Pavel Afremov.
>
>
>
>
> On 12/26/06, Gregory Shimansky <gs...@gmail.com> wrote:
> >
> > 2006/12/26, Weldon Washburn <we...@gmail.com>:
> > >
> > > On 12/25/06, Gregory Shimansky <gs...@gmail.com> wrote:
> > > >
> > > > Weldon Washburn wrote:
> > > > > On 12/24/06, Gregory Shimansky <gs...@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.
> >
> > --
> > Gregory
> >
> >
>
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm] finalizer design questions
Posted by Pavel Afremov <pa...@gmail.com>.
Hi.
On 12/19/06, in "[drlvm][gcv5] finalizer design" thread I wrote, that "WBS
should increase relative finalization performance by following steps:
- Increase number of finalizer threads while them quantity is less
then processors number.
- Using locks for stopping user threads. I have some ideas how to do
this without deadlock.
- Increase priority of finalizer thread. Or reduce priority of user
threads which generate finalizable objects, because finalization activities
shouldn't stop "good" threads which don't create fianalizabe object."
As I understand "independent" investigation provided by Weldon, which
discussed here, reaches the same results. So this design can be considered
as approved by Harmony community.
BR
Pavel Afremov.
On 12/26/06, Gregory Shimansky <gs...@gmail.com> wrote:
>
> 2006/12/26, Weldon Washburn <we...@gmail.com>:
> >
> > On 12/25/06, Gregory Shimansky <gs...@gmail.com> wrote:
> > >
> > > Weldon Washburn wrote:
> > > > On 12/24/06, Gregory Shimansky <gs...@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.
>
> --
> Gregory
>
>
Re: [drlvm] finalizer design questions
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 1, 2007, at 11:05 PM, Robin Garner wrote:
>
> From what I've seen to date, all the available DRLVM mechanisms are
> perfectly adequate, and we should all get back to doing something
> productive.
>
That's a bit harsh. Clearly someone has an interest in this. :)
I think that Weldon, Pavel and others did some good work here -
certainly it helped me understand how finalizers work in other impls..
geir
Re: [drlvm] finalizer design questions
Posted by Pavel Afremov <pa...@gmail.com>.
On 1/2/07, Weldon Washburn <we...@gmail.com> wrote:
> Yes with one reservation. I'd like to see the existing DRLVM
> mechanisms hard coded for just one finalizer thread for now. And that no
> finalizer code be committed that suspends/resumes java app threads. The
> intention is to reduce debug confusion.
Unclear and unfounded. No existing test was run by Weldon on different
finalization schemes, and no result was published. Unsuitable date was named
as noise, or ignored.
Also I see many visions that one scheme is better than other, without any
competitive comparison.
> We have plenty of problems in the
> threading subsystem that need sorting out. Adding finalizer threads that
> come and go along with starting/stopping java threads based on
> finalization
> load factor is way too confusing.
Threading system is separate component, and can't and shouldn't be confused
by Finalization system. But I see that finalization system design was
declared as source of threading system bug without any reasons. Before said,
it should be checked by finalization turn off flag.
I'm sorry, but I agree with Robin that discussing is not productive. Sorry
again for harsh words, but it's true.
To continue we should choose a strategy: copy existing scheme or developed
new one, which will be optimized for defined set of applications.
After that anybody can propose new scheme, with results of DRLVM on
different tests with different finalization schemes. After that We can
discuss it, and choose a way how implement the best finalization scheme.
Pavel Afremov.
Re: [drlvm] finalizer design questions
Posted by Robin Garner <ro...@anu.edu.au>.
>> and we should all get back to doing something
>> productive.
>
>
> Good point. As painful as it is, hammering out a workable design is
> actually productive. Robin, thanks for bearing with us through this
> process. As usual, your input is valuable.
Sorry didn't mean to sound so negative. I've followed this duscussion
with interest, but I think it passed the point of being productive a
little while ago ;)
Speaking of productive things, I've been looking into why JikesRVM sucks
on the DaCapo xalan benchmark, has anyone been doing the same for
DRLVM/harmony ?
--
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/
Re: [drlvm] finalizer design questions
Posted by Weldon Washburn <we...@gmail.com>.
On 1/1/07, Robin Garner <ro...@anu.edu.au> wrote:
> Pavel Afremov wrote:
> > On 12/31/06, Weldon Washburn <we...@gmail.com> wrote:
> >>
> >> This looks good to me. Its close enough for the current state of
> >> drlvm. In
> >> other words, don't try to precisely replicate the performance numbers I
> >> collected from Sun 1.5.0.
> >
> >
> >
> > 1/50 ratio with usual work load for finalization system is not good,
> > because
> > it means 2% VM performance for main task. Let's evaluate following
> > abstraction. For example for finalization of some objects requires the
> same
> > time as for creation. These objects were generated during 10 seconds for
> > example. So machine will works with 2% performance for main task during
> 10
> > seconds when finalizer is works. Finalization shouldn't stop main task,
> and
> > 2% of performance equals stopping.
>
> I think this is missing the point. Finalizers that run for a long time
> shouldn't be created.
Well put. Thank you.
> - Finalizers should be run with high priority because memory (possibly
> large structures) can't be freed until they have completed.
I agree.
> - Allowing the main application to make some progress while a badly
> written finalizer executes is good design practice
Exactly right.
> I think this is the only criteria by which a finalization scheme can be
> evaluated. Whether the ratio is 1/50, 1/25, 1/200 is neither here nor
> there.
Absolutely correct.
> From what I've seen to date, all the available DRLVM mechanisms are
> perfectly adequate,
Yes with one reservation. I'd like to see the existing DRLVM
mechanisms hard coded for just one finalizer thread for now. And that no
finalizer code be committed that suspends/resumes java app threads. The
intention is to reduce debug confusion. We have plenty of problems in the
threading subsystem that need sorting out. Adding finalizer threads that
come and go along with starting/stopping java threads based on finalization
load factor is way too confusing.
> and we should all get back to doing something
> productive.
Good point. As painful as it is, hammering out a workable design is
actually productive. Robin, thanks for bearing with us through this
process. As usual, your input is valuable.
> best regards,
> Robin
> --
> Robin Garner
> Dept. of Computer Science
> Australian National University
> http://cs.anu.edu.au/people/Robin.Garner/
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm] finalizer design questions
Posted by Pavel Afremov <pa...@gmail.com>.
On 1/2/07, Robin Garner <ro...@anu.edu.au> wrote:
>
> - Finalizers should be run with high priority because memory (possibly
> large structures) can't be freed until they have completed.
I agree, In described case it should work with high priority.
In current finalization scheme if garbage collection happened in the time
when finalization of previous part is not complete, additional finalization
threads are created, and relative performance of finalizers are increased.
So after several iteration WBS increases performance up to required level.
BR.
Pavel Afreov.
Re: [drlvm] finalizer design questions
Posted by Robin Garner <ro...@anu.edu.au>.
Pavel Afremov wrote:
> On 12/31/06, Weldon Washburn <we...@gmail.com> wrote:
>>
>> This looks good to me. Its close enough for the current state of
>> drlvm. In
>> other words, don't try to precisely replicate the performance numbers I
>> collected from Sun 1.5.0.
>
>
>
> 1/50 ratio with usual work load for finalization system is not good,
> because
> it means 2% VM performance for main task. Let's evaluate following
> abstraction. For example for finalization of some objects requires the same
> time as for creation. These objects were generated during 10 seconds for
> example. So machine will works with 2% performance for main task during 10
> seconds when finalizer is works. Finalization shouldn't stop main task, and
> 2% of performance equals stopping.
I think this is missing the point. Finalizers that run for a long time
shouldn't be created.
- Finalizers should be run with high priority because memory (possibly
large structures) can't be freed until they have completed.
- Allowing the main application to make some progress while a badly
written finalizer executes is good design practice
I think this is the only criteria by which a finalization scheme can be
evaluated. Whether the ratio is 1/50, 1/25, 1/200 is neither here nor
there.
From what I've seen to date, all the available DRLVM mechanisms are
perfectly adequate, and we should all get back to doing something
productive.
best regards,
Robin
> Its unclear if you actually ran GCv5 finalizer code or something "like new
>> GC v5 scheme". I don't know what the data means.
>
>
>
> I don't know clear how GC v5 should be started for correct work. I ask to
> help me and describe correct running way. But I haven't any replay. So I
> can
> emulate GC v5 finalization scheme only. So I use 1 finalization thread with
> high priority.
>
>> The point is that the "ideal finalization" design needs to be driven by
>> what
>> important commercial workloads require. It will be a while before these
>> workloads run fast and stable on drlvm. In other words, drlvm is not yet
>> ready for investigating the final finalization scheme. Incidentally, the
>> data collected on Sun 1.5.0 contradicts the "ideal finalization scheme"
>> suggested above. Given a choice, I would rather do something similar
>> to a
>> commercial JVM implementation at this point in time.
>
>
>
> The ideal system should have performance which provides finalization of
> created objects, but not more. Very high relative performance can block
> main
> task.
>
> So relative performance of Weldon's scheme in mode 2 is not so high as for
>> > SUN 1.5.0 JVM 15/ 2600 = 1/173 (main loop/finalizer call).
>
>
> It's your data. If You think that your results contains such "suitable"
> noise, lets use the other test. I asked You to check your scheme on
> gc.Synchronized FinalizerTest some time ago. Lets use it with various
> parameters.
>
>
> Also we should decide to optimize finalization system for defined set of
> application or emulate existing finalization scheme, i.e if any test works
> on RI it should works on our one too. Copping existing scheme for some
> application is not good way. If there is a set of application let's find
> the
> best solution.
>
>
> BR
> Pavel Afremov
>
> I think you are talking about the difference between 1/50 and 1/173. In my
>> opinion, this difference is in the noise. Its not material.
>>
>> I think that it can be improved by point 2 of my scheme (Using locks for
>> > stopping user threads)
>>
>>
>> As far as I can tell Sun 1.5.0 does not do this. Also, adding more
>> thread
>> suspend/resume logic to dlrvm does not help stability and actually may
>> decrease stability.
>>
>>
>> or by increasing quantity of finalizer threads like
>> > in current scheme of finalization.
>>
>>
>> As far as I can tell Sun 1.5.0 does not do this. Until additional
>> evidence
>> is available, I vote for the simplest possible finalizer scheme. This
>> will
>> help us a bunch in sorting out the problems in drlvm threading subsystem.
>>
>>
>> Thanks.
>> > Pavel Afremov
>> >
>> > On 12/28/06, Pavel Afremov <pa...@gmail.com> wrote:
>> >
>> > > Did you check it on current implementation of DRLVM Finalization
>> System?
>> > >
>> > > BR
>> > > Pavel Afremov.
>> > >
>> > >
>> > > On 12/28/06, Weldon Washburn <we...@gmail.com> wrote:
>> > > >
>> > > > On 12/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote
>> > > >
>> > > >
>> > > >
>> > > > > [snip]
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > > Why can't we simply mimic the rational behavior of the RI and
>> other
>> > > > > production VMs and leave it at that?
>> > > > >
>> > > > > geir
>> > > >
>> > > >
>> > > > I agree. To discover what other JVMs do, I created a very simple
>> > > > finalizer
>> > > > probe then put it in JIRA HARMONY-2908. I ran this probe on Sun
>> JVM
>> > > > 1.5.0_07. Below are the results. It would be good if someone can
>> > run
>> > > > this
>> > > > probe on other JVM/OS combinations. The probe is single threaded
>> and
>> > has
>> > > >
>> > > > three different execution modes ("java Finx 0", "java Finx 1" and
>> > "java
>> > > > Finx
>> > > > 2"). By running each of the modes on WindowsXP and using
>> Microsoft's
>> > > > Process Viewer, one can learn what the different JVM threads are
>> > doing.
>> > > > More on this later.
>> > > >
>> > > > Mode 0
>> > > > This mode intentionally does not create any finalizable
>> objects. The
>> > > > main()
>> > > > method simply runs a cpu intensive workload forever. After every
>> > > > 1000000
>> > > > loops main() will print a distinctive string that includes a loop
>> > count.
>> > > >
>> > > >
>> > > > Mode 1
>> > > > main() creates 100K finalizable objects that are intentionally
>> shoved
>> > > > into a
>> > > > state where their finalizer needs to be called. main() then
>> proceeds
>> > to
>> > > > run
>> > > > the same cpu intensive workload as above. The finalize() method
>> will
>> > > > execute just one call of the same cpu intensive workload then
>> > > > returns. This
>> > > > simulates a short running finalizer. finalize() prints a
>> distinctive
>> > > > string
>> > > > to make it easy to quickly read the output which is comingled with
>> > > > main().
>> > > >
>> > > > Mode 2
>> > > > This mode is identical to Mode 1 except the finalize() method calls
>> > the
>> > > > cpu
>> > > > intensive workload endlessly.
>> > > >
>> > > > The above describes how the probe is constructed. Below are
>> > > > observations
>> > > > from running this probe on Sun 1.5.0 JVM.
>> > > >
>> > > > Mode 0
>> > > >
>> > > > There are seven threads. Thread 0 consumes 99% of the total cpu
>> > > > time. And
>> > > > is executing in user mode 100% of the time. Most likely this is
>> the
>> > > > java
>> > > > app thread running main(). All the remaining threads do not
>> > accumulate
>> > > > any
>> > > > significant cpu time.
>> > > >
>> > > >
>> > > >
>> > > > Mode 1
>> > > >
>> > > > There are seven threads. Thread 0 accumulates roughly 2% of total
>> cpu
>> > > > time. Thread 3 accumulates the other 98%. Process Viewer reports
>> > > > Thread 3
>> > > > having "above normal" priority. (I have not chased down the
>> mapping
>> > > > from
>> > > > Process Viewer priority to win API priority). At the top of the
>> > > > finalize()
>> > > > method a static variable is incremented then printed out. This
>> allows
>> > > > us to
>> > > > watch a rolling count of how many objects have been
>> > finalized. Watching
>> > > > the
>> > > > console output for a few minutes, it looks like about 9000 objects
>> are
>> > > > finalized in the same time period that main() completes 100
>> > > > loops. Since
>> > > > both main() and finalize() are running the same workload, it looks
>> > > > like Thread 3 with "above normal" priority is the thread running
>> the
>> > > > finalizers. The disparity between 90:1 on console output and 50:1
>> in
>> > > > Process Viewer is probably sampling noise. Also, it looks like
>> Thread
>> > 0
>> > > > is
>> > > > running main() just like it was in Mode 0.
>> > > >
>> > > >
>> > > >
>> > > > Mode 2
>> > > >
>> > > > Again the JVM is running exactly 7 threads. Only the one object's
>> > > > finalize() method is ever called. Process Viewer shows Thread 3
>> has
>> > > > "above
>> > > > normal" priority and accumulating roughly 99% of the cpu
>> > time. Watching
>> > > > the
>> > > > console output for a few minutes, it look like 2600 finalize()
>> loops
>> > to
>> > > > 15
>> > > > main loops. It appears that no additional threads are created to
>> > handle
>> > > > to
>> > > > remaining 99,999 waiting finalizable objects. These objects
>> appear
>> > to
>> > > > be
>> > > > blocked waiting for the first object to finish. Also it looks like
>> > > > Thread 0
>> > > > is running main() just like Mode 0 and 1. Given that Process
>> Viewer
>> > > > shows
>> > > > that Thread 0 continuously and slowly accumulates CPU time, it
>> appears
>> > > > that
>> > > > main() is not suspended but continues to make forward progress.
>> > > >
>> > > >
>> > >
>> >
>> >
>>
>>
>> --
>> Weldon Washburn
>> Intel Enterprise Solutions Software Division
>>
>>
>
--
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/
Re: [drlvm] finalizer design questions
Posted by Pavel Afremov <pa...@gmail.com>.
On 12/31/06, Weldon Washburn <we...@gmail.com> wrote:
>
> This looks good to me. Its close enough for the current state of
> drlvm. In
> other words, don't try to precisely replicate the performance numbers I
> collected from Sun 1.5.0.
1/50 ratio with usual work load for finalization system is not good, because
it means 2% VM performance for main task. Let's evaluate following
abstraction. For example for finalization of some objects requires the same
time as for creation. These objects were generated during 10 seconds for
example. So machine will works with 2% performance for main task during 10
seconds when finalizer is works. Finalization shouldn't stop main task, and
2% of performance equals stopping.
Its unclear if you actually ran GCv5 finalizer code or something "like new
> GC v5 scheme". I don't know what the data means.
I don't know clear how GC v5 should be started for correct work. I ask to
help me and describe correct running way. But I haven't any replay. So I can
emulate GC v5 finalization scheme only. So I use 1 finalization thread with
high priority.
> The point is that the "ideal finalization" design needs to be driven by
> what
> important commercial workloads require. It will be a while before these
> workloads run fast and stable on drlvm. In other words, drlvm is not yet
> ready for investigating the final finalization scheme. Incidentally, the
> data collected on Sun 1.5.0 contradicts the "ideal finalization scheme"
> suggested above. Given a choice, I would rather do something similar to a
> commercial JVM implementation at this point in time.
The ideal system should have performance which provides finalization of
created objects, but not more. Very high relative performance can block main
task.
So relative performance of Weldon's scheme in mode 2 is not so high as for
> > SUN 1.5.0 JVM 15/ 2600 = 1/173 (main loop/finalizer call).
It's your data. If You think that your results contains such "suitable"
noise, lets use the other test. I asked You to check your scheme on
gc.Synchronized FinalizerTest some time ago. Lets use it with various
parameters.
Also we should decide to optimize finalization system for defined set of
application or emulate existing finalization scheme, i.e if any test works
on RI it should works on our one too. Copping existing scheme for some
application is not good way. If there is a set of application let's find the
best solution.
BR
Pavel Afremov
I think you are talking about the difference between 1/50 and 1/173. In my
> opinion, this difference is in the noise. Its not material.
>
> I think that it can be improved by point 2 of my scheme (Using locks for
> > stopping user threads)
>
>
> As far as I can tell Sun 1.5.0 does not do this. Also, adding more thread
> suspend/resume logic to dlrvm does not help stability and actually may
> decrease stability.
>
>
> or by increasing quantity of finalizer threads like
> > in current scheme of finalization.
>
>
> As far as I can tell Sun 1.5.0 does not do this. Until additional
> evidence
> is available, I vote for the simplest possible finalizer scheme. This
> will
> help us a bunch in sorting out the problems in drlvm threading subsystem.
>
>
> Thanks.
> > Pavel Afremov
> >
> > On 12/28/06, Pavel Afremov <pa...@gmail.com> wrote:
> >
> > > Did you check it on current implementation of DRLVM Finalization
> System?
> > >
> > > BR
> > > Pavel Afremov.
> > >
> > >
> > > On 12/28/06, Weldon Washburn <we...@gmail.com> wrote:
> > > >
> > > > On 12/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote
> > > >
> > > >
> > > >
> > > > > [snip]
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > Why can't we simply mimic the rational behavior of the RI and
> other
> > > > > production VMs and leave it at that?
> > > > >
> > > > > geir
> > > >
> > > >
> > > > I agree. To discover what other JVMs do, I created a very simple
> > > > finalizer
> > > > probe then put it in JIRA HARMONY-2908. I ran this probe on Sun JVM
> > > > 1.5.0_07. Below are the results. It would be good if someone can
> > run
> > > > this
> > > > probe on other JVM/OS combinations. The probe is single threaded and
> > has
> > > >
> > > > three different execution modes ("java Finx 0", "java Finx 1" and
> > "java
> > > > Finx
> > > > 2"). By running each of the modes on WindowsXP and using
> Microsoft's
> > > > Process Viewer, one can learn what the different JVM threads are
> > doing.
> > > > More on this later.
> > > >
> > > > Mode 0
> > > > This mode intentionally does not create any finalizable
> objects. The
> > > > main()
> > > > method simply runs a cpu intensive workload forever. After every
> > > > 1000000
> > > > loops main() will print a distinctive string that includes a loop
> > count.
> > > >
> > > >
> > > > Mode 1
> > > > main() creates 100K finalizable objects that are intentionally
> shoved
> > > > into a
> > > > state where their finalizer needs to be called. main() then
> proceeds
> > to
> > > > run
> > > > the same cpu intensive workload as above. The finalize() method
> will
> > > > execute just one call of the same cpu intensive workload then
> > > > returns. This
> > > > simulates a short running finalizer. finalize() prints a
> distinctive
> > > > string
> > > > to make it easy to quickly read the output which is comingled with
> > > > main().
> > > >
> > > > Mode 2
> > > > This mode is identical to Mode 1 except the finalize() method calls
> > the
> > > > cpu
> > > > intensive workload endlessly.
> > > >
> > > > The above describes how the probe is constructed. Below are
> > > > observations
> > > > from running this probe on Sun 1.5.0 JVM.
> > > >
> > > > Mode 0
> > > >
> > > > There are seven threads. Thread 0 consumes 99% of the total cpu
> > > > time. And
> > > > is executing in user mode 100% of the time. Most likely this is the
> > > > java
> > > > app thread running main(). All the remaining threads do not
> > accumulate
> > > > any
> > > > significant cpu time.
> > > >
> > > >
> > > >
> > > > Mode 1
> > > >
> > > > There are seven threads. Thread 0 accumulates roughly 2% of total
> cpu
> > > > time. Thread 3 accumulates the other 98%. Process Viewer reports
> > > > Thread 3
> > > > having "above normal" priority. (I have not chased down the mapping
> > > > from
> > > > Process Viewer priority to win API priority). At the top of the
> > > > finalize()
> > > > method a static variable is incremented then printed out. This
> allows
> > > > us to
> > > > watch a rolling count of how many objects have been
> > finalized. Watching
> > > > the
> > > > console output for a few minutes, it looks like about 9000 objects
> are
> > > > finalized in the same time period that main() completes 100
> > > > loops. Since
> > > > both main() and finalize() are running the same workload, it looks
> > > > like Thread 3 with "above normal" priority is the thread running
> the
> > > > finalizers. The disparity between 90:1 on console output and 50:1
> in
> > > > Process Viewer is probably sampling noise. Also, it looks like
> Thread
> > 0
> > > > is
> > > > running main() just like it was in Mode 0.
> > > >
> > > >
> > > >
> > > > Mode 2
> > > >
> > > > Again the JVM is running exactly 7 threads. Only the one object's
> > > > finalize() method is ever called. Process Viewer shows Thread 3 has
> > > > "above
> > > > normal" priority and accumulating roughly 99% of the cpu
> > time. Watching
> > > > the
> > > > console output for a few minutes, it look like 2600 finalize() loops
> > to
> > > > 15
> > > > main loops. It appears that no additional threads are created to
> > handle
> > > > to
> > > > remaining 99,999 waiting finalizable objects. These objects appear
> > to
> > > > be
> > > > blocked waiting for the first object to finish. Also it looks like
> > > > Thread 0
> > > > is running main() just like Mode 0 and 1. Given that Process Viewer
> > > > shows
> > > > that Thread 0 continuously and slowly accumulates CPU time, it
> appears
> > > > that
> > > > main() is not suspended but continues to make forward progress.
> > > >
> > > >
> > >
> >
> >
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>
>
Re: [drlvm] finalizer design questions
Posted by Pavel Afremov <pa...@gmail.com>.
If we'd like to copy the commercial VM behavior we can write several
synthetic tests, and try to reach the same behavior. And if any test works
on RI it should works on DRLVM.
Or we can optimize DRLVM for defined set of applications. Let's choose one
of the way here, at first.
Happy New Year!
Pavel Afremov.
On 12/31/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> On Dec 31, 2006, at 10:18 AM, Weldon Washburn wrote:
>
> > On 12/29/06, Pavel Afremov <pa...@gmail.com> wrote:
> >>
> >> I've checked Weldon's finalization scheme and two existing schemes on
> >> Weldon's test in mode 1 and 2.
> >> On my Machine WinXP HT Pentium 4 I've got following results.
> >>
> >> Weldon's design (on my machine 2 threads with highest priority).
> >> Mode 1: 1/50 (main loop/finalizer call)
> >> Mode 2: 1/50 (main loop/finalizer call)
> >
> >
> > This looks good to me. Its close enough for the current state of
> > drlvm. In
> > other words, don't try to precisely replicate the performance
> > numbers I
> > collected from Sun 1.5.0.
> >
> > Multithreading java scheme (old DRLVM scheme)
> >> Mode 1: 1/1 (main loop/finalizer call)
> >> Mode 2 1/250 (main loop/finalizer call)
> >> One native thread with highest priority (like new GC v5 scheme)
> >> Mode 1: 1/1 (main loop/finalizer call)
> >> Mode 2: 1/1 (main loop/finalizer call)
> >
> >
> > Its unclear if you actually ran GCv5 finalizer code or something
> > "like new
> > GC v5 scheme". I don't know what the data means.
> >
> > From Weldon's data SUN 1.5.0 JVM has:
> >> Mode 1: 1/50 (main loop/finalizer call) (may be 1/90)
> >> Mode 2: 1/173 (main loop/finalizer call) (15 / 2600 =
> >> 1/173)
> >>
> >> As I understand the ideal finalization scheme should provide:
> >> Mode 1: 1/1 (main loop/finalizer call)
> >> Mode 2: 0/1 (main loop/finalizer call)
> >
> >
> > The point is that the "ideal finalization" design needs to be
> > driven by what
> > important commercial workloads require.
>
> I'd be stunned if there were any important commercial workloads that
> used finalizers. (Nothing from SPEC is a commercial workload...)
>
> > It will be a while before these
> > workloads run fast and stable on drlvm. In other words, drlvm is
> > not yet
> > ready for investigating the final finalization scheme.
>
> I don't agree with that conclusion, as I don't think that they are
> connected concepts.
>
> > Incidentally, the
> > data collected on Sun 1.5.0 contradicts the "ideal finalization
> > scheme"
> > suggested above. Given a choice, I would rather do something
> > similar to a
> > commercial JVM implementation at this point in time.
>
> Me too
>
> geir
>
Re: [drlvm] finalizer design questions
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Dec 31, 2006, at 10:18 AM, Weldon Washburn wrote:
> On 12/29/06, Pavel Afremov <pa...@gmail.com> wrote:
>>
>> I've checked Weldon's finalization scheme and two existing schemes on
>> Weldon's test in mode 1 and 2.
>> On my Machine WinXP HT Pentium 4 I've got following results.
>>
>> Weldon's design (on my machine 2 threads with highest priority).
>> Mode 1: 1/50 (main loop/finalizer call)
>> Mode 2: 1/50 (main loop/finalizer call)
>
>
> This looks good to me. Its close enough for the current state of
> drlvm. In
> other words, don't try to precisely replicate the performance
> numbers I
> collected from Sun 1.5.0.
>
> Multithreading java scheme (old DRLVM scheme)
>> Mode 1: 1/1 (main loop/finalizer call)
>> Mode 2 1/250 (main loop/finalizer call)
>> One native thread with highest priority (like new GC v5 scheme)
>> Mode 1: 1/1 (main loop/finalizer call)
>> Mode 2: 1/1 (main loop/finalizer call)
>
>
> Its unclear if you actually ran GCv5 finalizer code or something
> "like new
> GC v5 scheme". I don't know what the data means.
>
> From Weldon's data SUN 1.5.0 JVM has:
>> Mode 1: 1/50 (main loop/finalizer call) (may be 1/90)
>> Mode 2: 1/173 (main loop/finalizer call) (15 / 2600 =
>> 1/173)
>>
>> As I understand the ideal finalization scheme should provide:
>> Mode 1: 1/1 (main loop/finalizer call)
>> Mode 2: 0/1 (main loop/finalizer call)
>
>
> The point is that the "ideal finalization" design needs to be
> driven by what
> important commercial workloads require.
I'd be stunned if there were any important commercial workloads that
used finalizers. (Nothing from SPEC is a commercial workload...)
> It will be a while before these
> workloads run fast and stable on drlvm. In other words, drlvm is
> not yet
> ready for investigating the final finalization scheme.
I don't agree with that conclusion, as I don't think that they are
connected concepts.
> Incidentally, the
> data collected on Sun 1.5.0 contradicts the "ideal finalization
> scheme"
> suggested above. Given a choice, I would rather do something
> similar to a
> commercial JVM implementation at this point in time.
Me too
geir
Re: [drlvm] finalizer design questions
Posted by Weldon Washburn <we...@gmail.com>.
On 12/29/06, Pavel Afremov <pa...@gmail.com> wrote:
>
> I've checked Weldon's finalization scheme and two existing schemes on
> Weldon's test in mode 1 and 2.
> On my Machine WinXP HT Pentium 4 I've got following results.
>
> Weldon's design (on my machine 2 threads with highest priority).
> Mode 1: 1/50 (main loop/finalizer call)
> Mode 2: 1/50 (main loop/finalizer call)
This looks good to me. Its close enough for the current state of drlvm. In
other words, don't try to precisely replicate the performance numbers I
collected from Sun 1.5.0.
Multithreading java scheme (old DRLVM scheme)
> Mode 1: 1/1 (main loop/finalizer call)
> Mode 2 1/250 (main loop/finalizer call)
> One native thread with highest priority (like new GC v5 scheme)
> Mode 1: 1/1 (main loop/finalizer call)
> Mode 2: 1/1 (main loop/finalizer call)
Its unclear if you actually ran GCv5 finalizer code or something "like new
GC v5 scheme". I don't know what the data means.
>From Weldon's data SUN 1.5.0 JVM has:
> Mode 1: 1/50 (main loop/finalizer call) (may be 1/90)
> Mode 2: 1/173 (main loop/finalizer call) (15 / 2600 = 1/173)
>
> As I understand the ideal finalization scheme should provide:
> Mode 1: 1/1 (main loop/finalizer call)
> Mode 2: 0/1 (main loop/finalizer call)
The point is that the "ideal finalization" design needs to be driven by what
important commercial workloads require. It will be a while before these
workloads run fast and stable on drlvm. In other words, drlvm is not yet
ready for investigating the final finalization scheme. Incidentally, the
data collected on Sun 1.5.0 contradicts the "ideal finalization scheme"
suggested above. Given a choice, I would rather do something similar to a
commercial JVM implementation at this point in time.
So relative performance of Weldon's scheme in mode 2 is not so high as for
> SUN 1.5.0 JVM 15/ 2600 = 1/173 (main loop/finalizer call).
I think you are talking about the difference between 1/50 and 1/173. In my
opinion, this difference is in the noise. Its not material.
I think that it can be improved by point 2 of my scheme (Using locks for
> stopping user threads)
As far as I can tell Sun 1.5.0 does not do this. Also, adding more thread
suspend/resume logic to dlrvm does not help stability and actually may
decrease stability.
or by increasing quantity of finalizer threads like
> in current scheme of finalization.
As far as I can tell Sun 1.5.0 does not do this. Until additional evidence
is available, I vote for the simplest possible finalizer scheme. This will
help us a bunch in sorting out the problems in drlvm threading subsystem.
Thanks.
> Pavel Afremov
>
> On 12/28/06, Pavel Afremov <pa...@gmail.com> wrote:
>
> > Did you check it on current implementation of DRLVM Finalization System?
> >
> > BR
> > Pavel Afremov.
> >
> >
> > On 12/28/06, Weldon Washburn <we...@gmail.com> wrote:
> > >
> > > On 12/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote
> > >
> > >
> > >
> > > > [snip]
> > >
> > >
> > >
> > >
> > >
> > > > Why can't we simply mimic the rational behavior of the RI and other
> > > > production VMs and leave it at that?
> > > >
> > > > geir
> > >
> > >
> > > I agree. To discover what other JVMs do, I created a very simple
> > > finalizer
> > > probe then put it in JIRA HARMONY-2908. I ran this probe on Sun JVM
> > > 1.5.0_07. Below are the results. It would be good if someone can
> run
> > > this
> > > probe on other JVM/OS combinations. The probe is single threaded and
> has
> > >
> > > three different execution modes ("java Finx 0", "java Finx 1" and
> "java
> > > Finx
> > > 2"). By running each of the modes on WindowsXP and using Microsoft's
> > > Process Viewer, one can learn what the different JVM threads are
> doing.
> > > More on this later.
> > >
> > > Mode 0
> > > This mode intentionally does not create any finalizable objects. The
> > > main()
> > > method simply runs a cpu intensive workload forever. After every
> > > 1000000
> > > loops main() will print a distinctive string that includes a loop
> count.
> > >
> > >
> > > Mode 1
> > > main() creates 100K finalizable objects that are intentionally shoved
> > > into a
> > > state where their finalizer needs to be called. main() then proceeds
> to
> > > run
> > > the same cpu intensive workload as above. The finalize() method will
> > > execute just one call of the same cpu intensive workload then
> > > returns. This
> > > simulates a short running finalizer. finalize() prints a distinctive
> > > string
> > > to make it easy to quickly read the output which is comingled with
> > > main().
> > >
> > > Mode 2
> > > This mode is identical to Mode 1 except the finalize() method calls
> the
> > > cpu
> > > intensive workload endlessly.
> > >
> > > The above describes how the probe is constructed. Below are
> > > observations
> > > from running this probe on Sun 1.5.0 JVM.
> > >
> > > Mode 0
> > >
> > > There are seven threads. Thread 0 consumes 99% of the total cpu
> > > time. And
> > > is executing in user mode 100% of the time. Most likely this is the
> > > java
> > > app thread running main(). All the remaining threads do not
> accumulate
> > > any
> > > significant cpu time.
> > >
> > >
> > >
> > > Mode 1
> > >
> > > There are seven threads. Thread 0 accumulates roughly 2% of total cpu
> > > time. Thread 3 accumulates the other 98%. Process Viewer reports
> > > Thread 3
> > > having "above normal" priority. (I have not chased down the mapping
> > > from
> > > Process Viewer priority to win API priority). At the top of the
> > > finalize()
> > > method a static variable is incremented then printed out. This allows
> > > us to
> > > watch a rolling count of how many objects have been
> finalized. Watching
> > > the
> > > console output for a few minutes, it looks like about 9000 objects are
> > > finalized in the same time period that main() completes 100
> > > loops. Since
> > > both main() and finalize() are running the same workload, it looks
> > > like Thread 3 with "above normal" priority is the thread running the
> > > finalizers. The disparity between 90:1 on console output and 50:1 in
> > > Process Viewer is probably sampling noise. Also, it looks like Thread
> 0
> > > is
> > > running main() just like it was in Mode 0.
> > >
> > >
> > >
> > > Mode 2
> > >
> > > Again the JVM is running exactly 7 threads. Only the one object's
> > > finalize() method is ever called. Process Viewer shows Thread 3 has
> > > "above
> > > normal" priority and accumulating roughly 99% of the cpu
> time. Watching
> > > the
> > > console output for a few minutes, it look like 2600 finalize() loops
> to
> > > 15
> > > main loops. It appears that no additional threads are created to
> handle
> > > to
> > > remaining 99,999 waiting finalizable objects. These objects appear
> to
> > > be
> > > blocked waiting for the first object to finish. Also it looks like
> > > Thread 0
> > > is running main() just like Mode 0 and 1. Given that Process Viewer
> > > shows
> > > that Thread 0 continuously and slowly accumulates CPU time, it appears
> > > that
> > > main() is not suspended but continues to make forward progress.
> > >
> > >
> >
>
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm] finalizer design questions
Posted by Pavel Afremov <pa...@gmail.com>.
Also this test shows that during printing many objects are created, maybe
include finalizable objects.
Could anybody run Weldon's test on current DRLVM implementation on the other
machine? The result ratio should be ready after 10 min of the run. It will
be very useful in the future.
Thanks
Pavel Afremov.
On 12/29/06, Pavel Afremov <pa...@gmail.com> wrote:
>
> I've checked Weldon's finalization scheme and two existing schemes on
> Weldon's test in mode 1 and 2.
> On my Machine WinXP HT Pentium 4 I've got following results.
>
> Weldon's design (on my machine 2 threads with highest priority).
> Mode 1: 1/50 (main loop/finalizer call)
> Mode 2: 1/50 (main loop/finalizer call)
> Multithreading java scheme (old DRLVM scheme)
> Mode 1: 1/1 (main loop/finalizer call)
> Mode 2 1/250 (main loop/finalizer call)
> One native thread with highest priority (like new GC v5 scheme)
> Mode 1: 1/1 (main loop/finalizer call)
> Mode 2: 1/1 (main loop/finalizer call)
>
> From Weldon's data SUN 1.5.0 JVM has:
> Mode 1: 1/50 (main loop/finalizer call) (may be 1/90)
> Mode 2: 1/173 (main loop/finalizer call) (15 / 2600 = 1/173)
>
> As I understand the ideal finalization scheme should provide:
> Mode 1: 1/1 (main loop/finalizer call)
> Mode 2: 0/1 (main loop/finalizer call)
>
> So relative performance of Weldon's scheme in mode 2 is not so high as
> for SUN 1.5.0 JVM 15/ 2600 = 1/173 (main loop/finalizer call).
>
> I think that it can be improved by point 2 of my scheme (Using locks for
> stopping user threads) or by increasing quantity of finalizer threads like
> in current scheme of finalization.
> Thanks.
> Pavel Afremov
>
> On 12/28/06, Pavel Afremov <pa...@gmail.com> wrote:
>
> > Did you check it on current implementation of DRLVM Finalization System?
> >
> >
> > BR
> > Pavel Afremov.
> >
> >
> > On 12/28/06, Weldon Washburn <weldonwjw@gmail.com > wrote:
> > >
> > > On 12/27/06, Geir Magnusson Jr. < geir@pobox.com> wrote
> > >
> > >
> > >
> > > > [snip]
> > >
> > >
> > >
> > >
> > >
> > > > Why can't we simply mimic the rational behavior of the RI and other
> > > > production VMs and leave it at that?
> > > >
> > > > geir
> > >
> > >
> > > I agree. To discover what other JVMs do, I created a very simple
> > > finalizer
> > > probe then put it in JIRA HARMONY-2908. I ran this probe on Sun JVM
> > > 1.5.0_07. Below are the results. It would be good if someone can
> > > run this
> > > probe on other JVM/OS combinations. The probe is single threaded and
> > > has
> > > three different execution modes ("java Finx 0", "java Finx 1" and
> > > "java Finx
> > > 2"). By running each of the modes on WindowsXP and using Microsoft's
> > > Process Viewer, one can learn what the different JVM threads are
> > > doing.
> > > More on this later.
> > >
> > > Mode 0
> > > This mode intentionally does not create any finalizable objects. The
> > > main()
> > > method simply runs a cpu intensive workload forever. After every
> > > 1000000
> > > loops main() will print a distinctive string that includes a loop
> > > count.
> > >
> > > Mode 1
> > > main() creates 100K finalizable objects that are intentionally shoved
> > > into a
> > > state where their finalizer needs to be called. main() then proceeds
> > > to run
> > > the same cpu intensive workload as above. The finalize() method will
> > > execute just one call of the same cpu intensive workload then
> > > returns. This
> > > simulates a short running finalizer. finalize() prints a distinctive
> > > string
> > > to make it easy to quickly read the output which is comingled with
> > > main().
> > >
> > > Mode 2
> > > This mode is identical to Mode 1 except the finalize() method calls
> > > the cpu
> > > intensive workload endlessly.
> > >
> > > The above describes how the probe is constructed. Below are
> > > observations
> > > from running this probe on Sun 1.5.0 JVM.
> > >
> > > Mode 0
> > >
> > > There are seven threads. Thread 0 consumes 99% of the total cpu
> > > time. And
> > > is executing in user mode 100% of the time. Most likely this is the
> > > java
> > > app thread running main(). All the remaining threads do not
> > > accumulate any
> > > significant cpu time.
> > >
> > >
> > >
> > > Mode 1
> > >
> > > There are seven threads. Thread 0 accumulates roughly 2% of total cpu
> > > time. Thread 3 accumulates the other 98%. Process Viewer reports
> > > Thread 3
> > > having "above normal" priority. (I have not chased down the mapping
> > > from
> > > Process Viewer priority to win API priority). At the top of the
> > > finalize()
> > > method a static variable is incremented then printed out. This allows
> > > us to
> > > watch a rolling count of how many objects have been
> > > finalized. Watching the
> > > console output for a few minutes, it looks like about 9000 objects are
> > > finalized in the same time period that main() completes 100
> > > loops. Since
> > > both main() and finalize() are running the same workload, it looks
> > > like Thread 3 with "above normal" priority is the thread running the
> > > finalizers. The disparity between 90:1 on console output and 50:1 in
> > > Process Viewer is probably sampling noise. Also, it looks like Thread
> > > 0 is
> > > running main() just like it was in Mode 0.
> > >
> > >
> > >
> > > Mode 2
> > >
> > > Again the JVM is running exactly 7 threads. Only the one object's
> > > finalize() method is ever called. Process Viewer shows Thread 3 has
> > > "above
> > > normal" priority and accumulating roughly 99% of the cpu
> > > time. Watching the
> > > console output for a few minutes, it look like 2600 finalize() loops
> > > to 15
> > > main loops. It appears that no additional threads are created to
> > > handle to
> > > remaining 99,999 waiting finalizable objects. These objects appear
> > > to be
> > > blocked waiting for the first object to finish. Also it looks like
> > > Thread 0
> > > is running main() just like Mode 0 and 1. Given that Process Viewer
> > > shows
> > > that Thread 0 continuously and slowly accumulates CPU time, it appears
> > > that
> > > main() is not suspended but continues to make forward progress.
> > >
> > >
> >
>
Re: [drlvm] finalizer design questions
Posted by Pavel Afremov <pa...@gmail.com>.
I've checked Weldon's finalization scheme and two existing schemes on
Weldon's test in mode 1 and 2.
On my Machine WinXP HT Pentium 4 I've got following results.
Weldon's design (on my machine 2 threads with highest priority).
Mode 1: 1/50 (main loop/finalizer call)
Mode 2: 1/50 (main loop/finalizer call)
Multithreading java scheme (old DRLVM scheme)
Mode 1: 1/1 (main loop/finalizer call)
Mode 2 1/250 (main loop/finalizer call)
One native thread with highest priority (like new GC v5 scheme)
Mode 1: 1/1 (main loop/finalizer call)
Mode 2: 1/1 (main loop/finalizer call)
>From Weldon's data SUN 1.5.0 JVM has:
Mode 1: 1/50 (main loop/finalizer call) (may be 1/90)
Mode 2: 1/173 (main loop/finalizer call) (15 / 2600 = 1/173)
As I understand the ideal finalization scheme should provide:
Mode 1: 1/1 (main loop/finalizer call)
Mode 2: 0/1 (main loop/finalizer call)
So relative performance of Weldon's scheme in mode 2 is not so high as for
SUN 1.5.0 JVM 15/ 2600 = 1/173 (main loop/finalizer call).
I think that it can be improved by point 2 of my scheme (Using locks for
stopping user threads) or by increasing quantity of finalizer threads like
in current scheme of finalization.
Thanks.
Pavel Afremov
On 12/28/06, Pavel Afremov <pa...@gmail.com> wrote:
> Did you check it on current implementation of DRLVM Finalization System?
>
> BR
> Pavel Afremov.
>
>
> On 12/28/06, Weldon Washburn <we...@gmail.com> wrote:
> >
> > On 12/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote
> >
> >
> >
> > > [snip]
> >
> >
> >
> >
> >
> > > Why can't we simply mimic the rational behavior of the RI and other
> > > production VMs and leave it at that?
> > >
> > > geir
> >
> >
> > I agree. To discover what other JVMs do, I created a very simple
> > finalizer
> > probe then put it in JIRA HARMONY-2908. I ran this probe on Sun JVM
> > 1.5.0_07. Below are the results. It would be good if someone can run
> > this
> > probe on other JVM/OS combinations. The probe is single threaded and has
> >
> > three different execution modes ("java Finx 0", "java Finx 1" and "java
> > Finx
> > 2"). By running each of the modes on WindowsXP and using Microsoft's
> > Process Viewer, one can learn what the different JVM threads are doing.
> > More on this later.
> >
> > Mode 0
> > This mode intentionally does not create any finalizable objects. The
> > main()
> > method simply runs a cpu intensive workload forever. After every
> > 1000000
> > loops main() will print a distinctive string that includes a loop count.
> >
> >
> > Mode 1
> > main() creates 100K finalizable objects that are intentionally shoved
> > into a
> > state where their finalizer needs to be called. main() then proceeds to
> > run
> > the same cpu intensive workload as above. The finalize() method will
> > execute just one call of the same cpu intensive workload then
> > returns. This
> > simulates a short running finalizer. finalize() prints a distinctive
> > string
> > to make it easy to quickly read the output which is comingled with
> > main().
> >
> > Mode 2
> > This mode is identical to Mode 1 except the finalize() method calls the
> > cpu
> > intensive workload endlessly.
> >
> > The above describes how the probe is constructed. Below are
> > observations
> > from running this probe on Sun 1.5.0 JVM.
> >
> > Mode 0
> >
> > There are seven threads. Thread 0 consumes 99% of the total cpu
> > time. And
> > is executing in user mode 100% of the time. Most likely this is the
> > java
> > app thread running main(). All the remaining threads do not accumulate
> > any
> > significant cpu time.
> >
> >
> >
> > Mode 1
> >
> > There are seven threads. Thread 0 accumulates roughly 2% of total cpu
> > time. Thread 3 accumulates the other 98%. Process Viewer reports
> > Thread 3
> > having "above normal" priority. (I have not chased down the mapping
> > from
> > Process Viewer priority to win API priority). At the top of the
> > finalize()
> > method a static variable is incremented then printed out. This allows
> > us to
> > watch a rolling count of how many objects have been finalized. Watching
> > the
> > console output for a few minutes, it looks like about 9000 objects are
> > finalized in the same time period that main() completes 100
> > loops. Since
> > both main() and finalize() are running the same workload, it looks
> > like Thread 3 with "above normal" priority is the thread running the
> > finalizers. The disparity between 90:1 on console output and 50:1 in
> > Process Viewer is probably sampling noise. Also, it looks like Thread 0
> > is
> > running main() just like it was in Mode 0.
> >
> >
> >
> > Mode 2
> >
> > Again the JVM is running exactly 7 threads. Only the one object's
> > finalize() method is ever called. Process Viewer shows Thread 3 has
> > "above
> > normal" priority and accumulating roughly 99% of the cpu time. Watching
> > the
> > console output for a few minutes, it look like 2600 finalize() loops to
> > 15
> > main loops. It appears that no additional threads are created to handle
> > to
> > remaining 99,999 waiting finalizable objects. These objects appear to
> > be
> > blocked waiting for the first object to finish. Also it looks like
> > Thread 0
> > is running main() just like Mode 0 and 1. Given that Process Viewer
> > shows
> > that Thread 0 continuously and slowly accumulates CPU time, it appears
> > that
> > main() is not suspended but continues to make forward progress.
> >
> >
>
Re: [drlvm] finalizer design questions
Posted by Pavel Afremov <pa...@gmail.com>.
Did you check it on current implementation of DRLVM Finalization System?
BR
Pavel Afremov.
On 12/28/06, Weldon Washburn <we...@gmail.com> wrote:
>
> On 12/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote
>
>
>
> > [snip]
>
>
>
>
>
> > Why can't we simply mimic the rational behavior of the RI and other
> > production VMs and leave it at that?
> >
> > geir
>
>
> I agree. To discover what other JVMs do, I created a very simple
> finalizer
> probe then put it in JIRA HARMONY-2908. I ran this probe on Sun JVM
> 1.5.0_07. Below are the results. It would be good if someone can run
> this
> probe on other JVM/OS combinations. The probe is single threaded and has
> three different execution modes ("java Finx 0", "java Finx 1" and "java
> Finx
> 2"). By running each of the modes on WindowsXP and using Microsoft's
> Process Viewer, one can learn what the different JVM threads are doing.
> More on this later.
>
> Mode 0
> This mode intentionally does not create any finalizable objects. The
> main()
> method simply runs a cpu intensive workload forever. After every 1000000
> loops main() will print a distinctive string that includes a loop count.
>
> Mode 1
> main() creates 100K finalizable objects that are intentionally shoved into
> a
> state where their finalizer needs to be called. main() then proceeds to
> run
> the same cpu intensive workload as above. The finalize() method will
> execute just one call of the same cpu intensive workload then
> returns. This
> simulates a short running finalizer. finalize() prints a distinctive
> string
> to make it easy to quickly read the output which is comingled with main().
>
> Mode 2
> This mode is identical to Mode 1 except the finalize() method calls the
> cpu
> intensive workload endlessly.
>
> The above describes how the probe is constructed. Below are observations
> from running this probe on Sun 1.5.0 JVM.
>
> Mode 0
>
> There are seven threads. Thread 0 consumes 99% of the total cpu
> time. And
> is executing in user mode 100% of the time. Most likely this is the java
> app thread running main(). All the remaining threads do not accumulate
> any
> significant cpu time.
>
>
>
> Mode 1
>
> There are seven threads. Thread 0 accumulates roughly 2% of total cpu
> time. Thread 3 accumulates the other 98%. Process Viewer reports Thread
> 3
> having "above normal" priority. (I have not chased down the mapping from
> Process Viewer priority to win API priority). At the top of the
> finalize()
> method a static variable is incremented then printed out. This allows us
> to
> watch a rolling count of how many objects have been finalized. Watching
> the
> console output for a few minutes, it looks like about 9000 objects are
> finalized in the same time period that main() completes 100 loops. Since
> both main() and finalize() are running the same workload, it looks
> like Thread 3 with "above normal" priority is the thread running the
> finalizers. The disparity between 90:1 on console output and 50:1 in
> Process Viewer is probably sampling noise. Also, it looks like Thread 0
> is
> running main() just like it was in Mode 0.
>
>
>
> Mode 2
>
> Again the JVM is running exactly 7 threads. Only the one object's
> finalize() method is ever called. Process Viewer shows Thread 3 has
> "above
> normal" priority and accumulating roughly 99% of the cpu time. Watching
> the
> console output for a few minutes, it look like 2600 finalize() loops to 15
> main loops. It appears that no additional threads are created to handle
> to
> remaining 99,999 waiting finalizable objects. These objects appear to be
> blocked waiting for the first object to finish. Also it looks like Thread
> 0
> is running main() just like Mode 0 and 1. Given that Process Viewer shows
> that Thread 0 continuously and slowly accumulates CPU time, it appears
> that
> main() is not suspended but continues to make forward progress.
>
>
Re: [drlvm] finalizer design questions
Posted by Pavel Afremov <pa...@gmail.com>.
JFYI
The current GC-finalization Subsystem interface and intercommoning
communication described in DevGuide. And now there are two finalization
implementation: multithreading one based on java thread and the other new
(created for GC5), based on 1 native thread.
On usual, multithreading implementation 1 "permanent" thread with normal
priority is created and this is enough. In heavy workloads additional treads
are created, but not many.
For example not more 4 under DeCapo on my machine. And it's pretty good on
HT P4.
Only in very stress situation more threads are created.
Also I know (by experiments) that 1 finalizer thread with any priority on
multi core machine is not enough.
Thanks
Pavel Afremov.
On 12/28/06, Rana Dasgupta <rd...@gmail.com> wrote:
> GCV5 does not need a custom finalizer. That is what would impact
> modularity.
> In fact, even that would not, if the interface were standardised.
> However, one would prefer GC's not to provide their own implementations
> for
> the interface since they are not fully aware of system load, and the GC
> dll
> can be unloaded in somewhat dynamic environments.
>
> All that has happened is that working on GCV5 has caused the current
> finalizer design/implementation to be reviewed.
>
> On 12/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> >
> > On Dec 28, 2006, at 11:33 AM, Rana Dasgupta wrote:
> >
> > > On 12/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >>
> > >>
> > >>
> > >> >Well, we need a finalizer. I agree that we're overthinking this a
> > >> >bit, but I'd like to understand why anyone thinks this belongs in
> > >> the
> > >> >GC - we keep claiming to do a modular VM, yet then do things like
> > >> >this... :)
> > >
> > >
> > > We can keep the minimal finalization implementation we have now ( a
> > > single
> > > high priority finalization thread ), and wait for use cases that
> > > need more.
> > > IMHO.
> > >
> > > The finalization subsystem is currently a VM component and the VM
> > > exposes
> > > the interface ( though minimal ) to the GC. This is the right way,
> > > and does
> > > not violate modularity or GC pluggability.
> >
> > So I don't understand what we are discussing - you seem to agree with
> > me that it belongs in the VM, and not the GC.
> >
> > This little discussion started because I was asking Xiaofeng why GCv5
> > had it's own finalization subsystem...
> >
> > geir
> >
> >
> >
> >
>
>
Re: [drlvm] finalizer design questions
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Dec 28, 2006, at 1:54 PM, Rana Dasgupta wrote:
> GCV5 does not need a custom finalizer. That is what would impact
> modularity.
> In fact, even that would not, if the interface were standardised.
> However, one would prefer GC's not to provide their own
> implementations for
> the interface since they are not fully aware of system load, and
> the GC dll
> can be unloaded in somewhat dynamic environments.
Exactly.
>
> All that has happened is that working on GCV5 has caused the current
> finalizer design/implementation to be reviewed.
I see. I was confused by the following from Xiao-Feng, which made me
think that the GVv5 had it's own finalizer subsystem.
On Dec 28, 2006, at 9:33 AM, Xiao-Feng Li wrote:
> Very interesting. Thanks for the probation. I think GCv5 finalization
> subsystem does similarly.
>
> On 12/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>>
>> On Dec 28, 2006, at 11:33 AM, Rana Dasgupta wrote:
>>
>> > On 12/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >>
>> >>
>> >>
>> >> >Well, we need a finalizer. I agree that we're overthinking
>> this a
>> >> >bit, but I'd like to understand why anyone thinks this belongs in
>> >> the
>> >> >GC - we keep claiming to do a modular VM, yet then do things like
>> >> >this... :)
>> >
>> >
>> > We can keep the minimal finalization implementation we have now ( a
>> > single
>> > high priority finalization thread ), and wait for use cases that
>> > need more.
>> > IMHO.
>> >
>> > The finalization subsystem is currently a VM component and the VM
>> > exposes
>> > the interface ( though minimal ) to the GC. This is the right way,
>> > and does
>> > not violate modularity or GC pluggability.
>>
>> So I don't understand what we are discussing - you seem to agree with
>> me that it belongs in the VM, and not the GC.
>>
>> This little discussion started because I was asking Xiaofeng why GCv5
>> had it's own finalization subsystem...
>>
>> geir
>>
>>
>>
>>
Re: [drlvm] finalizer design questions
Posted by Rana Dasgupta <rd...@gmail.com>.
GCV5 does not need a custom finalizer. That is what would impact modularity.
In fact, even that would not, if the interface were standardised.
However, one would prefer GC's not to provide their own implementations for
the interface since they are not fully aware of system load, and the GC dll
can be unloaded in somewhat dynamic environments.
All that has happened is that working on GCV5 has caused the current
finalizer design/implementation to be reviewed.
On 12/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> On Dec 28, 2006, at 11:33 AM, Rana Dasgupta wrote:
>
> > On 12/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >>
> >>
> >>
> >> >Well, we need a finalizer. I agree that we're overthinking this a
> >> >bit, but I'd like to understand why anyone thinks this belongs in
> >> the
> >> >GC - we keep claiming to do a modular VM, yet then do things like
> >> >this... :)
> >
> >
> > We can keep the minimal finalization implementation we have now ( a
> > single
> > high priority finalization thread ), and wait for use cases that
> > need more.
> > IMHO.
> >
> > The finalization subsystem is currently a VM component and the VM
> > exposes
> > the interface ( though minimal ) to the GC. This is the right way,
> > and does
> > not violate modularity or GC pluggability.
>
> So I don't understand what we are discussing - you seem to agree with
> me that it belongs in the VM, and not the GC.
>
> This little discussion started because I was asking Xiaofeng why GCv5
> had it's own finalization subsystem...
>
> geir
>
>
>
>
Re: [drlvm] finalizer design questions
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Dec 28, 2006, at 11:33 AM, Rana Dasgupta wrote:
> On 12/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>>
>>
>> >Well, we need a finalizer. I agree that we're overthinking this a
>> >bit, but I'd like to understand why anyone thinks this belongs in
>> the
>> >GC - we keep claiming to do a modular VM, yet then do things like
>> >this... :)
>
>
> We can keep the minimal finalization implementation we have now ( a
> single
> high priority finalization thread ), and wait for use cases that
> need more.
> IMHO.
>
> The finalization subsystem is currently a VM component and the VM
> exposes
> the interface ( though minimal ) to the GC. This is the right way,
> and does
> not violate modularity or GC pluggability.
So I don't understand what we are discussing - you seem to agree with
me that it belongs in the VM, and not the GC.
This little discussion started because I was asking Xiaofeng why GCv5
had it's own finalization subsystem...
geir
Re: [drlvm] finalizer design questions
Posted by Rana Dasgupta <rd...@gmail.com>.
On 12/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
>
> >Well, we need a finalizer. I agree that we're overthinking this a
> >bit, but I'd like to understand why anyone thinks this belongs in the
> >GC - we keep claiming to do a modular VM, yet then do things like
> >this... :)
We can keep the minimal finalization implementation we have now ( a single
high priority finalization thread ), and wait for use cases that need more.
IMHO.
The finalization subsystem is currently a VM component and the VM exposes
the interface ( though minimal ) to the GC. This is the right way, and does
not violate modularity or GC pluggability.
Re: [drlvm] finalizer design questions
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Dec 28, 2006, at 11:01 AM, Rana Dasgupta wrote:
> On 12/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>>
>>
>> >Question - why would this be part of the GC system, rather than a VM
>> >facility that the GC uses?
>
>
> It is a VM faciity, but the only consumer is the GC. So it doesn't
> matter
> where the code lives.
really? We're claiming that we do pluggable GC, so I do think it
matters. Also, doesn't this tie all sorts of user-thread priority
management and balancing issues into the GC codebase?
>
> Finalization is hardly ever used intensively by real apps, as far
> as I know,
agreed
> except to release unmanaged resources that can't wait for process
> teardown.
I doubt people even do that.
> We may be overthinking the design. I don't see a problem with
> Weldon's per
> cpu idea( though I don't know if one can assume that the JVM can
> control
> thread scheduling, it depends on how the JVM is hosted ). I think
> that it is
> OK to fail with out of memory for a badly written app. As mentioned
> elsewhere, I think, I would suggest waiting for a real problem to
> surface
> with an app or a benchmark we care about before trying to come up
> with the
> design that will solve it.
Well, we need a finalizer. I agree that we're overthinking this a
bit, but I'd like to understand why anyone thinks this belongs in the
GC - we keep claiming to do a modular VM, yet then do things like
this... :)
geir
Re: [drlvm] finalizer design questions
Posted by Rana Dasgupta <rd...@gmail.com>.
On 12/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
>
> >Question - why would this be part of the GC system, rather than a VM
> >facility that the GC uses?
It is a VM faciity, but the only consumer is the GC. So it doesn't matter
where the code lives.
Finalization is hardly ever used intensively by real apps, as far as I know,
except to release unmanaged resources that can't wait for process teardown.
We may be overthinking the design. I don't see a problem with Weldon's per
cpu idea( though I don't know if one can assume that the JVM can control
thread scheduling, it depends on how the JVM is hosted ). I think that it is
OK to fail with out of memory for a badly written app. As mentioned
elsewhere, I think, I would suggest waiting for a real problem to surface
with an app or a benchmark we care about before trying to come up with the
design that will solve it.
Re: [drlvm] finalizer design questions
Posted by Pavel Afremov <pa...@gmail.com>.
+1 Why?
It should be VM subsystem or independent component, I believe.
BR
Pavel Afremov.
On 12/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> On Dec 28, 2006, at 9:33 AM, Xiao-Feng Li wrote:
>
> > On 12/28/06, Weldon Washburn <we...@gmail.com> wrote:
> >> On 12/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote
> >>
>
> [SNIP]
>
>
> >> Mode 2
> >>
> >> Again the JVM is running exactly 7 threads. Only the one object's
> >> finalize() method is ever called. Process Viewer shows Thread 3
> >> has "above
> >> normal" priority and accumulating roughly 99% of the cpu time.
> >> Watching the
> >> console output for a few minutes, it look like 2600 finalize()
> >> loops to 15
> >> main loops. It appears that no additional threads are created to
> >> handle to
> >> remaining 99,999 waiting finalizable objects. These objects
> >> appear to be
> >> blocked waiting for the first object to finish. Also it looks like
> >> Thread 0
> >> is running main() just like Mode 0 and 1. Given that Process
> >> Viewer shows
> >> that Thread 0 continuously and slowly accumulates CPU time, it
> >> appears that
> >> main() is not suspended but continues to make forward progress.
> >>
> >
> > Very interesting. Thanks for the probation. I think GCv5 finalization
> > subsystem does similarly.
>
> Question - why would this be part of the GC system, rather than a VM
> facility that the GC uses?
>
> geir
>
>
>
>
Re: [drlvm] finalizer design questions
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Dec 28, 2006, at 9:33 AM, Xiao-Feng Li wrote:
> On 12/28/06, Weldon Washburn <we...@gmail.com> wrote:
>> On 12/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote
>>
[SNIP]
>> Mode 2
>>
>> Again the JVM is running exactly 7 threads. Only the one object's
>> finalize() method is ever called. Process Viewer shows Thread 3
>> has "above
>> normal" priority and accumulating roughly 99% of the cpu time.
>> Watching the
>> console output for a few minutes, it look like 2600 finalize()
>> loops to 15
>> main loops. It appears that no additional threads are created to
>> handle to
>> remaining 99,999 waiting finalizable objects. These objects
>> appear to be
>> blocked waiting for the first object to finish. Also it looks like
>> Thread 0
>> is running main() just like Mode 0 and 1. Given that Process
>> Viewer shows
>> that Thread 0 continuously and slowly accumulates CPU time, it
>> appears that
>> main() is not suspended but continues to make forward progress.
>>
>
> Very interesting. Thanks for the probation. I think GCv5 finalization
> subsystem does similarly.
Question - why would this be part of the GC system, rather than a VM
facility that the GC uses?
geir
Re: [drlvm] finalizer design questions
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 12/28/06, Weldon Washburn <we...@gmail.com> wrote:
> On 12/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote
>
>
>
> > [snip]
>
>
>
>
>
> > Why can't we simply mimic the rational behavior of the RI and other
> > production VMs and leave it at that?
> >
> > geir
>
>
> I agree. To discover what other JVMs do, I created a very simple finalizer
> probe then put it in JIRA HARMONY-2908. I ran this probe on Sun JVM
> 1.5.0_07. Below are the results. It would be good if someone can run this
> probe on other JVM/OS combinations. The probe is single threaded and has
> three different execution modes ("java Finx 0", "java Finx 1" and "java Finx
> 2"). By running each of the modes on WindowsXP and using Microsoft's
> Process Viewer, one can learn what the different JVM threads are doing.
> More on this later.
>
> Mode 0
> This mode intentionally does not create any finalizable objects. The main()
> method simply runs a cpu intensive workload forever. After every 1000000
> loops main() will print a distinctive string that includes a loop count.
>
> Mode 1
> main() creates 100K finalizable objects that are intentionally shoved into a
> state where their finalizer needs to be called. main() then proceeds to run
> the same cpu intensive workload as above. The finalize() method will
> execute just one call of the same cpu intensive workload then returns. This
> simulates a short running finalizer. finalize() prints a distinctive string
> to make it easy to quickly read the output which is comingled with main().
>
> Mode 2
> This mode is identical to Mode 1 except the finalize() method calls the cpu
> intensive workload endlessly.
>
> The above describes how the probe is constructed. Below are observations
> from running this probe on Sun 1.5.0 JVM.
>
> Mode 0
>
> There are seven threads. Thread 0 consumes 99% of the total cpu time. And
> is executing in user mode 100% of the time. Most likely this is the java
> app thread running main(). All the remaining threads do not accumulate any
> significant cpu time.
>
>
>
> Mode 1
>
> There are seven threads. Thread 0 accumulates roughly 2% of total cpu
> time. Thread 3 accumulates the other 98%. Process Viewer reports Thread 3
> having "above normal" priority. (I have not chased down the mapping from
> Process Viewer priority to win API priority). At the top of the finalize()
> method a static variable is incremented then printed out. This allows us to
> watch a rolling count of how many objects have been finalized. Watching the
> console output for a few minutes, it looks like about 9000 objects are
> finalized in the same time period that main() completes 100 loops. Since
> both main() and finalize() are running the same workload, it looks
> like Thread 3 with "above normal" priority is the thread running the
> finalizers. The disparity between 90:1 on console output and 50:1 in
> Process Viewer is probably sampling noise. Also, it looks like Thread 0 is
> running main() just like it was in Mode 0.
>
>
>
> Mode 2
>
> Again the JVM is running exactly 7 threads. Only the one object's
> finalize() method is ever called. Process Viewer shows Thread 3 has "above
> normal" priority and accumulating roughly 99% of the cpu time. Watching the
> console output for a few minutes, it look like 2600 finalize() loops to 15
> main loops. It appears that no additional threads are created to handle to
> remaining 99,999 waiting finalizable objects. These objects appear to be
> blocked waiting for the first object to finish. Also it looks like Thread 0
> is running main() just like Mode 0 and 1. Given that Process Viewer shows
> that Thread 0 continuously and slowly accumulates CPU time, it appears that
> main() is not suspended but continues to make forward progress.
>
Very interesting. Thanks for the probation. I think GCv5 finalization
subsystem does similarly.
Thanks,
xiaofeng
Re: [drlvm] finalizer design questions
Posted by Weldon Washburn <we...@gmail.com>.
On 12/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> On Dec 27, 2006, at 9:34 PM, Weldon Washburn wrote:
>
> > On 12/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote
> >
> >
> >
> >> [snip]
> >
> >> Why can't we simply mimic the rational behavior of the RI and other
> >> production VMs and leave it at that?
> >>
> >> geir
> >
> >
> > I agree. To discover what other JVMs do, I created a very simple
> > finalizer
> > probe then put it in JIRA HARMONY-2908.
>
> Um. Why not just commit? :) Put in in the tools (not jdktools)
> compomnent
>
> https://svn.apache.org/...../enhanced/tools/trunk
Good idea. I committed Finx.java and a cleaned up README.txt to:
.......enhanced/tools/trunk/finalizer_probe/
HARMONY-2908 has been closed.
Re: [drlvm] finalizer design questions
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Dec 27, 2006, at 9:34 PM, Weldon Washburn wrote:
> On 12/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote
>
>
>
>> [snip]
>
>
>
>
>
>> Why can't we simply mimic the rational behavior of the RI and other
>> production VMs and leave it at that?
>>
>> geir
>
>
> I agree. To discover what other JVMs do, I created a very simple
> finalizer
> probe then put it in JIRA HARMONY-2908.
Um. Why not just commit? :) Put in in the tools (not jdktools)
compomnent
https://svn.apache.org/...../enhanced/tools/trunk
> I ran this probe on Sun JVM
> 1.5.0_07. Below are the results. It would be good if someone can
> run this
> probe on other JVM/OS combinations. The probe is single threaded
> and has
> three different execution modes ("java Finx 0", "java Finx 1" and
> "java Finx
> 2"). By running each of the modes on WindowsXP and using Microsoft's
> Process Viewer, one can learn what the different JVM threads are
> doing.
> More on this later.
This is great. Can you try it w/ J9 and JRockit?
>
> Mode 0
> This mode intentionally does not create any finalizable objects.
> The main()
> method simply runs a cpu intensive workload forever. After every
> 1000000
> loops main() will print a distinctive string that includes a loop
> count.
>
> Mode 1
> main() creates 100K finalizable objects that are intentionally
> shoved into a
> state where their finalizer needs to be called. main() then
> proceeds to run
> the same cpu intensive workload as above. The finalize() method will
> execute just one call of the same cpu intensive workload then
> returns. This
> simulates a short running finalizer. finalize() prints a
> distinctive string
> to make it easy to quickly read the output which is comingled with
> main().
>
> Mode 2
> This mode is identical to Mode 1 except the finalize() method calls
> the cpu
> intensive workload endlessly.
>
> The above describes how the probe is constructed. Below are
> observations
> from running this probe on Sun 1.5.0 JVM.
>
> Mode 0
>
> There are seven threads. Thread 0 consumes 99% of the total cpu
> time. And
> is executing in user mode 100% of the time. Most likely this is
> the java
> app thread running main(). All the remaining threads do not
> accumulate any
> significant cpu time.
>
>
>
> Mode 1
>
> There are seven threads. Thread 0 accumulates roughly 2% of total cpu
> time. Thread 3 accumulates the other 98%. Process Viewer reports
> Thread 3
> having "above normal" priority. (I have not chased down the
> mapping from
> Process Viewer priority to win API priority). At the top of the
> finalize()
> method a static variable is incremented then printed out. This
> allows us to
> watch a rolling count of how many objects have been finalized.
> Watching the
> console output for a few minutes, it looks like about 9000 objects are
> finalized in the same time period that main() completes 100 loops.
> Since
> both main() and finalize() are running the same workload, it looks
> like Thread 3 with "above normal" priority is the thread running the
> finalizers. The disparity between 90:1 on console output and 50:1 in
> Process Viewer is probably sampling noise. Also, it looks like
> Thread 0 is
> running main() just like it was in Mode 0.
>
>
>
> Mode 2
>
> Again the JVM is running exactly 7 threads. Only the one object's
> finalize() method is ever called. Process Viewer shows Thread 3
> has "above
> normal" priority and accumulating roughly 99% of the cpu time.
> Watching the
> console output for a few minutes, it look like 2600 finalize()
> loops to 15
> main loops. It appears that no additional threads are created to
> handle to
> remaining 99,999 waiting finalizable objects. These objects
> appear to be
> blocked waiting for the first object to finish. Also it looks like
> Thread 0
> is running main() just like Mode 0 and 1. Given that Process
> Viewer shows
> that Thread 0 continuously and slowly accumulates CPU time, it
> appears that
> main() is not suspended but continues to make forward progress.
Re: [drlvm] finalizer design questions
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Wow - same number of threads? I'd have never guessed that.
geir
On Dec 28, 2006, at 6:26 AM, Tim Ellison wrote:
> I ran your test on IBM Java 5.0, and saw similar results. I was using
> the SysInternals processViewer so the details may not quite match up,
> but in each case there were seven threads created, and the scenario
> you
> described below of threads making progress appear to jive with my
> observations. Let me know if you want some specific info.
>
> Regards,
> Tim
>
> Weldon Washburn wrote:
>> On 12/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote
>>
>>
>>
>>> [snip]
>>
>>
>>
>>
>>
>>> Why can't we simply mimic the rational behavior of the RI and other
>>> production VMs and leave it at that?
>>>
>>> geir
>>
>>
>> I agree. To discover what other JVMs do, I created a very simple
>> finalizer
>> probe then put it in JIRA HARMONY-2908. I ran this probe on Sun JVM
>> 1.5.0_07. Below are the results. It would be good if someone
>> can run
>> this
>> probe on other JVM/OS combinations. The probe is single threaded
>> and has
>> three different execution modes ("java Finx 0", "java Finx 1" and
>> "java
>> Finx
>> 2"). By running each of the modes on WindowsXP and using Microsoft's
>> Process Viewer, one can learn what the different JVM threads are
>> doing.
>> More on this later.
>>
>> Mode 0
>> This mode intentionally does not create any finalizable objects. The
>> main()
>> method simply runs a cpu intensive workload forever. After every
>> 1000000
>> loops main() will print a distinctive string that includes a loop
>> count.
>>
>> Mode 1
>> main() creates 100K finalizable objects that are intentionally shoved
>> into a
>> state where their finalizer needs to be called. main() then
>> proceeds to
>> run
>> the same cpu intensive workload as above. The finalize() method will
>> execute just one call of the same cpu intensive workload then
>> returns.
>> This
>> simulates a short running finalizer. finalize() prints a distinctive
>> string
>> to make it easy to quickly read the output which is comingled with
>> main().
>>
>> Mode 2
>> This mode is identical to Mode 1 except the finalize() method
>> calls the cpu
>> intensive workload endlessly.
>>
>> The above describes how the probe is constructed. Below are
>> observations
>> from running this probe on Sun 1.5.0 JVM.
>>
>> Mode 0
>>
>> There are seven threads. Thread 0 consumes 99% of the total cpu
>> time. And
>> is executing in user mode 100% of the time. Most likely this is
>> the java
>> app thread running main(). All the remaining threads do not
>> accumulate any
>> significant cpu time.
>>
>>
>>
>> Mode 1
>>
>> There are seven threads. Thread 0 accumulates roughly 2% of total
>> cpu
>> time. Thread 3 accumulates the other 98%. Process Viewer reports
>> Thread 3
>> having "above normal" priority. (I have not chased down the
>> mapping from
>> Process Viewer priority to win API priority). At the top of the
>> finalize()
>> method a static variable is incremented then printed out. This
>> allows
>> us to
>> watch a rolling count of how many objects have been finalized.
>> Watching
>> the
>> console output for a few minutes, it looks like about 9000 objects
>> are
>> finalized in the same time period that main() completes 100
>> loops. Since
>> both main() and finalize() are running the same workload, it looks
>> like Thread 3 with "above normal" priority is the thread running the
>> finalizers. The disparity between 90:1 on console output and 50:1 in
>> Process Viewer is probably sampling noise. Also, it looks like
>> Thread 0 is
>> running main() just like it was in Mode 0.
>>
>>
>>
>> Mode 2
>>
>> Again the JVM is running exactly 7 threads. Only the one object's
>> finalize() method is ever called. Process Viewer shows Thread 3
>> has "above
>> normal" priority and accumulating roughly 99% of the cpu time.
>> Watching
>> the
>> console output for a few minutes, it look like 2600 finalize()
>> loops to 15
>> main loops. It appears that no additional threads are created to
>> handle to
>> remaining 99,999 waiting finalizable objects. These objects
>> appear to be
>> blocked waiting for the first object to finish. Also it looks like
>> Thread 0
>> is running main() just like Mode 0 and 1. Given that Process
>> Viewer shows
>> that Thread 0 continuously and slowly accumulates CPU time, it
>> appears that
>> main() is not suspended but continues to make forward progress.
>>
Re: [drlvm] finalizer design questions
Posted by Tim Ellison <t....@gmail.com>.
I ran your test on IBM Java 5.0, and saw similar results. I was using
the SysInternals processViewer so the details may not quite match up,
but in each case there were seven threads created, and the scenario you
described below of threads making progress appear to jive with my
observations. Let me know if you want some specific info.
Regards,
Tim
Weldon Washburn wrote:
> On 12/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote
>
>
>
>> [snip]
>
>
>
>
>
>> Why can't we simply mimic the rational behavior of the RI and other
>> production VMs and leave it at that?
>>
>> geir
>
>
> I agree. To discover what other JVMs do, I created a very simple finalizer
> probe then put it in JIRA HARMONY-2908. I ran this probe on Sun JVM
> 1.5.0_07. Below are the results. It would be good if someone can run
> this
> probe on other JVM/OS combinations. The probe is single threaded and has
> three different execution modes ("java Finx 0", "java Finx 1" and "java
> Finx
> 2"). By running each of the modes on WindowsXP and using Microsoft's
> Process Viewer, one can learn what the different JVM threads are doing.
> More on this later.
>
> Mode 0
> This mode intentionally does not create any finalizable objects. The
> main()
> method simply runs a cpu intensive workload forever. After every 1000000
> loops main() will print a distinctive string that includes a loop count.
>
> Mode 1
> main() creates 100K finalizable objects that are intentionally shoved
> into a
> state where their finalizer needs to be called. main() then proceeds to
> run
> the same cpu intensive workload as above. The finalize() method will
> execute just one call of the same cpu intensive workload then returns.
> This
> simulates a short running finalizer. finalize() prints a distinctive
> string
> to make it easy to quickly read the output which is comingled with main().
>
> Mode 2
> This mode is identical to Mode 1 except the finalize() method calls the cpu
> intensive workload endlessly.
>
> The above describes how the probe is constructed. Below are observations
> from running this probe on Sun 1.5.0 JVM.
>
> Mode 0
>
> There are seven threads. Thread 0 consumes 99% of the total cpu time. And
> is executing in user mode 100% of the time. Most likely this is the java
> app thread running main(). All the remaining threads do not accumulate any
> significant cpu time.
>
>
>
> Mode 1
>
> There are seven threads. Thread 0 accumulates roughly 2% of total cpu
> time. Thread 3 accumulates the other 98%. Process Viewer reports Thread 3
> having "above normal" priority. (I have not chased down the mapping from
> Process Viewer priority to win API priority). At the top of the finalize()
> method a static variable is incremented then printed out. This allows
> us to
> watch a rolling count of how many objects have been finalized. Watching
> the
> console output for a few minutes, it looks like about 9000 objects are
> finalized in the same time period that main() completes 100 loops. Since
> both main() and finalize() are running the same workload, it looks
> like Thread 3 with "above normal" priority is the thread running the
> finalizers. The disparity between 90:1 on console output and 50:1 in
> Process Viewer is probably sampling noise. Also, it looks like Thread 0 is
> running main() just like it was in Mode 0.
>
>
>
> Mode 2
>
> Again the JVM is running exactly 7 threads. Only the one object's
> finalize() method is ever called. Process Viewer shows Thread 3 has "above
> normal" priority and accumulating roughly 99% of the cpu time. Watching
> the
> console output for a few minutes, it look like 2600 finalize() loops to 15
> main loops. It appears that no additional threads are created to handle to
> remaining 99,999 waiting finalizable objects. These objects appear to be
> blocked waiting for the first object to finish. Also it looks like Thread 0
> is running main() just like Mode 0 and 1. Given that Process Viewer shows
> that Thread 0 continuously and slowly accumulates CPU time, it appears that
> main() is not suspended but continues to make forward progress.
>
Re: [drlvm] finalizer design questions
Posted by Weldon Washburn <we...@gmail.com>.
On 12/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote
> [snip]
> Why can't we simply mimic the rational behavior of the RI and other
> production VMs and leave it at that?
>
> geir
I agree. To discover what other JVMs do, I created a very simple finalizer
probe then put it in JIRA HARMONY-2908. I ran this probe on Sun JVM
1.5.0_07. Below are the results. It would be good if someone can run this
probe on other JVM/OS combinations. The probe is single threaded and has
three different execution modes ("java Finx 0", "java Finx 1" and "java Finx
2"). By running each of the modes on WindowsXP and using Microsoft's
Process Viewer, one can learn what the different JVM threads are doing.
More on this later.
Mode 0
This mode intentionally does not create any finalizable objects. The main()
method simply runs a cpu intensive workload forever. After every 1000000
loops main() will print a distinctive string that includes a loop count.
Mode 1
main() creates 100K finalizable objects that are intentionally shoved into a
state where their finalizer needs to be called. main() then proceeds to run
the same cpu intensive workload as above. The finalize() method will
execute just one call of the same cpu intensive workload then returns. This
simulates a short running finalizer. finalize() prints a distinctive string
to make it easy to quickly read the output which is comingled with main().
Mode 2
This mode is identical to Mode 1 except the finalize() method calls the cpu
intensive workload endlessly.
The above describes how the probe is constructed. Below are observations
from running this probe on Sun 1.5.0 JVM.
Mode 0
There are seven threads. Thread 0 consumes 99% of the total cpu time. And
is executing in user mode 100% of the time. Most likely this is the java
app thread running main(). All the remaining threads do not accumulate any
significant cpu time.
Mode 1
There are seven threads. Thread 0 accumulates roughly 2% of total cpu
time. Thread 3 accumulates the other 98%. Process Viewer reports Thread 3
having "above normal" priority. (I have not chased down the mapping from
Process Viewer priority to win API priority). At the top of the finalize()
method a static variable is incremented then printed out. This allows us to
watch a rolling count of how many objects have been finalized. Watching the
console output for a few minutes, it looks like about 9000 objects are
finalized in the same time period that main() completes 100 loops. Since
both main() and finalize() are running the same workload, it looks
like Thread 3 with "above normal" priority is the thread running the
finalizers. The disparity between 90:1 on console output and 50:1 in
Process Viewer is probably sampling noise. Also, it looks like Thread 0 is
running main() just like it was in Mode 0.
Mode 2
Again the JVM is running exactly 7 threads. Only the one object's
finalize() method is ever called. Process Viewer shows Thread 3 has "above
normal" priority and accumulating roughly 99% of the cpu time. Watching the
console output for a few minutes, it look like 2600 finalize() loops to 15
main loops. It appears that no additional threads are created to handle to
remaining 99,999 waiting finalizable objects. These objects appear to be
blocked waiting for the first object to finish. Also it looks like Thread 0
is running main() just like Mode 0 and 1. Given that Process Viewer shows
that Thread 0 continuously and slowly accumulates CPU time, it appears that
main() is not suspended but continues to make forward progress.
Re: [drlvm] finalizer design questions
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Dec 26, 2006, at 8:30 PM, Xiao-Feng Li wrote:
> On 12/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>> On Dec 26, 2006, at 10:53 AM, Weldon Washburn wrote:
>>
>>
>> >
>> > 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.
Right - the finalizer can't actually know.
>
> 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.
Why can't we simply mimic the rational behavior of the RI and other
production VMs and leave it at that?
geir
Re: [drlvm] finalizer design questions
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 12/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> On Dec 26, 2006, at 10:53 AM, Weldon Washburn wrote:
>
> > On 12/26/06, Gregory Shimansky <gs...@gmail.com> wrote:
> >>
> >> 2006/12/26, Weldon Washburn <we...@gmail.com>:
> >> >
> >> > On 12/25/06, Gregory Shimansky <gs...@gmail.com> wrote:
> >> > >
> >> > > Weldon Washburn wrote:
> >> > > > On 12/24/06, Gregory Shimansky <gs...@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
>
>
Re: [drlvm] finalizer design questions
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Dec 26, 2006, at 10:53 AM, Weldon Washburn wrote:
> On 12/26/06, Gregory Shimansky <gs...@gmail.com> wrote:
>>
>> 2006/12/26, Weldon Washburn <we...@gmail.com>:
>> >
>> > On 12/25/06, Gregory Shimansky <gs...@gmail.com> wrote:
>> > >
>> > > Weldon Washburn wrote:
>> > > > On 12/24/06, Gregory Shimansky <gs...@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.
geir
Re: [drlvm] finalizer design questions
Posted by Weldon Washburn <we...@gmail.com>.
On 12/26/06, Gregory Shimansky <gs...@gmail.com> wrote:
>
> 2006/12/26, Weldon Washburn <we...@gmail.com>:
> >
> > On 12/25/06, Gregory Shimansky <gs...@gmail.com> wrote:
> > >
> > > Weldon Washburn wrote:
> > > > On 12/24/06, Gregory Shimansky <gs...@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.
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.
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.
5)
How are real java apps designed? What do they really use finalizer for?
--
> Gregory
>
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm] finalizer design questions
Posted by Gregory Shimansky <gs...@gmail.com>.
2006/12/26, Weldon Washburn <we...@gmail.com>:
>
> On 12/25/06, Gregory Shimansky <gs...@gmail.com> wrote:
> >
> > Weldon Washburn wrote:
> > > On 12/24/06, Gregory Shimansky <gs...@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.
--
Gregory
Re: [drlvm] finalizer design questions
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 12/26/06, Weldon Washburn <we...@gmail.com> wrote:
> On 12/25/06, Gregory Shimansky <gs...@gmail.com> wrote:
> >
> > Weldon Washburn wrote:
> > > On 12/24/06, Gregory Shimansky <gs...@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.
Thanks,
xiaofeng
> 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
>
>
Re: [drlvm] finalizer design questions
Posted by Weldon Washburn <we...@gmail.com>.
On 12/25/06, Gregory Shimansky <gs...@gmail.com> wrote:
>
> Weldon Washburn wrote:
> > On 12/24/06, Gregory Shimansky <gs...@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".
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.
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
Re: [drlvm] finalizer design questions
Posted by Gregory Shimansky <gs...@gmail.com>.
Weldon Washburn wrote:
> On 12/24/06, Gregory Shimansky <gs...@gmail.com> wrote:
>>
>> On Sunday 24 December 2006 16:23 Weldon Washburn wrote:
>> > Very interesting. Please tell me if the following is correct. Without
>> > WBS, finalizing objects falls further and further behind because
>> > finalization thread(s) are unable to grab enough of the CPU(s) to keep
>> up.
>> > Instead of increasing the priority of the finalization thread(s), WBS
>> takes
>> > the approach of increasing the number of finalization threads. The net
>> > effect is to increase the rate of finalization by diluting the OS ready
>> > queue.
>> >
>> > Does the following alternative design make sense? Assume the OS/VM
>> porting
>> > layer allows the VM to change an OS thread's priority appropriately.
>> > During VM boot, query the OS to determine the number of CPUs in the box
>> and
>> > create one finalizer thread for each CPU. Never create additional
>> > finalizer threads. Boost the priority of the finalizer threads above
>> the
>> > level of Java app threads (but probably below real time priority.)
>> Note
>> > that all of this is orthogonal to "native" vs. "java" finalizer
>> threads.
>>
>>
>> I like this approach. It probably covers all mentioned problems except
>> for
>> the
>> fundamental finalizers problem of long running (never ending) finalize()
>
>
> To answer this question, I build a simple single thread finalizer test. It
> causes the JVM to call a finalize() method that does a never ending CPU
> intensive task. Every 10 million iterations, this method prints out an
> iteration count. While finalize() is running, main() executes a second
> copy
> of exactly the same workload. main()'s print statement is slightly
> different so that its easy to sort out the comingled output.
>
> I ran the above workload on a product JVM on a single CPU laptop and
> observed the following. The print statements of main() and finalize() are
> indeed comingled. This suggests that the JVM runs finalize() in a seperate
> thread. The test ran for a rough approximation of eternity (I killed the
> test after 30 minutes). This suggests that the JVM is never supposed to
> kill a long running finalizer. In other words, the finalizer is
> supposed to
> run as long as it wants. This utility of building an app that contains a
> finalizer that consumes vast quantities of CPU time is an entirely
> different
> issue from JVM architecture.
>
> There were about 40 finalize() print statements to one main() print
> statement. In other words, the finalize() method consumed about 97% of the
> CPU and main() got the remaining 3%. Given the workloads are identical,
> one
> explanation for the above is that the JVM is setting its finalizer thread
> priority higher than normal Java threads. I don't know the current
> windowsXP thread sched algorithm but my guess that is that it has some
> notion of "nice" which allows lower priority threads to run once every
> 30 or
> 40 thread sched ticks.
>
> If DRLVM were ever ported to an OS that did not have a "nice" thread sched
> algorithm, we could simply move the finalizer thread priority back to
> normal.
>
> In other words, I don't yet see evidence that my original proposal is
> incorrect. Sorry for the long explanation.
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?
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
Re: [drlvm] finalizer design questions
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Dec 25, 2006, at 5:45 PM, Weldon Washburn wrote:
> On 12/24/06, Gregory Shimansky <gs...@gmail.com> wrote:
>>
>> On Sunday 24 December 2006 16:23 Weldon Washburn wrote:
>> > Very interesting. Please tell me if the following is correct.
>> Without
>> > WBS, finalizing objects falls further and further behind because
>> > finalization thread(s) are unable to grab enough of the CPU(s)
>> to keep
>> up.
>> > Instead of increasing the priority of the finalization thread
>> (s), WBS
>> takes
>> > the approach of increasing the number of finalization threads.
>> The net
>> > effect is to increase the rate of finalization by diluting the
>> OS ready
>> > queue.
>> >
>> > Does the following alternative design make sense? Assume the OS/VM
>> porting
>> > layer allows the VM to change an OS thread's priority
>> appropriately.
>> > During VM boot, query the OS to determine the number of CPUs in
>> the box
>> and
>> > create one finalizer thread for each CPU. Never create additional
>> > finalizer threads. Boost the priority of the finalizer threads
>> above
>> the
>> > level of Java app threads (but probably below real time
>> priority.) Note
>> > that all of this is orthogonal to "native" vs. "java" finalizer
>> threads.
>>
>>
>> I like this approach. It probably covers all mentioned problems
>> except for
>> the
>> fundamental finalizers problem of long running (never ending)
>> finalize()
>
>
> To answer this question, I build a simple single thread finalizer
> test. It
> causes the JVM to call a finalize() method that does a never ending
> CPU
> intensive task. Every 10 million iterations, this method prints
> out an
> iteration count. While finalize() is running, main() executes a
> second copy
> of exactly the same workload. main()'s print statement is slightly
> different so that its easy to sort out the comingled output.
>
> I ran the above workload on a product JVM on a single CPU laptop and
> observed the following.
This is cool. Did you run the test on Sun, BEA and IBM? I'd be
interested to see how they different VMs behave.
geir
Re: [drlvm] finalizer design questions
Posted by Weldon Washburn <we...@gmail.com>.
On 12/24/06, Gregory Shimansky <gs...@gmail.com> wrote:
>
> On Sunday 24 December 2006 16:23 Weldon Washburn wrote:
> > Very interesting. Please tell me if the following is correct. Without
> > WBS, finalizing objects falls further and further behind because
> > finalization thread(s) are unable to grab enough of the CPU(s) to keep
> up.
> > Instead of increasing the priority of the finalization thread(s), WBS
> takes
> > the approach of increasing the number of finalization threads. The net
> > effect is to increase the rate of finalization by diluting the OS ready
> > queue.
> >
> > Does the following alternative design make sense? Assume the OS/VM
> porting
> > layer allows the VM to change an OS thread's priority appropriately.
> > During VM boot, query the OS to determine the number of CPUs in the box
> and
> > create one finalizer thread for each CPU. Never create additional
> > finalizer threads. Boost the priority of the finalizer threads above
> the
> > level of Java app threads (but probably below real time priority.) Note
> > that all of this is orthogonal to "native" vs. "java" finalizer threads.
>
>
> I like this approach. It probably covers all mentioned problems except for
> the
> fundamental finalizers problem of long running (never ending) finalize()
To answer this question, I build a simple single thread finalizer test. It
causes the JVM to call a finalize() method that does a never ending CPU
intensive task. Every 10 million iterations, this method prints out an
iteration count. While finalize() is running, main() executes a second copy
of exactly the same workload. main()'s print statement is slightly
different so that its easy to sort out the comingled output.
I ran the above workload on a product JVM on a single CPU laptop and
observed the following. The print statements of main() and finalize() are
indeed comingled. This suggests that the JVM runs finalize() in a seperate
thread. The test ran for a rough approximation of eternity (I killed the
test after 30 minutes). This suggests that the JVM is never supposed to
kill a long running finalizer. In other words, the finalizer is supposed to
run as long as it wants. This utility of building an app that contains a
finalizer that consumes vast quantities of CPU time is an entirely different
issue from JVM architecture.
There were about 40 finalize() print statements to one main() print
statement. In other words, the finalize() method consumed about 97% of the
CPU and main() got the remaining 3%. Given the workloads are identical, one
explanation for the above is that the JVM is setting its finalizer thread
priority higher than normal Java threads. I don't know the current
windowsXP thread sched algorithm but my guess that is that it has some
notion of "nice" which allows lower priority threads to run once every 30 or
40 thread sched ticks.
If DRLVM were ever ported to an OS that did not have a "nice" thread sched
algorithm, we could simply move the finalizer thread priority back to
normal.
In other words, I don't yet see evidence that my original proposal is
incorrect. Sorry for the long explanation.
methods.
>
> --
> Gregory
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm] finalizer design questions
Posted by Gregory Shimansky <gs...@gmail.com>.
On Sunday 24 December 2006 16:23 Weldon Washburn wrote:
> Very interesting. Please tell me if the following is correct. Without
> WBS, finalizing objects falls further and further behind because
> finalization thread(s) are unable to grab enough of the CPU(s) to keep up.
> Instead of increasing the priority of the finalization thread(s), WBS takes
> the approach of increasing the number of finalization threads. The net
> effect is to increase the rate of finalization by diluting the OS ready
> queue.
>
> Does the following alternative design make sense? Assume the OS/VM porting
> layer allows the VM to change an OS thread's priority appropriately.
> During VM boot, query the OS to determine the number of CPUs in the box and
> create one finalizer thread for each CPU. Never create additional
> finalizer threads. Boost the priority of the finalizer threads above the
> level of Java app threads (but probably below real time priority.) Note
> that all of this is orthogonal to "native" vs. "java" finalizer threads.
I like this approach. It probably covers all mentioned problems except for the
fundamental finalizers problem of long running (never ending) finalize()
methods.
--
Gregory
Re: [drlvm] finalizer design questions
Posted by Weldon Washburn <we...@gmail.com>.
On 12/23/06, Ivan Volosyuk <iv...@gmail.com> wrote:
>
> On 12/22/06, Weldon Washburn <we...@gmail.com> wrote:
> > On 12/22/06, Mikhail Fursov <mi...@gmail.com> wrote:
> > >
> > > Weldon,
> > > AFAIR without WBS it's an easy to write a test(we had such tests) that
> > > will
> > > work smoothly on SUN or BEA but fails on Harmony.
> > > Is "run any app RI is able to run" reason enough?
> >
> >
> > Yes indeed this is reason enough for this stage of Harmony VM
> development.
> > Taken to the limit, "run any app RI is able to run" means cloning the
> RI.
> > At some point in the future we will need to revisit the above rule but
> its
> > good nuff for now.
>
> BTW, the work balancing system was introduced to workaround missing
> high priority threads in VM. IMHO, a high priority finalizer thread
> can do the job.
Very interesting. Please tell me if the following is correct. Without WBS,
finalizing objects falls further and further behind because finalization
thread(s) are unable to grab enough of the CPU(s) to keep up. Instead of
increasing the priority of the finalization thread(s), WBS takes the
approach of increasing the number of finalization threads. The net effect
is to increase the rate of finalization by diluting the OS ready queue.
Does the following alternative design make sense? Assume the OS/VM porting
layer allows the VM to change an OS thread's priority appropriately. During
VM boot, query the OS to determine the number of CPUs in the box and create
one finalizer thread for each CPU. Never create additional finalizer
threads. Boost the priority of the finalizer threads above the level of
Java app threads (but probably below real time priority.) Note that all of
this is orthogonal to "native" vs. "java" finalizer threads.
--
> Ivan
>
> >
> > On 12/22/06, Weldon Washburn <we...@gmail.com> wrote:
> > > >
> > > > The existing VM finalizer system has something called a Work
> Balancing
> > > > System. It would be good to know the motivation for this
> feature. If
> > > > this
> > > > feature was built for specific workloads, please tell us which ones.
> > > > Thanks
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm] finalizer design questions
Posted by Ivan Volosyuk <iv...@gmail.com>.
On 12/22/06, Weldon Washburn <we...@gmail.com> wrote:
> On 12/22/06, Mikhail Fursov <mi...@gmail.com> wrote:
> >
> > Weldon,
> > AFAIR without WBS it's an easy to write a test(we had such tests) that
> > will
> > work smoothly on SUN or BEA but fails on Harmony.
> > Is "run any app RI is able to run" reason enough?
>
>
> Yes indeed this is reason enough for this stage of Harmony VM development.
> Taken to the limit, "run any app RI is able to run" means cloning the RI.
> At some point in the future we will need to revisit the above rule but its
> good nuff for now.
BTW, the work balancing system was introduced to workaround missing
high priority threads in VM. IMHO, a high priority finalizer thread
can do the job.
--
Ivan
>
> On 12/22/06, Weldon Washburn <we...@gmail.com> wrote:
> > >
> > > The existing VM finalizer system has something called a Work Balancing
> > > System. It would be good to know the motivation for this feature. If
> > > this
> > > feature was built for specific workloads, please tell us which ones.
> > > Thanks
Re: [drlvm] finalizer design questions
Posted by Weldon Washburn <we...@gmail.com>.
On 12/22/06, Mikhail Fursov <mi...@gmail.com> wrote:
>
> Weldon,
> AFAIR without WBS it's an easy to write a test(we had such tests) that
> will
> work smoothly on SUN or BEA but fails on Harmony.
> Is "run any app RI is able to run" reason enough?
Yes indeed this is reason enough for this stage of Harmony VM development.
Taken to the limit, "run any app RI is able to run" means cloning the RI.
At some point in the future we will need to revisit the above rule but its
good nuff for now.
On 12/22/06, Weldon Washburn <we...@gmail.com> wrote:
> >
> > The existing VM finalizer system has something called a Work Balancing
> > System. It would be good to know the motivation for this feature. If
> > this
> > feature was built for specific workloads, please tell us which ones.
> > Thanks
> >
> >
> > --
> > Weldon Washburn
> > Intel Enterprise Solutions Software Division
> >
> >
>
>
> --
> Mikhail Fursov
>
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm] finalizer design questions
Posted by Mikhail Fursov <mi...@gmail.com>.
Weldon,
AFAIR without WBS it's an easy to write a test(we had such tests) that will
work smoothly on SUN or BEA but fails on Harmony.
Is "run any app RI is able to run" reason enough?
On 12/22/06, Weldon Washburn <we...@gmail.com> wrote:
>
> The existing VM finalizer system has something called a Work Balancing
> System. It would be good to know the motivation for this feature. If
> this
> feature was built for specific workloads, please tell us which ones.
> Thanks
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>
>
--
Mikhail Fursov