Alokacja pamięci. Cel
Języki programowania pozostają w napięciu pomiędzy łatwością użycia (przez programistę) a sprawnością gotowego kodu.
Zacząłem się kiedyś zastanawiać, czy nie da się inaczej podejść do zagadnienia alokacji pamięci. Znaleźć trzecią drogę.
Trzecia droga miałaby polegać na tym, żeby nie alokować pamięci automatycznie (co się wiąże z użyciem garbage collectora), ale też nie zmuszać programisty do zarządzania tymi sprawami (precz z malloc i z new!).
Czy kompilator nie mógłby na drodze precyzyjnej statycznej analizy kodu całkowicie skutecznie rozplanować użycia pamięci we właściwy sposób? Program wiedziałby gdzie i kiedy co zapisywać, a gdy niepotrzebne, po prostu zostawić, porzucić, a pamięć wykorzystać…
Zacząłem eksperymentować i myśleć. Najpierw powstał język poziomu wyższego niż C, coś podobnego do ML. Badałem możliwości analizy. Na początku nie powstawała żadna implementacja, potrzebna była teoria. Zapisałem wiele papieru - dosłownie parę zeszytów (piórem, fizycznie!).
Jak ograniczyć Mediolan, żeby zaprowadził nas do celu
Język, który jest nośnikiem moich eksperymentów ma różne formy, ale jedną nazwę - Mediolan. Z biegiem czasu okazało się, że trzeba go przykroić. Zamiast algebraicznych typów danych rozpatruję dane proste - jak w Lispie. Mam więc “wielką trójkę”: car, cdr, cons. Z tego buduję cały świat, ścieżki alokacji, warunki użycia, Data Flow Analysis, zbieżność analizy, w końcu - to, co z tego wychodzi - alokację regionami.
Wszystkie dane są niemutowalne, nie ma też domknięć, ani typów polimorficznych. Dlatego też da się sprowadzić program do jednego bloku inline, a potem rozplanować wszystko od początku do końca.
Podobną ścieżką podążają autorzy kompilatora MLTon. Podobieństwo podejść jest duże, niemniej u mnie narracja rozwija się w inną stronę. Ostatecznie mam zamiar znaleźć sposoby na znaczące usprawnienie mechanizmów alokacji.
O tym wszystkim chcę pisać - po kolei, zaczynając od ogółu, przechodząc po kolei do szczegółów. Na początek w kolejnym odcinku spróbuję pokazać argumenty za celowością opisywanych działań!
Kogo zapraszam
Na pewno nie są to tematy interesujące wszystkich. Przyznaję, że nie jestem naukowcem, tylko zwykłym programistą, który lubi drążyć istotne tematy. Pytanie o idealny kompilator - jest jedną ze spraw które zaprzątają umysły. Każdy, kto próbuje zaimplementować interpreter, czy transpiler, w końcu myśli na ten temat. Jest on wielkim marzeniem, dalekosiężnym (a nie - nieosiągalnym) celem.
Przeczuwam, że każdy programista może skorzystać z tych pomysłów i ustaleń, niezależnie od tego, na ile kompletne będą moje opisy.
W kolejnej części opiszę jeszcze raz dokładniej, co jest celem moich pomysłów.