La máquina Da Vinci , también llamada máquina virtual multilingüe , fue un proyecto de Sun Microsystems cuyo objetivo era crear un prototipo de la extensión de la máquina virtual Java (JVM) para añadir soporte para lenguajes dinámicos .
Ya era posible ejecutar lenguajes dinámicos sobre la JVM, pero el objetivo es facilitar nuevas implementaciones de lenguajes dinámicos y aumentar su rendimiento. Este proyecto fue la implementación de referencia de JSR 292 ( Soporte para lenguajes de tipado dinámico en la plataforma Java ). [ 1 ]
Historia

Antes de Java 7, la Máquina Virtual de Java no tenía soporte integrado para lenguajes de tipado dinámico :
- El conjunto de instrucciones JVM existente es de tipado estático . [ 2 ]
- La JVM tiene un soporte limitado para modificar dinámicamente las clases y los métodos existentes. Actualmente, solo funciona en un entorno de depuración .
JSR 292 ( Soporte para lenguajes de tipado dinámico en la plataforma Java ) [ 1 ] propone lo siguiente:
- agregar una nueva
invokedynamicinstrucción a nivel de JVM, para permitir la invocación de métodos que dependen de la verificación dinámica de tipos , [ 3 ] [ 4 ] [ 5 ] - Poder cambiar clases y métodos dinámicamente en tiempo de ejecución en un entorno de producción.
Tras el éxito de la implementación de JRuby en Java , el proyecto Da Vinci se inició a finales de enero de 2008. [ 6 ] Se planeó que las capacidades experimentadas por Da Vinci se añadieran a Java 7. Su objetivo es crear un prototipo de este JSR, pero también de otras extensiones de menor prioridad. [ 7 ] El primer prototipo funcional, desarrollado como un parche en OpenJDK , se anunció y se puso a disposición a finales de agosto de 2008. [ 8 ] [ 9 ] [ 10 ]
Desde entonces, el equipo de JRuby ha integrado con éxito la invocación dinámica en su código. La invocación dinámica se incluyó en la versión 1.1.5 y se deshabilitará en las JVM sin invokedynamiccapacidades. [ 11 ]
Desde entonces, el proyecto se ha integrado en el código base de JDK 7 [ 12 ] y luego se ha integrado en la versión Java 7 .
Arquitectura
La invocación dinámica se basa en el hecho de que, aunque Java es un lenguaje fuertemente estático a nivel de lenguaje, la información de tipo es mucho menos frecuente a nivel de código de bytes .
Sin embargo, las implementaciones de lenguajes dinámicos necesitan poder usar la compilación justo a tiempo (en lugar de la reflexión ) para lograr un buen rendimiento, y así compilar los scripts a bytecode en tiempo de ejecución. Para que la Máquina Virtual de Java permita su ejecución , estos bytecodes deben verificarse antes de la ejecución, y el verificador comprueba que los tipos sean estáticos en todo el código. Esto conlleva que estas implementaciones tengan que crear muchos bytecodes diferentes para los distintos contextos de una llamada a un método, cada vez que cambia la firma de los argumentos .
Esto no solo consume mucha memoria, sino que también llena un área de memoria llamada Metaspace (Generación Permanente antes de Java 8), una parte del montón que la JVM utiliza para almacenar información sobre las clases . La memoria utilizada en esta área casi nunca se elimina mediante el recolector de basura porque almacena datos inmutables en el contexto de los programas Java; y debido a eso, las implementaciones de lenguajes dinámicos solo pueden compilar una pequeña parte de los scripts. [ 13 ]
JSR 292 propone lo siguiente:
- proporcionar un mecanismo mediante el cual se pueda cargar y modificar una clase existente, produciendo una nueva clase con esas modificaciones pero compartiendo el resto de su estructura y datos, sin ocupar así el espacio de Generación Permanente ,
- Proporcionar el nuevo
invokedynamiccódigo de bytes que permite a la JVM optimizar las llamadas de este tipo. [ 3 ]
Véase también
- Programación de scripts para la plataforma Java
- Lista de lenguajes JVM
- Dynamic Language Runtime : un entorno de Microsoft que proporciona compatibilidad con lenguajes dinámicos al Common Language Runtime de .NET Framework.
- Nashorn (motor JavaScript) — basado en la máquina Da Vinci
Referencias
- 1 2 ver JSR 292
- ↑ Nutter, Charles (2007-01-03). "InvokeDynamic: ¿Realmente útil?" . Recuperado el 2008-02-06 .
- 1 2 Ed Ort (julio de 2009). "Nueva característica de JDK 7: soporte para lenguajes de tipado dinámico en la máquina virtual Java" . Recuperado el 26 de julio de 2009 .
- ↑ Jeff Friesen (16 de diciembre de 2014). "Cómo invocar dynamic" . JavaWorld . Consultado el 10 de junio de 2020 .
- ↑ Rafael Winterhalter (2 de marzo de 2015). "Desmantelando invokedynamic" . dzone.com . Consultado el 10 de junio de 2020 .
- ↑ Krill, Paul (31 de enero de 2008). "La máquina Da Vinci de Sun amplía la cobertura de la JVM" . Archivado del original el 28 de marzo de 2009. Consultado el 6 de febrero de 2008 .
- ↑ "Subproyectos e investigaciones" . Sun Microsystems . 2007. Consultado el 6 de febrero de 2008 .
- ↑ Rose, John (26 de agosto de 2008). "¡Feliz Día Internacional de Invokedynamic!" . Archivado del original el 3 de septiembre de 2008. Recuperado el 3 de septiembre de 2008 .
- ↑ Rose, John (2 de septiembre de 2008). "¡Feliz Día Internacional de Invokedynamic!" . Consultado el 7 de septiembre de 2008 .
- ↑ Lorimer, RJ (1 de septiembre de 2008). "La invocación dinámica se ejecuta en OpenJDK" . infoq.com . Consultado el 3 de septiembre de 2008 .
- ↑ Nutter, Charles (11 de septiembre de 2008). "Una primera toma de InvokeDynamic" . Recuperado el 13 de septiembre de 2008. ¡
Logré integrar InvokeDynamic directamente en el proceso de despacho de JRuby! ¡Qué emoción! El código ya está en la rama principal de JRuby y se incluirá con JRuby 1.1.5 (aunque obviamente estará deshabilitado en las JVM sin InvokeDynamic).
- ↑ Rose, John (22 de abril de 2009). "progreso: indy.patch -> JDK7" . Consultado el 30 de abril de 2009.
La mayor parte de indy.patch se ha incorporado a la máquina virtual JDK7 en el repositorio de integración de mi grupo de trabajo, hoy alrededor de las 4:00 a. m. PDT:
- ↑ Nutter, Charles (11 de septiembre de 2008). "Una primera toma de InvokeDynamic" . Recuperado el 6 de febrero de 2008. El
secreto sucio de varias implementaciones de JVM, incluyendo Hotspot, es que hay un montón separado (o una generación separada del montón) utilizado para tipos especiales de datos como definiciones de clase, metadatos de clase y, a veces, bytecode o código nativo JIT. Y no podría tener un nombre más aterrador: la Generación Permanente. Excepto en casos raros, los objetos cargados en la PermGen nunca se recolectan como basura (porque se supone que son permanentes, ¿entiendes?) y si no se usa con mucho, mucho cuidado, se llenará (...)
Enlaces externos
- Página del proyecto de la Máquina Da Vinci
- Presentación de Sun en el Simposio Lang.NET
- Blog de John Rose (líder del proyecto)
- Documento de presentación JSR 292
- Documento de presentación JSR 292 ACM 2010
- máquina virtual Java
- Software de plataforma Java
- Software beta
- Solicitudes de especificación de Java
- Software de Sun Microsystems
- Software que utiliza la excepción de enlace GPL