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 11:50:11 GMT
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