Vlákno názorů k článku Příběhy z vývoje nejrychlejšího virtuálního stroje na světě od 8665c891-f916-47c6-829f-8c9c4dbd - Potom si clovek v language shootoute vsimne pamat...

Potom si clovek v language shootoute vsimne pamat a zaplace. (Alebo zajasa, ak je vyrobca pamati.)

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/java.html

Chrome je rychly, ale plati sa za to dvesto-tristomegovymi tabmi. A to uz je problem.

Ano, to je správné pozorování. V článku jsem napsal, že u dynamických jazyků již rychlost není problém. Ale ta paměť! Z principu toho, jak se překladače dynamických jazyků píší (můžu se o tom rozepsat v nějakém budoucím článku, bude-li zájem), je třeba udržovat neuvěřitelné množství metadat pro případ, že vygenerovaný assembler je příliš optimistický. Pak je třeba kód zahodit, přepnout se zpět do interpretru a to potřebuje ty meta-informace.

Pro případ Javy to umíme vyřešit. Součástí GraalVM je native-image, který umí přeložit Java bytekód do EXE souboru a úplně eliminovat potřebu metadat. Startuje to pak rychle a paměťové nároky jsou malé. Asi by to také vydalo na samostatný článek.

Dostal jsem za úkol přečíst si Lukášovu dizertační práci, tak uvidíme, jestli se tam dozvím něco, co by stálo za překlad.

Zrovna včera jsem se na GraalVM díval a překvapilo mne, že už je to dotažené do první finální podoby – a chystal jsem se na něj o víkendu podívat víc. Článek přišel jak na zavolanou :-)

Trochu mne překvapilo, že je GraalVM dostupný jen pro Linux a enterprise verze ještě pro Mac. native-image tedy umí vytvořit i Winwods x64 exe? Pro Linux umí překládat nativní kód pro x64, a i pro jiné platformy, třeba pro ARMy? Právě u zařízení s nízkým výkonem bych viděl větší výhodu kódu předem transformovaného do nativního kódu.

Když GraalVM nemusí být součástí nativní aplikace, předpokládám, že výsledkem native-image už je čistě jen nativní kód pro cílovou platformu. Je nějaký výhled, že by to místo toho byla jakási nultá iterace just-in-time překladu, s tím, že by za běhu byla stále přítomna GraalVM a na základě analýzy běhu programu by případně vytvářela just-in-time nové optimalizovanější verze nativního kódu? Ideálně kdyby pak zase uměla tyhle dodatečné optimalizace zase serializovat do spustitelné binárky, takže při ukončení procesu by se o ně nepřišlo.

Primárně GraalVM vyvíjíme na Linuxech a Macích. Proto to na nich funguje nejlépe. To, že GraalVM CE není ke stažení pro Mac je spíše věc nedostatku času a testování.

Hlavní architekturou je x64. Máme i verzi pro SPARC (nejlepším způsob jak rozchodit node.js na Solarisu je právě GraalVM) a nedávno jsem se v Krakově na GeeCONu bavil s lidmi s ARMu, co je třeba udělat pro lepší (RedHat už na tom dost zapracoval) podporu ARM64. Zdá se, že nejlepší je uchodit native-image nad JDK9+. To jsem odhadl tak na listopad 2018 +/- dvanáct měsíců. Tak uvidíme.

Když jsem překládal "native image binary", tak jsem se rozhodl to nazvat "EXE soubor". Přišlo mi, že se to v češtině vcelku vžilo i pro jiné systémy než Windows. Pravdou však je, že native-image na Windows neběží. Problém není kód, ale emulace systémových volání. Máme jen POSIX - někdo by to musel přepsat na WIN32 API či co se tam používá. Avšak Graal kompilátor na Windows funguje - opět jsme jen nenašli dost času dát to všechno dohromady - ale je to open source, že!?

Pro desktopové aplikace asi nemá native-image takový význam, a pro ostatní už tu Posixovou vrstvu nad WIN32 API řeší Microsoft v Linux Subsystem on Windows 10 – tak ať se taky snaží Microsoft :-) GraalVM nabízí spoustu nových možností, je mi jasné, že si musíte vybrat některé z nich a na ostatních.

To jsem odhadl tak na listopad 2018 +/- dvanáct měsíců

Mínus těžko, to už by to bylo loni v listopadu. :D

Je nějaký plán na nultou iteraci JIT překladu?

Ano, takový plán existuje a kupodivu to není jen plán, ale realita. JDK9 přišla s verzí ahead-of-time překladu při "instalaci" modulu. Tento překlad je implementován pomocí Graal překladače. V podstatě vytvoří tu žádanou nultou iteraci a pokud se ukáže, že není dostatečná nakopne to normální JIT a přeloží se to znova.

Výše uvedené mimochodem znamená, že Graal překladač už je součastí JDK9. Jen je třeba znát ty správné přepínače, jak jej zapnout jako JDK9 JIT:

java -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI \
  -XX:+UseJVMCICompiler  -XX:-TieredCompilation -XX:+PrintCompilation \
  -XX:CompileOnly=Demo::workload Demo

Perfektní, díky. To jsem zvědav, jestli tohle přežijí Go nebo Kotlin Native. Protože podle mne mají stejný cíl, zejména Go je asi o něco napřed co se týče připravenosti k produkčnímu nasazení, ale zase GraalVM má oproti Go obrovské možnosti a navíc může použít vše, co je teď dostupné pro Javu a dnes i JavaScript.