Witam,
Ostatnio zainteresowała mnie tematyka garbage collectorów i po poczytaniu na temat ich działania postanowiłem napisać swój mały edukacyjny GC dla C++. Czy ktoś zna jakieś książki/strony/materiały, które mogę mi pomóc w tym zadaniu? Szczególnie szukam czegoś na temat GC współbieżnych.
0
0
Edukacyjnie możesz pisać, ale nie spodziewaj się, że efekt będzie porównywalny z GC Javy czy C#.
Dla C++ takowego nie da się napisać, bo ani kompilatory ani platforma wykonawcza nie dają odpowiedniego wsparcia.
Zliczanie referencji ssie natomiast ine wydajne techniki wykorzystujące wiele generacji czy defragmentację sterty są w ogóle niemożliwe.
0
Krolik napisał(a)
Dla C++ takowego nie da się napisać, bo ani kompilatory ani platforma wykonawcza nie dają odpowiedniego wsparcia.
bzdura.. jesli w Javie czy w .Net sie udalo, to i w C++ jest to mozliwe i proste do udowodnienia: obie maszyny wirtualne sa napisane w C++, wiec dalo sie w nim napisac GC ktory jest w stanie pewne struktury efektywnie sledzic i kontrolowac... po napisaniu podobnego w swojej aplikacji, wystarczy go zastosowac do odpowiednich segmentow wzglednie prosto -- jesli zamiast wskaznika type* bedzie sie uzywalo jakiegos-tam-specjalnego uchwytu kompatybilnego z wskaznikiem, dajmy na to tracker<type> to .. juz sprawa zalatwiona.
faktyczny problem, ktory jest przytaczany dla udowodnienia ze GC w C++ to mrzonka, brzmi:
"trzebaby wymusic na programistach aby uzywali odpowiednich typow danych (patrz tracker<t>), oraz sprawic zeby moduly wspolpracujace, dllki 3rdparty - zwlaszcza te nie uzywajace go (itp) - nie kolidowaly z wlasciwa aplikacja"
oba sa dosc, hem, ciezkie. ale zważ, że i Java i .Net nie rozwiazaly tych problemow, tylko obeszly
- Java problem pierwszy rozwiazala wymuszajac uzywanie tylko referencji, drugi zas - odcinajac sie w 100% od native, a ew. problemy z niezwalniania zasobow pozostalych (bo ktos wewnatrz nativecode zapomnial czegos zwolnic) po nativeinvocation olewajac
- .Net pozwala uzywac takich i takich typow referencji (normalne zmienne sa ref ala java, ale istnieja tez unsafe pointers!), ale rowniez olewaja problemy z niezwalniania zasobow z pozostalych po wyjsciu z unmanagedcode/niezwolnieniu unsafe pointers :)
i wracajac do C++ --- wymuszajac na programistach uzywanie specjalnych typow danych, jestes w stanie osiagnac dokladnie to co w Javie czy .Net. wszelkie teorie twierdzace ze 'ale co z 3rd party, a co z durnym koderem, a co jak jakis memory hog sie trafi' sa do rozbicia o kant stolu - to nie nasz problem, to beda problemy wyraznie akceptowalne, sa to problemy nieprawidlowego uzycia native, unmanagedcode, a nie z 'naszego dobrego poprawnego GC i jego tracker<t>' :)
0
quetzalcoatl, powiedz mi zatem, jak zaimplementować w C++ GC oparte na mark & sweep, Generational GC, czy GC defragmentujące pamięć - chociaż szkic przedstaw.
0
quetzalcoatl napisał(a)
Krolik napisał(a)
Dla C++ takowego nie da się napisać, bo ani kompilatory ani platforma wykonawcza nie dają odpowiedniego wsparcia.
bzdura.. jesli w Javie czy w .Net sie udalo, to i w C++ jest to mozliwe i proste do udowodnienia: obie maszyny wirtualne sa napisane w C++, wiec dalo sie w nim napisac GC ktory jest w stanie pewne struktury efektywnie sledzic i kontrolowac... po napisaniu podobnego w swojej aplikacji, wystarczy go zastosowac do odpowiednich segmentow wzglednie prosto -- jesli zamiast wskaznika type* bedzie sie uzywalo jakiegos-tam-specjalnego uchwytu kompatybilnego z wskaznikiem, dajmy na to tracker<type> to .. juz sprawa zalatwiona.
faktyczny problem, ktory jest przytaczany dla udowodnienia ze GC w C++ to mrzonka, brzmi:
"trzebaby wymusic na programistach aby uzywali odpowiednich typow danych (patrz tracker<t>), oraz sprawic zeby moduly wspolpracujace, dllki 3rdparty - zwlaszcza te nie uzywajace go (itp) - nie kolidowaly z wlasciwa aplikacja"oba sa dosc, hem, ciezkie. ale zważ, że i Java i .Net nie rozwiazaly tych problemow, tylko obeszly
- Java problem pierwszy rozwiazala wymuszajac uzywanie tylko referencji, drugi zas - odcinajac sie w 100% od native, a ew. problemy z niezwalniania zasobow pozostalych (bo ktos wewnatrz nativecode zapomnial czegos zwolnic) po nativeinvocation olewajac
- .Net pozwala uzywac takich i takich typow referencji (normalne zmienne sa ref ala java, ale istnieja tez unsafe pointers!), ale rowniez olewaja problemy z niezwalniania zasobow z pozostalych po wyjsciu z unmanagedcode/niezwolnieniu unsafe pointers :)
i wracajac do C++ --- wymuszajac na programistach uzywanie specjalnych typow danych, jestes w stanie osiagnac dokladnie to co w Javie czy .Net. wszelkie teorie twierdzace ze 'ale co z 3rd party, a co z durnym koderem, a co jak jakis memory hog sie trafi' sa do rozbicia o kant stolu - to nie nasz problem, to beda problemy wyraznie akceptowalne, sa to problemy nieprawidlowego uzycia native, unmanagedcode, a nie z 'naszego dobrego poprawnego GC i jego tracker<t>' :)
Przeczytaj ten pdf który dałem u góry?
Przeczytaj post królika?
Jedyne możliwe GC to albo liczenie referencji - swoje typy itd, tak jak Ty to powiedziałeś - czyli najgorszy możliwy (jednocześnie najprostszy w implementacji) - najwolniejszy, zajmuje najwięcej pamięci i ma ogromny problem z cyklami.
Ma on sens tylko w bardzo ograniczonych zastosowaniach, do automatycznego odśmiecania wewnątrz jakiejś większej struktury w programie - nie do całego programu.
Drugi to gc 'całkowicie konserwatywny' - zatrzymujesz w pewnym momencie program, przechodzisz CAŁĄ pamięć bajt po bajcie (ew. tylko te obszary które były zmodyfikowane, per strona), traktująć KAŻDY dword jako możliwy adres - jeśli okazuje się on poprawny, jest on liczony jako referencja do danego obszaru.
Następnie następuje sprawdzanie rejestrów wg. tej samej zasady.
O ogromnym narzucie i 'rozrzutności' takiego GC mówić chyba nie trzeba?... W ten sposób działa afair taki boehm's gc, do którego pewnie zaraz dasz link...
I to są +jedyne+ możliwości.
GC bez wsparcia języka nie ma właściwie racji bytu.
0
1' moze to nie bylo widoczne w moim "bzdura" na starcie: moja wypowiedz tyczy sie DRUGIEGO zdania, tego zacytowanego. nie neguje anty-wydajnosci, negowalem "niemozliwosc napisania GC w jezyku X"
2' szkic: pisze w C++ swoja maszyne wirtualna Javy z GC. zakladam ze udalo mi sie - w takim razie mam jakis wewnetrzny typ danych sluzacy do utrzymywania referencji-na-sledzony-obiekt. nazwijmy go X. od teraz rozbudowuje swoj program uzywajac jedynie tego typu danych, tak efektywnie zamieniajac wszystkie typy jakich bym uzywal (nawet int, int* etc) na typ X z informacja ze trzyma obiekt typu takiego-a-takiego. albo ujmujac inaczej: zamiast mojej maszynie javy dawac zestaw plikow .class i pozwalac jej na automatycznie utworzenie ich wewnetrzny obrazow, "po prostu" od razu odpowiednimi konstrukcjami w dodatkowych plikach zrodlowych .cpp maszyny konstruuje ten obrazy "z palca".
tak to jest bez sensu, maksymalnie nieefektywne i podane na bledy
ale: przyjmujac zalozenia ze mamy programistow ktorzy trzymaja sie zasad oraz ze bledy wywolan spoza naszego systemu GC nas nie obchodza, bedzie to dzialac i bedzie taki GC napisany
taki byl zamierzony sens mojego postu powyzej. nie mam zamiaru udowadniac ze da sie napisac przystawke do kompilatora C++ ktora wezmie typowy normlany kod C++ i sprawi ze nagle wsyzsktie wskazniki same sie beda sledzic i inteligentnie zwalniac, ze magicznie wartosci w rejestrach procesora tez beda sledzone, ze da sie przesuwac obiekty w pamieci czy nawet defragmentowac pamiec fizyczna - bo jest oczywiste (prz. dla mnie) ze nie jest to mozliwe. nie da sie zautomatyzowac, ani z-pol-automatyzowac tego procesu dla C++ przy obecnych kompilatorach. kropka. zgadzam sie ze wszsytkimi ktorzy tak twierdza.
mowie ze: jesli napisac z palca mechanizmy zawarte w Javie/.Net ORAZ dostarczyc odpowiednie nakladki ORAZ trzymac sie ich i tylko ich bezwzgledne, to da sie uzyskac taki efekt. a ze koszt takiego podejscia jest niewspolmierny, to chyba tez oczywiste, bo ilosc kodu jaka trzebaby bylo wytworzyc dla wykonania najprostszych zadan byla by ogromna => ilosc przypadkowych bledow implementacji natychmiast by to rozwalila. dlatego powstala idea jako platform ktore to robia za nas i beda gwarantowac utworzenie logicznych odpowiednikow tego calego badziewia ktore by trzeba bylo klepac (.....i tak dalej. mam nadizeje ze moja intencja jest juz jasna)
0
quetzalcoatl napisał(a)
jesli napisac z palca mechanizmy zawarte w Javie/.Net ORAZ dostarczyc odpowiednie nakladki ORAZ trzymac sie ich i tylko ich bezwzgledne, to da sie uzyskac taki efekt.
...i tak powstanie kolejny Lisp.
0
quetzalcoatl napisał(a)
jesli napisac z palca mechanizmy zawarte w Javie/.Net ORAZ dostarczyc odpowiednie nakladki ORAZ trzymac sie ich i tylko ich bezwzgledne, to da sie uzyskac taki efekt.
Tiaa, tylko patrząc na to realistycznie, chyba to trochę nierealistyczne jest?