<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2017-01-10 21:54 GMT+01:00 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Will event-driven VM fix this problem completely? Or heartbeat will be needed anyway?</div></div></blockquote><div><br></div><div>As I understand it, the heartbeat us always needed.  In an event-driven VM it may be that the Smalltalk executive is called form the event loop, but the Smalltalk executive still has to break out of executing Smalltalk to return to the event loop to receive new events.</div><div><br></div><div>The thing to understand about the JIT VM is that Smalltalk is executing in machine code just like simple code in some low level language.  That code can respond to Smalltalk events such as attempting to wait on a Semaphore with no outstanding signals, which may cause it to switch processes.  But it cannot respond to external asynchronous events unless it is informed of those events.  And it is very difficult to construct a VM that can accept interrupts at arbitrary times that activate Smalltalk code (imagine receiving an interrupt in the middle of a GC, or mid-way through looking up a send not found in the cache, etc, etc; essentially interrupts can only be accepted at limited times).  So the VM needs to check for events (and indeed interrupts) at safe points.  The efficient implementation of safe points is checking on the next frame-building send.  But if every frame-building send checked for interrupts and/or events, frame build would be very slow and the entire VM would crawl.  The function of the heart beat is to cause frame building sends to check for interrupts and/or events at regular, but (relative to frame-builling send frequency) infrequent occasions.</div><div><br></div><div>Compare that to interrupts in a real processor.  The processor /also/ only tests e.g. the interrupt request pin at a safe point (perhaps at the end of each interaction decode cycle), and also provides means to disable interrupts for critical sections of code.  It's just that the quanta are much smaller than in a Smalltalk vm.</div></blockquote></div><br>Thank's Eliot. It's very informative explanation</div></div>