GC v Javě a Go

[geek]

Mám dotaz, na který se mi nepovedlo vygooglit odpověď: Proč je latence GC v Go o tolik menší než v Javě? Při velké haldě (nad řekněme 16GB) se Java zasekává na vteřiny, kdežto Go zamrzne jen na pár milisekund. Cvičně jsem nahrál do paměti celou naši firemní databázi (přes 10 GB) a při práci s vše jede Go hladce, zatímco Java "stops the world". Testováno na Linuxu, Java je od Oraclu, Go verze 1,5.

[Reklama]

[Anonymous]

este nedavno (go 1.4.1) to bolo nahovno aj v go. ale teraz v 1.5 to komplet prerobili a je to parada

[Radek Miček]

Asi v Javě používáte nevhodný GC. Zkoušel jste G1?

[Anonymous]

Asi v Javě používáte nevhodný GC. Zkoušel jste G1?

presne toto je filozofia java sveta, spravit vela garbage collectorov, v kazdom milion parametrov, potom mat v produkcii zvlast
cloveka co nic ine nerobi nez furt ladi parametere tych garbage collectorov

[Sten]

Těžko říct, záleží, jaký typ GC se v té Javě používá. Paralelní mark+sweep (-XX:+UseConcMarkSweepGC), který používá Go, je velmi rychlý, i když není tak efektivní. Máme v Javě několik serverů, které mají haldy v gigabajtech, a žádné záseky tam CMS nejsou, ani když paměť lítá. Můžete zkusit i hodně nový G1 (-XX:+UseG1GC), ten je i soft realtime (-XX:MaxGCPauseMillis=200).

Druhá možnost je, že se to dostane až blízko k OOM. Nevím, jak se v takovém případě chová Go, ale Java se snaží opravdu hodně, aby uvolnila veškerou poslední paměť, kterou může, což při takové haldě opravdu bude trvat dlouho (ale i to lze změnit).

[Reklama]

[Kit]

Pokud bych dnes programoval GC, asi bych segmentoval hromadu na mikrooddíly se samostatnou správou. Každé spuštění GC by pak defragmentovalo jen jeden oddíl. Sice by se to muselo spouštět častěji, ale zkrátily by se latence.

Třeba podobnou strategii použili i v novém Go.

[Sten]

Asi v Javě používáte nevhodný GC. Zkoušel jste G1?

presne toto je filozofia java sveta, spravit vela garbage collectorov, v kazdom milion parametrov, potom mat v produkcii zvlast
cloveka co nic ine nerobi nez furt ladi parametere tych garbage collectorov

To bude tím, že u GC musíte vyvažovat mezi rychlý, konkurentní a efektivní. Tudíž neexistuje univerzální GC, který bude dobře fungovat na jednojádrových strojích s desítkami MiB RAM, na vícejádrových (jednoprocesorových) strojích s pár GiB RAM i na strojích s mnoha procesory a desítkami GiB NUMA RAM. A proto Java dává možnost volby a detailní nastavení. Možná by dnes už stálo za to, aby Java měla jako výchozí CMS, ale komunita kolem Javy je hodně konzervativní k jakýmkoliv změnám výchozího nastavení.

[Zdenek Henek nereg]

Asi v Javě používáte nevhodný GC. Zkoušel jste G1?

presne toto je filozofia java sveta, spravit vela garbage collectorov, v kazdom milion parametrov, potom mat v produkcii zvlast
cloveka co nic ine nerobi nez furt ladi parametere tych garbage collectorov

To bude tím, že u GC musíte vyvažovat mezi rychlý, konkurentní a efektivní. Tudíž neexistuje univerzální GC, který bude dobře fungovat na jednojádrových strojích s desítkami MiB RAM, na vícejádrových (jednoprocesorových) strojích s pár GiB RAM i na strojích s mnoha procesory a desítkami GiB NUMA RAM. A proto Java dává možnost volby a detailní nastavení. Možná by dnes už stálo za to, aby Java měla jako výchozí CMS, ale komunita kolem Javy je hodně konzervativní k jakýmkoliv změnám výchozího nastavení.

