Názory k článku Monitorování procesů a správa paměti v JDK 6 a JDK 7 (2)

Escape analysis?

> Dobrý projekt totiž má dobře navržený zodpovědnostní model. Každý objekt má
> na starost jiné objekty a ty vytváří a likviduje. Platnost je vždy předem
> známa. A sdílení objektů se děje opravdu minimálně a pokud se opravdu děje,
> tak klasický refcounting (bez zamykání i v MT) to pořeší

Nojo, ale jsou i "špatné" projekty, kde to prostě takhle nejde ;-)

Mně zas třeba netrápí řešení alokace zdrojů, protože v mých projektech jediné, co se musí explicitně uvolňovat, jsou DB spojení a o ta se mi postará automaticky Spring.

Zpravidla nejsou zodpovědné za jejich život. V dokumentaci se akorát uvede, že musí platit po dobu života konstruovaného objektu. Ten kdo objekt konstruuje pak nese zodpovědnosti i za objekty, které do konstruktoru předává. Pokud je třeba držet objekty spolu s nově vznikajícím objektem v jedné instanci, pak se třída podědí a do jejího destruktoru se přidá delete na ty objekty.

Složitější situace se řeší refcountingem, nebo sdílením (třída co sleduje život kopií jedné instance a sdílené zdroje uvolňuje v okamžiku, kdy se ničí a už je jedinou)

Proti cyklům ve sdílení lze bojovat tak, že se program navrhne jako DAG (Directed Acyclic Graph), a ukazatele jdoucí opačně se do refcountingu nezapočítávají

Nojo, jenže smyslem mého příspěvku je ten, že na každý problém se hodí jiné řešení, proto jich mám v rukávech více (čím víc, tím lepší výběr) zatímco u GC jsem shledal většinou nevýhody, než výhody a nedává mi to možnost používat alternativní řešení.

Prave ze tohle je vec kterou si java programtor predstavuje jenom v nejhorsi nocni mure (aka finilizer). Cili moje predstava tady radeji selhava aneb bych prave tohle nidky neudelal ;). Je to vicemene zakazovano v kazdem lepsim kurzu javy.

V situaci, kdy paměť je jeden z prostředů, čili nemá výsadní postavení před jinými (disk, síť, procesor), je GC zbytečný luxus. A nebo by měl řešit úklid i těchto jiných prostředků, například zavírat opuštěné soubory, či likvidovat opuštěná vlákna (v C++ běžně dělám to, že "zanechávám" běžící vlákno a destruktor zajistí jeho bezproblémové ukončení. V javě musí vlákno ukončit explicitně)

O řešení v JDK 7 vím, už jsem to komentoval, je to rozhodně lepší, ale někde na půl cesty. Přitom mít možnost navázat destrukci objektu na likvidaci stackframe by se celkem dalo jednoduše implementovat.

Vlákna samozřejmě nezabíjím. Destrukor zároveň používám jako automaticky zavolanou funkci, která pošle signál a počká, až vlákno skončí. Nechat vlákno běžet dál, to je zlé. Pokud opravdu nemám přehled o tom, co zrovna vlákno dělá, mohlo by pracovat s nekonzistetními daty. GC mi sice zajistí, že data nikdo neuvolní předčasně, ale to není řešení. Kolikrát to může způsobit víc škody, než pád aplikace na SIGSEG. O pádu se programátor dozví hned, zápis do nekonzistetních dat se může projevit až po nasazení do provozu.

I za vlákno musí někdo nést zodpovědnost a nemusí to být navázáno na metodu, ale na život objektu, který jej používá, třeba okno.

Třeba zavření okna ukončí všechny vlákna, které si otevřelo, a nemusím to řešit v handleru tlačítka close.

Tak si třeba představte UI na kompresi WAV do MP3. UI ukazuje progressbar a tlačítko cancel a křížek. Vlastní algoritmus musí běžet ve vlákně, protože UI musí reagovat na uživatele. Myslíte si, že je rozumné, aby takové vlákno pracovalo dál, když uživatel tohle okno zavře?

Ano je (minimálně v některých případech).

Jaké případy máte na mysli?

Například pokud chceme, aby komprese dál běžela na pozadí.

A to se dělá zavíracím tlačítkem? Aha... Už chápu, proč si s některými výtvoru Open-source programátorů nerozumím :-)

PS: V zadání bylo, že vlákno vytvořilo okno. Okno je zodpovědné za vlákno. Pokud by to mělo běžet na pozadí, musel by vlákno vytvořit někdo jiný, třeba objekt modelu a okno je pak view (controler). To je ale jiná situace, řeší se jinak, a také nepotřebuje vlákno bežící nekontrolovatelně dál.

