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.

Search the boards