Misplaced Pages

Da Vinci Machine

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.

The Da Vinci Machine , also called the Multi Language Virtual Machine , was a Sun Microsystems project aiming to prototype the extension of the Java Virtual Machine (JVM) to add support for dynamic languages .

#499500

5-630: It was already possible to run dynamic languages on top of the JVM, but the goal is to ease new dynamic language implementations and increase their performance. This project was the reference implementation of JSR 292 ( Supporting Dynamically Typed Languages on the Java Platform ). Prior to Java 7, the Java Virtual Machine had no built-in support for dynamically typed languages : JSR 292 ( Supporting Dynamically Typed Languages on

10-559: The JRuby team has successfully wired dynamic invocation in their codebase. Dynamic invocation shipped with the 1.1.5 release, and will be disabled on JVMs without invokedynamic capabilities. Since then, the project has been integrated in the JDK 7 codebase and then integrated in the Java 7 release . Dynamic invocation is built on the fact that, even if Java is a strongly static language at

15-556: The Java Platform ) proposes to: Following the success of the JRuby Java implementation, the Da Vinci project was started at the end of January 2008. The capabilities experimented by Da Vinci were planned to be added to Java 7 . It aims to prototype this JSR, but also other lower-priority extensions. The first working prototype, developed as a patch on OpenJDK , was announced and made available on end of August 2008. Since then,

20-407: The language level, the type information is much less prevalent at the bytecode level. However, dynamic languages implementations need to be able to use just-in-time compilation (rather than reflection ) to achieve good performance, and so to compile scripts to bytecode at runtime. To be allowed to be run by the Java Virtual Machine , these bytecodes must be verified prior to the execution, and

25-465: The verifier check that the types are static throughout the code. It leads to these implementations having to create many different bytecodes for the different contexts of a method call, each time the signature of the arguments change. This not only uses a lot of memory, but also fills a memory area called Metaspace (Permanent Generation prior to Java 8), a part of the heap used by the JVM to store information about classes . Memory used in this area

#499500