Context Management in VisualWorks 5i Eliot Miranda ParcPlace Division CINCOM, Inc. [email protected] Abstract Smalltalk-80 provides a reification of execution state in the form of context objects which represent procedure activation records. Smalltalk-80 also provides full closures with indefinite extent. These features pose interesting implementation challenges because a naïve implementation entails instantiating context objects on every method activation, but typical Smalltalk-80 programs obey stack discipline for the vast majority of activations. Both software and hardware implementations of Smalltalk-80 have mapped contexts and closure activations to stack frames but not without overhead when compared to traditional stack-based activation and return in “conventional” languages. We present a new design for contexts and closures that significantly reduces the overall overhead of these features and imposes overhead only in code that actually manipulates execution state in the form of contexts. Keywords: Representation, Optimization, Activation Records, Stack Frames, Closures, Contexts, Smalltalk-80, VisualWorks 1 Introduction Smalltalk-80 provides a reification of execution state in the form of context objects which represent procedure activation records [Ingalls76]. This feature provides a portable abstraction of execution state which has several advantages, including · writing the system’s debugger and the majority of the exception-handling system entirely in Smalltalk · making processes persistent, typically as snapshots of a running system · adding new computational mechanisms not directly supported by the underlying execution semantics, such as backtracking and dynamic (non-lexical) variable binding [Deutsch81] [LaLonde88] A naïve implementation of contexts, as specified by the “blue book” [Goldberg83] definition, implies creating a context object for every method and closure activation, and eventually reclaiming a context for every return. It also implies copying arguments from the caller context to the callee context on every activation, and some form of interaction with the garbage collector to manage references from contexts to arguments and temporary values. These basic operations can be the source of considerable overhead and can dominate execution costs. One hardware implementation managed to achieve good performance with such an implementation [Deutsch83] but software implementations have been markedly less efficient [Ungar83] [Ingalls97]. Consequently, much work has been done to implement contexts more efficiently, both in hardware [Lewis86] [Samples86] and software [Deutsch84] [Caudill86] [Moss87] [Miranda87]. The earliest and highest performance software approach is presented in [Deutsch84] which describes the PS virtual machine1. The same techniques were evolved to implement a more portable machine, HPS2, the virtual machine used in VisualWorks Smalltalk [CINCOM99]. The work in this paper is a modification of the HPS virtual machine. 1 PS stands for either Peter’s Smalltalk, or Portable Smalltalk 2 HPS stands for High Performance Smalltalk 1 2 Context-Stack Mapping in HPS Smalltalk-80 is a late-bound object-oriented programming language with full closures. Message sends create method activations which return to their senders. Conceptually closures are created within method activations or nested within closure activations within method activations. Closures can close-over the receiver and local variables of their lexically-enclosing-scoped closure and method activations.3 The vast majority of Smalltalk activations obey stack discipline, and the only common exception from this is “non- local return” from a closure activation where a closure activation returns to the caller of its enclosing method activation. Effectively, then Smalltalk-80 obeys stack discipline for procedure (method and closure) activation. Hence efficient implementation of contexts can most obviously be achieved by stack allocation of contexts. In HPS the key technique for efficient implementation of contexts is to map activations to stack frames during normal execution and only reify execution state when required. This, along with other significant optimizations outside the scope of this paper, is facilitated by translating Smalltalk bytecode into native machine code which is cached and used to execute all Smalltalk code. By mapping contexts to conventional stack frames HPS is able to use the host machine’s native call and return instructions, and to pass arguments directly on the stack, avoiding copying arguments from caller to callee contexts. In HPS there are three context representations. Volatile contexts are procedure activations which have yet to be accessed as context objects. These are conventional stack frames, created using native procedure call and prologue instructions, and reclaimed by stack discipline on executing native procedure epilogue and return instructions. Stable contexts are the standard object form of procedure activations, contexts proper. Hybrid contexts are a pair of a context object and its associated procedure activation. The context object acts as a proxy for the activation. Objects in HPS are composed of a header and a body. The header holds an object’s class, a flag word encoding the object’s size, hash and garbage collector flags, and an indirection pointer which points to the body which holds the object’s instance variables: 32-bit pointer (oop) class oop instance variable size, hash, gc flags instance variable… indirection pointer Hybrid contexts adapt this representation such that the class field holds a special class object used to mark the object as hybrid, the indirection pointer holds the frame pointer, and the actual indirection pointer is copied to a slot in the frame. The stack frames of hybrid contexts need to be marked to distinguish them from volatile frames and need to refer to their hybrid context object. This requires three extra slots in the frame: · The saved pc slot. A hybrid frame is flagged as such by using its return pc which has the advantage that it is set for free on procedure call, when the return pc is always pushed. To mark a frame hybrid its return pc is written into the saved pc slot and the return pc is set to zero. Consequently the return code sequence must be modified to check for a zero return pc and a hybrid return executed, of which more below. · The my data slot which holds the indirection pointer referencing the context’s body. · The my oop slot which holds the pointer to the context object itself. These three extra slots are only considered valid if the return pc is zero so the normal procedure prolog needs to make room for the extra slots but does not need to initialize them. 3 This is a departure from the original blue book specification where anonymous functions were implemented as partially-initialized activation records called BlockContexts. Evaluation of an anonymous function involved making its activation record current, hence breaking stack discipline. 2 Volatile contexts are converted to hybrid contexts when a volatile context must be referenced as an object. This can happen in a number of situations (listed approximately from high to low frequency): · A block is created which references its enclosing activation. · A hybrid context is converted to stable, in which case its caller, if volatile, must be made hybrid. Thus stack walks, e.g. to deliver an exception or construct a stack trace for the debugger, convert volatile frames to stable. To avoid this when delivering exceptions, primitives are used to search the stack for frames marked as handler contexts, without hybridizing intervening volatile contexts. · A process switch is made. Processes refer to their chain of activations via the top context. Thus operations like a blocking wait on a Semaphore entail making the top context hybrid. · Volatile and hybrid contexts are housed in a stack zone composed of small stack segments usually 2k bytes in size. When a deep call chain overflows a stack segment a new segment is allocated, the top frame in the previous segment is made hybrid. Each segment starts with a dummy frame at its base, the root frame, uses this context to chain back to the stack segment. A root return is a return from a root frame, which calls a run-time routine to return to the context. · Smalltalk code references the thisContext pseudo-variable which refers to the current context. Volatile or hybrid contexts are converted to stable contexts whenever the full object representation of a context is required. This also occurs in a number of circumstances: · When executing a return, if the current context is hybrid it must be converted to stable, since the context might be referenced by a block which has outlived its activation. This is a hybrid return. · When executing a non-local return all hybrid contexts between the returning context and the home context from which it returns must be converted to stable. This is simply a compound form of the preceding single hybrid return case. · When allocating a new stack segment if no empty stack segment exists, the least recently used segment is evacuated by converting all the frames in the segment, volatile or hybrid, into stable contexts. · Whenever a message is sent to a hybrid context it is converted to its stable form. · When a snapshot is made all volatile or hybrid contexts are converted to stable so that only objects are written to the snapshot file. Since the snapshot may be resumed on a different machine only the machine-independent stable