Dlaczego JVM nie buforuje skompilowanego kodu JIT?

Implementacja kanonicznej maszyny JVM firmy Sun stosuje dość wyrafinowaną optymalizację kodu bajtowego, aby uzyskać prawie natywne prędkości wykonywania po kilkukrotnym uruchomieniu kodu.

Pytanie brzmi, dlaczego ten skompilowany kod nie jest zapisywany w pamięci podręcznej na dysku w celu użycia podczas kolejnych zastosowań tej samej funkcji / klasy?

W obecnej formie, za każdym razem, gdy program jest wykonywany, kompilator JIT uruchamia się od nowa, zamiast używać wstępnie skompilowanej wersji kodu. Czy dodanie tej funkcji nie zwiększyłoby znacząco początkowego czasu wykonywania programu, gdy kod bajtowy jest zasadniczo interpretowany?

Bez uciekania się do wycinania i wklejania linku opublikowanego przez @MYYN, podejrzewam, że dzieje się tak, ponieważ optymalizacje, które wykonuje JVM, nie są statyczne, ale raczej dynamiczne, oparte na wzorcach danych i wzorcach kodu. Jest prawdopodobne, że te wzorce danych ulegną zmianie w okresie istnienia aplikacji, powodując, że optymalizacje zapisane w pamięci podręcznej będą mniej niż optymalne.

Potrzebowałbyś więc mechanizmu do ustalenia, czy zapisane optymalizacje były nadal optymalne, w którym to momencie równie dobrze możesz po prostu dokonać ponownej optymalizacji w locie.

JVM firmy Oracle jest rzeczywiście udokumentowane, aby to robić - cytując Oracle,

kompilator może korzystać z modelu rozwiązywania klas Oracle JVM, aby opcjonalnie utrwalać skompilowane metody Java w wywołaniach, sesjach lub instancjach bazy danych. Taka trwałość pozwala uniknąć niepotrzebnych ponownych kompilacji między sesjami lub wystąpieniami, gdy wiadomo, że semantycznie kod Java nie uległ zmianie.

Nie wiem, dlaczego wszystkie zaawansowane implementacje maszyn wirtualnych nie oferują podobnych opcji.

Zaktualizowany do istniejących odpowiedzi - Java 8 ma JEP poświęcony rozwiązaniu tego problemu:

=> JEP 145: Skompilowany kod pamięci podręcznej . Nowy link .

Na bardzo wysokim poziomie jej deklarowanym celem jest :

Zapisz i ponownie wykorzystaj skompilowany kod natywny z poprzednich uruchomień, aby skrócić czas uruchamiania dużych aplikacji Java.

Mam nadzieję że to pomoże.

Excelsior JET ma buforujący kompilator JIT od wersji 2.0, wydanej w 2001 roku. Co więcej, jego kompilator AOT może przekompilować pamięć podręczną do pojedynczego obiektu DLL / współdzielonego obiektu przy użyciu wszystkich optymalizacji.

Nie znam faktycznych powodów, nie jestem w żaden sposób zaangażowany w implementację JVM, ale mogę wymyślić kilka prawdopodobnych:

• Ideą Javy jest bycie językiem do zapisu, który można jednorazowo uruchomić w dowolnym miejscu, a umieszczanie wstępnie skompilowanych rzeczy w pliku klasy jest pewnym naruszeniem tego (tylko „w pewnym sensie”, ponieważ rzeczywisty kod bajtowy nadal tam byłby)
• Zwiększyłoby to rozmiary plików klas, ponieważ miałbyś tam ten sam kod wiele razy, zwłaszcza jeśli zdarzyło ci się uruchomić ten sam program na wielu różnych maszynach JVM (co nie jest rzadkością, gdy rozważasz różne wersje jako różne maszyny JVM), naprawdę muszę zrobić)
• Same pliki klas mogą nie być zapisywalne (chociaż byłoby to dość łatwe do sprawdzenia)
• Optymalizacje JVM są częściowo oparte na informacjach z czasu wykonywania, a przy innych uruchomieniach mogą nie być tak przydatne (chociaż nadal powinny zapewniać pewne korzyści)

Ale naprawdę zgaduję i jak widzisz, nie sądzę, aby którykolwiek z moich powodów był faktycznym zatrzymaniem show. Wydaje mi się, że Sun po prostu nie traktuje tego wsparcia jako priorytetu i być może mój pierwszy powód jest bliski prawdy, ponieważ robienie tego zwykle może również skłonić ludzi do myślenia, że ​​pliki klas Java naprawdę potrzebują osobnej wersji dla każdej maszyny wirtualnej zamiast być wieloplatformowy.

Moim preferowanym sposobem byłoby posiadanie oddzielnego translatora z kodu bajtowego na natywny, którego można by użyć do zrobienia czegoś takiego jawnie wcześniej, tworząc pliki klas, które są jawnie zbudowane dla konkretnej maszyny wirtualnej, z prawdopodobnie oryginalnym kodem bajtowym w nich może również działać z różnymi maszynami wirtualnymi. Ale to prawdopodobnie wynika z mojego doświadczenia: głównie robię Java ME, gdzie naprawdę boli, że kompilator Java nie jest mądrzejszy w kompilacji.