Bez virtuální paměti
Virtuální paměť je jedna ze stěžejních iluzí poskytovaná hardwarem. Předstírá, že paměť je hojná, spojitá a proces ji má celou jen pro sebe.
Nic ale nikdy není zadarmo a iluze usnadňující programování má svou cenu. Aby překlad virtuálních adres na fyzické byl únosně rychlý, procesory na palubě musí mít TLB (translation lookaside buffer) – malou cache uchovávající několik málo mapování mezi adresami. A malá skutečně je. Například datová L1 TLB v druhém Zenu disponuje místem pro 64 záznamů, L2 pro 2048. Na jedné straně, protože je třeba přeložit adresu při každém paměťovém požadavku, kdy program zapisuje nebo čte z paměti a nezáleží, jestli skončí v cache nebo v RAM, musí být překlad velice rychlý. Každá cesta do paměti vede přes TLB. Z toho důvodu je L1 TLB miniaturní. Na druhou stranu některé aplikace přistupují k obrovskému rozsahu dat (představte si práci s gigantickým grafem, kde lokalita je jen malá) a TLB musí pokrýt co největší rozsah, proto je L2 větší, ale rozhodně ne dostatečně pro všechny případy. Problém představuje spotřeba a plocha křemíku nutná pro implementaci, která není nezanedbatelná. TLB se nachází v neřešitelné situaci: Musí být rychlá, velká a zároveň energeticky nenáročná. Současný stav představuje kompromis.
V poslední době se ke mně dostaly dva články, které problém řeší tím, že se virtuální paměti a drahých iluzí, jež nabízí, zcela zřeknou.
The Cost of Software-Based Memory Management Without Virtual Memory navrhuje v hardwaru zachovat ochranu paměti, ale eliminovat virtuální paměť. Procesy využívají sdílený prostor fyzické paměti, ale nemůžou si vzájemně lézt do zelí, to CPU ohlídá. Kontrola přístupových práv může probíhat paralelně s čtením dat a technicky vzato out-of-order jádru nic nebrání ve spekulativní exekuci s tím, že ověření dopadne dobře, což se většinou stane. Jen nevím jak bezpečné by to bylo v ve světě po Meltdownu a Spectre.
Návrh se podobá vaporware architektuře Mill, která uvažovala sdílenou virtuální paměť pro všechny procesy v systému včetně jádra operačního systému. TLB by byly třeba jen, když paměťový požadavek opustí cache subsystém. Ten tak může být adresovaný zcela virtuálně (namísto virtálního adresování a fyzického tagování L1 cache, což je to nejlepší, na co se současný hardware zmůže). Návrháři uvažovali, že RAM je pomalá a trochu pomalejší TLB nebude mít velký dopad. Navíc pak můžou mít TLB větší s nížsí x spotřebou. (Po Millu se poslední 3 roky slehla zem.)
Změna by měla dopad na programovací model. Operační systém rozdává segmenty fyzické paměti tak jak jsou a nemůže garantovat jejich spojitost. Pole větší než jeden segment bude muset být implementováno jako strom. To nepředstavuje problém pro vysokoúrovňové runtime v duchu JVM, kde tohle všechno může být skryté za abstrakci + runtime beztak vykonává funkce blízké operačnímu systému při správě paměti a zdrojů, pokud potřebuje velký blok spojité paměti, GC přesune data stranou a nějaký uvolní.
CARAT: A Case for Virtual Memory through Compiler- and Runtime-Based Address Translation problém virtuální paměti řeší těsnou spoluprací operačního systému a kompilátoru. Uvažuje, že hardware neposkytne žádnou ochranu ani překlad adres. Bezpečnost zajistí kompilátor, který před každou dereferenci pointeru vloží guard kontrolující, jestli nemíří do oblasti, která procesu nepatří. Kompilátor musí odchytit všechny unikající pointery, neudělat jedinou chybu a navíc provádět velice agresivní optimalizace, aby snížil provozní režii do akceptovatelných mezí. To je zase něco, co JITy dělají docela běžně.
Conceptually, guard injectionintroduces a guard to every load, store, and call instruction. A guard verifies that the physical address about to be used by the instruction is within the restricted set allowed by the kernel and that the appropriate access permissions hold. The kernel essentially provides a dynamic set of address regions and their privileges to the CARAT runtime, and a guard checks the address range of the prospective access against this set.
Dost se to podobá garbage collectoru v manažovaných runtime – vkládá bariéry, zastavuje běžící vlákna v safe-pointech, sleduje pointery, aby je mohl aktualizovat v případě přesunu dat. Virtuální stroje jsou operační systémy uvězněné v jiných operačních systémech a v principu není důvod, proč by nemohli běžet přímo na hardwaru. Vysokoúrovňový VM by pro takovou architekturu mohl být perfektní .
K tématu