Tim Felgentreff

Checks and balances: constraint solving without surprises in object-constraint programming languages

Object-constraint programming systems integrate declarative constraint solving with imperative, object-oriented languages, seamlessly providing the power of both paradigms. However, experience with object-constraint systems has shown that giving too much power to the constraint solver opens up the potential for solutions that are surprising and unintended as well as for complex interactions between constraints and imperative code. On the other hand, systems that overly limit the power of the solver, for example by disallowing constraints involving mutable objects, object identity, or polymorphic message sends, run the risk of excluding the core object-oriented features of the language from the constraint part, and consequently not being able to express declaratively a large set of interesting problem solutions. In this paper we present design principles that tame the power of the constraint solver in object-constraint languages to avoid difficult corner cases and surprising solutions while retaining the key features of the approach, including constraints over mutable objects, constraints involving object identity, and constraints on the results of message sends. We present our solution concretely in the context of the Babelsberg object-constraint language framework, providing both an informal description of the resulting language and a formal semantics for a core subset of it. We validate the utility of this semantics with an executable version that allows us to run test programs and to verify that they provide the same results as existing implementations of Babelsberg in JavaScript, Ruby, and Smalltalk.

SqueakJS: a modern and practical smalltalk that runs in any browser

We report our experience in implementing SqueakJS, a bit-compatible implementation of Squeak/Smalltalk written in pure JavaScript. SqueakJS runs entirely in the Web browser with a virtual filesystem that can be directed to a server or client-side storage. Our implementation is notable for simplicity and performance gained through adaptation to the host object memory and deployment leverage gained through the Lively Web development environment. We present several novel techniques as well as performance measurements for the resulting virtual machine. Much of this experience is potentially relevant to preserving other dynamic language systems and making them available in a browser-based environment.

Babelsberg/JS

�� � � � � � �� � ��� �� � � � � � � � � � � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � �� � � � � � � � � � � Constraints provide a useful technique for ensuring that desired properties hold in an application. As a result, they have been used in a wide range of applications, including graphical layout, simulation, scheduling, and problem-solving. We describe the design and implementation of an Object Constraint Programming language, an object-oriented language that cleanly integrates constraints with the underlying language in a way that respects encapsulation and standard object-oriented programming techniques, and that runs in browser-based applications. Prior work on Object Constraint Programming languages has relied on modifying the underlying Virtual Machine, but that is not an option for web-based applications, which have become increasingly prominent. In this paper, we present an approach to implementing Object Constraint Programming without Virtual Machine support, along with an implementation as a JavaScript extension. We demonstrate the resulting language, Babelsberg/JS, on a number of applications and provide performance measurements. Programs without constraints in Babelsberg/JS run at the same speed as pure JavaScript versions, while programs that do have constraints can still be run efficiently. Our design and implementation also incorporate incremental re-solving to support interaction, as well as a cooperating solvers architecture that allows multiple solvers to work together to solve more difficult problems.

Towards reducing the need for algorithmic primitives in dynamic language VMs through a tracing JIT

When implementing virtual machines, besides the interpreter and optimization facilities, we have to include a set of primitive functions that the client language can use. Some of these implement truly primitive behavior, such as arithmetic operations. Other primitive functions, which we call algorithmic primitives, are expressible in the client language, but are implemented in the vm to improve performance. However, having many primitives in the vm makes it harder to maintain them, or re-use them in alternative vm implementations for the same language. With the advent of efficient tracing just-in-time compilers we believe the need for algorithmic primitives to be much diminished, allowing more of them to be implemented in the client language. In this work, we investigate the trade-offs when creating primitives, and in particular how large a difference remains between primitive and client function run times in vms with tracing just-in-time compiler. To that end, we extended the RSqueak/VM, a vm for Squeak/Smalltalk written in RPython. We compare primitive implementations in C, RPython, and Smalltalk, showing that due to the tracing JIT the performance gap can be significantly reduced.

Follow the path: Debugging state anomalies along execution histories

