[Vm-dev] Sista/Scorch callbacks v. clock jitter

Ben Coman btc at openinworld.com
Sun Oct 29 16:35:02 UTC 2017

On Sun, Oct 29, 2017 at 10:49 PM, Clément Bera <bera.clement at gmail.com>

> On Sat, Oct 28, 2017 at 5:55 PM, Ben Coman <btc at openinworld.com> wrote:
>> hi Clement,
>> I was watching your nice talk on Pharo Optimizing JIT Internals. At 14:40
>> [1]
>> you mention VM call-back to Scorch DNU-style.  I was just curious how
>> that might affect the jitter of the DelayScheduler waiting for the
>> timingSemaphore set by "primSignal: timingSemaphore atMilliseconds:
>> millisecondNextTick"
>> to be signalled by the VM?
> I am not sure I understand the question. Only 1 optimisation call-back is
> running at once (It disables itself when started, re-enables itself at the
> end). If another green thread takes over the runtime, the optimisation of
> the function will time out. The other green thread can then be optimized.
> Does this answer the question ?

Partly answered.  So my current perception is that execution only stays in
the VM for very short periods, so the VM code generating the
timingSemaphore ticks occurs frequently and the Image code can be
responsive to the clock ticks.

If the VM does a callback into the Image when a hotspot is detected, I
presume the VM is blocked at that point waiting for the callback to
return(??), which may delay the VM signalling timingSemaphore and the Image
receiving it.

I don't quite follow the part about another green thread taking over?
Would the VM callback to Scorch operate at a particular priority level?
(what priority?)
So the timing event loop at priority 80 would get a chance to preempt the
scorch callback?  But even then, the VM wouldn't have generated the signal
if its paused at the callback point.

Sorry I feel like I'm missing something making it hard to frame a good

cheers -ben

>> [1] https://youtu.be/yDKaHphbFow?list=PLJ5nSnWzQXi_THfKwhzxFwbXy
>> 00YTi0uv&t=883
>> cheers -ben
>> P.S. Later when you say Sista will be an optional VM - curious whether
>> Sista might be switched on/off from within the VM? or just a command line
>> flag? or an actual different VM (which adds complexity to system
>> management).
>> Different VMs. In the Sista VM you can turn things on/off. In the default
> VM you only have unoptimized behavior. Once the image has Sista methods it
> requires the Sista VM unless you switch it off and revert all optimised
> code.
> --
> Clément Béra
> Pharo consortium engineer
> https://clementbera.wordpress.com/
> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20171030/24ef6905/attachment.html>

More information about the Vm-dev mailing list