here - Stefan-Marr.de

7.3. Summary
the RoarVM, primitives are executed on the current context object, which
is different from normal method activations, which are done in their own
context object. When primitive execution is intercepted by the domain, the
RoarVM+OMOP cannot provide the same semantics. An intercession handler
executes in its own context object, i. e., stack frame, and consequently if it
invokes the primitive, it executes on the handler’s stack frame instead of the
stack frame it has originally been invoked in. One example where that matters
is a primitive that implements loops in SOM. It resets the instruction
pointer in the context object to achieve looping. In the RoarVM+OMOP, this
is not possible. However, while this design restricts what primitives can implement,
it is not a practical issue for the RoarVM codebase. The codebase
does not contain primitives that use the context objects in problematic ways,
even though the codebase includes the plugins reused from Squeak and the
CogVM (cf. Sec. 4.4). The primitives merely work on the parameters provided
to them and restrict access to the context object to the corresponding stack
operations. Thus, the RoarVM+OMOP did not need to solve this limitation
and it is assumed that it does not pose a problem in practice.
7.3. Summary
This chapter presented two implementation approaches for the OMOP. It details
for each of the approaches how the mechanisms of the OMOP are realized
and how the requirements are fulfilled.
The AST-OMOP is based on AST transformation and operates on top of the
VM without requiring changes to it. The transformations add the necessary
operations to trigger the OMOP’s intercession handlers, e. g., on method execution,
access to object fields or globals, or to intercept primitives. The AST-
OMOP was the first prototype to investigate the ideas of using a metaobject
protocol and to build the case studies on top, i. e., the AmbientTalkST and the
LRSTM implementation. Thus, the AST-OMOP facilitated the evaluation of
part of the thesis statement without requiring changes to the VM.
The RoarVM+OMOP is the implementation that is used to evaluate the
performance part of the thesis statement. It adapts a bytecode interpreter to
directly support the OMOP. The bytecode and primitive implementations are
changed to trigger the OMOP’s intercession handlers instead of performing
their original operations if execution is performed enforced, and if the corresponding
intercession handler has been customized. The check whether the
intercession handler is customized is a simple optimization that facilitates
debugging.
199