[Vm-dev] Tasks of the heartbeat code

John McIntosh johnmci at smalltalkconsulting.com
Sun Sep 13 20:11:56 UTC 2015


I looked at this six years back and altered the code base to pause the
heart beat thread  until we know when we have to wakeup .

Results were inclusive, so more testing is welcome.

(a) how much overhead is there to pause and wakeup the thread? If you sleep
for 2 ms, is it worth it?
(b) because of the morphic polling look we are woken every 16-20
milliseconds.
(c) There is a race? between what the VM thinks the next wakeup time, and
what the ioRelinquishProcessorForMicroseconds is expected.
Sometimes you are asked to sleep, yet the internal VM timer says you should
wakeup to service a task right now or a millisecond in the past. Yet the VM
had decided there was no runable tasks just microseconds ago.

(d) Do mouse/trackpad/keyboard/socket/FD events actually awake the paused
program?


On Sun, Sep 13, 2015 at 1:00 PM, Holger Freyther <holger at freyther.de> wrote:

>
>
> > On 13 Sep 2015, at 19:53, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
>
>
> > Hi Holger,
>
> Hi!
>
> thank you for the super quick reply!
>
>
> > You are correct for #1.  The main use is 1.  To cause a breakout from
> machine code at regular intervals (default every 2ms).  Backward jumps also
> perform the test.  Using counters instead does not work well; counters are
> expensive to update in every send and the frequency of breakout varies
> wildly depending on whether one is calling code containing slow primitives
> (eg LargeIntegerArithmetic) or not.
> >
> > For 2, getting the heartbeat to update the clock is for delay expiry.
> Fetching the time is slow, and delays need only have about a millisecond
> resolution.  So having the heartbeat update the clock saves time when
> seeing if the active delay has fired.  At first it was used also to update
> the time seen through the time primitives but Dave had me change it.  This
> gives you much better (microsecond) clock resolution at the cost of a
> slower primitive.  That's probably a good default choice.  It does lessen
> the case for doing this at all though. That's an experiment that I'm
> interested in the results of.
>
>
> can you think of a strategy to stop the timer when nothing is running
> inside the
> image? I see getNextWakeupUsecs in ioRelinquishProcessorForMicroseconds
> but that does’t seem to disable the interval timer? E.g. if I look at the
> mac vm
> and ioRelinquishProcessorForMicroseconds it doesn’t appear to stop the
> itimer?
>
>
> I am looking at this from the aioPoll/SIGIO point of view. I was surprised
> how close
> we are to have a system that doesn’t consume CPU when nothing is running.
> Maybe
> there is something I am missing (I don’t know win32) but if the
> IdleProcess starts to
> run the system could:
>
>         * Stop the heartbeat timer
>         * Have the mac variant of ioRelinquishProcessorForMicroseconds for
> unix
>           and  get the time the next Delay expires.
>         * Set the heartbeat to expire at this time?
>         * Yield execution and wait for the SIGIO (or the timer)?
>         * On return to the image call aioPoll if the SIGIO occurred?
>
>
> Is there any general objection to this?
>
>
>
> kind regards
>         holger




-- 
===========================================================================
John M. McIntosh. Corporate Smalltalk Consulting Ltd
https://www.linkedin.com/in/smalltalk
===========================================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150913/df047f1e/attachment-0001.htm


More information about the Vm-dev mailing list