here - Stefan-Marr.de

5.5. Customizations and VM-specific Design Choices
executing in another domain. Consequently, an instantiation of the OMOP
taking this use case into account could provide special intercession handlers
for both cases. For reading fields, it could provide #readFieldFromWithin:of:
and #readFieldFromOutside:of:. Similarly, the other intercession handlers
could be provided in these two variants, as well. While the resulting OMOP
would no longer be minimal, an implementation of isolation on top of it
would not require testing for ownership but could rely on the VM, which
might provide better performance.
In future work (cf. Sec. 9.5.6), the different properties of supported concurrent
programming concepts can be studied and formalized, which could yield
similar variation points and a declarative representation of possible language
policies. Such a representation would again allow a different representation
of key elements of the OMOP and allow more efficient implementation of
common use cases.
Opt-In for Enforced Execution Mode Another design decision made in the
presented OMOP is that execution starts out in unenforced mode. With the
semantics discussed in Sec. 5.3.1 and Sec. 5.4 (cf. Lst. 5.4), a language implementer
needs to opt-in explicitly to enforced execution. This design was chosen
to provide predictable behavior and the ability to set up all relevant libraries
and system parts before enforced execution mode is activated. This
choice is partially motivated by the fact that the OMOP has been developed
for an existing system with existing infrastructure. Thus, starting in unenforced
execution mode provides more flexibility. However, in a system that is
designed from the ground up as a multi-language VM with support for the
OMOP, it might be desirable to execute code in the enforced execution mode
from the beginning. The benefits of this choice would be that a language
implementer does not need to opt-in to enforced execution and thus, the standard
case will ensure that language semantics are ensured at all times.
Handling of Primitives Primitives, i. e., built-in functionality provided by
the VM needs to be covered by the OMOP to guarantee that the semantics
of a concurrent programming concept can be enforced in their entirety. Thus,
if primitives are not covered correctly, they could be used, for instance to
circumvent the isolation required between processes in CSP.
The presented OMOP design includes every single primitive as a separate
intercession handler on the OMOP. This choice works well as part of the
presentation in this dissertation and for VMs that have only a small number
129