The E1 execution model is based on the migrating threads concept [18]. At any point in time each thread runs in the context of a specific object. During method invocation, execution of a thread is transferred to the target object. Thus, the thread is not permanently bound to any specific object or domain. As shown in [18] migrating threads are more appropriate for object-oriented environment, than traditional static threads.

Migrating threads eliminate the need of starting a separate thread for processing each call or queuing calls for sequential processing. This results in increased efficiency of object interaction, as well as a simpler and more lightweight object architecture.

To start a new thread, one specifies its initial object and method. While executing this method, thread can perform nested calls to other objects. The thread is terminated on return from the method, in the context of which it was started.

If a thread performs an illegal operation while running in the context of some distributed object replica, this replica will be destroyed and the thread will return to the previous element in the stack of nested calls just like if it had completed execution of a method with an error code.

Since in E1, distributed object invocation is actually an invocation of its local replica, it does not cause the transfer of thread execution to a remote node. There is, however, one particular situation, when such transfer occurs. It is when the replication strategy requires migration of object replica between network nodes (>>). The object state is then moved to the target node, along with all of its threads. After completing execution within the migrated object replica, threads return to their home nodes.

Associated with each thread is an activation stack, which describes the sequence of nested calls, both intradomain and crossdomain, performed by the given thread. Each element of the activation stack stores the address of the object, which performed the invocation. For crossdomain calls, the activation stack also stores the processor context, i.e. a set of register values to be restored on return from the call. This information allows the thread to correctly return from method invocations. In addition, by placing special instructions to the elements of the activation stack, the operating system can control the thread's behaviour, e.g. suspend it, transfer to remote node or terminate. Execution of these instructions is deferred until the thread returns from method invocation, having finished all possible modifications of an object's state.