GraalVM - High-Performance Polyglot Runtime

Zespół badawczy od Oracle'a pracuje nad nowym kompilatorem (z AST do kodu natywnego) oraz odpowiadającym mu frameworkiem (o nazwie Truffle) do szybkiej implementacji języków programowania. Dzięki frameworkowi implementator nowego języka musi jedynie napisać w Javie tłumacza z własnego języka na Truffle AST, a optymalizacją zajmie się tandem Truffle + Graal.

Artykuł: Graal & Truffle

We would want something, some kind of tool or technique, that gave us the following:

• A way to create a new language in just a few weeks
• That ran as fast as the fastest other languages, automatically
• That had high quality debugging support, automatically (ideally without any kind of slowdown)
• That had profiling support, automatically
• That had a high quality garbage collector, automatically … but only if we wanted one
• That could use all the existing code that was out there, no matter what language it was written in
• That supported any style of language, from low level C or FORTRAN to Java to Haskell to extremely dynamic scripting languages like Python and Ruby
• And which could be either just-in-time or ahead-of-time compiled
• And heck, why not, that supports hotswap of code into a running program
• Oh, and we’d want this magic tool to be open source of course. And, er, it should come with a pony. I think that’s it.

Being a smart reader, you of course already guessed that I wouldn’t be writing this article unless such a tool actually did exist. It goes by the bizarre name of Graal & Truffle. Despite sounding like it should be a pretentious hipster restaurant, it is actually a vast research project with over 40 computer scientists from across industry and academia. Together they are building a new set of compiler and virtual machine technologies that implements our wishlist above.

Lista publikacji na stronie projektu: https://github.com/graalvm/graal/blob/master/docs/Publications.md

W prezentacji https://lafo.ssw.uni-linz.ac.at/pub/papers/2016_PLDI_Truffle.pdf jest taki slajd o porównaniu wydajności GraalVMa w stosunku do najszybszych alternatyw (w sensie: jak szybko dany język chodzi na Graalu w porównaniu do najszybszej konkurencyjnej VMki dla tego języka):

Wyniki są chyba jednak trochę przestarzałe, bo powtarzają się w wielu prezentacjach. Mimo wszystko już jest nieźle.

Graala można ściągnąć stąd: http://www.oracle.com/technetwork/oracle-labs/program-languages/overview/index.html
Zawiera nawet taką funkcjonalność jak: node - Drop-in replacement for node.js with Graal.js as the executing JavaScript engine.

Moim zdaniem projekt ma mega potencjał. Nie wiadomo jednak kiedy będzie miał oficjalny status (obecnie jest w fazie rozwoju). Java 9 (która wychodzi za niecałe dwa miesiące) będzie mieć ukrytą pod przełącznikami nową funkcjonalność - możliwość podpięcia Graala jako wtyczki dla HotSpota. Prawdopodobnie w którejś kolejnej wersji Javy GraalVM zostanie zintegrowany z HotSpotem jako kolejny poziom optymalizacji.

Aktualizacja:
Nowa strona GraalVM'a jest pod adresem: https://www.graalvm.org/

Wygląda bardzo obiecująco, szczególnie biorąc pod uwagę, że pozwoli, to na integrowanie dowolnego języka bezpośrednio z VMką jedynie za pomocą odpowiedniego transpilera język-> truffle AST. Zastanawiam się jedynie jak będzie wyglądać dostęp do API z poziomu czystej Javy, bo jeżeli to jakoś rozwiążą (nazewnictwo produkowane przez Gralla), to w sumie platforma Java będzie miała jeszcze ze stulecie przed sobą.

Macie jakieś badania / raporty na temat tego gdzie wykorzystuje się języki JVM-owe (nie Java i nie Scala) na szeroką skalę?
Bo mam wrażenie że głównie jako support do Javy (typu Jython w WebSphere).
A jeśli by tak było to w zasadzie nie ma się czym ekscytować.

Groovy jako język testowy i budowania:

• gradle
• pipeline w Jenkinsie
• spock
• jmeter

