Koji bi bili specifični razlozi za isključivanje GC-a?

Nije mi jasan deo "uklanjanje objekata po referenci BEZ collect-a"? To i _jeste_ collect.

Ako se ukloni GC onda filozifija .NET-a pada u vodu, zar ne?!

GC se ne može ukloniti.

Može se smanjiti verovatnoća pojavljivanja tako što se forsira GC:



može se markirati object kao non-collectable:



ili se mogu koristiti value tipovi (struct, int, double i slični) koji se smeštaju na stek a ne na heap, pa do GC neće ni doći.

GC nije .Net filozofija, to je samo memory management (kao što GC nije filozofija jave)

GC je nesto sto na sta se prije moralo misliti, a sad ne, koliko sam ja skontao. Iako nisam programirao u C-u prije (klasicnom ANSI Cu) citao sam da su tamo programeri morali misliti na ponistavanje objekata i oslobadjanje istih iz memorije. GC cini to za tebe, tj ne trebas ti misliti da li ti je objekat jos potreban ili ne i da li ga trebas ponistiti.

Ne bi trebao raditi ovo. Svaki collect radi promotion zivih objekata u sledecu generaciju i posle dva uzastopna collect-a skoro svi objekti koje budes imao ce biti "zakljucani" u drugoj generaciji. GC nece pokusavati collect druge generacije dok god uspe da oslobodi dovoljno memorije kroz nultu i prvu, sto ce rezultovati vecim memory footprintom aplikacije, bez potrebe. U praksi, na kompjuteru sa prosecno memorije druga generacija se nece ocistiti sve do izlaska iz aplikacije.

Sta znaci 'drugu generaciju' objekata?

http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/default.aspx

A ne bi bilo loše da pročitaš i prvi deo članka: http://msdn.microsoft.com/msdnmag/issues/1100/gci/

Ok, da konacno odgovorim i tebi.

Kao prvo, .NET tj GC ne koristi brojanje referenci. To je radio COM, i cak i kad publikujes .NET objekte kroz COM brojanje referenci obavlja proxy klasa u CCW (COM callable wrapper), ne same klase niti GC. Vise detalja o tome kako GC radi svoj posao mozes procitati na ova dva linka sto je DragiTata okacio.

GC, koliko ja znam, se ne moze ugasiti, niti vidim bilo kakvu primenu toga. Kad GC ne bi radio posao, memorija bi se na kraju napunila i na kraju bi zavrsio sa EOutOfMemoryException na nekoj new komandi. Shvatam da je vecini GC neka fantomska crna kutija koju bi najradije ugasili (narocito C+ programeri ), ali za tim stvarno nema potrebe, GC savrseno dobro obavlja svoj posao za potrebe .NETa.

Koliko vidim, svoj posao ću lakše obaviti na jeziku C++.

Nevezano za C# i .NET, postoje dva glavna algoritma za automatsko oslobađanje memorije.

Prvi je brojanje referenci. To ne mora da funkcioniše baš uvek. Naime, može objekat A da pokazuje na objekat B, a objekat B da pokazuje na objekat A, i da nijedan drugi objekat ne pokazuje ni na A, ni na B. Tada čistač đubreta zasnovan na brojanju referenci to neće znati da očisti iz memorije. Međutim, ako graf pokazivanja u memoriji nema ciklusa, onda ovaj algotitam savršeno funkcioniše.

Drugi algoritam se s vremena na vreme uključi i napravi graf pokazivanja na objekte polazeći od lokalnih proenljivih, i pritom beleži adrese obkekata koje je posetio. Zatim, obrišeb sve objekte koji nisu na zapamćenim adresama, a onda obriše i spisak adresa i pusti proces da radi dalje. To je vrlo skupa operacija i obavlja se kad se GC-u "ćefne". Taj indeterminizam isključuje takve programske jezike iz nekih oblasti, kao što su multimedija, video igre i druge vrste programiranja u realnom vremenu.

Krasna tema za "Art of Programming" forum ;)



Eh, savršeno. Taj sistem može da ispadne još sporiji nego nedeterministički GC, posebno u višenitnom okruženju, jer svaka promena vrednosti i provera brojača referenci mora da ude zaključana.



Ima tu i gorih posledica :) Recimo, mnogo programera smatra da GC brine ne samo o memoriji, već i o svim drugim resursima, pa nastanu vesele situacije zbog toga. Recimo, procenat .NET programera koji stvarno razume Dispose pattern je zastrašujuće mali.


Lično, ja najviše volim "treći" sistem automatskog oslobađanja memorije, a to je stack :) Doduše, nije primenljiv u svim okolnostima, ali tamo gde jeste radi savršeno, ne samo za memoriju već i za sve druge resurse.

