The uFork Actor Virtual Machine performs interleaved execution of threaded instruction streams. Instruction streams are not assumed to be arranged in consecutive memory locations. Instead, each instruction contains a "pointer" to the subsequent instruction, or multiple pointers in the case of conditionals, etc.
This is combined with a lightweight computational context (IP+SP+EP) that makes it efficient to enqueue the context after each instruction. Then the next context can be dequeued and executed. Thus an arbitrary number of instruction streams can be executed, interleaved at the instruction level.
This interleaved instruction execution engine is used to service an actor message-event queue. If the target of the event at the head of the queue is not already busy handling a prior event, a new computational context (continuation, or "thread") is created (and added to the continuation queue) to execute instructions in the target actor's behavior. If the event target is busy, the event is recycled to the tail of the queue. Since asynchronous actor messages may be arbitrarily delayed, this does not change the message-passing semantics.
Effects caused by an actor's behavior (send, create, and become) are applied to the system in an all-or-nothing transaction. The instruction stream defining the actor's behavior will end with a "commit" or "abort" instruction, at which time transactional effects will either be applied or discarded. Since these instructions have no "next instruction" field, there is nothing to put on the continuation queue and the stream ends (the "thread" dies).
The blog post "Memory Safety Simplifies Microprocessor Design" describes this architecture, and the rationale behind it.
The uFork virtual machine is designed to support machine-level actors. All instructions execute within the context of an actor handling a message-event. There is no support for address arithmetic or load/store of arbitrary memory. Mutation is always local to an actor's private state. Immutable values are passed between actors via message-events. External events (such as "interrupts") are turned into message-events.
There are currently two variations of the uFork VM. A proof-of-concept prototype written in C, and a more robust implementation written in Rust/WASM. The instruction set and internal representation has evolved so the two implementations are no longer compatible, but each demonstrates important aspects of the design space.