Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: neutral (herse.apache.org: 216.86.168.178 is neither permitted
 nor denied by domain of geir@pobox.com)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <4593A9D6.6050301@gmail.com>
References: <4dd1f3f00612211832u447fa2e4i90b4eb108762af8f@mail.gmail.com>
	 <200612242309.03593.gshimansky@gmail.com>
	 <4dd1f3f00612251445t7caaf743y201c474f6be85eec@mail.gmail.com>
	 <emplsm$3pm$1@sea.gmane.org>
	 <4dd1f3f00612251705j1a331404sa60db8b43c40a30d@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>
 <4593A9D6.6050301@gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3805F46C-74ED-425B-93D9-EE019FF8BF46@pobox.com>
Content-Transfer-Encoding: 7bit
From: "Geir Magnusson Jr." <geir@pobox.com>
Subject: Re: [drlvm] finalizer design questions
Date: Thu, 28 Dec 2006 08:52:01 -0500
To: dev@harmony.apache.org

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.
>>