harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm] finalizer design questions
Date Thu, 28 Dec 2006 13:52:01 GMT
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. <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
View raw message