Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Date: Tue, 02 Jan 2007 15:05:26 +1100
From: Robin Garner <robin.garner@anu.edu.au>
Subject: Re: [drlvm] finalizer design questions
In-reply-to: <783bf8b0701010524r6b00b4aamc0fbefccbdde06ef@mail.gmail.com>
To: dev@harmony.apache.org
Message-id: <4599DA06.1090803@anu.edu.au>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <4dd1f3f00612211832u447fa2e4i90b4eb108762af8f@mail.gmail.com>
 <208da7a50612260642g4314df3es8ed8b57865f4e5b2@mail.gmail.com>
 <4dd1f3f00612260753r703a65a4yf3b5c1dfc632bdb@mail.gmail.com>
 <4AFE8DB0-26D1-4CA1-A7D9-FCAD13AC33A4@pobox.com>
 <9623c9a50612261730k1c7342c3m9ad6b3d158cedcd1@mail.gmail.com>
 <866ECD92-8D0F-4F0D-B214-1B27A8870C5A@pobox.com>
 <4dd1f3f00612271834j7afa7a06v5778d3783df525db@mail.gmail.com>
 <783bf8b0612280743k26dd70d9qe290fe635b70593b@mail.gmail.com>
 <783bf8b0612290350r6f175763ucf36f49b6db10879@mail.gmail.com>
 <4dd1f3f00612310718t23fd2cf6tb178d9cb0e97b9dd@mail.gmail.com>
 <783bf8b0701010524r6b00b4aamc0fbefccbdde06ef@mail.gmail.com>
User-Agent: Thunderbird 1.5.0.8 (X11/20061115)

Pavel Afremov wrote:
> On 12/31/06, Weldon Washburn <weldonwjw@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 <pavel.n.afremov@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.
>> > > >
>> > > >
>> > >
>> >
>> >
>>
>>
>> -- 
>> Weldon Washburn
>> Intel Enterprise Solutions Software Division
>>
>>
> 


-- 
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/