Mimochodem, jak u takového nekontrolovatelného vlákna poznáte, že už je hotové?

No, múže se to dělat, záleží na designu aplikace. Prostě dáš "nová konverze", otevře se nové okno, v tom zadáš parametry, pustíš a buď počkáš na výsledek nebo okno zavřeš a děláš v aplikaci něco jiného a konverze zatím běží na pozadí, zobrazovaná třeba ve status baru. IMHO takový design smysl dává.

Jinak ano, máš pravdu, asi před deseti příspěvky se o tom mluvilo, že to vytváří okno, tak daleko jsem nedočetl.

Já vím, což pro mě dělá Javu nepoužitelnou. Celý systém založený na GC je prostě takový hack řešící problémy běžné tak před 10 lety. Řekl bych, že z ručního uvolňování resourců jsem tak nějak vyrostl.

" dnes je nejak zazracne vyresen nebo jak tomu mam rozumet?"

Přesně tak! Ten kdo skutečně programuje objektově a má na vědomosti i to, že objekty nejen vznikají, ale i zanikají a má navržený správně model zodpovědností, nemusí tento problém vůbec řešit! A je úplně jedno, v jakém to je jazyce. Důležité je, že je třeba definovat přesný okamžik zániku objektu. Což objektový jazyk z GC není schopen, proto jej považuji za méně OOP, než C++

to že se při zániku objektu někde uvolňuje paměť je nepodstatné. v Javě je tohle postaveno nahlavu. Přednější je paměť, objekty jsou odsunuty na druhou kolej.

Vám přijde zodpovědné "zanechat jen tak objekt?". Kdo vám zaručí, že takto zanechaný objekt bude opravdu zničen a nebude vyvíjet nějakou další činnost? Co když Vám někdo předhodí objekt, který v sobě vytváří vlákno? Pak "zanechat jen tak" takový objekt je velice nebezpečné. A pokud nemáte jistotu, že opouštíte objekt v bezpečném stavu, musíte si bepečný stav zajistit nějak jinak... ručně, protože Java nemá nástroj na automatické sledování platnosti a zodpovědnosti

> To je nejaka uznavana definice "skutecneho oop"?

Velmi výmluvná otázka. Jsem si jist, že člověk, který by věděl o čem mluvím by se takhle neptal.

> Zkuste si to aspon predstavit!

Říkáte člověku, který několik let dělal v Javě :-D

Bredy, to máš tedy dost špatně vychované objekty, když začínají najednou samy od sebe vyvíjet záškodnickou činnost :-D

A teď vážně: Řešíš jako strašný problém něco, co v reálu problém vůbec není, nebo alespoň u 99.99% aplikací ne.

Z principu OOP - objekt je černá krabička, která může dělat leccos. Je třeba se na ni divat jako na zařízení, které se zapíná (konstruuje) a když už ho nepotřebuju, tak se vypne (destruuje). Zanechávat zapnutá zařízení na skládce fakt není dobrý nápad.

U 99% javovských aplikací, protože stejně argumentuju, že javovské aplikace se speciálně navrhují aby vyhověli Javě.

No, i když přistoupím na tu "černou krabičku", tak ta buď má tlačítko "vypni" a pak ho musím stisknout, když už objekt nepotřebuji. Nebo ho nemá a pak se nemusím o vypínání starat a komplikovat si architekturu ještě nějakým "modelem zodpovědnosti". V praxi drtivá většina objektů takové tlačítko nepotřebuje a nemá.

Zaplať pánbůh, že má tlačítko "zapni" :-)

No, taky ne vždycky - viz design pattern "Factory" :-)

Chápu. Ono, říkat vám pak, že na vlákno je často potřeba se dívat jako na objekt je tedy asi mrhání energií. Že to není kvůli neexistenci GC v jiných jazycích, ale prostě proto, že chci se na vlákno dívat jako na objekt, protože to spoustu věcí řeší samo...

Potvrzuje se moje doměnka, že v Javě programují ti, co OOP moc nepochopili.

"To v C++ je to vhodne kvuli uvolneni"

NE! je to vhodné kvůli oběktovému přístupu

"V jave je to sice fakticky objekt, ale kdyz se k tomu tak budete stavet, mate problem s GC"

Samozřejmě. Nemohu uplatňovat OOP přístup na vlákna v Jave, protože GC. A není to jen u vláken.

" Uvolnete se, predstavte si ze uvolneni zdroje a dealokace objektu neni to same a GC se vam odmeni. "

Nenohu. Klasické programování (takové, kde zdroje musím uvolňovat ručně) jsem zapoměl.

Tak hlavně nezapomeňte při ručním uvolňování odchytit všechny výjimky (např.), a na všech potencionálních místech :-D