Posted By: medved (A~z na v~eky Mikov~ce.) on 'CZprogram' Title: Re: garbage collector Date: Fri Nov 5 14:41:55 2004 > > > > OK, mas pravdu, pokud by GC byla optimalizovana timto zpusobem, pak by > mohlo > > vzniknout pravidlo "zdroje v destruktoru uvolnovat muzete, ale pouze pokud > > jste si jisti, ze vas objekt nemuze zustat vzajemne referencovany s jinym > > nepouzivanym objektem, nebot pak je treba cekat na GC, ktery nemusi prijit > > nikdy". > > Proc? Priznam se, ze neznam presne detaily fungovani GC, nicmene ma > predstava > je, ze v okamziku zavolani destruktoru neni reference ani z jinych > nepouzivanych objektu. Tzn. v pripade puvodni cross-reference se nejdrive > nastavi pointer z druheho objektu na prvni na NULL a pote se teprve zavola > destruktor (ci jakkoli to nazveme) prvniho objektu. V opacnem pripade by > byly destruktory skutecne nepouzitelne ;) Problem lezi v tom, ze GC hleda nepouzivane objekty sekvencne (resp. sekvencne projizdi pamet). Takze pokud mas v pameti 100 objektu provazanych zpetne (100. ma odkaz na 99. az 2. odkazuje na 1.), tak GC pri prvnim behu bere 99 prvnich objektu jako platnych a teprve ten 100. neni referencovan a muze byt zrusen. V druhem prubehu zrusi 99. objekt a tak dale az teprve pri 100. spusteni GC dojde k zahozeni prvniho objektu. Takze jeho instance muze smrdet v pameti velmi dlouho = velmi dlouho budou blokovany zdroje zahazovane v destruktoru. (toto je priklad velmi tupeho GC, ale ukazuje, co se muze stat) > ... pochopitelne v popsanem pripade s onou nekonsistenci musi onen > destruktor > nejakym zpusobem pocitat (ze mu nekdo za jeho zady prenastavi pointer > apod.). > > Krysa Bye Medved No matter where you go, everyone is connected.