here - Stefan-Marr.de

4. Experimentation Platform
Bytecodes The bytecode set used by the RoarVM is very similar to the
Smalltalk-80 bytecode set depicted in Tab. 4.2. It encodes common operations
with single bytes, directly encoding a small range of parameters. Supposedly,
this encoding was chosen to keep the code size of Smalltalk methods small
and enable efficient implementation based on C’s switch/case statement that
will be mapped on a dispatch table by most compilers. The RoarVM also still
uses switch/case instead of direct or indirect threading. While the RoarVM
supports the closure extension that was introduced by the CogVM, it is not
considered in this dissertation. Another difference in the used bytecode set is
the changed meaning of bytecode 132. It has been changed to the unequivocal
name: doubleExtendedDoAnythingBytecode. Three bits of the second byte are
used to encode the operation, and the remaining 5 bits encode an argument.
The third byte encodes a literal to be used.
The bytecodes for arithmetic and special methods are essentially shortcut
bytecodes that reduce the number of bytes needed to encode presumably
common message sends. Besides arithmetic operations such as add, subtract,
and multiply, this includes comparisons such as less than, greater or equal, and
equal. The special methods include for instance #at:, #at:put:, and class.
The implementation of these bytecodes will first set the corresponding symbol
for the message send, and then issue the actual message send. However,
if possible the addition is executed directly without doing an actual message
send, for instance if the receiver and the argument of the #+ message are
integers.
4.4.2. Memory Systems Design
The memory system of the RoarVM has been designed with simplicity in
mind, facilitating the experimentation on manycore platforms like the Tilera
TILE64 [Wentzlaff et al., 2007]. Therefore, the RoarVM uses a simple compacting
mark-and-sweep GC that relies on a stop-the-world mechanism for safe
memory reclamation. Beside the SmallInt immediate tagged integers, all objects
are garbage collected.
One important artifact of Ungar and Adams’ research that became part of
the RoarVM is an additional memory word that is prepended to every object.
For their implementation of the Ly and Sly language prototypes [Ungar and
Adams, 2010], they changed the semantics of message dispatching. In Sly, an
object can be part of an ensemble, i. e., a collection. If a message is sent to such
an object, the message is reified and sent to the ensemble instead. This technique
allows Ungar and Adams to unify to a certain degree the treatment of
104