vat termination: reference cleanup, message rejection

[warner]

#24 is about creating dynamic vats, but we also need to talk about vat termination. We expect vats to terminate when:

• they invoke a syscall with illegal arguments, such as:
  • referencing an import (o-4) that isn't present in the kernel's c-list
  • resolving a promise for which they do not have resolution authority, perhaps because they resolved it once already, or because they gave away their resolution authority via a result parameter
  • resolving a non-promise
  • referencing an unparseable/invalid identifier (q+4 instead of o+4/p+4)
• the controller object (returned by the addVat() device to whoever asked for the dynamic vat to be created) is used to terminate a dynamic vat
• the Vat exceeds its gas limit during execution, and its Keeper does not choose to renew the Meter
  • this include runaways, infinite loops, various forms of malice and/or logic errors
• the Vat is migrated to a remote machine (this is a special case: all references in and out of the Vat will be replaced with forwarders, in cooperation with the new host)

For all non-migration cases, we need the kernel to:

• make sure we never invoke the Vat again: we either remove it from the kernel's knowledge entirely, or set a flag to remember that it has been terminated
• remove all run-queue messages that might be delivered to the dead vat (perhaps immediately, perhaps lazily)
• remove the kernel object/promise table entries that point into the dead vat, replacing them with something that rejects all incoming messages with an error
• reject any remaining kernel promises for which the dead vat held the decision-making authority
• make sure no future messages will cause the kernel to attempt to invoke the dead vat's dispatch object
• drop the dispatch object, to release the dead vat's object graph and allow GC to reclaim the memory
• delete on-disk state for the dead vat

[warner]

At the meeting, @dtribble suggested:

“halt after N turns”. That way we can both permanently halt the
block and also set the value to halt earlier during replay (e.g. to
allow debugging of a failing program)

I'm still confused by that suggestion. It might mean we should use a debugger() statement to pop out to a debugger, but then we aren't really terminating the vat, we're just adding a breakpoint that fires under some particular condition (e.g. we're about to replay transcript entry N). Maybe it implies a "pause vat" feature that we didn't talk about: instead of terminating the vat, we just want to not deliver messages to it for a while (but retain the option to resume delivering them again in the future). To implement this, I think we'd need to add a new "pause queue". Each time we pull a message off the run-queue and see that it's destined for a paused Vat, we append it to the pause-queue instead of delivering it.

I don't know what consequences these new message-ordering rules might have, nor where the authority to pause and resume a Vat should be held. I'm pretty sure a paused vat should retain all its normal references, so paused vats are very different than terminated vats (which the kernel should be able to forget about utterly).

[warner]

This is pretty much done. I moved dean's suggestion to a different ticket.