🚀 go-pugleaf

Kalafiorczyk wrote:

> Andrzej Lewandowski wrote:
> > Niestety, wada w zasadzie wszystkich jezykow
> > z odsmiecaczami jest ze ich dzialanie jest przypadkowe i nie mozna ich
> > powstrzymac od tej zboznej dzialalnosci wtedy gdy to jest naprawde
> > niepotrzebne. To jest wlasnie jedna z przyczyn dla ktorych Java nie
> > bardzo sie nadaje do real-time.
>
> Ja bardzo lubie czytac historyjki Doktora Lewandowskiego.
> Ale znowu zmuszony jestem Go porawic. Od wielu lat znane sa metody
> pozwalajace na odsmiecanie bez zatrzymywania dzialania programu.
>
> http://www.harlequin.com/mm/reference/
>

Zgoda. Np. reference count. Ale ta metoda ma inne wady.
W warunkach polowych (tj. w komercyjnych systemach)
nie wszystkie metody znajduja zastosowanie, poniewaz wystepuje
tu sprzecznosc pomiedzy poziomem abstrakcji jezyka a
efektywnoscia. Dla jezykow o niskim poziomie abstakcji ale efektywnych
(do ktorych zaliczam Java i C++) pewne metody (np. p. Dijkstry) sie
nie nadaja. Nadaja sie natomiast dla jezykow takich jak Lisp lub Scheme,
ale kogo z kregow komercyjnych one obchodza?

W zrobionym przeze mnie systemie programowania Loqis (bardzo duzy
poziom abstrakcji) przetrenowalem pare metod garbage collection.
Okazalo sie, ze popularne poglady, ktore mowia, ze zbieranie smieci
powinno byc 'leniwe", tj. oddelegowane do specjalnego kawalka programu,
ktory robi to od czasu do czasu (co jak slusznie wskazuje p. Lewandowski
powoduje zawieszenia dzailalnosci aplikacji) nie maja zadnej przewagi nad
metodami "wczesnymi" (eager), ktore robia porzadek ze smieciem natychmiast
po tym, jak on powstal. Jezeli znajde kiedys troche czasu (co okazuje sie
ostatnio coraz mniej prawdopodobne), to moje eksperymenty z odsmiecaczem
opisze w jakiejs ksiazce.

Pozdrowienia
Kazimierz Subieta