A partial read barrier for efficient support of live object-oriented programming

Abstract

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.

Preserving instance state during refactorings in live environments

“…gDSU applies all the changes in the new environment in a bulk swap operation, as said before this operation is implemented in the Smalltalk Virtual Machine. However, the existent implementation needs to update the whole memory [57], extending the time required in the update window. So that, gDSU is using the Miranda [57] et al implementation that reduces the update window time.…”

“…However, the existent implementation needs to update the whole memory [57], extending the time required in the update window. So that, gDSU is using the Miranda [57] et al implementation that reduces the update window time.…”

Two decades of smalltalk VM development: live VM development through simulation tools

“…There is no need to create a reproducible case for bugs encountered during simulation 11 ; the reproducible case is at hand. This approach was key in rapid development of the new memory manager that supports both 32 and 64 bits [MB15].…”

“…Support for multiple bytecode sets was added, initially to support Newspeak, and more recently to support adaptive optimization. Finally, a new object representation and garbage collector was added to improve performance and also to support 64 bits [MB15]. This required refactoring the interpreter to allow the object representation to be chosen at start-up 3 .…”

Dynamic Software Update from Development to Production.

“…To allow atomic core library and self updates and avoid meta-circularity problems, gDSU performs a copy of all objects affected by the update. It then leverages forwarders, a modern memory management technique existing in the Pharo VM, to apply the commit operation with minimal performance overhead [MB15].…”