Машина Да Винчи
 | В этой статье есть несколько проблем. Пожалуйста, помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти шаблонные сообщения )
|
 | |
| Разработчик(и) | Сан Микросистемс |
|---|---|
| Операционная система | Кросс-платформенный |
| Тип | Библиотека |
| Лицензия | GPL + исключение привязки |
| Веб-сайт | openjdk |
Машина Да Винчи , также называемая многоязычной виртуальной машиной , была проектом Sun Microsystems, целью которого было создание прототипа расширения виртуальной машины Java (JVM) для добавления поддержки динамических языков .
Уже было возможно запускать динамические языки поверх JVM, но цель состоит в том, чтобы упростить реализацию новых динамических языков и повысить их производительность. Этот проект был эталонной реализацией JSR Поддержка динамически типизированных языков на платформе 292 ( Java ). [1]
История
[ редактировать ]
До Java 7 виртуальная машина Java не имела встроенной поддержки динамически типизированных языков :
- Существующий набор инструкций JVM типизирован статически . [2]
- JVM имеет ограниченную поддержку динамического изменения существующих классов и методов. В настоящее время он работает только в среде отладки .
JSR 292 ( Поддержка динамически типизированных языков на платформе Java ) [1] предлагает:
- добавить новый
invokedynamicинструкция на уровне JVM, чтобы разрешить вызов метода на основе динамической проверки типов , [3] [4] [5] - иметь возможность динамически изменять классы и методы во время выполнения в производственной среде.
После успеха реализации JRuby Java в конце января 2008 года был запущен проект Da Vinci. [6] Возможности, над которыми экспериментировал Да Винчи, планировалось добавить в Java 7 . Целью проекта является создание прототипа этого JSR, а также других расширений с более низким приоритетом. [7] Первый рабочий прототип, разработанный как патч для OpenJDK , был анонсирован и доступен в конце августа 2008 года. [8] [9] [10]
С тех пор команда JRuby успешно внедрила динамический вызов в свою кодовую базу. Динамический вызов поставляется с выпуском 1.1.5 и будет отключен на JVM без invokedynamic возможности. [11]
С тех пор проект был интегрирован в JDK 7. кодовую базу [12] а затем интегрирован в версию Java 7 .
Архитектура
[ редактировать ]Динамический вызов основан на том факте, что, даже если Java является строго статичным языком на уровне языка, информация о типе гораздо менее распространена на уровне байт-кода .
Однако реализации динамических языков должны иметь возможность использовать JIT-компиляцию (а не отражение ) для достижения хорошей производительности и, таким образом, для компиляции сценариев в байт-код во время выполнения. [ нужна ссылка ] Чтобы разрешить запуск виртуальной машины Java , эти байт-коды должны быть проверены перед выполнением, а проверяющий проверяет, что типы являются статическими во всем коде. Это приводит к тому, что этим реализациям приходится создавать множество разных байт-кодов для разных контекстов вызова метода каждый раз, когда сигнатура аргументов меняется .
Это не только использует много памяти, но и заполняет область памяти, называемую Metaspace (Permanent Generation до Java 8), часть кучи, используемую JVM для хранения информации о классах . Память, используемая в этой области, почти никогда не подвергается сборке мусора , поскольку в ней хранятся неизменяемые данные в контексте программ Java; и по этой причине реализации динамических языков могут скомпилировать лишь небольшую часть сценариев. [13]
JSR 292 предлагает:
- предоставить механизм, с помощью которого существующий класс может быть загружен и изменен, создавая новый класс с этими изменениями, но разделяя остальную часть своей структуры и данных, таким образом, не заполняя пространство постоянного поколения ,
- предоставить новый
invokedynamicбайт-код, который позволяет JVM оптимизировать вызовы такого типа. [3]
См. также
[ редактировать ]
- Сценарии для платформы Java
- Список языков JVM
- Среда динамического языка выполнения — среда от Microsoft, обеспечивающая поддержку динамических языков в среде общего языка .NET Framework.
- Нашорн (движок JavaScript) — на основе машины да Винчи.
Ссылки
[ редактировать ]- ^ Jump up to: а б см. JSR 292
- ^ Наттер, Чарльз (3 января 2007 г.). «InvokeDynamic: действительно полезно?» . Проверено 6 февраля 2008 г.
- ^ Jump up to: а б Эд Орт (июль 2009 г.). «Новая функция JDK 7: поддержка динамически типизированных языков в виртуальной машине Java» . Проверено 26 июля 2009 г.
- ^ Джефф Фризен (16 декабря 2014 г.). «Как вызвать динамику» . JavaWorld . Проверено 10 июня 2020 г.
- ^ Рафаэль Винтерхальтер (2 марта 2015 г.). «Демонтаж Invokedynamic» . dzone.com . Проверено 10 июня 2020 г.
- ^ Крил, Пол (31 января 2008 г.). «Компания Sun Da Vinci Machine расширяет возможности JVM» . Архивировано из оригинала 28 марта 2009 г. Проверено 6 февраля 2008 г.
- ^ «Подпроекты и расследования» . Сан Микросистемс . 2007 . Проверено 6 февраля 2008 г.
- ^ Роуз, Джон (26 августа 2008 г.). «С Международным днем Invokedynamic!» . Архивировано из оригинала 3 сентября 2008 г. Проверено 3 сентября 2008 г.
- ^ Роуз, Джон (2 сентября 2008 г.). «С Международным днем Invokedynamic!» . Проверено 7 сентября 2008 г.
- ^ Лоример, Р.Дж. (1 сентября 2008 г.). «Динамический вызов выполняется на OpenJDK» . infoq.com . Проверено 3 сентября 2008 г.
- ^ Наттер, Чарльз (11 сентября 2008 г.). «Первый опыт InvokeDynamic» . Проверено 13 сентября 2008 г.
Мне удалось успешно подключить InvokeDynamic непосредственно к процессу отправки JRuby! Такое волнение! Код уже находится в багажнике JRuby и будет поставляться с JRuby 1.1.5 (хотя он, очевидно, будет отключен на JVM без InvokeDynamic).
- ^ Роуз, Джон (22 апреля 2009 г.). «прогресс: indy.patch -> JDK7» . Проверено 30 апреля 2009 г.
Большая часть indy.patch поступила в виртуальную машину JDK7 в репозитории интеграции моей рабочей группы сегодня около 4:00 утра по тихоокеанскому времени:
- ^ Наттер, Чарльз (11 сентября 2008 г.). «Первый опыт InvokeDynamic» . Проверено 6 февраля 2008 г.
Грязный секрет некоторых реализаций JVM, включая Hotspot, заключается в том, что существует отдельная куча (или отдельное поколение кучи), используемая для особых типов данных, таких как определения классов, метаданные классов, а иногда и байт-код или собственный JIT-код. И у него не могло быть более страшного названия: Постоянное Поколение. За исключением редких случаев, объекты, загруженные в PermGen, никогда не удаляются сборщиком мусора (потому что они должны быть постоянными, понимаете?), и если их не использовать очень и очень осторожно, они заполнятся(...)