With the ubiquity of parallel commodity hardware, developers turn to high-level concurrency models such as the actor model to lower the complexity of concurrent software. However, debugging concurrent software is hard, especially for concurrency models with a limited set of supporting tools. Such tools often deal only with the underlying threads and locks, which obscures the view on e.g. actors and messages and thereby introduces additional complexity.To improve on this situation, we present a low-overhead record & replay approach for actor languages. It allows one to debug concurrency issues deterministically based on a previously recorded trace. Our evaluation shows that the average run-time overhead for tracing on benchmarks from the Savina suite is 10% (min. 0%, max. 20%). For Acme-Air, a modern web application, we see a maximum increase of 1% in latency for HTTP requests and about 1.4 MB/s of trace data. These results are a first step towards deterministic replay debugging of actor systems in production.

Live programming, originally introduced by Smalltalk and Lisp, and now gaining popularity in contemporary systems such as Swift, requires on-the-fly support for object schema migration, such that the layout of objects may be changed while the program is at one and the same time being run and developed. In Smalltalk schema migration is supported by two primitives, one that answers a collection of all instances of a class, and one that exchanges the identities of pairs of objects, called the become primitive. Existing instances are collected, copies using the new schema created, state copied from old to new, and the two exchanged with become, effecting the schema migration.Historically the implementation of become has either required an extra level of indirection between an object's address and its body, slowing down slot access, or has required a sweep of all objects, a very slow operation on large heaps. Spur, a new object representation and memory manager for Smalltalk-like languages, has neither of these deficiencies. It uses direct pointers but still provides a fast become operation in large heaps, thanks to forwarding objects that when read conceptually answer another object and a partial read barrier that avoids the cost of explicitly checking for forwarding objects on the vast majority of object accesses.

OpenSmalltalk-VM is a virtual machine (VM) for languages in the Smalltalk family (e.g. Squeak, Pharo) which is itself written in a subset of Smalltalk that can easily be translated to C. Development is done in Smalltalk, an activity we call "Simulation". The production VM is derived by translating the core VM code to C. As a result, two execution models coexist: simulation, where the Smalltalk code is executed on top of a Smalltalk VM, and production, where the same code is compiled to an executable through a C compiler. In this paper, we detail the VM simulation infrastructure and we report our experience developing and debugging the garbage collector and the just-in-time compiler (JIT) within it. Then, we discuss how we use the simulation infrastructure to perform analysis on the runtime, directing some design decisions we have made to tune VM performance. CCS Concepts • Software and its engineering → Runtime environments; Just-in-time compilers; Interpreters;

Speculative inlining in just-in-time compilers enables many performance optimizations. However, it also introduces significant complexity. The compiler optimizations themselves, as well as the deoptimization mechanism are complex and error prone. To stabilize our bytecode to bytecode just-in-time compiler, we designed a new approach to validate the correctness of dynamic deoptimization. The approach consists of the symbolic execution of an optimized and an unoptimized bytecode compiled method side by side, deoptimizing the abstract stack at each deoptimization point (where dynamic deoptimization is possible) and comparing the deoptimized and unoptimized abstract stack to detect bugs. The implementation of our approach generated tests for several hundred thousands of methods, which are now available to be run automatically after each commit.

International audienceDynamically typed languages allow developers to write more expressive source code, but their lack of static information about types of variables increases the complexity of a program. Static type information about types of variables facilitates program comprehension and maintenance. Simple type inference algorithms suffer from the problem of false positives or negatives, thus complex approaches are required to avoid this problem. We propose a simple heuristic that uses easily accessible run-time information about the usage of each class as a receiver type for a message send. This frequency serves as a proxy for the likelihood that a run-time type of the variable is that class and it is used to promote the correct type towards the top of the list of possible types for a variable. Our evaluation of a proof-of-concept prototype implemented in Pharo Smalltalk shows that our heuristic is reasonably precise to detect correct types on average in 65.92% to 82.83% of cases

OpenSmalltalk-VM is a virtual machine (VM) for languages in the Smalltalk family (eg, Squeak and Pharo), which is itself written in a subset of Smalltalk that can easily be translated to C. VM development is done in Smalltalk, an activity we call "simulation." The production VM is then derived by translating the core VM code to C. As a result, two execution models coexist: simulation, where the Smalltalk code is executed on top of a Smalltalk VM, and production, where the same code is compiled to an executable through a C compiler. The whole VM execution can be simulated: the heap is represented as a huge byte array, the VM code is executed as Smalltalk, and the native code generated by the just-in-time (JIT) compiler is executed by a processor simulator. All the Smalltalk development tools, such as the debugger, are then available while simulating. In addition, in simulation, it is also possible to use debugging features such as single stepping in the machine code generated by the JIT compiler. The Smalltalk development tools combined with the simulation debugging features provide developers with a productive environment in which to extend and debug the VM. In this article, we detail the VM simulation infrastructure and report our experiences developing and debugging VM features within it such as the garbage collector and the JIT compiler.

International audienceIn several Smalltalk implementations, a program can mark any object as read-only (unfortunately incorrectly sometimes miscalled immutable). Such read-only objects cannot be mutated unless the program explicitly revert them to a writable state. This feature, called write barrier, may induce noticeable overhead if not implemented carefully, both in memory footprint and execution time. In this paper I discuss the recent addition of the write barrier in the Cog virtual machine and the support introduced in the Pharo 6 image. I detail specific aspects of the implementation that allows, according to multiple evaluations presented in the paper, to have such a feature with little to no overhead

No abstract