<div dir="ltr">Hi Sven,<br><div class="gmail_extra"><br></div><div class="gmail_extra"> cc'ing squeak list cuz answer may be generally useful.<br><br><div class="gmail_quote">On Wed, Oct 23, 2013 at 8:07 AM, Sven Van Caekenberghe <span dir="ltr"><<a href="mailto:sven@stfx.eu" target="_blank">sven@stfx.eu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Eliot,<br>
<div class="im"><br>
On 23 Oct 2013, at 14:59, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
<br>
> Hi Sven,<br>
><br>
> On Wed, Oct 23, 2013 at 5:52 AM, Sven Van Caekenberghe <<a href="mailto:sven@stfx.eu">sven@stfx.eu</a>> wrote:<br>
><br>
> On 23 Oct 2013, at 14:22, Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>> wrote:<br>
><br>
> > Yeah, i was also exploring, why even if i do not touch image i got like 3-5% CPU load.<br>
> > What i found that it is in VM. Because i basicaly removed everything in image,<br>
> > and just left idle process, and still had such loads.<br>
><br>
> Igor, some time ago you told me which thread inside the VM was doing this, but maybe you forgot ;-)<br>
><br>
> two different things. One is the idle process, in the image. This is heavy-weight. It calls relinquishProcessorForMicroseconds: which does all sorts of things, including system calls to poll for i/o. The other is the poll thread in the Cog and Stack VMs. This simply sleeps for a millisecond, wakes up and sets a variable, and then goes back to sleep. It is relatively lightweight.<br>
><br>
> I suspect the 3-5% is due to the former, not the latter. One way to test would be to compare the interpreter VM against the Stack and Cog VMs and see how much time the interpreter VM takes. If the interpreter VM also takes a lot of time at idle, then the poll thread is not the culprit.<br>
<br>
</div>Thanks for the answer, I think I understand, more or less.<br>
<br>
But #relinquishProcessorForMicroseconds: is primitive 230, so anything it might be doing is done in the VM right ?</blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The only thing that can be done from the image level is to call it less often, unless that would create problems. Right ?<br></blockquote><div><br></div><div>Currently. But a better solution entirely would be to replace the mechanism with something that blocks until an event or i/o is possible. Then the VM would go to sleep when at idle instead of uselessly spinning.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What is the function of the poll thread then ?<br></blockquote><div><br></div><div>In the Interpreter VM there is a counter, decremented on every backward branch or non-primitive send, that causes a check for interrupts when it reaches zero. The basic problem with such counters is that they either incur too much work or too much latency. Set the counter to a high value and latency increases. Set the counter too low and work increases. Further, if the program starts doing something time consuming in primitives (e.g. very large integer arithmetic operations) that reduces the frequency of counter decrements and the system can become unresponsive (because events are not being checked) for a long time, apparently locking up.</div>
<div><br></div><div>In the Stack and Cog VMs execution is on a stack divided up into pages (because this allows sharing the stack between processes, and limits the amount of work done converting stack activations into context activations when more stack is needed). Every (non-primitive) method activation must check the current stack limit to avoid overflowing the current page. The stack limit can then be used as a "free" interrupt check. If the variable holding the stack limit is set to all ones every stack check fails (cuz the stack grow down). The stack overflow logic checks if the stack has really overflowed and if not, checks for events. Backward branch is modified to check the stack limit also.</div>
<div><br></div><div>The poll thread periodically sets the stack limit variable to all ones, causing an event check soon there-after. This is much cheaper and much more regularly periodic than the counter approach.</div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Sven<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> > On 23 October 2013 13:52, Sven Van Caekenberghe <<a href="mailto:sven@stfx.eu">sven@stfx.eu</a>> wrote:<br>
> > Hi,<br>
> ><br>
> > This morning I upgraded my MacBook Air to Mac OS X 10.9 Mavericks. The good new is that my trusty VM [1] is still working OK !<br>
> ><br>
> > However, something seems to have changed regarding full screen mode: it more or less works but there are two black bands and the window title remains visible, it is as if it did not expand enough:<br>
> ><br>
> > <Screen Shot 2013-10-23 at 13.40.56.png><br>
> ><br>
> > Which is a pity: I rely on this a lot to get more screen space on my 13 inch screen and to work distraction free.<br>
> ><br>
> > I guess we’ll have to wait for our hero Esteban to have a look.<br>
> ><br>
> > Also new is the focus on energy management and efficiency. Sadly Pharo is flagged as using to much (look at the menu under the battery icon top right and the energy tab in the activity monitor):<br>
> ><br>
> > <Screen Shot 2013-10-23 at 13.49.53.png><br>
> ><br>
> > This is probably related to the busy thread running/polling every ms or so inside the VM.<br>
> ><br>
> > I could turn these into issues.<br>
> ><br>
> > Sven<br>
> ><br>
> > [1]<br>
> ><br>
> > Virtual Machine<br>
> > ---------------<br>
> > /Users/sven/Develop/Smalltalk/Pharo.app/Contents/MacOS/Pharo<br>
> > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013<br>
> > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013<br>
> > git://<a href="http://gitorious.org/cogvm/blessed.git" target="_blank">gitorious.org/cogvm/blessed.git</a> Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <<a href="mailto:estebanlm@gmail.com">estebanlm@gmail.com</a>> Jenkins build #14535<br>
> ><br>
> > Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB<<br>
> > VMMaker versionString git://<a href="http://gitorious.org/cogvm/blessed.git" target="_blank">gitorious.org/cogvm/blessed.git</a> Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <<a href="mailto:estebanlm@gmail.com">estebanlm@gmail.com</a>> Jenkins build #14535<br>
> > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013<br>
> > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Best regards,<br>
> > Igor Stasenko.<br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> best,<br>
> Eliot<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>