here - Stefan-Marr.de

8.5. Assessment of Performance Characteristics
The high overhead on the CogVM can be explained by the differences in
implementations. On the one hand, the AST transformation adds a significant
number of bytecodes to each method that need to be executed, and on the
other hand, the reflective operations preclude some of the optimizations of
the CogVM. For instance the basic benefit of the JIT compiler to compiling
bytecodes for field access to inline machine code cannot be realized, since
these operations have to go through the domain object’s intercession handler.
Other optimizations, such as polymorphic inline caches [Hölzle et al., 1991]
cannot yield any benefit either, because method invocations are performed
reflectively inside the intercession handler, where polymorphic inline caches
are not applied.
In the RoarVM+OMOP the overhead is comparatively lower, because it only
performs a number of additional checks and then executes the actual reflective
code (cf. Sec. 7.2.1). Thus, initial performance loss is significantly lower.
Speculating on how the CogVM could benefit from similar adaptations,
there are indications that the JIT compiler could be adapted to deliver improved
performance for code that uses the OMOP. However, because of the
restricted generalizability of these results, it is not clear whether the CogVM
could reach efficiency to the same degree as the RoarVM+OMOP implementation.
However, this question is out of the scope of this dissertation and will
be part of future work (cf. Sec. 9.5.2).
8.5.2. Inherent Overhead
Context and Rationale Sec. 7.2.1 outlined the implementation strategy for
the RoarVM+OMOP. One performance relevant aspect of it is the modification
of bytecodes and primitives to perform additional checks. If the check
finds that execution is performed in enforced mode, the VM triggers the intercession
handlers of the OMOP. However, since these checks are on the performance
critical execution path, they prompted the question of how much
they impact overall performance. This section assesses the inherent overhead
on unenforced execution for both OMOP implementation strategies.
AST-OMOP The AST-OMOP has only an overhead in terms of memory usage
but does not have a direct impact on execution performance. The memory
overhead comes from the need of keeping methods for both execution modes,
the enforced as well as the unenforced, in the image (cf. Sec. 7.1.1). Furthermore,
since in most classes the AST-OMOP represents the owner of an object
as an extra object field, there is also a per-object memory overhead. The per-
221