Meta-tools such as debuggers, profilers, and sandboxing need to continu- ously reflect on the behavior of applications. Just like the construction of VMs, building debuggers and profiles is a tedious task mostly left to experts resulting in generic tools. These resulting tools are only rarely customizable by the user to fit his needs in a particular situation. The need for custom tools is clear however, given that most developers reach out to lower level and less scalable, but more customizable means like print statements.
Building such tools is difficult because the executable format of program- ming language code is expressed in terms of the low-level execution engine. The problem is that there is a large gap between the low-level execution model and the mental model a programmer has of his application. Debug- gers are often specified in terms of the low-level model since they are the only representation of the application available at run-time. While meta- information about the executable code is sometimes available, this is gener- ally not an executable model, preventing light-weight semantics modifica- tions.
Chapter 3. Background and Problems
3.6
Summary
We have presented a short overview of the implementation of programming languages
In this chapter, we have discussed work related to opening up language runtimes to fundamental changes. We have focused on reflection as a tech- nique to change a runtime from within, and the technique of generating high-performance VMs from higher-level models as a technique to lower the cost of building runtimes tailored to the requirements of a language. From there on we have identified three problems resulting from limitations of existing reflective models and of VMs:
1. VMs are hardwired towards a particular language or language family, and do not support fundamental modifications at run-time.
2. Languages only support a single set of predefined encodings of ob- jects.
3. The gap between run-time code and source code limits the develop- ment of debuggers and profiles.
In the following chapters we tackle these problems one by one. Chapter 4 enforces polymorphism at the meta-level by implementing a self-supporting runtime library. Chapter 5 extends the structural model of the language with first-class support for object layouts, enabling user-defined layout cus- tomizations. Chapter 6 introduces first-class AST interpreters as basis for continuous behavioral reflection.
4
First-Class Message Lookup
It has been argued that a VM should be built using the techniques and pat- terns that are established in normal software engineering [99, 143]. We argue that this principle should not only hold for the implementation of the lan- guage runtime, but also for the behavior of a compiled and running system. Similar to the introduction of field programmable gate arrays, we argue that a VM should not be a hardwired black box with bytecode as arbitrary cut- off level. Instead it should be a combination of a standardized interface to all components, a reusable runtime library to support the used language.
In this chapter we efficiently reify the most basic building block of object- oriented languages: the communication between objects by sending mes- sages. The presented model standardizes the interface between objects, and supports custom message handling semantics on a per-object basis. This is the most basic building block since it allows developers to freely choose language semantics at object boundaries.
Pinocchio provides messaging semantics as a self-supporting runtime library. The runtime library replaces the traditional VM by implementing meta-level semantics, like message sending, directly in Smalltalk. Since the runtime library is itself implemented in Smalltalk and is first-class, it also serves as its own runtime library. It is therefore inherently self-supporting.
Objects and code from the base- and meta-level are therefore unified. They can flow between the two, and base-level objects can polymorphically replace meta-level objects. Thus all parts of the runtime library are com- posed of run-time accessible and reusable parts. Since the runtime library implements the behavior of the Smalltalk language, behavioral reflection is available to the language as a side-effect of the uniformity of the system.
Chapter 4. First-Class Message Lookup
time can be achieved by replacing part of the meta-level at run time. In particular we show how the Pinocchio runtime can be adapted to support prototype-based message lookup.
The contributions of this chapter are:
• we propose a novel approach to realizing a truly self-supporting run- time that does not rely on interpretation or bytecode;
• we demonstrate how a formal unification of meta- and base-level code enables runtime extensions;
• we present evidence that a self-supporting and extensible runtime can be implemented efficiently; and
• we demonstrate that typical language extensions in such a runtime can be realized with modest effort.
Outline We provide a high-level overview of our approach in Section 4.1. In Section 4.2 we describe the key elements of the design and implemen- tation of the self-supporting, extensible Pinocchio language runtime. We provide a series of examples of typical extensions in Section 4.3, and show how they can be easily achieved in Pinocchio by substituting meta-level ob- jects with compatible run-time1 objects. In Section 4.4 we review several of the perceived benefits of VM-based approaches to the implementation of languages, and discuss how these points are impacted by the approach. We discuss related work in Section 4.5 and summarize the chapter in Section 4.6.
4.1
The Message is the Medium
In the previous chapter we have seen that a conventional VM is a closed black box, offering only a restricted MOP to support reflection and metapro- gramming (see left side of Figure 4.1). The implementation of the VM is compiled away, and is not accessible to the running application, except through the pre-defined MOP. Extensions required to support new program- ming languages can be achieved only by constructing a custom VM, nega- tively impacting reusability and compatibility.
In contrast, the Pinocchio runtime consists of objects sending messages. The semantics of receiving messages is defined by object-specific meta-levels. These meta-levels are, just like application code, implemented using ob- jects and messages. The entire Pinocchio runtime is accessible to application code, rather than just a restricted MOP. Furthermore, to realize extensions, Pinocchio’s meta-level objects can be replaced at run time by compatible application objects (see Figure 4.1, right side).
1The Pinocchio runtime enables run-time extensions, i.e., at run time as opposed to compile time.
4.2. The Message is the Medium
Figure 4.1: A conventional VM (left) is closed, offering only a fixed API for application objects (top) to interact with it. The Pinocchio runtime (right) consists of meta-level objects sending messages, just like application objects. Application objects can fully interact with meta-level objects. Meta-level objects can be replaced by at run time to realize extensions.
The essential ingredients to run-time extensibility in Pinocchio are: (i) a self-supporting runtime; (ii) a message sending invocation conventions; and (iii) unification of meta- and base-level execution.
A self-supporting runtime. The Pinocchio runtime is implemented in a metacircular fashion, so it relies on itself to provide the meta-level facilities needed for its own execution. The Pinocchio runtime is compiled to ma- chine code, resulting in a runtime library rather than a conventional VM.
Message sending invocation conventions. The Pinocchio runtime only hardwires the most essential meta-level facilities needed to support dynamic languages, particularly message sending. Pinocchio provides a meta-level invoke function to lookup a method when an object received a message (see subsection 4.2.2). Method lookup makes use of a monomorphic inline cache. This cache can be pre-filled at compile time, thus avoiding infinite meta-regression when the runtime evaluates itself.
Unification of meta- and base-level execution. The Pinocchio runtime is fully specified in Smalltalk. The Pinocchio compiler compiles the runtime down to machine code, yielding a fully object-oriented runtime library. In essence, the compiler builds the MOP from the Smalltalk sources. As a con- sequence, the language meta-level is unified with use code, allowing one to move freely between the base- and the meta-level. Furthermore, the meta- level objects, being accessible, can be replaced at run time by compatible application code, thus enabling run-time adaptations.
Chapter 4. First-Class Message Lookup