Strange behaviour of 'WeakArray finalization process'

John M McIntosh johnmci at smalltalkconsulting.com
Thu Nov 11 17:42:43 UTC 2004


Ok, I've a changeset that counts dispatch clock time for a process via  
looking at the clock when the transfer process logic is done in the VM.
Perhaps it's time to drag that out again. It would have shown than most  
clock time was sent to the lowest priority process wait a few  
milliseconds.
Versus lots to the finalization process.

On Nov 11, 2004, at 7:56 AM, Avi Bryant wrote:

>
> On Nov 11, 2004, at 4:16 PM, Lukas Renggli wrote:
>
>> Hi,
>>
>> to give some more information about the WeakArray finalization  
>> problem, here is a screenshot of a profiling-session in a 80 MB image  
>> running a big Seaside application:
>>
>> <weakarray.gif>
>>
>> As far as I understand this means that during those 10 seconds we ran  
>> MessageTally, the finalization process bruned cpu cycles during 7  
>> seconds. There must be definitely something wrong, because we  
>> observed even stranger cases where ALL the cycles were spent there  
>> and the image became unresponsive. Of course we were not able to  
>> profile those, but this one is close and should give you a better  
>> idea about the problem.
>
> Hm, I don't interpret this the same way.  The top two lines of your  
> tally are:
>
> 70.9% {7113ms} primitives
> 29.1% {2920ms}  
> WeakIdentityKeyDictionary(WeakKeyDictionary)>>finalizeValues
>
> And this was spying on the finalizationProcess, right?
>
> Looks like it spent 30% of its time actually finalizing values, and  
> the other 70% in "primitives" - but probably just waiting around to  
> wake up and do something.  You're measuring clock time, not CPU time.   
> So in fact if this process is low priority, even during that 30% it's  
> probably not using a whole lot of CPU.
>
> For example, try this:
>
> [MessageTally spyOn: [(Delay forSeconds: 5) wait]] fork
>
> I get :
>
> **Tree**
> 100.0% {5021ms} Delay>>wait
>   99.7% {5006ms} primitives
>
> But that doesn't mean we were burning many cycles on the #wait...
>
> Avi
>
>
>
>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===




More information about the Squeak-dev mailing list