here - Stefan-Marr.de

7. Implementation Approaches
The most important aspect here is that the intercession handlers that stand
in for the original bytecode operations preserve the required stack semantics.
Bytecodes that for instance push the value of a receiver’s field or a global
literal will just result in a message send instead. The return value of the message
send will then reflect the result of the read operation. Message sends and
simple bytecodes that store into an object’s field are handled very similarly.
The delegation of bytecodes with store and pop behavior requires an additional
intercession handler. The store and pop bytecodes from the Smalltalk-
80 bytecode set are problematic. These are more complex to handle because
they require that the top element of the stack be removed after the operation.
However, this demands care, because all Smalltalk methods return
a value, which gets pushed onto the stack after the method returns. The
RoarVM+OMOP solved this problem by adding a special intercession handler
#write:toField:of:return: in addition to the normal #write:toField:of:
handler. It takes an additional parameter, the predetermined return value for
the handler.
The code implementing this adaptation is given in Lst. 7.3. It shows the C++
code of the RoarVM+OMOP for the store and pop bytecode. As line 6 shows,
two values are popped from the stack, instead of only the value that is to
be stored into the receiver. The second value, which corresponds to what the
top value of the stack should be after the store and pop bytecode, is given to
the intercession handler as a last parameter, and will be restored when the
handler returns. The calling conventions and the current compiler in Squeak
and Pharo guarantee that this approach is safe. Theoretically, it is problematic
to assume that there are always two elements on the stack that can be removed
by the pop operation. However, in this situation it is guaranteed that there is
the original element to be popped and in addition, there is at least the receiver
object at the bottom of the stack, which is never subject to a store and pop
bytecode. Thus, it is safe to pop the second element, which might be the
receiver, and restore it when the message send returns.
The send special message bytecodes and the quick methods require proper
adaptation as well (cf. Sec. 4.4.1). For message bytecodes, the RoarVM+OMOP
needs to force the intercession point for an actual message send when the
domain customizes the request execution intercession points. While the quick
methods need to force the intercession point for the reading of the receiver’s
fields to be able to intercept them as any other field read with the intercession
handler.
192