@book{FelgentreffBorningHirschfeld2013,
  author    = {Felgentreff, Tim and Borning, Alan and Hirschfeld, Robert},
  title     = {Babelsberg : specifying and solving constraints on object behavior},
  publisher = {Universit{\"a}tsverlag Potsdam},
  address   = {Potsdam},
  isbn      = {978-3-86956-265-0},
  url       = {http://nbn-resolving.de/urn:nbn:de:kobv:517-opus-67296},
  publisher      = {Universit{\"a}t Potsdam},
  pages     = {53},
  year      = {2013},
  abstract  = {Constraints allow developers to specify desired properties of systems in a number of domains, and have those properties be maintained automatically. This results in compact, declarative code, avoiding scattered code to check and imperatively re-satisfy invariants. Despite these advantages, constraint programming is not yet widespread, with standard imperative programming still the norm. There is a long history of research on integrating constraint programming with the imperative paradigm. However, this integration typically does not unify the constructs for encapsulation and abstraction from both paradigms. This impedes re-use of modules, as client code written in one paradigm can only use modules written to support that paradigm. Modules require redundant definitions if they are to be used in both paradigms. We present a language - Babelsberg - that unifies the constructs for en- capsulation and abstraction by using only object-oriented method definitions for both declarative and imperative code. Our prototype - Babelsberg/R - is an extension to Ruby, and continues to support Ruby's object-oriented se- mantics. It allows programmers to add constraints to existing Ruby programs in incremental steps by placing them on the results of normal object-oriented message sends. It is implemented by modifying a state-of-the-art Ruby virtual machine. The performance of standard object-oriented code without con- straints is only modestly impacted, with typically less than 10\% overhead compared with the unmodified virtual machine. Furthermore, our architec- ture for adding multiple constraint solvers allows Babelsberg to deal with constraints in a variety of domains. We argue that our approach provides a useful step toward making con- straint solving a generic tool for object-oriented programmers. We also provide example applications, written in our Ruby-based implementation, which use constraints in a variety of application domains, including interactive graphics, circuit simulations, data streaming with both hard and soft constraints on performance, and configuration file Management.},
  language  = {en}
}
@article{PapeFelgentreffHirschfeldetal.2016,
  author    = {Pape, Tobias and Felgentreff, Tim and Hirschfeld, Robert and Gulenko, Anton and Bolz, Carl Friedrich},
  title     = {Language-independent Storage Strategies for Tracing-JIT-based Virtual Machines},
  series = {ACM SIGPLAN notices},
  volume    = {51},
  journal   = {ACM SIGPLAN notices},
  publisher = {Association for Computing Machinery},
  address   = {New York},
  issn      = {0362-1340},
  doi       = {10.1145/2816707.2816716},
  pages     = {104 -- 113},
  year      = {2016},
  abstract  = {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 off er 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.},
  language  = {en}
}