Vlákno názorů k článku Vyšla Java 11: menší core systém a experimentálne garbage collectory od Bflmpsvz - A kdy to přestane být tak nenažrané na...

A kdy to přestane být tak nenažrané na systémové prostředky? Tak příjemný a hezký jazyk zabít totálně nenažraným JVM. Nechápu.

Nemyslím, že je java zrovna nenažraná co se týká JVM. Celkově jsou tady hlavní problémy dva. Prvním je neznalost programátorů, kteří často neví, jak se JVM chová k jejich datům v paměti, jak alokuje a uvolňuje prostředky. Neumí správně optimalizovat kód aby nevytvářel zbytečně nové "short lived" instance objektů, tedy nerecykluje. Využití profileru je bohužel u takových jedinců velkou neznámou. Druhým problémem pak je uživatel co aplikaci spouští s "default" nastavením JVM. Když mu dám 1 GB paměti, tak si to JVM prostě vezme, pak tu jsou ty neopodstatněné stížnosti na nenažrané aplikace, bohužel je to jen neznalost.

Když jsem psal aplikaci (computer vision a machine learning), tak mi úplně stačilo 64 MB aby to celé nespadlo na nedostatek paměti, ale čas procesoru strávený v GC byl už nad 10 %. Naopak, když jsem aplikaci dal 2 GB, tak se GC nespustil téměř nikdy, ale už je to celkem pořádný kousek paměti oproti minimu. Tím chci říct, že vždy jde o nalezení kompromisu mezi spotřebou RAM, CPU a programátorskou leností.

ZGC a Shenandoah GC tento koncept kompletne rusia. Oba pouzivaju particie. Shenandoah fixne, ZGC variabilne velke. Oba sa uz nespoliehaju na generational hypothesis ale razia cestu kooperativnej concurrent kompakcie. Shenandoah myslim aplikuje aj back pressure na rogue thready, ktore vela alokuju.

Nesetrna praca s pamatou aj vyplyva z principu, ktory JVM presadzuje: ked je kazdy objekt alokovany na heape a vsetko je by reference, tak holt musi pocitat s tym, ze bude vela kratko zijucich objektov. Keby bolo mozne alokovat na stacku, a bolo by mozne pouzivat by value, tak to by uvolnilo tlak na pamat.

Rovnako profiler: ked ma programator aplikaciu, kde mu bezi cely jboss, spring, hibernate plus nejake dalsie velke frameworky, tak sa necudujem, ze sa na neho vykasle. Vtedy je docela rad, ze to vobec funguje v ramci terminov, v ktorych sa moze pohybovat.

Není jedním z hlavních „selling points“ Javy to, že se člověk nemusí starat o nízkoúrovňové věci jako je to, jak se JVM chová k datům, jak jsou tato data representována v paměti apod.? Pro většinu aplikací je dnes výkonu a paměti dost, takže není divu, že většina vývojářů tyhle nízkoúrovňové záležitosti neřeší. Další generace už to třeba ani nebude umět.

Další problém je to, že normální vývojář zákaznické aplikace pracuje s řadou různých knihoven a nemá čas na to, aby je všechny detailně zkoumal, nebo si psal vlastní. Takže i když budu optimalisovat co to jde a psát perfektní kód, stačí jedna problematická knihovna a chování celé aplikace jde do háje.

Ad garbage collector: mně více vyhovovalo ARC v ObjC, ale i s GC se žít dá. Velké problémy mi způsobil jen jednou (import a zpracování velkého množství nevhodně strukturovaných dat na hodně slabém hardware).

JJ

Vždycky se o to musíš nějak starat ... Nebo musíš, nemusíš, ale ...

"Pro většinu aplikací je dnes výkonu a paměti dost"
To jiste ... a proto si porad vsichni stezujou, ze to nefunguje.

Při přebírání zákazníkem to většinou nějak přijatelně funguje a dál holt spousta lidí nedohlédne, nebo to neřeší, protože jim většinou nikdo nezaplatí za to, aby nějaká funkce/aplikace byla napsána čistěji a běžela o 5 % rychleji nebo potřebovala o 2 MB méně paměti. No a když podobně postupují autoři knihoven a operačních systémů, tak se těch 5 % postupně nastřádá a je veselo.

IMHO jsou tyhle problémy odvrácenou stranou toho, že programování je čím dál tím více odděleno od železa a operačních systémů různými abstrahujícími vrstvami. Což má samozřejmě i spoustu výhod a je to svým způsobem nezbytné, protože v assembleru dnešních CPU se uživatelské aplikace reálně moc psát nedají.

Tohle "začnete něco stavět jako microservices" zrovna zní jako typický případ, kdy se nevyplatí investovat čas a prachy do nějaké přehnané optimalizace. Jo, můžeš si to napsat celé v C nebo assembleru a uplatnit v tom všechny Berkeley/MIT/Matfyz triky, co znáš, ale pokud to není vyloženě trivialita, bude ti to nejspíš trvat násobně déle než v Javě. A celou tu dobu, co tím strávíš navíc, bys mohl dělat něco jiného. Mnohé firmy si už dávno spočítaly, že čas vývojářů je příliš cenný prostředek, než aby si mohly dovolit jím plýtvat na něco, co se dá jednoduše vykompenzovat navýšením výpočetního výkonu. Což samozřejmě neznamená, že bychom se měli na optimalizaci vykašlat úplně, spíš myslet na to, že technicky dokonalé řešení je v praxi mnohdy zbytečný overkill.