🚀 go-pugleaf

>> 2. Operacje na wskaźnikach są kosztowne (wymaga operacji atomowych).
>
> I tu -- niespodzianka -- nie wymagają. Sam się zdziwiłem, gdy
> wpadłem na pomysł rozwiązania, ale ono było złudnie proste.
> Zaimplementowałem pierwotny pomysł w 2 dni, a potem... przez
> 7 debugowałem, zanim zrozumiałem, że to nie w kodzie jest
> problem i poprawiłem algorytm. Przedstawiłem tu kiedyś szkic
> pomysłu. Ale on jest błędny (choć wtedy jeszcze tego nie
> wiedziałem); ot, super rzecz dla szpiegów przemysłowych
> -- coś, co wygląda na poprawne, ale wybuchnie w rękach... :-)
>
> Dlatego ostatnimi czasy wróciłem do rozwiązań ze zliczaniem
> referencji (intruzywnym), po tuningu są niewiele wolniejsze niż
> zwykły wskaźnik.

Operacje atomowe na liczniku nie sa wymagane tylko w przypadku, gdy ma sie 
pewność, że manipulacja wskaźnikiem odbywa się w jednym wątku aplikacji.

>> 3. Zwalnianie większych struktur, może doprowadzić do przepełnienia ramki 
>> stosu.
>
> To się da rozwiązać, choć nie zawsze jest to konieczne. Naiwna
> implementacja mark&sweep cierpi na dokładnie ten sam problem.

Zawsze można to jakoś rozwiązać. Można się jednak nieźle ździwić, gdy niby 
prawidłowy fragment kodu wysypuje nam aplikację.

>> 4.  Zwalnianie większych struktur, może na dłuższy okres wstrzymać 
>> działanie aplikacji (wymaga operacji atomowych).
>
> Ja deterministyczny punkt destrukcji uznaję za zaletę.

Trudno uznać za zaletę stuację w której aplikacja zatrzymuje się na dwie 
sekundy tylko po to, aby zwolnić zajmowana przez siebie pamięć.

>> Prawde powiedziawszy, na chwilę obecną, nie spotkałem jeszcze takiej 
>> implementacji systemu GC w jakimkolwiek języku czy środowisku.
>
> Pogratulować. :-)

Dzięki, choć niestety rozwiązanie nie jest pozbawione wad.

Pozdrawiam.

- Bastek -