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.
Urcite sa prosim rozpiste. Zaujima ma:
1 ako je to s reflexiou a invoke dynamic pri AOT kompilacii cez native image
2 nejake quick teoreticke intro k partial escape analysis
3 ten magicky garbage collector v Substrate VM, ktory je noop a nic nerobi
4 separatne heapy a dropovanie heapov bez gc
5 AOT a pamatove bariery/JMM/volatile
dakujem!
Jen pro kompletnost. Omezení SubstrateVM jsou sepsaná zde https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md
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!?
Vzhledem k tomu, že node.js má podporu SPARC jen ve Feature Requestu a V8 NEMÁ podporu SPARC tak by bylo lepší dopsat podporu pro SPARC do V8 a následně do node.js.
Na to není čas/HW :( přitom je to na 99 % stejné jako Solaris na x64 (endianity jsou snad vyřešeny díky podpoře MIPS/PPC).
Ale vymýšlet workaroundy stylem 30 MB node.js vám na SPARC poběží, když si ještě nainstalujete 100 MB? GraalVM + X GB Java 8 na to čas je. Ale je to OpenSource, že? ;)
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.
To je bozi, ja uz jsem to zkousel u JDK 9 (diky tomu jsem se vlastne o GraalVM dozvedel).
Jeste jsem se chtel zeptat, je nejaka sance na rozsireni native-image o dalsi funkcionalitu, ktera by umoznila beh rekneme Java enterprise aplikaci pomoci native-image?
Veci rekneme typu Spring Boot / Thorntail - v soucasne dobe to urcite mozne neni minimalne diky omezeni reflexi a hlavne dynamickeho class loadingu.
Nejsem si jisty, zda by to vubec melo smysl, spise me to zajima za zvedavosti, jake mate plany v native-image.
Nedávno jsem pracoval na integraci native-image s Fn Projektem (to by mohla být budoucnost oblačných technologií u Oraclu). AOT překlad by se tam hodil - rychleji to startuje a zabírá to méně paměti. Fn projekt používá Jackson na serializaci/deserializaci JSONu a zdá se, že to není problém uchodit. Jen je potřeba dopředu specifikovat, které třídy mají být dostupné pro reflektivní přístup - viz. dokumentace. O SpringBootu se u nás také mluvilo, ale zatím se nenašel nikdo, kdo by měl čas a chuť to uchodit, pokud vím.