On Tue, Dec 11, 2012 at 9:26 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 12 December 2012 00:43, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Dec 11, 2012 at 3:35 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Dec 11, 2012 at 10:26 AM, Igor Stasenko <siguctua@gmail.com> wrote:
hehe.. it looks like we can do it:
- when memory hits the waterline mark, VM should do the following: - for every currently scheduled process , push an artificial stack frame on top , which is StackOverflow signal.
If the VM supports the LowSpaceSignal mechanism as it used to be then
this
can be done in the image with a high-priority process. And tehrefore it can e.g. be avoided for processes such as the Delay process, where IMO it is inappropriate.
And if it is done in the image it is easy to e.g. avoid pushing two such frames on the same process because the process has made no progress since the last occurrence, etc.
indeed.. i did not realized that this can be done inside an image :)
i was thinking more about stack limit, not space limit. because scanning the stack will trigger putting all contexts on heap (which in own turn will put even more pressure on memory).. while in VM, to determine stack depth, it can walk the stack frames without marrying them with heap contexts to count stack depth. or it is not the case? is accessing the context state triggers "marrying" it with heap object, i.e.
[ count := count + 1. context := context sender. ] whileNotNil
?
exactly. The VM can provide a primitive to walk the stack without creating objects (which worsens the space situation). Even better the VM could maintain stack depth in Process, but that's for the future, because it needs a) a slot in Process and b) the support writing in both VMs. --
Best regards, Igor Stasenko.
-- best, Eliot