jdk 9 by melo mit defaultni G1, jeste se o tom diskutuje.

zatim pouzivam CMS, pri upgrade ze 7 na 8 jsem presel z iCMS na CMS a zatim v pohode. Max full gc bylo po 2 mesicich provozu bez restartu 2s a full gc se provedlo tusim 10x. Heap 6gb, vetsionu vyuzito tak 2 - 3 gb. Oproti iCMS jsem se jeste nikdy nedostal pres 5gb heapu.

[Zdenek Henek nereg]

Asi v Javě používáte nevhodný GC. Zkoušel jste G1?

presne toto je filozofia java sveta, spravit vela garbage collectorov, v kazdom milion parametrov, potom mat v produkcii zvlast
cloveka co nic ine nerobi nez furt ladi parametere tych garbage collectorov

Budu hadat, ze ani ten jeden clovek moc zazraku neudela.

Neznam Vas kontext, ale stalo by za to se podivat, jestli to neni chyba mezi programatorovou klavesnici a zidli. Nevhodne nakladani s pameti zpusobuje presne, co jste popsal. Immutable objekty, zpracovani velkeho mnozstvi dat ve streamu by mohlo pomoct. Misto  "patternu" nacti vse, zpracuj vse, zahod vse, kde vse je v radu stovek megabajtu. To se pak gc pekne zapoti.

[gofan]

pan mozna spatne guglil :

http://lmgtfy.com/?q=golang+new+gc

nic proti jave samozrejme

[andy]

Pretoze golang pouziva mierne upraveny algoritmus, ktory vymyslel jeden z autorov. Ma niekde vycapeny aj dokaz korektnosti, ale o podrobnosti som sa nezaujimal.

[Kolemjdoucí]

Nevhodne nakladani s pameti zpusobuje presne, co jste popsal. Immutable objekty, zpracovani velkeho mnozstvi dat ve streamu by mohlo pomoct.

Není naopak naprosto obráceně lepší se těch immutable objektů zbavit? Mít jeden objekt který mění vnitřní stav je přeci pro GC mnohem lepší než pořád vytvářet nové immutable objekty!

[zboj]

Pretoze golang pouziva mierne upraveny algoritmus, ktory vymyslel jeden z autorov. Ma niekde vycapeny aj dokaz korektnosti, ale o podrobnosti som sa nezaujimal.

Go používá tricolor GC.

[zboj]

Nevhodne nakladani s pameti zpusobuje presne, co jste popsal. Immutable objekty, zpracovani velkeho mnozstvi dat ve streamu by mohlo pomoct.

Není naopak naprosto obráceně lepší se těch immutable objektů zbavit? Mít jeden objekt který mění vnitřní stav je přeci pro GC mnohem lepší než pořád vytvářet nové immutable objekty!

Funkcionální struktury jsou často lepší. "Vnitřní stav" může být často dost divoký.

[zboj]

Mám dotaz, na který se mi nepovedlo vygooglit odpověď: Proč je latence GC v Go o tolik menší než v Javě? Při velké haldě (nad řekněme 16GB) se Java zasekává na vteřiny, kdežto Go zamrzne jen na pár milisekund. Cvičně jsem nahrál do paměti celou naši firemní databázi (přes 10 GB) a při práci s vše jede Go hladce, zatímco Java "stops the world". Testováno na Linuxu, Java je od Oraclu, Go verze 1,5.

Java má zásadní problém, že vše alokuje na haldě. V Go vzniká z principu mnohem méně odpadu a ve spojení s kvalitním (tricolor) GC se ta troška uklidí rychle. ObjC také mělo podobně kvalitní tracing GC, než zavedli ARC, jež mimochodem slouží stejně dobře.