To understand how observable failures come into being, back-in-time debuggers help developers by providing full access to past executions. However, such potentially large execution histories do not include any hints to failure causes. For that reason, developers are forced to ascertain unexpected state properties and wrong behavior completely on their own. Without deep program understanding, back-in-time debugging can end in countless and difficult questions about possible failure causes that consume a lot of time for following failures back to their root causes. In this paper, we present state navigation as a debugging guide that highlights unexpected state properties along execution histories. After deriving common object properties from the expected behavior of passing test cases, we generate likely invariants, compare them with the failing run, and map differences as state anomalies to the past execution. So, developers obtain a common thread through the large amount of run-time data which helps them to answer what causes the observable failure. We implement our completely automatic state navigation as part of our test-driven fault navigation and its Path tools framework. To evaluate our approach, we observe eight developers during debugging four non-trivial failures. As a result, we find out that our state navigation is able to aid developers and to decrease the required time for localizing the root cause of a failure.

Sista: Saving Optimized Code in Snapshots for Fast Start-Up

Modern virtual machines for object-oriented languages such as Java HotSpot, Javascript V8 or Python PyPy reach high performance through just-in-time compilation techniques, involving on-the-fly optimization and deoptimization of the executed code. These techniques require a warm-up time for the virtual machine to collect information about the code it executes to be able to generate highly optimized code. This warm-up time required before reaching peak performance can be considerable and problematic. In this paper, we propose an approach, Sista (Speculative Inlining SmallTalk Architecture) to persist optimized code in a platform-independent representation as part of a snapshot. After explaining the overall approach, we show on a large set of benchmarks that the Sista virtual machine can reach peak performance almost immediately after start-up when using a snapshot where optimized code was persisted.

How to Build a High-Performance VM for Squeak/Smalltalk in Your Spare Time: An Experience Report of Using the RPython Toolchain

In this paper we present our experience in letting students develop RSqueak/VM, a fast virtual machine for executing Squeak/Smalltalk, over the course of multiple introductory VM courses and projects. Our experience indicates that the way RSqueak/VM is constructed makes it easy for developers with little or no prior exposure to VM development to construct a Squeak runtime that is very nearly competitive to the professional grade Cog VM, which is used by Squeak and other flavors of Smalltalk. In this experience report we discuss the benefits and drawbacks of RSqueak/VM as a research vehicle for developing and evaluating Smalltalk language extensions without having to learn the deep secrets of VM development.

Language-independent storage strategies for tracing-JIT-based virtual machines

Storage strategies have been proposed as a run-time optimization for the PyPy Python implementation and have shown promising results for optimizing execution speed and memory requirements. However, it remained unclear whether the approach works equally well in other dynamic languages. Furthermore, while PyPy is based on RPython, a language to write VMs with reusable components such as a tracing just-in-time compiler and garbage collection, the strategies design itself was not generalized to be reusable across languages implemented using that same toolchain. In this paper, we present a general design and implementation for storage strategies and show how they can be reused across different RPython-based languages. We evaluate the performance of our implementation for RSqueak, an RPython-based VM for Squeak/Smalltalk and show that storage strategies may indeed offer performance benefits for certain workloads in other dynamic programming languages.We furthermore evaluate the generality of our implementation by applying it to Topaz, a Ruby VM, and Pycket, a Racket implementation.

Lively groups: shared behavior in a world of objects without classes or prototypes

Development environments which aim to provide short feedback loops to developers must strike a balance between immediacy and the ability to abstract and reuse behavioral modules. The Lively Kernel, a self-supporting, browser-based environment for explorative development supports standard object-oriented programming with classes or prototypes, but also a more immediate, object-centric approach for modifying and programming visible objects directly. This allows users to quickly create graphical prototypes with concrete objects. However, when developing with the object-centric approach, sharing behavior between similar objects becomes cumbersome. Developers must choose to either abstract behavior into classes, scatter code across collaborating objects, or to manually copy code between multiple objects. That is, they must choose between less concrete development, reduced maintainability, or code duplication. In this paper, we propose Lively Groups, an extension to the object-centric development tools of Lively to work on multiple concrete objects. In our approach, developers may dynamically group live objects that share behavior using tags. They can then modify and program such groups as if they were single objects. Our approach scales the Lively Kernel’s explorative development approach from one to many objects, while preserving the maintainability of abstractions and the immediacy of concrete objects.

Applying Data-driven Tool Development to Context-oriented Languages

There are numerous implementations of context-oriented programming on host languages that come with graphical programming environments. However, comprehensive tool support is often missing because building and integrating graphical tools is still laborious; many programmers cannot afford to be both tool user and tool builder. We present a novel, data-driven approach on programming tools to alleviate this problem. We implemented a framework in Squeak/Smalltalk and show how programmers can use it to create and adapt integrated tools for ContextS2.