Proč nefunguje garbage collector?

[Val]

(budu psát o Javě, kterou znám nejlépe, ale je to IMHO i záležitost .NETu apod.) Setkávám se s tím pořád - ačkoliv v knížkách o Javě se píše jak je rychlá, skvělá a jazyky, které se překládají přímo do strojového kódu (např C++) beznadějně zastaralé, tak v reálu jsou často programy psané v Javě pomalé přesto, že výkon CPU a velikost paměti neustále rychle roste.

Zajímá mě hlavně fakt, že hodně Java aplikací co denně používám si neustále ukusuje z paměti (a ne málo), ale už ji nechce uvolňovat - což po určité době vede k vyčerpání RAM, značnému propadu výkonu a je nutné aplikaci restartovat.

Jak je to možné, vždyť garbage collector by měl tohle řešit za programátora? Kde je chyba - v programu, v platformě nebo úplně jinde? A jak se tomu vyhnout při vytváření vlastních aplikací?

[perry]

[quas4]

doporucuju si precist: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

Cely clanek je sice tematicky zamereny jinam, ale od odstavce: "Not designed for performance" pres "All about garbage collectors" a dal je to velmi pekny uvod do toho o cem GC je, jake ma vyhody a nevyhody.

[Amorph]

quas4: zajimavej clanek, diky! Jinak imho gc v jave je pouzitelnej za predpokladu, ze mas pameti dost, ale na automatiku se neda prilis spolehat, je treba jeho volani nejak vhodne osetrit. Kdyz jsem psal pred lety mobilni aplikace, tak jsem ho radsi ale zakazoval a pouzival jen explicitni volani ve vhodny moment, protoze jinak se casto choval dost nedeterministicky a delalo to nezadouci spiky ve vykonu. Ale mozna se to za ta leta uz zlepsilo, to nevim. A nakonec jsem se teda snazil psat vsechno co nejvic staticky (naalokovat rovnou s rezervou vse co muzu kdy potrebovat) i kdyz je jasne, ze se to da pouzit jen v urcitych pripadech, kdy se da aspon odhadnou maximalni pametova narocnost a zaroven si to muzu dovolit s ohledem na podminky behu moji aplikace.

[nou]

ono to nie je ze by garbage collector tie objekty neuvolnil. ale java si uz raz zabranu pamet neuvolnuje. teda ak mate v programe nejaku spicku v pouzivani pameti tak vam potom vyuzitie neklesne aj ked ju uvolnite. Java si ju proste bude drza na dalsie alokacie.
_________________
Najjednoduchšie chyby sa najtažšie hľadajú.

[tomkis]

[Val]

Trochu jsem si s tím teď hrál. Vytvořil si testovací prográmek abych viděl jak se to chová.

Při opakovaném volání funkce ve které se alokuje paměť jsem viděl, že java odmítala vůbec uvolnit paměť, dokud to nedosáhlo meze zhruba 1GB (moje PC má celkem 6GB RAM). Pak už se drží na této mezi a uvolňuje jen aby to nebylo přes. Ten 1GB odmítá uvolnit i když ví, že ho nepotřebuje a to i tehdy, když ostatní programy zbytek paměti zaplní a PC jde do kolen.

Pokud spustím tento testovací prográmek víckrát, tak každý si klidně vezme svůj 1GB paměti - takže stačí pár náročnějších java programů a postupně vám sežerou paměť - respektive drží si paměť kterou už nepotřebují.

No nevím, moc se mi to nelíbí i když předpokládám, že tvůrci Javy k tomu měli jistě dobrý důvod. Minimálně to skvěle zapadá do strategie firmy Oracle - tj vytvářet robustní a neskutečně rozežraný SW.

[goddard]

jak psal nou, tak jvm si alokovanou pamet drzi pokud ho nedonutite pomoci flagu k necemu jinemu. dalsi vec je, ze poustet jvm bez flagu pro min. a max. velikost haldy je trosku nezodpovedne. pro optimalni vykon se doporucuje nadsadit odhadovane pozadavky na pamet (ram) o 30% (to je taky duvod proc jvm alokovanou pamet neuvolnuje - aby pokryl spicky) a zvolit vhodny gc algoritmus, co z hodne zavisi na dane aplikaci (zivotnost objektu).
lidi na tohle zapominaji, pripadne si mysli ze kdyz maji vm s gc tak automaticky zmizi vsechny problemy spojene se spravou pameti. pritom jde jen o presun z urovne zdrojoveho kodu na uroven administrace prostredku aplikace v os.
_________________
http://www.dredwerkz.cz

[Val]

Nj, ale já nemusím vědět kolik bude program potřebovat z haldy a když to nastavím příliš nízko tak aplikace spadne.
Jak se dá nastavit GC aby si paměť nesyslil, ale vracel jí systému?

[goddard]

[Val]

Nj, ale pokud program načítá data ze souborů/databáze u kterých dopředu neznáš velikost tak stejně nevíš kolik to v důsledku sežere paměti.
Hrál jsem si s tím MinHeapFreeRatio a MaxHeapFreeRatio, nejdřív to nemělo vliv (respektive ne co bych čekal) až když jsem nastavil -XX:+UseSerialGC tak to zafungovalo (defaultně se předpokládám pro můj komp použije parallel GC)

[goddard]

[Val]

[goddard]

jde to jednoduse osetrit tim, ze zjistis kolik je aktualni velikost haldy pred krachem a pri dalsim spustenim to automaticky navysis. nebo nekde udelas v menu predvolbu pro zvyseni haldy a v napovede tuhle situaci popises. anebo se z te oom dostanes tak ze vsechny objekty s tim spojene uvolnis - proste ten obrazek nenactes kdyz zjistis ze je vetsi nez nastavena halda.
to ze je to potencialne nebezpecne a ne uplne jednoduche je mozna pravda, ale za svou 8 letou praxi s javovskyma aplikacnima serverama jsem se nesetkal s tim ze by nekde dlouhodobe stacil default a ze by vyrobce aplikace nedodal alespon minimalni pozadavky.
proste si holt budes muset dat tu praci a prohnat svou aplikaci v prubehu vyvoje nekolikrat profilerem a poradne ji otestovat.
pokud delas prohlizec obrazku, je to jednoduchy - musis zjistit dve veci - kolik zere sama o sobe a pak treba prumernou velikost obrazku. tak si nastavis haldu, nadsadis 30% a je to. pokud to nekdy nekomu spadne na OOM vyjimce, tak zkus dodat tu funkcionalitu ktetrou jsem popsal na zacatku.
_________________
http://www.dredwerkz.cz