Hi Dimitry,<br><br><div class="gmail_quote">On Wed, Jul 6, 2011 at 12:00 PM, Dimitry Golubovsky <span dir="ltr"><<a href="mailto:golubovsky@gmail.com">golubovsky@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Hi,<br>
<br>
What is the importance of heartbeat in Cog? What happens if heartbeat<br>
frequency is unstable or low?<br></blockquote><div><br></div><div>The heartbeat determines a) the clock frequency, how fast the microsecond clock advances in time, and b) how often the VM checks for input, delays expiring, external semaphores being signalled etc. If the frequency is unstable or low the clock resolution will be poor, delays will fire erratically and input won't be responded to promptly.</div>
<div><br></div><div>Note that a) is strictly optional. An alternative architecture, as used in the VisualWorks VM, would move checking for delays expiring to the platform, using some kid of interrupt-driven expiring timer (on Windows spawining a thread that waits with a timeout on an OS semaphore, the timeout being the time to the next delay, on Unix a call to nanosleep in some thread, or use of setitimer, etc). Then there is no need for the heartbeat to wake up while the system is inactive. Instead when inactive the Vm enters some efficient blocking sleep waiting on any input events, and if a pending delay expires, the delay code breaks the VM out of its blocking wait. But the Squeak VM has been written to check for expiring delays as part of its event check. It maintains the time of the next expiring delay and in the Cogit and Stack VMs checks it in checkForEventsMayContextSwitch: (see nextWakeupUsecs) and in the Interpreter checks it in checkForInterrupts (see nextWakeupTick).</div>
<div><br></div><div>So changing this (which I think is a good idea; it works well for VW) requires some effort.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Concerning running Cog in Android: most of the time (between<br>
screen/hardware button presses) an activity (and any of Cog code) is<br>
just not running. I can give it periodic timer events, but if they are<br>
too frequent then CPU load is higher therefore battery drains faster.<br></blockquote><div><br></div><div>You could safely lower the frequency when the VM is inactive, and raise it when active. You just need to be aware of the pending delay issue and not e.g. lower the frequency to 1Hz when the next delay is scheduled to fire in 10ms.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Cog gets control only when some external event is ready to be<br>
processed. Plus, I am not sure whether external signals are available<br>
to Android programs same way they are in Linux.<br>
<br>
Is it possible to replace external signal-driven heartbeat with some<br>
synchronous action invoked in the interpreter every N bytecodes, or<br>
just one beat at interpreter entry, one at exit?<br></blockquote><div><br></div><div>No it is not, not without performance impact. The heartbeat is a far more efficient way of causing the VM to break-out of Smalltalk bytecode execution than a counter. The counter itself is expensive; a read-modify-write cycle in some high-dynamic-freqency operation such as frame building. The counter also suffers from a really bad bug in that its frequency depends on what Smalltalk is being executed. If the system is executing long-running large integer primitives then the counter counts slowly and the system is unresponsive as a result. If the system is executing high send frequency code then the counter counts very fast and the system wastes cycles checking for interrupts, or at least checking whether it should check for interrupts.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Sorry if my question is complete nonsense, but I feel like I need to<br>
ask anyway ;)<br></blockquote><div><br></div><div>No, these are excellent questions. The answers are a little tricky however :)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Andeas' hack on classic VM (which is currently used in Android) was to<br>
return from the interpreter once the VM internal process queue is<br>
empty. I am thinking that instead of this I could create a special<br>
display module, and switch in and out the VM on calls to ioGetEvent.<br>
But classic VM did not have heartbeat, did it?<br>
<br>
Thanks.<br>
<br>
PS I realize that in such mode internal process management by the Cog<br>
VM is impaired, but my goal is to use it mostly for GUI anyway and<br>
rely more on host processes and threads.<br>
<br>
PPS I am interested in Stack VM only since JIT for ARM may not even<br>
exist at this moment.<br>
<font color="#888888"><br>
--<br>
Dimitry Golubovsky<br>
<br>
Anywhere on the Web<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>best,<div>Eliot</div><br>