Multi-language virtual machines have a number of advantages. They allow software developers to use software libraries that were written for different programming languages. Furthermore, language implementors do not have to bother with low-level VM functionality and their implementation can benefit from optimizations in existing virtual machines. MagLev is an implementation of the Ruby programming language on top of the GemStone S virtual machine for the Smalltalk programming language. In this work, we present how software components written in both languages can interact. We show how MagLev unifies the Smalltalk and the Ruby object model, taking into account Smalltalk meta classes, Ruby singleton classes, and Ruby modules. Besides, we show how we can call Ruby methods from Smalltalk and vice versa. We also present MagLev's concept of bridge methods for implementing Ruby method calling conventions. Finally, we compare our solution to other language implementations and virtual machines.
In a later paper, evaluate the concept of behavior objects for Java in Smalltalk X @cite_9 . Just as in MagLev, every Smalltalk X object is a Java object. Instead of environments, use different behavior objects for every programming language. A behavior object contains the methods for an object in one programming language. A Smalltalk behavior object is a Smalltalk class and a Java behavior object is an object similar to a Java class. Therefore, objects can have two classes. In addition, they use mapping functions to transform the object layout for object state, assuming that different programming languages expect different object state layouts. Just as in MagLev, every programming language can define a different superclass. The superclass is stored in the behavior object.
@cite_9
2074001172
To learn what constitutes correct program behavior, one can start with normal behavior. We observe actual program executions to construct state machines that summarize object behavior. These state machines, called object behavior models, capture the relationships between two kinds of methods: mutators that change the state (such as add()) and inspectors that keep the state unchanged (such as isEmpty()): "A Vector object initially is in isEmpty() state; after add(), it goes into ¬isEmpty() state". Our ADABU prototype for JAVA has successfully mined models of undocumented behavior from the AspectJ compiler and the Columba email client; the models tend to be small and easily understandable.