Hi Sven,
cc'ing squeak list cuz answer may be generally useful. On Wed, Oct 23, 2013 at 8:07 AM, Sven Van Caekenberghe <[hidden email]> wrote: Hi Eliot, 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.
best, Eliot
|
Free forum by Nabble | Edit this page |