Vlákno názorů k článku Monitorování procesů a správa paměti v JDK 6 a JDK 7 (2) od Vít Šesták (v6ak) - Co vím, tak jeden z předpokladů, který není...
-
Co vím, tak jeden z předpokladů, který není v článku zmíněn a na kterém staví dnešní GC, je, že staré objekty zřídkakdy odkazují na mladé (obvykle to je naopak). Celkem by mě zajímalo, jak se tato vzácná situace řeší - napadlo mě, že by ten mladý objekt mohl být přesunut ke starším nebo případně naopak (a s ním mnohdy kaskádovitě i další objekty), aby tím nevznikala nekonzistence (při projítí mladších objektů nebude muset hledat ve starších, což by popíralo smysl generačního GC). Trefil jsem se, nebo je to řešeno jinak?
Druhá věc je, kdy tato situace obvykle vzniká. Představím-li si webový server, pak má obvykle objekty pro celý server (ty asi půjdou do nejstarší generace), objekty pro požadavek (asi málokdy pújdou do starší generace) a někdy i objekty pro session (ty nemusí jít do nejstarší generace, ale v nejmladší se taky asi neudrží), které budou sloužit asi spíše jako cache (např. při výpadku proudu by se mohly udržet). V tomto případě asi odkazování staršího na mladšího obvykle znamená spíše to, že ten mladší se bude chovat jako starší než naopak (když si představím takový přesun celého rozsáhlého LinkedListu do mladší generace... :-D)
Taky přemýšlím, jestli sessions nemohou být slabým (nebo aspoň nejslabším) místem ve výkonu správy paměti webového serveru.
Nakonec mě napadá, jestli existuje nějaká vláknově lokální generace, ve které se budou držet objekty, dokud na ně není odkázáni z jiného vlákna. Tato generace by mohla zvýšit výkon u jepičích vláken - pokud by nebylo toho naalokováno příliš, bylo by uklizeno vše najednou při konci vlákna.
-
To by bylo taky řešení, ale minule tu bylo zmíněno, že ve vícevláknovém prostředí je refcounting drahý. A přijde mi přirozenější to moje řešení. Ony jsou v případě, že mladší objekt ukazuje na starší, asi tři možnosti:
* Starší na něj ukazoval jen dočasně a pak si to 'rozmyslel'. Pokud na něj ukazoval jen malou chvíli, pak nevím, proč by to dělal. Pokud dlouho, pak nemusí být problém v převedení mladšího objektu do starších, protože bude žít déle.
* Starší na něj ukazuje až do konce svého života a tedy mladší bude žit minimálně tak dlouho, jako ten starší.
* Ona je tu nějaká třetí možnost? To asi teď vypadám, jako bych neuměl do *pěti* napočítat :-D -
A při přesunu do starší generace by bylo tento flag nutno znovu prověřovat a při teoretickém dřívějším úmrtí jednoho ze starších objektů taky. A hlavně by to dočasně znamenalo častější prohledávání všech starších generací.
Lze to vylepšit zavedením flagu pro každou generaci zvlášť, ale pořád tu hlavní problémy zůstávají. A celkově mi přijde to moje řešení elegantnější - IMHO by ten objekt v té starší generaci stejně časem skončil.
-
Ales Hakl (neregistrovaný)
Konkretne Sun JVM prilis neznam, ovsem:
Reference ze starsich do mladsich generaci se obvykle resi konstrukci jmenem "remembered set", coz je seznam do ktereho zapisova bariera ve starsi generaci zapisuje odkazovane objekty z dane mladsi generace, tato struktura se pak pri tech rychlejsich kolekcich pouziva jako dalsi koren.
Ohledne tech vlaken: pomerne caste reseni je, ze nejmladsi generace je opravdu nejakym zpusobem "lokalni" pro vlakno. Motivaci ovsem obvykle neni zrychlit GC, ale zrychlit alokaci pameti jako takovou (tj. odstranit nutnost synchronizace pri alokaci).
