On May 24, 5:28 am, "Borneq" <b...@a...hidden.pl> wrote:
> Użytkownik "M.M. " <m...@N...gazeta.pl> napisał w
wiadomościnews:jpk0rc$922$1@inews.gazeta.pl...
>
> >> A co się dzieje gdy jest Garbage Collector i zwalniane są w
> >> inny sposób?
> > Nie rozumiem czego się obawiasz. Gdy jest zero to są
> > zwalniane, a sposób w jaki są zwalnianie nie ma znaczenia.
>
> Czy w językach z GC można zwalniać przez delete? Czy też raczej nie stosuje
> się tego, bo po delete zostaną wiszące referencje, a zwolnienie obiektu z
> interfejsem przez licznik tego nie powoduje.

Interfejsy COM, o które, jak rozumiem, ci chodzi, nie są związane z
żadnym językiem. One są protokołem do komunikacji między komponentami
(oddzielnymi programami lub programem i biblioteką DLL) i nie powinny
w żadnym wypadku być stosowane do komunikacji wewnątrz danego
komponentu.

Założenia podziału na komponenty są takie, że każdy komponent może być
zaimplementowany w innym języku, i każdy sam zarządza swoją pamięcią.
Liczniki referencji służa tylko do określenia, czy dany obiekt jest
używany jeszcze poza danym komponentem, czy możesz go usunąć.

> Jednak co gdy mamy GC
> przenoszący dane do ciąglego obszaru przy zwalnianiu aby  maksymalnie
> przyśpieszyc alokację? Czy tylko takie zwalnianie bez GC to zmiana flagi na
> "zwolnione" ale bez odzyskania pamieci?

Interfejsy COM jako takie nie mogą być relokowane, bo są
identyfikowane przez wskaźnik. Ale w związku z tym tak czy inaczej
serwer COM musi być implementowany w języku dającym dostęp do takich
niskopoziomowych konceptów. Normalnie jak sądzę jest tak, że tworząc
serwer COM w języku wysokopoziomowym będziesz korzystał ze wsparcia
zaimplementowanego w języku odpowiednio niskopoziomowym,
prawdopodobnie w C++ - i albo takie wsparcie masz wbudowane, albo
będziesz je sam musiał sobie dopisać. Polegałoby to w skrócie na tym,
że masz jakąś ręcznie zarządzaną stertę czy inną kolekcję z obiektami
proxy, które z jednej strony mają stały adres i zawierają wskaźnik na
tablicę funkcji wirtualnych implementujących dany interfejs COM, a z
drugiej strony zawierają 'sprytną referencję' do obiektu w docelowym
języku, rejestrowaną w runtime tak, żeby garbage collector ją widział
- w tej sposób każdy obiekt, dla którego istnieje interfejs COM jest
'live' niezależnie od tego, czy są na niego jakieś inne referencje. W
momencie, kiedy licznik referencji na obiekcie proxy osiągnie 0, jest
on usuwany z kolekcji interfejsów i referencja na niego zostaje
usunięta. O ile nie ma żadnych innych referencji, referowany obiekt
zostanie usunięty w następnym cyklu odśmiecania.

> > Aby było skuteczne, Release i dekrementacja licznika musi zachodzić
> > rekurencyjnie. W tym przypadku Release musi być wywołana dla każdego
> > pola wskazującego na inne obiekty.
>
> A co gdy powstają cykle? Klasa C dziedzicząca interfejs ma pole klasy C. A
> obiekt p0 wskazuje na p1 a p1 na p0.

Liczenie referencji jako ogólna metoda jest podatna na cykle. W
przypadku COM problem nie jest tak bardzo poważny o tyle, że
komponenty komunikują się w architekturzy klient-serwer, gdzie serwer
tylko wystawia interfejsy a klient tylko z nich korzysta. Teoretycznie
możliwe jest powstanie cykli, jeśli występują cykle na poziomie
komponentów (komponent A jest klientem komponentu B, B jest klientem
komponentu C, C jest klientem A), ale to już jest problem na poziomie
architektury systemu: generalnie takich projektów powinno się unikać,
a w ekstremalnych sytuacjach, kiedy się już absolutnie nie da tego
uniknąć, trzeba zadbać, żeby nie występowały cykliczne zależności
blokujące zwolnienie zasobów.

> Chciałem się jeszcze dopytać o kolektory przenoszące Mark & compact. Wtedy
> alokacja jest łyskawiczna, jedynie przesunięcie wskaźnika i można sobie
> darować obiektu bez alokacji na stosie. Ale co ze zwalnianiem, takie
> kopiowanie moze znacznie spowolnić.

Może, i długie cykle odśmiecania są realnym problemem. Ale po pierwsze
rozwiązuje się to w ten sposób, że skopiowanie obiektu można wykonać
przez zwykłe skopiowanie obszaru pamięci, a po drugie założenie
wydajnościowe kolektorów kompaktujących/przenoszących jest takie, że w
momencie odśmiecania większość obiektów na danej stercie to śmieci - a
kosztuje tylko przeniesienie żywych obiektów.

> I jak to jest robione, dla dużych
> obiektów opłacało by się mieć tablicę wskaźników pośrednich, która była by
> zmieniana (pozostają problemy gdy taka tablica rośnie, Realloc - tu już nie
> można jedynie przesuwać wskaźnika) A co z mniejszymi? Wypadałoby że tak
> samo, bo jak inaczej? Trzeba by modyfikowac wszystkie pola gdzie sa
> wskaźniki wstecznie a wskaźnik jest jednokierunkowy.

Można tworzyć dodatkowe tymczasowe struktury/pola, istniejące tylkow
cyklu odśmiecania, które pamiętają co i gdzie było przenoszone. W
praktyce można to zrobić przez odpowiednią konstrukcję sterty.
Dodatkowo pomocne jest rozwiązanie, gdzie przenoszenie następuje tylko
między rozłącznymi obszarami: ze sterty A przenosisz do sterty B, więc
patrząc na wskaźnik od razu możesz stwierdzić, na którą stertę
wskazuje. Jeśli wskazuje na 'nową' to nic dalej nie trzeba robić.
Jeśli wskazuje na 'starą', to używając owych struktur można sprawdzić,
czy obiekt już został przeniesiony ze starej na nową i ewentualnie
jaki jest jego adres na nowej stercie.

W praktyce współczesne systemy z odśmiecaniem, w których istotna jest
wysoka wydajność, stosują odśmiecanie pokoleniowe z różnymi
strategiami dla kolejnych pokoleń.