[ENH] CPU time for Processes.

John M McIntosh johnmci at smalltalkconsulting.com
Fri Mar 9 03:49:42 UTC 2001


I'm tossing this out to the Squeak list for comment. Perhaps it can 
assist in debugging where the time goes.

Today at a client we watched a set of processes run in another 
dialect of Smalltalk and wondered where the CPU time was going. It's 
hard to track isn't it? Oh, we used TOP and the like to watch the 
other Unix processes and it occurred to me all the Operating system 
(Solaris) was doing was tracking CPU dispatch time for the Unix 
process and giving those milliseconds values to us to admire. So why 
can't we know how much time a particular process runs in the VM? 
Smalltalk is just an OS right, we need to collect some metrics. Well 
we can, just a few changes are required.

I spent a few hours this evening looking at how to solve this 
problem. You see although much of the process scheduler is exposed 
most of it really lives in the VM. So you can't just add code to 
Process suspend and resume...

First I added new instance vars to Process, startTime, and 
runDuration which track when a process starts based on the 
millisecond clock, and duration which is calculated from the 
startTime and the time the process is stopped when another is 
started. This duration accumulates as an integer.

Now in Interpreter>>transferTo: aProc  it suspends the current 
process and starts the new process running. I *think* this is the 
only place where a process switch occurs. IE for Jitter this seems 
the only place where we notify the compiler that the process is 
changing. So we just look at the millisecond clock, look at startTime 
which should be in the past, calculate the diff and add to 
runDuration. For the about to be started process we store the current 
time and keep going.

Note we could store the time we stopped the old process to get the 
suspend time, but I'll let the crowd decide if this is useful. 
Perhaps you might want it to boost processes that have been sleeping 
too long?

So now I can track how many milliseconds a Smalltalk process has been 
dispatch for the hosting OS CPU to work with.

To get this to work you need a new VM!!!! built with this patch. Also 
you might need the latest VM with the class reshaping patch to keep 
the VM from crashing when it reshapes the Process class. (For the mac 
this is 3.0.9, which isn't out the door yet, just try doing uploads 
etc at 14400 baud).

So file this in, hope it doesn't crash your image, and see if you can 
get a new VM. If you need a mac VM (3.0.10) to test with let me know. 
Note you get a notifier berating you that changing Process isn't a 
good idea, just keep going.

What else... Mmm I altered ProcessBrowser a bit to print the value of 
runDuration, via the Process print methods. But we need a startup 
method to reset the startTime and runDurations when an image 
restarts. I'm sure we could calculate % of CPU used per update 
interval and the like with a little bit of code eh?. I'll leave some 
of the details to others, just getting the numbers is enough for this 
evening.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: CaptureProcessTimeJMM.4.cs
Type: application/mac-binhex40
Size: 4586 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010308/3efd2d02/CaptureProcessTimeJMM.4.hqx
-------------- next part --------------
-- 
--
===========================================================================
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