here - Stefan-Marr.de

5. An Ownership-based MOP for Expressing Concurrency Abstractions
1 SOMInterpreter = (
2 | frame universe currentBytecode |
3
4 doPopField = (
5 | omopWriteField args oldFrame value |
6 value := frame pop .
7 frame enforced ifFalse : [
8 ^ self currentObject
9 fieldAtIndex : currentBytecode fieldIndex
10 put : value ].
11
12 omopWriteField := self currentObject domain class
13 lookupInvokable : # write : toField :of :.
14 oldFrame := frame .
15 oldFrame pushAll : { self currentObject domain .
16 value .
17 currentBytecode fieldIndex .
18 self currentObject }.
19 frame := interpreter pushNewFrameWithMethod : omopWriteField .
20 frame copyArgumentsFrom : oldFrame )
21
22 pushNewFrameWithMethod : method = (
23 ^ frame := SOMFrame new
24 method : method ;
25 previousFrame : frame ;
26 resetStackPointerAndBytecodeIndex ;
27 domain : frame domain ;
28 enforced : ( frame enforced and : [ method unenforced not ]);
29 yourself )
30 " ... " )
Listing 5.5: Reifying mutation of object fields
and PUSH_FIELD bytecode is that the latter uses its own OMOP intercession
handler #readField:of:.
The bytecodes for sends and super sends themselves remain unchanged
(cf. Sec. 4.2.2, Lst. 4.5). However, both bytecodes rely on adaptation of the actual
send in the #performSend:to:lookupCls: method. Lst. 5.7 shows that
#performSend:to:lookupCls: will send the message directly during unenforced
execution, and it will rearrange the operand stack during enforced
execution to be able to trigger the #requestExecOf:with:on:lookup: intercession
handler on the receiver’s domain instead.
While handling message sends implicitly covers the methods that represent
the VM’s primitives, they still need to be treated explicitly to redefine them
126