here - Stefan-Marr.de

7.2. Virtual Machine Support
to the domain object. 5 This provides part of the support for controlled
enforcement.
The initial ownership of newly created objects is deduced from a special
field in each domain object. During initialization of a domain, the domain
can predetermine the owner domain for objects newly created during execution
in the domain’s context. The standard owner domain is the domain the
Process is currently executing in. However, it can be useful to create objects
with a domain different from their initial owner. For example, objects created
by an update function in the context of a Clojure agent should be owned
by the immutable domain (cf. Sec. 2.4.3). The RoarVM+OMOP represents the
initial owner via a field in the domain because it avoids executing another
Smalltalk method on every object creation, while giving some flexibility with
regard to the initial owner. For more complex use cases, it is always possible
to change the owner of an object during the course of the execution. Furthermore,
setting the owner during object initialization avoids race conditions on
the object owner as compared to when it is set afterwards.
Changed Bytecode Semantics and Customization Constant To expose the
OMOP’s intercession points, i. e., to support managed state and managed
execution, the RoarVM+OMOP adapts most bytecodes and primitives.
The general idea is to check first, whether currently an enforced execution
is required, and if that is the case, the target object’s domain is inspected
to determine whether a relevant intercession handler has been customized
based on the customization constant. If this is the case, the intercession handler
is invoked instead of executing the bytecode’s or primitive’s operation.
During enforced execution, bytecodes reify their operations and delegate
them to the intercession handlers. Most of the bytecodes have trivial semantics,
in terms of the stack operations they perform. Thus, a Smalltalk
method, such as the intercession handlers can stand in for the actual bytecode
operation without loss of flexibility. During enforced execution, the bytecode
implementations can therefore perform message sends, similarly to the standard
behavior of the send bytecode, instead of performing their operations
directly. This approach corresponds directly to the one describing the overall
semantics of the OMOP in Sec. 5.4.
5 On a 32-bit architecture with 4 byte alignment, the first bit of an Oop is used to indicate
whether an Oop is an immediate integer, or a references. The second bit remains unused,
and is used to encode the enforcement.
191