here - Stefan-Marr.de
here - Stefan-Marr.de
here - Stefan-Marr.de
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
7. Implementation Approaches<br />
introducing it was not performance, but the system’s <strong>de</strong>buggability nee<strong>de</strong>d<br />
to be improved.<br />
Since most domains customize only a subset of all intercession handlers, it<br />
becomes a major problem to have all intercession handlers be invoked. While<br />
the standard intercession handlers only enco<strong>de</strong> the semantics of unenforced<br />
Smalltalk execution, they significantly increase the amount of co<strong>de</strong> that is<br />
executed for each operation with a corresponding intercession handler. For<br />
the purpose of <strong>de</strong>bugging, the execution of this co<strong>de</strong> only adds noise and<br />
results in additional co<strong>de</strong> execution that one needs to step through, without<br />
relevance to the semantics.<br />
During <strong>de</strong>bugging at the VM byteco<strong>de</strong> level as well as during <strong>de</strong>bugging<br />
at the Smalltalk source level, it was essential to avoid such noise in or<strong>de</strong>r<br />
to be able to focus on the problem at hand. The customization constant reduced<br />
unnecessarily executed co<strong>de</strong> significantly and consequently improved<br />
the <strong>de</strong>bugging experience for co<strong>de</strong> executed in the enforced mo<strong>de</strong>.<br />
Representation of Ownership The RoarVM+OMOP represents object ownership<br />
by using an extra hea<strong>de</strong>r word for every object. While this direct approach<br />
enables the VM to obtain the owner simply by object inspection, it<br />
comes with a significant memory overhead for small objects. In the field of<br />
garbage collection, different solutions have been proposed to track similar<br />
metadata for various purposes. One possible approach that is common for<br />
GCs is to partition the heap [Jones et al., 2011, chap. 8] based on certain criteria<br />
to avoid the direct encoding of related properties. For the OMOP, the<br />
ownership of an object could be enco<strong>de</strong>d by it being located in a partition<br />
that belongs to a specific domain. Such an approach would avoid the space<br />
overhead of keeping track of ownership. While partitioning might add complexity<br />
to the memory subsystem of the VM, it might also open up opportunities<br />
for other optimizations. Depending on the use of the domains, and<br />
the concurrency concepts expressed with them, a GC could take advantage of<br />
additional partitioning. For instance, in an actor-like domain, additional partitioning<br />
could have benefits for generational collectors. In such a system, the<br />
nursery partition would be local to a single actor, which could have a positive<br />
impact on GC times.<br />
Limitations of Primitives A final semantic issue is the handling of primitives.<br />
By reifying their execution and requiring the indirection to the domain<br />
object, the execution context changes when the primitive is applied. In<br />
198