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

[Ben Coman]

On Mon, Oct 30, 2017 at 3:47 PM, Clément Bera <bera.clement at gmail.com>
wrote:

>
>
>
> On Sun, Oct 29, 2017 at 5:35 PM, Ben Coman <btc at openinworld.com> wrote:
>
>>
>>
>>
>> On Sun, Oct 29, 2017 at 10:49 PM, Clément Bera <bera.clement at gmail.com>
>> wrote:
>>
>>>
>>>
>>>
>>> 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.
>>
>
> Scorch VM call-back is at the priority of the green thread starting it. It
> has a limited time window to perform optimisation. During that time window
> Scorch is disabled on all green threads to avoid infinite loops with Scorch
> optimising itself. If the green thread is preempted, likely the time window
> will time out and another green thread will be able to perform
> optimisation. The time window is currently guaranteed using
> BlockClosure>>#valueWithin:onTimeout:.
>

That explains it clearly, thanks.
cheers -ben



>
> You can read the Metacircular chapter of my thesis [1] which deals with
> this kind of problems. The specific case you mention is not detailed though.
>
> Still not sure this answers the question since I am not very familiar with
> the VM signalling timingSemaphore.
>
> [1] See ReadMe in https://github.com/clementbera/PHDThesis
>
>
>>
>> Sorry I feel like I'm missing something making it hard to frame a good
>> question.
>>
>> 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
>>>
>>>
>>
>>
>
>
> --
> 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/096c0609/attachment-0001.html>