Maszyna da Vinci

Wielojęzyczna maszyna wirtualna
Deweloperzy Mikrosystemy Słońca
System operacyjny Międzyplatformowe
Typ Biblioteka
Licencja GPL + wyjątek łączenia
Strona internetowa openjdk .java .net /projekty /mlvm /

Maszyna Da Vinci , zwana także wielojęzyczną maszyną wirtualną , była projektem Sun Microsystems mającym na celu stworzenie prototypu rozszerzenia Java Virtual Machine (JVM) w celu dodania obsługi języków dynamicznych .

Uruchamianie języków dynamicznych na JVM było już możliwe, ale celem jest ułatwienie implementacji nowych języków dynamicznych i zwiększenie ich wydajności. Ten projekt był referencyjną implementacją JSR 292 ( Obsługa dynamicznie typowanych języków na platformie Java ).

Historia

Java virtual machine architecture.svg

Przed wersją Java 7 wirtualna maszyna Java nie miała wbudowanej obsługi języków o dynamicznym typowaniu :

JSR 292 ( Supporting Dynamically Typed Languages ​​on the Java Platform ) proponuje:

  • dodać nową instrukcję invokedynamic na poziomie JVM, aby umożliwić wywołanie metody w oparciu o dynamiczną kontrolę typu ,
  • aby móc dynamicznie zmieniać klasy i metody w czasie wykonywania w środowisku produkcyjnym.

Po sukcesie implementacji JRuby Java , pod koniec stycznia 2008 r. rozpoczęto projekt Da Vinci. Możliwości eksperymentowane przez Da Vinci miały zostać dodane do Javy 7 . Ma na celu stworzenie prototypu tego JSR, ale także innych rozszerzeń o niższym priorytecie. Pierwszy działający prototyp, opracowany jako łatka na OpenJDK , został ogłoszony i udostępniony pod koniec sierpnia 2008 roku.

Od tego czasu zespół JRuby z powodzeniem okablował dynamiczne wywołanie w swojej bazie kodu. Wywoływanie dynamiczne jest dostarczane z wersją 1.1.5 i zostanie wyłączone na maszynach JVM bez możliwości wywoływania dynamicznego .

Od tego czasu projekt został zintegrowany z kodem JDK 7 , a następnie zintegrowany z wydaniem Java 7 .

Architektura

Dynamiczne wywołanie opiera się na fakcie, że nawet jeśli Java jest językiem silnie statycznym na poziomie języka, informacje o typie są znacznie mniej rozpowszechnione na poziomie kodu bajtowego .

Jednak implementacje języków dynamicznych muszą być w stanie używać kompilacji just-in-time (zamiast refleksji ), aby osiągnąć dobrą wydajność, a więc kompilować skrypty do kodu bajtowego w czasie wykonywania. [ potrzebne źródło ] Aby mogły być uruchamiane przez wirtualną maszynę Java , te kody bajtowe muszą zostać zweryfikowane przed wykonaniem, a weryfikator sprawdza, czy typy są statyczne w całym kodzie. Prowadzi to do tego , że te implementacje muszą tworzyć wiele różnych kodów bajtowych dla różnych kontekstów wywołania metody, za każdym razem, gdy zmienia się sygnatura argumentów .

To nie tylko zużywa dużo pamięci, ale także wypełnia obszar pamięci zwany Metaspace (Permanent Generation przed Javą 8), część sterty używanej przez JVM do przechowywania informacji o klasach . Pamięć używana w tym obszarze prawie nigdy nie jest zbierana bezużytecznie , ponieważ przechowuje niezmienne dane w kontekście programów Java; iz tego powodu implementacje języków dynamicznych mogą skompilować tylko niewielką część skryptów.

JSR 292 proponuje:

  • zapewnić mechanizm, za pomocą którego można ładować i modyfikować istniejącą klasę, tworząc nową klasę z tymi modyfikacjami, ale dzieląc resztę swojej struktury i danych, nie zapełniając w ten sposób przestrzeni Permanent Generation ,
  • udostępnić nowy dynamiczny kod bajtowy invoke , który umożliwia maszynie JVM optymalizację wywołań tego rodzaju.

Zobacz też

Linki zewnętrzne