Vlákno názorů k článku Monitorování procesů a správa paměti v JDK 6 a JDK 7 (4) od Vít Šesták (v6ak) - Minule jsme zde nakousli situaci ve vícevláknovém prostředí....

Minule jsme zde nakousli situaci ve vícevláknovém prostředí. A článek se o tom vlastně taky zmínil. Chtěl bych se zeptat, jak to tam vlastně vypadá. Každé vlákno si vytvoří svoji mladou generaci? Nebo si ukousne kousek z globální mladé generace? Jak je to s objekty sdílenými mezi vlákny?

U vice vlaken nemuze GC (bezici skryte taky ve svem vlakne, podobne jako casti GUI atd.) vlastne nic dopredu predikovat, takze heap nerozdeluje. Vlakna maji "pouze" svuj zasobnik resp. obecne sadu zasobnikovych ramcu (nemusi se jednat o kontinualni oblast pameti), ovsem zde jsou ulozeny pouze promenne primitivnich datovych typu a odkazy (reference) na objekty na halde - vse ostatni je sdilene per proces.

No dokud se ten objekt nestane přístupný jiným vláknům, tak by IMHO bylo výhodné mít oddělený heap a dokud tam není objekt s nahrazenou metodou finalize, bylo by možné po skončení vlákna tyto všechny objekty naráz odstranit. Nebo spíše ty, na které vidí jiné vlákno, zachovat (překopírovat někam jinam) a pak to celé odstranit.

Jinak k tomuto pohledu mě dovedla mj. tato část článku:
"Na tomto místě je vhodné poznamenat, že správce paměti většinou běží v samostatném vláknu a NEmusí zamykat všechny objekty, s nimiž pracuje, což znamená, že vlákno/vlákna aplikace ve skutečnosti nemusí být pozastavena na takovou dobu, jaká je uvedena ve výpisu."

Říkám si, pokud je teda ta oblast sdílená na proces, jak pak je možné některým vláknům umožnit běžet? (Smysl by dával právě ten úklid v rámci vlákna, který by neohrozil běh ostatních vláken.)

"ovsem zde jsou ulozeny pouze promenne primitivnich datovych typu a odkazy (reference) na objekty na halde"
Nevím, jak moc to je pokročilé (já JVM nevyvíjím), ale prý zde může být i celý objekt, u kterého je díky escape analysis jasné, že bude zrušen do konce běhu metody.

Ten cluster se muze za behu zvetsovat/zmensovat nebo se pri jeho zaplneni proste naalokuje dalsi cluster? Uvolneni celeho clusteru je asi reseno klasicky pocitanim objektu v nem ze (to me prijde nejjednodussi).

Ja tomu rozumim, ze v mnoha ohledech by byla moznost heap per thread zajimava a z hlediska naroku GC mozna i jednodussi.

Problem tvurci hotspotu pravdepodobne(?) videli v tom, ze v kodu muze byt neco na tento zpusob:

while (true)
{
    if (random.nextBoolean()) {
        new myThread().run();
    }
}

no trosku prehanim :-) ale jde o to, ze o poctu vlaken je rozhodnuto az v runtime a ve chvili, kdy vlakno vznikne by musel GC nejak preorganizovat heap (defragmentace atd.) aby uvolnil dostatecnou (jak moc dostatecnou - treba pro vlakno co jen obslouzi jeden HTTP dotaz a potom umre staci 10k nebo radeji 1M?) kapacitu pro young generation.

V extremnim pripade by pak na heapu bylo alokovano n prazdnych oblasti young generation pro n vlaken, takze by bud jejich kapacita byla velmi mala (caste volani GC nebo casty zapis do tenured) nebo by se zabrala cast tenured.

Urcite by to slo resit, pravdepodobne nejakou analyzou v runtime, ale prozatim nevim, ze by to nejaky GC dokazal dobre osefovat :-(

Dalo by se to třeba řešit profilováním a to IMHO i celkem úspěšně. A i kdyby to bylo potřeba při vytvoření vlákna uvést ručně, byla by to IMHO celkem levná ruční optimalizace.

Jinak mě napadá, že by vlákno mohlo dostat svou vlastní oblast celkem malou (třeba jen eden) a pak použít sdílenou paměť.

K myšlence mě asi přivedla představa serveru s krátkými požadavky. Pokud by se to dobře poladilo, stop-the-world by zde mohlo téměř zmizet (využívalo by se hlavně na sessions).

Jinak pořád jsem nepochopil, jak je v současném stavu možné udělat stop-the-world jen pro vlákno.