05.08.2014 Views

here - Stefan-Marr.de

here - Stefan-Marr.de

here - Stefan-Marr.de

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!