@15: Samozřejmě že je .NET runtime obyčejný program. Ale i ty si mohou, jak ostatně bylo zmíněno v @17, namapovat (téměř) kamkoli třeba soubor nebo paměťový prostor jiného procesu.
K nenabízení - překopíruju si nějaké stránky o kus vedle (hezky zarovnaně). Co udělá kernel? Deduplikuje mi je, tj. nastaví jejich mapování na stejnou fyzickou adresu a zapne cow.
Stránkování samozřejmě nemůžete napsat, když ten procesor neznáte - minimálně potřebujete vědět, jak velké jsou fyzické stránky a jak funguje ochrana paměti, TLB a podobné záležitosti, bez toho žádnou správu nenapíšete. Ale jakmile máte tyhle věci hotové, je zbytek "brnkačka" a multiplatformní kód.
Jednak řešíme MS implementaci .NET runtime na Windows. A MMU/chráněný mód je, pokud mě pamět nešálí, povinný požadavek na Linux, a ačkoliv existují varianty bez MMU (uCLinux), ochrana paměti je jedna ze základních vlastností operačních systémů (sám jste se jí oháněl v @13). Navíc dnes už i "obyčejné" ARM11, používané v (hloupých) mobilech, MMU obsahují.
@16: Jenže SOH se kompaktí - a s ohledem na velikost tam ukládaných objektů bych čekal, že těch úprav bude mnohem víc. Nezáleží na velikosti objektů, ale na počtu referencí. Při GC stejně musíte projít stromy referencí, takže víte, co opravovat. A v managed kódu samozřejmě žádné pointery nemáte, takže odpadá ono procházení celé paměti a hádáni, co by tak mohl být ukazatel. Vždycky máte přehled o referencích na všechny objekty, to je tak nějak jeden ze smyslů celé té srandy. Takže tenhle argument nedává smysl.
