Maszyna da Vinci
Deweloperzy | Mikrosystemy Słońca |
---|---|
System operacyjny | Międzyplatformowe |
Typ | Biblioteka |
Licencja | GPL + wyjątek łączenia |
Strona internetowa |
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
Przed wersją Java 7 wirtualna maszyna Java nie miała wbudowanej obsługi języków o dynamicznym typowaniu :
- Istniejący zestaw instrukcji maszyny JVM ma typ statyczny .
- JVM ma ograniczone wsparcie dla dynamicznego modyfikowania istniejących klas i metod. Obecnie działa tylko w środowisku debugowania .
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ż
- Skrypty dla platformy Java
- Lista języków JVM
- Dynamic Language Runtime — środowisko firmy Microsoft, które zapewnia obsługę języków dynamicznych w .NET Framework Common Language Runtime
- Nashorn (silnik JavaScript) — oparty na maszynie Da Vinci