harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Afremov" <pavel.n.afre...@gmail.com>
Subject Re: [drlvm] finalizer design questions
Date Fri, 29 Dec 2006 20:42:14 GMT
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 <pavel.n.afremov@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 <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.
> > >
> > >
> >
>

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