Pozvánka na 165. sraz OpenAlt – Praha – GraalVM

I když je GraalVM “nejrychlejší virtuální stroj na světě,” nebylo by lepší “virtuální stroj” vůbec nemít a překládat přímo do binárky? Jaké jsou v dnešní době výhody?

Např. můžete za běhu generovat nativní kód optimalizovaný podle reálného běhu aplikace, můžete ve virtuálním stroji spouštět dynamické jazyky. Spíš si nejprve zkuste odpovědět na otázku, proč by podle vás mělo být lepší virtuální stroj vůbec nemít. Myslíte si, že zpomaluje aplikaci? Proč si to myslíte? Je to úplně stejné, jako s programovacími jazyky – teoreticky by také nejrychlejší aplikace byly napsané ve strojovém kódu a bylo by lepší vůbec nemít žádný assembler, nebo dokonce C nebo Python nebo Javu. Jenže ve vyšších jazycích se píše mnohem efektivněji a dnešní kompilátory už umí optimalizovat lépe, než by to optimalizoval programátor. Stejné je to i s virtuálními stroji – píše se pro ně efektivněji, a dnes už přichází ta doba, že kód jimi optimalizovaný za běhu se rychlostí vyrovnává kódu optimalizovanému předem kompilátorem.

Rychlost se “téměř vyrovnává” nativnímu kódu a deployment je mnohem větší vopruz, takže máme zatím dvě nevýhody. Co je ta výhoda, která by mě měla přimět nainstalovat VM, když můžu nasadit (v ideálním případě statickou) binárku?

Proč se na něco ptáte, když odpověď slyšet nechcete? Kdyby vás odpověď zajímala, najdete ji v komentáři, na který jste reagoval. Místo toho si radši vymýšlíte.

Ta otázka byla v podstatě rétorická, každý zkušený vývojář ostatně výhody statických binárek zná. Záhadou spíše je, proč javisti zdůrazňují rychlost VM, ta je vskutku (vzhledem ke způsobu práce VM) úctyhodná, ovšem memory footprint je, zejména v případě Javy, v porovnání s jinými, nativně překládanými jazyky, katastrofický. To Java funboys mlčky přecházejí, protože na to neexistuje argument.

Upřímně by mě zajímala reakce od někoho, kdo tomu rozumí a je objektivní.

Pro běh server aplikací jsou optimalizace na VM co jsem tak četl efektivnější, VM může ten běh sledovat a optimalizovat průběžně, ale zas to žere hodně paměti myslím. AOT - tak se jmenuje to spojené s tím překladem rovnou do bináru, tam to takhle optimalizovat nepůjde. A obecně z pohledu vývoje celého řešení a VM a AOT jde proti sobě. Nicméně co vím tak Dart, .NET a asi i Go to mají vyřešené a GrallVM to podle mě také právě řeší.

Jenže AOT je z principu efektivní a JIT se k němu může efektivitou jen asymptoticky blížit (což se na amd64 děje, na ARMu to je zatím veleostuda). Otázka je, co vyváží nevýhody složitého deploymentu, VM je element navíc bez zjevných výhod. To s tím žraním paměti je sice v případě Javy pravda, ale nesouvisí to s VM, prostě má špatně udělanou celou správu paměti, ale tohle není kontroverzní téma, co vidí každý, kdo zná jazyky s kvalitní escape analýzou.

Uvidíme, jestli se vyjádří někdo z týmu GraalVM.