Sista/Scorch callbacks v. clock jitter

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Sista/Scorch callbacks v. clock jitter

Ben Coman
 
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?


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).



Reply | Threaded
Open this post in threaded view
|

Re: Sista/Scorch callbacks v. clock jitter

Clément Bera-4
 


On Sat, Oct 28, 2017 at 5:55 PM, Ben Coman <[hidden email]> 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 ?
 


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
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
Reply | Threaded
Open this post in threaded view
|

Re: Sista/Scorch callbacks v. clock jitter

Ben Coman
 


On Sun, Oct 29, 2017 at 10:49 PM, Clément Bera <[hidden email]> wrote:
 


On Sat, Oct 28, 2017 at 5:55 PM, Ben Coman <[hidden email]> 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 question.

cheers -ben 

 


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
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq


Reply | Threaded
Open this post in threaded view
|

Re: Sista/Scorch callbacks v. clock jitter

Clément Bera-4
 


On Sun, Oct 29, 2017 at 5:35 PM, Ben Coman <[hidden email]> wrote:
 


On Sun, Oct 29, 2017 at 10:49 PM, Clément Bera <[hidden email]> wrote:
 


On Sat, Oct 28, 2017 at 5:55 PM, Ben Coman <[hidden email]> 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:.

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.

 

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

cheers -ben 

 


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
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq






--
Clément Béra
Pharo consortium engineer
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
Reply | Threaded
Open this post in threaded view
|

Re: Sista/Scorch callbacks v. clock jitter

Ben Coman
 


On Mon, Oct 30, 2017 at 3:47 PM, Clément Bera <[hidden email]> wrote:
 


On Sun, Oct 29, 2017 at 5:35 PM, Ben Coman <[hidden email]> wrote:
 


On Sun, Oct 29, 2017 at 10:49 PM, Clément Bera <[hidden email]> wrote:
 


On Sat, Oct 28, 2017 at 5:55 PM, Ben Coman <[hidden email]> 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.

 

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

cheers -ben 

 


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
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq






--
Clément Béra
Pharo consortium engineer
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq