[Vm-dev] Re: CogVM | Granularity of process switching/interruption

[Marcel Taeumel]

Hi Eliot,

thank you for this comprehensive answer. Sure, I just CC'ed vm-dev.

No concrete example/worries. I am just brainstorming about the general possibilities/limitations of user interfaces (and application frameworks) in Squeak. :-)

Best,
Marcel
Am 05.04.2016 08:33:57 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
Hi Marcel,



On Apr 4, 2016, at 6:24 AM, Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> wrote:


Hi Eliot,

is it still (roughly) at the granularity of message sends where processes will be interrupted?

The suspension points are
- the first bytecode in a non-primitive method
- the first bytecode in a primitive method (after the callPrimitive bytecode) if the primitive fails
- a backward branch
- the first bytecode of a block (unless invoked with valueNoContextSwitch[:]

That is a maximal set of suspension points.  If the JIT can compile a method or block without needing a frame (because the code is simple, eg doesn't do a send) then there will be no suspension point in that method when jitted.

Hence, the worst that can happen is that Squeak's debugger shows up and complains about some DNU based on corrupted state? (Or that the app runs a while until some debugger shows up...)

The potential failures are
- MNU
- mustBeBoolean
- cannotReturn:
- cannotResume:
- illegalBytecodeAt:
and with read-only object support
- attemptToAssign:withIndex:

Meaning: The VM will never crash by bad multi-programming?

Hmmm.  Not sure whether that's true because one could possibly create synthetic examples that crash the VM and then try and provoke these by "bad multi-programming".  But I think you're right.  The VM doesn't suspend at arbitrary points.

But perhaps you could express what you're worried about.  Any examples?

And this is a discussion we could have on vm-dev...no?

Best,
Marcel

Best,
Eliot
_,,,^..^,,,_ (phone)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160405/4052665d/attachment.htm