<div dir="ltr">Hi Holger,<br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 13, 2015 at 1:00 PM, Holger Freyther <span dir="ltr"><<a href="mailto:holger@freyther.de" target="_blank">holger@freyther.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<br>
> On 13 Sep 2015, at 19:53, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
><br>
<br>
<br>
> Hi Holger,<br>
<br>
Hi!<br>
<br>
thank you for the super quick reply!<br>
<span class=""><br>
<br>
> 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.<br>
><br>
> 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.<br>
<br>
<br>
</span>can you think of a strategy to stop the timer when nothing is running inside the<br>
image? I see getNextWakeupUsecs in ioRelinquishProcessorForMicroseconds<br>
but that does’t seem to disable the interval timer? E.g. if I look at the mac vm<br>
and ioRelinquishProcessorForMicroseconds it doesn’t appear to stop the itimer?<br></blockquote><div><br></div><div>You've read what John has said. I think the easiest thing to do is not to stop and start the heartbeat thread, but merely to set a flag when entering ioRelinquishProcessorForMicroseconds, clearing it on exit, and have the heartbeat test this flag before doing anything that could disturb the VM thread(s). The overhead of the heartbeat thread is very low. It doesn't call select or anything like that. All it does is spin, calling nanosleep, polling the clock and then setting a variable. For example, avoiding polling the clock when in ioRelinquishProcessorForMicroseconds might save a few cycles.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I am looking at this from the aioPoll/SIGIO point of view. I was surprised how close<br>
we are to have a system that doesn’t consume CPU when nothing is running. Maybe<br>
there is something I am missing (I don’t know win32) but if the IdleProcess starts to<br>
run the system could:<br>
<br>
* Stop the heartbeat timer<br></blockquote><div><br></div><div>or set the flag that gets it to do nothing. It may be more efficient to set this flag an have it tested than stop and start the heartbeat thread.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
* Have the mac variant of ioRelinquishProcessorForMicroseconds for unix<br>
and get the time the next Delay expires.<br>
* Set the heartbeat to expire at this time?<br></blockquote><div><br></div><div>Make sure that the blocking call to poll or whatever will time out at or shortly before the next delay expiry.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
* Yield execution and wait for the SIGIO (or the timer)?<br>
* On return to the image call aioPoll if the SIGIO occurred?<br></blockquote><div><br></div><div>I think blocking in epoll and the like is the right approach. That gives control to the kernel for the most efficient possible wait state.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Is there any general objection to this?<br></blockquote><div><br></div><div>Absolutely not. Quite the opposite. It would be great to see the VM block efficiently. Great to have your energy!! Thank you!</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">kind regards<br>
<span class=""><font color="#888888"> holger</font></span></blockquote></div><br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>