ExecSG w szczegółach: pamięć - autor Thomas Frieden
Ostatni artykuł poruszał temat nowego systemu bibliotek w AmigaOS4.
Chciałbym skorzystać z okazji i przedstawić kolejny element: system pamięci.
System pamięci klasycznego Execa.
System Amigi jest systemem 32-bitowym. Oznacza to, że posiada 32-bitowe
adresy, co z kolei daje możliwość dostępu do 4 294 967 296 pojedynczych
komórek, które tworzą przestrzeń adresową. Niektóre części tych adresów
tworzą "prawdziwą" pamięć. Oznacza to, że jeżeli przechowamy dane w tych
adresach, będziemy w stanie z powrotem je odczytać. Pozostała część
wykorzystywana jest do innych celów, jak dla przykładu, umożliwiając dostęp
do układów specjalizowanych.
Większość Amig posiada różne banki pamięci.
Wszystkie posiadają pamięć chip (która zawsze rozpoczyna się od adresu 0),
niektóre posiadają dodatkową pamięć fast (dla przykładu te na płycie głównej
A4000), a jeżeli obecny jest procesor PPC prawdopodobne jest, że posiada
również własny bank pamięci. Wszystkie te banki pamięci znajdują się w
specyficznych adresach, które są dobierane przez sprzęt.
Starsze wersje
execa dokładnie tak zagospodarowują pamięć. Aby umożliwić programom
dynamicznie alokowanie pamięci, te wersje używają prostych list, które
kolejno pokrywają obszar pamięci: wolna pamięć jest częścią listy, zajęta
pamięć - nie. Początkowo cały bank pamięci wypełniony jest przez listę z
jednym zerem. Gdy pamięć jest alokowana, lista jest skanowana, a pierwszy
blok, który jest albo większy albo dokładnie takich samych rozmiarów, jest
pobierany i usuwany z listy. Jeśli ten blok jest większy niż wymagana ilość
pamięci, jest dzielony i pozostała pamięć wraca na listę.
Ta metoda jest raczej prosta i może być z powodzeniem stosowana, lecz niesie
ona ze sobą kilka problemów. Oczywistym problemem jest to, że metoda ta
umożliwia programom alokacja tylko takiej ilości pamięci jaka fizycznie
znajduje się w komputerze. Jeśli komputer wyposażony jest dla przykładu w
16MB pamięci, dla żadnego programu nie jest możliwe zainstalowanie większej
ilości nawet jeżeli 32-bitowa przestrzeń adresowa umożliwia alokowanie do 4GB
adresowalnej pamięci.
Kolejnym problemem nawet bardziej denerwującym, który z całą pewnością już
nie raz doświadczyłeś jest to, ze po kilku godzinach komputer staje się coraz
wolniejszy, a programy zaczynają narzekać na posiadanie zbyt małej ilości
dostępnej pamięci - nawet wtedy gdy Workbench wskazuje że pamięci jest nawet
nadto. Problem nazywany jest fragmentacją.
Fragmentacja powodowana jest przez ciągłe alokowanie i uwalnianie pamięci,
które prowadzi do powstawania luk w wolnej pamięci. Sprawia to również, że
lista staje się dosyć duża, tak więc więcej czasu zajmuje jej sprawdzenie (a
to powoduje ogólne spowolnienie). Jedynym sposobem na pozbycie się
fragmentacji, jest zresetowanie komputera, a to trzeba przyznać nie jest za
dobre rozwiązanie.
ExecSG: w kierunku środowiska wirtualnego
Do zaadresowania pamięci ExecSG wprowadza "wirtualne adresowanie".
Zamiast akceptowania istniejącego układu pamięci zapoczątkowanego przez
sprzęt, ExecSG próbuje "zreorganizować" pamięć. Umożliwia to uniknąć
fragmentacji i poprawia wiele innych problemów (wprowadza jednak drobne
niekompatybilności).
Zanim przejdziemy dalej, muszę wyjaśnić co oznacza wirtualne adresowanie.
Bez obaw, postaram się to zrobić możliwie jak najmniej technicznie.
Wirtualne adresowanie
Słownik definiuje słowo "wirtualny" jako "istniejący lub dający efekt w
postaci bytu lub efektu, który nie jest aktualnie faktem, formą lub nazwą.
Innymi słowy, opisuje coś co jest widziane, ale właściwie go nie ma - jak
miraż. W rzeczywistości tak właśnie można opisać wirtualne adresowanie:
można zaadresować pamięć, która normalnie nie jest dostępna. Dla przykładu,
procesor może próbować uzyskać dostęp do pamięci o adresie 100, lecz w
rzeczywistości, dostęp będzie następował do adresu 2340. Część procesora
zwana "jednostką zarządzającą pamięcią" (w skrócie MMU) podmienia wirtualne
adresy adresami fizycznymi. Możliwym się staje wykorzystanie MMU do
kompletnej zmiany układu pamięci. Dla przykładu możemy złączyć kilka
obszarów pamięci w liniowy blok. Jeśli to rozważymy, możemy uniknąć
fragmentacji: przez łączenie mniejszych bloków w większe (wirtualne) bloki.
Oczywiście takie remapowanie nie może być dowolne. Nowoczesne procesory
potrafią remapować bloki pamięci w inne bloki. Takie bloki nazywane są
często płytkami lub stronami. Zwrot "płytka" trafnie opisuje jak to działa.
Wyobraźmy sobie kafelki, płytki glazury na ścianie w łazience. MMU potrafi
"wirtualnie" przestawić te płytki tak, aby uformować nową ścianę (porównanie
jest trochę słabe, ale obrazuje jak to działa).
Uwaga: Nawet jeżeli zwrot "płytka" opisuje co się dzieje, normalnie używa
się zwrotu "strona".
Jako przykład z życia wzięty może posłużyć PowerPC. Potrafi ono remapować
strony do 4096 bajtów każda (starsze procesory jak, oryginalny 68000 nawet
nie posiadały takiej możliwości. Wprowadzono ją dopiero w 68020 jako
zewnętrzny układ, a od 68030 jako część procesora).
ExecSG wykorzystuje stronę o rozmiarze 64kB. Oznacza to, że dzieli pełną 4
gigabajtową przestrzeń adresować na 65536 różnych stron.
Zarządzanie obiektowo zorientowaną pamięcią.
ExecSG omija zastosowane w starym execu podejście listy. Obszary pamięci są
teraz obiektami, które są przechowywane w priorytetowo posortowanej liście.
Gdy wymagana jest pamięć, ExecSG kieruje zapytanie do obiektów na liście, czy
są w stanie wykonać żądanie na zapotrzebowanie pamięciowe w zakresie rozmiaru
i rodzaju pamięci. Gdy obiekt nie może spełnić żądania, przechodzi ono na
następny. Gdy żądanie może zostać spełnione, jest ono wykonywane a obiekt
informuje ExecSG o obszarze zaalokowanej pamięci.
Kluczowe w tym wszystkim jest to, że obecna implementacja obiektu jest
nieprzezroczysta: zamiast wymagać listy pamięci, obiekt może implementować
ją w jakikolwiek sposób chce. Sprawia to, że możliwa staje się wymiana
wprowadzonych implementacji obiektu. Obiekt nie musi nawet posiadać
możliwości do alokowania pamięci. Obiekty te potrafią robić jednak dużo
więcej. Każdy obiekt kontroluje obszar przestrzeni adresowej. Oprócz
zarządzania pamięcią, zarządza również innymi rzeczami. Dla przykładu, gdy
program próbuje uzyskać dostęp do czegoś wewnątrz obszaru kontrolowanego
przez obiekt i powoduje to wystąpienie błędu, obiekt potrafi przechwycić błąd
i zachowywać się zgodnie z nim. Jest to bardzo silny mechanizm, które może
być wykorzystany w wielu aplikacjach, jak się o tym wkrótce będziemy mogli
przekonać.
Aplikacje i możliwości
Podejście zorientowane na obiekt umożliwia implementację wielu mechanizmów,
które nie były możliwe w oryginalnym zamyśle. Chciałbym wymienić kilka
możliwości: kilka już zaimplementowanych i kilka, które są planowane.
Pamięć wirtualna: jedna z podstawowych funkcji obiektów pamięci. Obszar
przestrzeni adresowej wykorzystywany jest jako pamięć z "prawdziwą" (tj.
fizycznie istniejącą) pamięcią jest remapowany, aby utworzyć jeden duży
obszar pamięci. To pozwala skutecznie uniknąć fragmentacji, która była
prawdziwym utrapieniem starego Execa. Dodatkowo, umożliwia to także zmianę
rozmiarów zaalokowanych bloków pamięci oraz wywołuje opóźnienie alokacji
pamięci. Opóźniona alokacja oznacza, że wirtualne adresy pamięci są
alokowane, lecz pamięć fizyczna nie. Gdy program próbuje uzyskać dostęp do
pamięci, następuje błąd. Obiekty pamięci potrafią przechwycić to i wtedy
próbują ulokować niewielki bit pamięci, aby upewnić się, że dostęp jest
możliwy i zwracają kontrolę programowi.
Ciekawe może to wyglądać w przypadku programów, które wczytują skompresowane
dane do pamięci: alokują duży obszar z opóźnioną alokacją (nie wykorzystują
prawdziwej pamięci), a następnie odkompresowują dane do tej pamięci, aby w
końcu zmienić rozmiar bloku do potrzebnego rozmiaru. Nie jest używane więcej
pamięci niż jej naprawdę potrzeba.
Paging/Swapping: te zwroty najczęściej są stosowane przy zagadnieniu pamięci
wirtualnej. Jeżeli pamięć jest potrzebna, lecz jej nie ma, części
istniejącej pamięci są zapisywane na dysk. Powstała w ten sposób wolna
pamięć jest wykorzystywana do tego, do czego była potrzebna. Pamiętajmy, że
wirtualne adresowanie umożliwia blokom pamięci pojawić się w dowolnym
miejscu, tak więc nie ma to znaczenia skąd pamięć pochodzi.
Automatyczne zwiększanie stosu. Jeżeli kiedykolwiek zdażyło ci się korzystać
z GCC lub grałeś w jeden z portów naszych gier, prawdopodobnie wiesz, że
korzystają one z bardzo dużych rozmiarów stosu. Trzeba ustawiać go ręcznie,
z poziomu shell lub w ikonie programu. Przy wykorzystaniu obiektów pamięci
ExecSG, możliwym staje się tworzyć stosy, które są automatycznie zwiększane
gdy są za małe. Nie wymaga to specjalnych fragmentów kodu w programie (tak
jak teraz) i jest możliwe bez żadnych dodatkowych kosztów (normalnie,
program, który sam sprawdza rozmiar stosu, uruchamia się wolniej niż
programy, które o to nie zabiegają).
Pliki lub obiekty mapowane w pamięci. Cechą innych systemów operacyjnych
jest możliwość mapowania plików w pamięci. Zamiast używać specjalnych
funkcji do odczytu i zapisu pliku, dostęp do pliku następuje tak jakby on
cały był wczytany do pamięci, nawet wtedy gdy jest większy niż dostępna
pamięć. Ta cecha jest również możliwa w obiektowej pamięci ExecSG.
Obsługa Mediatora: prosta wersja pamięci obiektowej potrafi również
symulować "MMU feature" Mediatora.
Ochrona pamięci: to kolejny duży krok na przód. Jedna z kolejnych wersji
AmigaOS4 będzie posiadać per-aplikację obiektowej pamięci. Dostępne obiekty
będą zależne od obecnie wykonywanych procesów. Ten prosty krok wygeneruje
duży efekt. Zapewni to każdemu programowi na posiadanie jego własnego układu
pamięci. Oznacza to, że każdy program będzie uruchamiany w swojej własnej
przestrzeni adresowej, a to sprawia, że taka pamięć jest chroniona przed
przypadkowymi jej naruszeniami przez inne programy. Niektóre obiekty pamięci
pozostaną dostępne dla wszystkich programów w celu dostarczenia pamięci,
która jest częścią wszystkich programów (współdzielona pamięć).
Ten krok sprawi, że Amiga otrzyma nowy poziom stabilności i bezpieczeństwa.
Podsumowanie
Jak widać, istnieje wiele możliwości. Ten artykuł tylko wprowadza do tematu.
Mam nadzieję, że nie był przesycony technikaliami, lecz sam temat jest z
natury bardzo techniczny. Miłej zabawy.
Autor: Thomas Frieden, Hyperion Entertainment
Club Amiga logo concept and artwork by Mark Rickan & Mohamed Moujami, winners of the Club Amiga Logo Contest.
Submitted text and images reproduced in Club Amiga Monthly are copyright by their respective authors.
All other text and images reproduced in Club Amiga Monthly are copyright 2003 Amiga Inc.
Content may not be reprinted or reproduced in part or in whole without express written consent of Amiga Inc.