here - Stefan-Marr.de

7. Implementation Approaches
Customization Constant In addition to showing the implementation of the
store and pop bytecode, Lst. 7.3 also contains the specifics of the customization
constant implementation. On line 2, the bytecode implementation calls the
method requires_delegation(..) with the receiver (rcvr) object and a bit
mask, which indicates a write operation. Line 18 defines the called method.
It first looks up the domain owning the given receiver. Then, it looks up the
customization constant in the domain object and uses another helper method
that checks whether the constant has the corresponding bits of the bit mask
set. If that is not the case, the bytecode implementation will continue executing
at line 11 and directly perform the operation, as if the code was executed
in the unenforced execution mode. This avoids the overhead of reifying the
operation and performing it later reflectively. In case a delegation is required,
the bytecode implementation will call redirect_write_field(..) instead of
performing the write directly.
Handling of Primitives Primitives are handled similarly to bytecodes. Once
the primitive code is reached it is already clear that the message send that
led to it succeeded and does not need to be considered anymore. However,
the primitive itself might still need to be intercepted by the domain. Thus,
it needs to check whether the domain customizes the corresponding intercession
handler. Lst. 7.4 provides an example of the adapted primitive for
shallow copying of objects. As described, the receiver is first checked whether
it customizes the corresponding handler, and if this is the case, the handler is
invoked instead. As request_primitive_clone() demonstrates, we rely for
that operation on the standard method invocation, i. e., commonSend().
Strategy for Controlled Enforcement As mentioned before, each context object
keeps track of whether the VM is supposed to execute the corresponding
code in enforced or unenforced mode.
The VM offers two ways to switch to enforced execution. The first one is
the #evaluateEnforced: primitive, which takes a block that is going to be
evaluated with enforcement enabled. The second way is enabled by the variants
of the #performEnforced: primitives, which take a selector, arguments,
and optionally a lookup class for super sends. Both approaches cause either
blocks or methods to be executed in enforced mode.
To leave enforced execution, methods are marked similarly to the solution
for SOM and the AST-OMOP. The RoarVM+OMOP implementation uses bit
30 (UN) in the method header (cf. Tab. 7.1) to indicate to the VM that the
194