Kotlin obecnie język drugiego wyboru dla Androida. Google dodał go do listy oficjalnie wspieranych języków.
I to chyba na tyle. Szukałem już pewien czas temu takiego raportu i nic nie ma :(

To w zasadzie potwierdza to co napisałem. Może z wyjątkiem Kotlina, ale nie wiadomo czy on przyspiesza na GraalVM, bo nie jest skryptowy.
Groovy jest wykorzystywany w Grails, ale nie wiem ile firm go stosuje, ja spotkałem jedną poważną firmę, ale szczególnie się tym nie interesowałem (zwłaszcza po wyskokach autora Groovy).

Cytuję:
"I can honestly say if someone had shown me the Programming Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy."
(był jeszcze gdzieś cytat że Scala też mu się przejadła - ale nie wiem czy prawdziwy)

@vpiotr
Absolutnie nie rozumiem co mało używane języki JVMowe mają wspólnego z Graal VM. Graal opiera się o AST, pomija całkowicie konwersję do Javowego bajtkodu. Nie ma też w planach robienia specjalnego backendu dla Scali, Kotlina czy Groovy'ego skoro są to języki wprost przeznaczone do kompilacji do Javowego bajtkodu.

Myślę, że nie ma sensu powtarzać tego co jest w linkach które podałem w pierwszym poście (czytaliście to w ogóle?), więc może podam jakiś przykład.

Załóżmy, że chcemy z poziomu Javy (np w odpowiedzi na zapytanie RESTowe) wywołać jakiś kod Pythonowy, który z kolei korzysta z kodu napisanego w C.

Obecne opcje są takie:

1. Odpalenie rzeczywistego Pythona. Zalety są takie, że nie trzeba się martwić kompatybilnością (używamy przecież standardowego interpretera). Wadą jest bardzo niska prędkość, zarówno przez to, że startujemy Pythona w kółko od nowa jak i przez to, że Python jest bardzo powolnym interpreterem.
2. Użycie Jythona, który jest generalnie równie wolny jak standardowy Python w wykonywaniu kodu czysto Pythonowego, ale nawet wolniejszy jeśli używamy JNI do uruchamiania kodu natywnego. Jython w obecnej postaci jest więc mało atrakcyjny. Zyskujemy jedynie na tym, że nie trzeba ładować Pythona w kółko od nowa.

W przypadku Graala możliwości są takie (obecnie jest implementacja Pythona dla Graala https://github.com/securesystemslab/zippy ale nie wiem które funkcjonalności obsługuje):

• kod Pythonowy i C są tłumaczone na wspólne AST (leniwie, tzn linijki kodu są tłumaczone na AST w momencie pierwszego wykonania)
• Graal VM interpretuje, a następnie JITuje powstały AST, przez co narzut na przeplatanie się języków jest zredukowany do minimum
• dostajemy kod, który jest bardzo szybki, bo użyliśmy zaawansowanego JITa, zaawansowane GC i ominęliśmy powolne interfejsy typu JNI

Myślę, że najwięcej szumu może narobić implementacja Node.js oparta o Graala. Dzięki użyciu Graala można odpalać JavaScriptowe wstawki z prędkością oferowaną przez Google'owe V8 bez narzutu na start tegoż V8. Odpalanie wstawek JavaScriptowych w JVMce pociąga za sobą mocne zalety:

• redukcja duplikacji kodu - możemy tę samą walidację odpalić zarówno po stronie klienta jak i serwera
• renderowanie kodu HTML po stronie serwera - w przypadku takiego Reacta czy Angulara mamy możliwość wyrenderowania statycznego HTMLa, który służy do szybkiego wyświetlenia początkowej postaci strony zanim załaduje się ów React czy Angular, podepną się pod DOMa i zaczną obsługiwać zdarzenia

Obecnie mamy w Javie do dyspozycji silniki JavaScript jak Mozilla Rhino czy Nashorn, ale oba są powolne (Rhino to już w ogóle) oraz mają spore ograniczenia (na rozmiar kodu, który mogą wykonać).

Ponadto są jeszcze inne miejsca, gdzie Graal VM może dać niezłego kopa. Mam na myśli Apache Spark. Spark jest napisany w Scali, ale oferuje interfejsy dla Javy, Scali, Pythona i R. Wykorzystanie Graala sprawiłoby, że kod w Pythonie czy R wykonywałby się znacznie szybciej, a to zwiększyłoby atrakcyjność Sparka dla analityków danych.

Obecnie jest sporo języków, którym brakuje wydajnej VMki: Python, Perl, PHP, Ruby, R, itd Wszystkie korzystają z bibliotek napisanych w C. Stąd pisanie dla nich implementacji, które opierają się na Javowym bajtkodzie i wywołaniach JNI jest dość mało atrakcyjne, bo rewolucji się tak nie zrobi. Dopiero Graal da tutaj dużego kopa i to wszystkim tym językom naraz.

Czysto natywnego kodu jak na razie Graal nie przyspiesza - w sensie LLVM IR jest JITowany przez Graala do zwykle trochę wolniejszego kodu niż ten który jest wypluwany przez kompilator LLVM AOT. Graal jest jednak dość młodym projektem w porównaniu do LLVM, więc jeszcze dużo może się zdarzyć. Najwcześniejsze commity w Graalu jakie wypatrzyłem były z 2012 roku, natomiast LLVM miał pierwsze wydanie w 2003 roku (tak podaje Wikipedia).

@Wibowit: dzieki za wyjasnienie. Z tego co opisales to JavaScript dla mnie ma najwiekszy sens jako najbardziej popularny dodatek do Javy. Python - moze dla Javovcow na jvm ma sens, ale to zbyt popularny jezyk zeby sie nagle wszyscy przerzucili z wersji C (free w znaczeniu GNU) na kontrolowana przez Wielka Czerwona Wrozke jvmke.

byłem tamtym roku na geeconie razem z @jarekr000000 i na żywo fajnie prezentowało się to ustrojstwo

Nie wiem, dla mnie ten facet ośmieszył swój własny projekt. Może z zawiści (bo np. stracił nad nim kontrolę) a może ten język rzeczywiście jest słaby - skoro nawet jego autor nie potrafi się profesjonalnie zachować? Fajny jest wywiad w Programiście z autorem PHP - facet przynajmniej jest skromny i stabilny emocjonalnie. - vpiotr wczoraj, 09:30

Nie widzę absolutnie nic nieprofesjonalnego w stwierdzeniu "I can honestly say if someone had shown me the Programming Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy." Programowanie to nie polityka - tutaj nie musisz iść w zaparte i przekonywać wszystkich, że jesteś nieomylny i najlepszy. James Strachan przestał zajmować się Groovy'm, ale schedę po nim przejęli inni i projekt był cały czas stabilny i bardzo funkcjonalny.

Podniecasz się autorem PHP, a sytuacja jest taka, że autor PHP sam się przyznał do wielu kompromitujących rzeczy ( https://en.wikiquote.org/wiki/Rasmus_Lerdorf ):

• I did not develop the PHP we know today. Dozens, if not hundreds of people, developed PHP. I was simply the first developer.
• I actually hate programming, but I love solving problems.
• I was really, really bad at writing parsers. I still am really bad at writing parsers.
• I've never thought of PHP as more than a simple tool to solve problems.
• I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way.

To ostatnie jest szczególnie kompromitujące, ale oddaje istotę PHP - to coś zaczynało jako pseudo-język ze zlepków luźnych pomysłów, bez świadomości tego jak tworzy się dobrze ustrukturyzowane języki programowania.

@Wibowit: dzieki za wyjasnienie. Z tego co opisales to JavaScript dla mnie ma najwiekszy sens jako najbardziej popularny dodatek do Javy. Python - moze dla Javovcow na jvm ma sens, ale to zbyt popularny jezyk zeby sie nagle wszyscy przerzucili z wersji C (free w znaczeniu GNU) na kontrolowana przez Wielka Czerwona Wrozke jvmke.

Pewnie nie zajrzałeś po te linki które podałem. Podam więc jeszcze raz http://www.oracle.com/technetwork/oracle-labs/program-languages/overview/index.html
Jest tam taka wyliczanka:

• node - Drop-in replacement for node.js with Graal.js as the executing JavaScript engine.
• ruby - Drop-in replacement for MRI Ruby with TruffleRuby as the executing Ruby engine.
• R - Drop-in replacement for GNU R with FastR as the executing R engine.

Jak widać, jest mocny nacisk na kompatybilność z oficjalnymi implementacjami. Jeżeli użycie GraalVMa dla naszego ulubionego języka będzie wiązało się tylko i wyłącznie z podmianą ścieżki do środowiska uruchomieniowego, a zysk będzie namacalny (w stylu kilka lub kilkadziesiąt razy wyższa wydajność) to wybór będzie oczywisty.

Dla zysku wydajnościowego ludzie są nawet w stanie poświęcić trochę kompatybilności. Tak było z PHP przed wersją 7 (gdzie we współpracy z Intelem mocno poprawiono wydajność interpretera) i HHVM'em od Facebooka. HHVM nie był w 100% kompatybilny z PHP (chyba nawet dość daleko było do tego), ale miał sporą bazę użytkowników, bo pod HHVM'em programy napisane w PHP działały kilkakrotnie szybciej.

Implementacje GraalVM'owe będą moim zdaniem (tzn wg mnie wszystko na to wskazuje) znacznie bardziej kompatybilne z oficjalnymi interpreterami niż HHVM od Facebooka, a zarazem będą dawać bardziej wymierne korzyści, więc Graalowi wróżę znacznie lepszy los niż ten który ma HHVM.

Oracle wypuściło wersję 1.0 (RC?) GraalVMa wraz z konkretną stronką: https://www.graalvm.org/

Z nowości jest osadzenie GraalVMa w eksperymentalnych wersjach MySQL czy Oracle Database. Można dzięki temu pisać procedury składowane w JavaScripcie (ale wstrętny język wybrali na start, mam nadzieję, że szybko dorzucą chociaż Pythona).

Aktualizacja:
Jest opcja by przepisać .NETa do Javy. Ktoś chętny? :D
https://github.com/oracle/graal/issues/349

Cześć, słyszał ktoś coś nowego o GraalVM?
Rozwija się to dobrze i rokuje na przyszłość?

Zastanawiam się czy mogę go używać do kompilacji Scali do aplikacji standalone po tym jak Scala Native umarła na na wersji 2.11

Pozdrawiam,
Nekromanta, poziom 10

Jest eksperymentalne wsparcie dla WebAssembly: https://github.com/oracle/graal/tree/master/wasm
Jest też postęp z native-image dla Windowsa, więc możliwe że w tym albo następnym kwartale będzie już możliwość generowania samodzielnych EXEków (bez JITa w środku) z programami Javowymi (edit: możilwe, że już się da, ale w niestandardowy sposób).

@Kamil Żabiński: żyje i ma się bardzo dobrze. Na chwilę obecną wygląda na to, że za dwa lata będzie, to javowy must have dla dużej części rynku. Chociażby dlatego, że zapewni lepszą interoperacyjność pomiędzy różnymi technologiami.

Wibowit napisał(a):

Jest też postęp z native-image dla Windowsa, więc możliwe że w tym albo następnym kwartale będzie już możliwość generowania samodzielnych EXEków (bez JITa w środku) z programami Javowymi (edit: możilwe, że już się da, ale w niestandardowy sposób).

Aktualizacja:
Provide more regular GraalVM Windows builds:

This is completed. With 20.0:

• Windows release contains a natively compiled gu that allows you to install native-image as add-on (just like on all other supported platforms).
• Contains fully functional js native-image (not that cmd-script that runs GraalJS on JVM)

There will be further refinements in 20.1 (some are already on master).

Na https://github.com/graalvm/graalvm-ce-dev-builds/releases/ są buildy testowe. Możliwe, że te najświeższe zawierają już wspomniane zmiany.

GUI toolkity takie jak Swing czy JavaFX chyba średnio działają albo w ogóle nie działają z native-image, ale w sumie native-image najbardziej się przydaje do tworzenia lekkich aplikacji konsolowych, które mają szybko startować i zajmować mało RAMu. GUI tak czy siak jest ciężkie, więc może latać na JITu.
Szczegóły np https://github.com/oracle/graal/issues/1327 lub https://github.com/oracle/graal/issues/403

Aktualizacja 2:
Jest wersja 20.0.0 GraalVMa: https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-20.0.0

• oficjalna dystrybucja zawiera komponent WebAssembly (pewnie dalej w wersji eksperymentalnej, ale można go łatwo zainstalować tak jak inne komponenty)
• native-image (kompilacja AOT) dla Windowsa działa teraz tak samo jak na innych platformach (wcześniej były jakieś protezy)

Ktoś zaczął tworzyć implementację PHP opartą o GraalVMa: https://github.com/direktspeed/trufflephp :P
Na mini benchmarku wyniki są obiecujące https://github.com/direktspeed/trufflephp/blob/master/graalvm_jjug20190227.pdf ale to baaardzo trywialny kod.

Aktualizacja: jest też osobny projekt o podobnym przeznaczeniu: https://github.com/abertschi/graalphp

Traktuj to jako potencjalny bullshit, bo nie miałem czasu zrobić pełnej, rzetelnej analizy (miała być, ale odwołali konfę i zająlem się innymi rzeczami):

Przerobiłem to co mówi człowiek w tej prezentacji na róznych vm, opcjach i graalu:

Dorobiłem też własne dodatkowe benchmarki.

Koszt abstrakcji (głównie immutable - np case class vs to samo chamsko na varach ) zmniejszał się dramatycznie na graal (co ciekawe najlepiej na najnowszym CE (20.0.0.r11-grl) ( nie EE(!!)).

(to potwierdza co mówi Chris Thalinger - aczkolwiek wyniki w benchmarkach u mnie były na poziomie nawet 10razy szybciej (względem klasycznego jvm) - trzeba jednak pamiętać, że w skali pełnej aplikacji to niestety się rozmywa, więc w efekcie wychodzi jedno-dwu procentowy przyrost wydajności (dla twittera to już istotnia różnica ).
Poprawa była Na pewno w dużym stopniu dzieki escape anaysis - z nie generowaniem śmiecia. Brak, albo duże zmniejeszenie częstości wywoływania gc był widoczny. Być może coś jeszcze, czego nie wiem.

Native image ćwiczyłem, ale nie pod kątem wydajności, nie bardzo widze sens, co gorsza nawet nie wiem jak taki jmh odpalić na native image, chociaż pewnie się da - nie spróbowałem.

(Może to opublikuje jakoś (ale mam pięc innych projektów na myśłi .... wiadomo)).

Java na Javie - w końcu można mieć JITa bez (napisanego w C++) HotSpota! (o ile dobrze zrozumiałem)

Java on Truffle — Going Fully Metacircular

A very important detail of this implementation is that it’s implemented in Java. Java on Truffle is Java on Java! Self-hosting is the holy grail of Java virtual machine research and development.
...
Being implemented in Java and being able to run Java gives Java on Truffle a very interesting property: it can run itself. Indeed, Java on Truffle is a metacircular VM, it can run itself several levels deep (albeit slower and slower every time).

Uruchamianie Javy na Javie na Javie na Javie ad infinitum to oczywiście tylko ciekawostka, ale Truffle framework, na którym oparta jest ta Java na Javie (nazwa kodowa: espresso) dostarcza różnego rodzaju narzędzia (do profilowania zużycia CPU i pamięci, mierzenia pokrycia kodu, itd) czy też dodatkowe możliwości, np. redefinicja (kawałków) klas.