Hi Sven,

    cc'ing squeak list cuz answer may be generally useful.

On Wed, Oct 23, 2013 at 8:07 AM, Sven Van Caekenberghe <sven at stfx.eu> wrote:

> Hi Eliot,
>
> On 23 Oct 2013, at 14:59, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> > Hi Sven,
> >
> > On Wed, Oct 23, 2013 at 5:52 AM, Sven Van Caekenberghe <sven at stfx.eu>
> wrote:
> >
> > On 23 Oct 2013, at 14:22, Igor Stasenko <siguctua at gmail.com> wrote:
> >
> > > Yeah, i was also exploring, why even if i do not touch image i got
> like 3-5% CPU load.
> > > What i found that it is in VM. Because i basicaly removed everything
> in image,
> > > and just left idle process, and still had such loads.
> >
> > Igor, some time ago you told me which thread inside the VM was doing
> this, but maybe you forgot ;-)
> >
> > 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.
> >
> > 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.
>
> Thanks for the answer, I think I understand, more or less.
>
> But #relinquishProcessorForMicroseconds: is primitive 230, so anything it
> might be doing is done in the VM right ?


Yes.


> The only thing that can be done from the image level is to call it less
> often, unless that would create problems. Right ?
>

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.


> What is the function of the poll thread then ?
>

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.

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.

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.


> Sven
>
> > > On 23 October 2013 13:52, Sven Van Caekenberghe <sven at stfx.eu> wrote:
> > > Hi,
> > >
> > > 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 !
> > >
> > > 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:
> > >
> > > <Screen Shot 2013-10-23 at 13.40.56.png>
> > >
> > > 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.
> > >
> > > I guess we’ll have to wait for our hero Esteban to have a look.
> > >
> > > 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):
> > >
> > > <Screen Shot 2013-10-23 at 13.49.53.png>
> > >
> > > This is probably related to the busy thread running/polling every ms
> or so inside the VM.
> > >
> > > I could turn these into issues.
> > >
> > > Sven
> > >
> > > [1]
> > >
> > > Virtual Machine
> > > ---------------
> > > /Users/sven/Develop/Smalltalk/Pharo.app/Contents/MacOS/Pharo
> > > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
> > > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
> > > git://gitorious.org/cogvm/blessed.git Commit:
> 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100
> By: Esteban Lorenzano <estebanlm at gmail.com> Jenkins build #14535
> > >
> > > Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB<
> > > VMMaker versionString git://gitorious.org/cogvm/blessed.git Commit:
> 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100
> By: Esteban Lorenzano <estebanlm at gmail.com> Jenkins build #14535
> > > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
> > > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Igor Stasenko.
> >
> >
> >
> >
> >
> > --
> > best,
> > Eliot
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131023/5dc98023/attachment.htm