[squeak-dev] hydra vm update

Igor Stasenko siguctua at gmail.com
Sat May 3 01:57:44 UTC 2008


2008/5/3 John M McIntosh <johnmci at smalltalkconsulting.com>:
> some observations
>  (a) In the past we would call checkForInterrupts. One of the interesting
> things with that routine was that it used interruptCheckCounter
>  to modulate how often it was called. Thus in the bytecode
>         longUnconditionalJump
>                 /* begin internalQuickCheckForInterrupts */
>                         if ((foo->interruptCheckCounter -= 1) <= 0)
>
>  We tried only to call checkForInterrupts every 1 millisecond or so by
> incrementing, decrementing interruptCheckCounter  to some large number.
>
>  See my note on the squeak mailing list
>  "VM tuning results and a question or two?" November 16, 1999 11:09:04 PM
> PST (CA)
>
>  We would of course set that to a negative number if we wanted a more
> instant response.
>
>  However now the HydraCode promptly does a return from interp on each jump
> backwards at some unknown cost, I'd guess this affects looping to some
> interesting value?
>

No, it changes the way how interrupts are handled. Instead of
optimistic way (check each 1 msec, and hope there is something to
handle) , now it's more deterministic: interrupt if and only if there
are events to handle.
A cost of returning from interpret() function and then calling it back
is too small to take in account.
And the frequency , how often interpret() interrupts is now depends
only from how often you generating events. But cost to generate event
and putting it to queue is much more than simply return and call
function again. So even if you flood VM with events , a bottleneck
will be not in interpret() , but in your event generation code :)
In fact i observed a little speedup, when finished refactoring to new
model (about 0.8%) on my PC.

Also, making intepret() reentrant leads to some other benefits, not
yet exploited, but i'm sure you can see it yourself what perspectives
it opens. One of the obvious perspective, that i can replace a loop
from
while (1)
to
while (!terminated),
which will allow me to handle killing interpreter instance in graceful
way, without quitting VM. Comparing to old VM, the only way how you
can terminate interpreter, is to quit OS process, what its actually
doing.
But in HydraVM, a quit primitive should be changed to stop interpreter
instance, while continue working with another instances.


>From a comment from mail you pointed to:

> I think the big problem is the timer accuracy which currently depends on the
> frequency of #checkForInterrupts. If you increase the #interruptCheckCounter
> your timer accuracy will decrease. Though, of course, one could adjust the
> interruptCheckCounter based on whether or not a timer is active (or even how
> far in the future the next timer tick is).

- now, in Hydra there is no such dependency.

> Good question. For user interrupts, once or twice per second is possibly
> sufficient. For the timer it should be as accurate as possible. For external
> semaphores or finalization it should be as soon as these are signaled.

- all semaphores signaled by generating events, and as i already
stated, any event pushed to Interpreter event queue causes interpreter
loop return as soon as possible.

>
>  (b) Buried in checkForInterrupts was code to thump TheTimerSemaphore when
> needed and to watch for millisecond clock rollover.
>
>  But now it seems the platform implementer is now require to build a pthread
> based routine to mange the next wakeup time, and or do something clever
> elsewhere to
>  watch when the millisecond clock rolls over and/or exceeds the next
> expected wakeup time.
>
>  However that implies each implementation will have the same behaviour,
> where as before it was magically handled by the VM and not requiring lots of
> independently written operating system timer magic.
>
>
>  As of now I don't have a workable vm since I need to implement this timer
> thread logic and one hopes that will solve the where we lockup the carbon
> event handler as something fails
>  to process the draw window request at window activation properly.
>

Consider, that my implementation was based on observations of what
windows VM doing. And its already used a multimedia timer, which was
set to trigger checking for interrupts each 1 msec (or at minimum time
periods which OS can provide, but not less than 1mses). And these
routines created own timer thread, hidden from the eyes of developer.
So, what i did, i just replaced this thread by own implementation.
Also, because of using multimedia timer, i seen an ovelap: an
optimistic ( interruptCheckCounter handling) was doing the same as
multimedia timer does, which, IMHO, can't be considered as a good
algorithm.

After refactoring, i got a code which can handle timer with better
accuracy comparing to old VM. (Read a topic some time back about
Delays accuracy).
In fact, i was surprised, when seen, that my implementation provides
more accurate timers, i expected it to be worser :)


>
>  --
>  ===========================================================================
>  John M. McIntosh <johnmci at smalltalkconsulting.com>
>  Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>  ===========================================================================
>
>

-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list