here - Stefan-Marr.de

6. Evaluation: The OMOP as a Unifying Substrate
by one. Both of the presented implementations guarantee this basic aspect.
Furthermore, both implementations guarantee the notion of safe messaging (cf.
Sec. 3.3.2). Thus, messages exchanged between actors are guaranteed not to
introduce shared state.
State encapsulation on the other hand is not supported by either of the implementation,
even though it would be straightforward with the OMOP.
Ad Hoc Solution The ad hoc implementation strategy is similar to the one
described by Schäfer and Poetzsch-Heffter [2010], but kept much simpler. Similar
to their approach of wrapping objects, we use stratified [Bracha and Ungar,
2004] proxies [Van Cutsem and Miller, 2010] to represent far references,
i. e., references between objects residing in different actors. The proxy wraps
actual objects and reifies all operations on them to enforce safe messaging and
asynchronous execution. This approach also provides coverage for Smalltalk’s
reflection, because it is based on message sends to the object.
Safe messaging is realized by wrapping all objects in parameters and return
values. Thus, this implementation comes with the performance drawbacks
described in Sec. 3.3.2. Each object needs to be wrapped with another object.
However, it avoids the need for copying the entire object graph.
While not implemented, this approach can be extended to provide ownership
transfer semantics upon message send. With Smalltalk’s #become: it is
possible to ensure that the original actor does not hold on to the object it sent
via a message. However, the #become: operation is expensive. It scans the
whole heap to exchange object references of the receiver with the reference
given as an argument. Furthermore, the #become: operation is not supported
by VMs such as the JVM and CLI, and, it cannot be used as a general implementation
strategy.
Unfortunately, the approach of using proxies, i. e., wrapper objects does
not account for global state. Thus, class variables are shared between actors
and introduce undesired shared state. In Java, this could be avoided by using
different class loaders for each actor. However, in Squeak/Pharo there are no
facilities which could provide such functionality. Since the implementation
with the described features is already larger than the OMOP-based implementation,
we decided to accept the limitation of partial state encapsulation
only.
OMOP-based Solution The OMOP-based implementation uses the ATActor
domain as the actor itself. Thus, a domain instance corresponds to an execut-
154