Da Vinci Machine
| Company type | Software project |
|---|---|
| Industry | Software development, Virtual machines |
| Founded | January 2008 |
| Founder | Sun Microsystems |
| Fate | Integrated into JDK 7 codebase |
| Headquarters | Santa Clara , United States |
| Products | Enhancements to Java Virtual Machine for dynamic languages (JSR 292 reference implementation) |
| Parent | Sun Microsystems |
The Da Vinci Machine, also known as the Multi Language Virtual Machine, was an initiative by Sun Microsystems designed to enhance the Java Virtual Machine (JVM) by incorporating native capabilities for dynamic languages. Although dynamic languages were already executable on the JVM, this project sought to streamline their development and boost their runtime efficiency. It acted as the reference implementation for JSR 292, titled Supporting Dynamically Typed Languages on the Java Platform.
History
Prior to the release of Java 7, the JVM did not inherently support dynamically typed languages:
- The JVM’s instruction set was based on static typing.
- Runtime modifications of classes and methods were minimal and primarily limited to debugging scenarios.
JSR 292 introduced proposals including:
- The addition of an
invokedynamicinstruction to facilitate method calls with dynamic type resolution. - Enabling runtime alterations to classes and methods in live environments.
Inspired by the achievements of the JRuby implementation on Java, Sun initiated the Da Vinci project in January 2008 to develop prototypes implementing JSR 292 features alongside other improvements. The initial functional prototype, delivered as a patch for OpenJDK, became available in August 2008.
The JRuby development team incorporated dynamic invocation into their platform, releasing it in JRuby version 1.1.5; this capability automatically deactivates on JVMs lacking invokedynamic support.
Ultimately, the advancements from the Da Vinci project were integrated into the JDK 7 codebase and officially launched with the Java 7 release.
Architecture
Dynamic invocation takes advantage of the fact that while Java is strongly statically typed at the language level, its bytecode contains less explicit type information.
Implementations of dynamic languages depend on just-in-time compilation rather than reflection to efficiently translate scripts into bytecode during execution. To operate within the JVM, these bytecodes must pass through a verification process that enforces static typing consistency. This requirement leads to generating numerous bytecode variants for each method call scenario based on the signature of the parameters involved.
Such a methodology results in substantial memory consumption and exerts pressure on the JVM’s Metaspace (previously called Permanent Generation prior to Java 8), which holds class metadata. This memory region is infrequently subject to garbage collection because it mainly contains immutable data, thereby restricting how extensively dynamic language implementations can perform compilation.[1]
The objectives of JSR 292 include:
- Supporting loading and modifying existing classes to generate new classes that share structure and data without consuming additional Permanent Generation memory,
- Introducing the
invokedynamicbytecode instruction to enable JVM-level optimization of these dynamic method calls.[2]
See also
- Scripting for the Java Platform
- List of JVM languages
- Dynamic Language Runtime — Microsoft's framework enabling dynamic language support on the .NET Framework Common Language Runtime
- Nashorn (JavaScript engine) — a JavaScript engine derived from the Da Vinci Machine