Hvala, i ja preferiram taj treći algoritam (stog), ali šta u situacijama u kojima on nije primenljiv?

Možda je brojanje referenci globalno sporije, ali ti se neće desiti da program soji po par sekundi.

Hehehe, pazi da ti mmix ne obriše poruku zbog ovog "stog".



Generalno uzev, tako je. Da dodam samo da hardcore real-time programeri ne koriste ni jedno ni drugo, jer nikad ne rezervišu memoriju sa heapa (htedoh reći gomile :) ). malloc i slične funkcije traju nepredvidivo dugo, a za njih to nije prihvatljivo.

Hehe, necu ne brini, digao sam ruke od toga. Moj stav o balkanizaciji strucnih termina je vise nego poznat, ali ako nekome stog znaci nesto konkretno, super, ko sam ja da tvrdim suprotno, sebi pucate u nogu, ne meni . Ja koliko se secam svojih korena, stog je sipka na koju se nabacuje seno, a zasto je to nekome bilo asocijacija na stek, nemam pojma. Stek je FILO struktura, stog nije (ako se ne varam, seljaci ne skidaju seno sa vrha stoga nego sa strane). Elem, ovo su bila samo moja dva centa, nije poziv na jezicku raspravu, stog se prihvata



Upravo sad to htedoh reci, takve stvari se nikad nemogu znati unapred, i sve (bolje) igrice imaju svoju internu memorijsku strukturu i interni memory managment sa sopstvenim heap-om koji se jednom alocira na pocetku igrice/nivoa/poglavlja i lokuje u fizicku memoriju.
Od kad je izasao .NET video sam samo jednu .NET igricu (neka bolidna simulacija vozova), i performanse su bile katastrofalne. Sta god reko MS, C#+DirectX.NET nije alternativa dobro napisanom C++DirectX codu. Tako da preostaje samo jedan savet, C++ u ruke .NET je za korisnicke programe gde povremene pauzice ne predstavljaju nikakav problem i gde nije vazno postici toliko i toliko frejmova u sekundi. Za te potrebe GC je savrsen.

Za vise detalja o tome zasto je .NET memory mgmt dat GC-u, pogledaj ova tekst iz ranih dana .NETa Nesto je zastarelo ali vredi procitati.

http://discuss.develop.com/arc...010A&L=DOTNET&P=R28572

Sećam se tog teksta. Interesantno je da su u međuvremenu pronašli način kako da pomire determinističku finalizaciju i nedeterministički GC, ali je to za sada primenjeno samo u C++/CLI: http://www.codeproject.com/managedcpp/cppclidtors.asp

A zar stack na engleskom ne znači stog? Inače, znam da ozboljne igrice koriste jednom alociranu memoriju za statičke stogove, redove itd. Svejedno, ne sumnjam da će osvanuti dan kada će C#+DirectX.NET biti pristojna platforma za razvoj igara.

Postoji i deterministicka finalizacija i u C#:

http://www.samspublishing.com/...s/article.asp?p=24446&rl=1

Spomenuta je i u prije navedenom clanku:

Ako misliš na using statement, postoji i u VB 2005 http://www.novetehnologije.com/Default.aspx?tabid=84 ali je takva implementacija vrlo problematična, jer je teret na korisniku klase, a i uvođenje novog opsega nema baš mnogo smisla. To je mnogo bolje rešeno u C++/CLI.

Koliko sam uspeo da pohvatam GC i njegov rad, trik deterministicke
finalizacije je da se svi objekti oslobode bez upotrebe destruktora.
Koliko sam shvatio ukoliko objekat poseduje destruktor onda
se objekat stavlja u neku vrstu reda. GC prvo poziva desturktor, pa posle nekog
nedefinisanog vremena brise sam objekat. A ukoliko nema destruktora onda odmah brise
objekat.

Sa kljucnom reci using kao sto si naveo u primeru na sajtu, objekat postoji
samo u tom segmentu koda i odmah se oslobadja, bez potrebe za destruktorom.

Ovde imamo problem sa terminologijom, a za to krivim činjenicu da C# sintaksa za finalizer izgleda isto kao C++ sintaksa za destruktor, mada su u pitanju dve različite stvari.

Kad u C++/CLI napišeš destruktor, kompajler generiše ceo "Dispose" pattern - i Dispose i Finalize. U C#-u, kad napišeš "destruktor", kompajler generiše samo Finalize metod, a Dispose moraš da napraviš ručno.

Inače, sve to što si napisao je potpuno tačno ako zameniš "destruktor" sa "finalizer".