Ручное разбиение памяти в .Net Framework (возможно ли / как?)

У меня есть большой интерес к написанию системы управления базами данных. Прочитав несколько страниц о том, как был реализован SQL Server 2000, я обнаружил, что использовались страницы памяти размером 4 КБ, каждая из которых была прямой копией страницы размером 4 КБ на жестком диске. Эти страницы загружались в оперативную память по мере необходимости, а затем лениво записывались на диск, когда они простаивали (упрощение).

Находясь на стадии планирования моего проекта, мне интересно, возможен ли такой уровень контроля в коде, работающем в среде CLR. Я понимаю, что C, C++ или D, вероятно, лучше подходят для этой задачи, но я хотел бы доказать, что для себя в первую очередь. Частично мотивация этого заключается в том, что я в конечном итоге хотел бы фактически переопределить сборщик мусора CLR своим собственным, используя мою базу данных в качестве кучи, по крайней мере, для относительно устаревших объектов.

Можно ли напрямую управлять памятью из CLR? Если да, то как бы я это сделал?

Предположим сейчас, что мои данные представляют собой набор структур/классов шириной 256 байт, хранящихся в плоской таблице на диске, и я использую страницы размером 64 КБ.


person kd8azz    schedule 12.09.2012    source источник
comment
Возможно, связано с stackoverflow.com/questions/2648560/   -  person cadrell0    schedule 12.09.2012


Ответы (1)


Вроде. Вы можете использовать файлы с отображением памяти в .NET, чтобы запись в "память " действительно пишет на диск.

person Peter Ritchie    schedule 12.09.2012
comment
Спасибо за эту ссылку; это информативно. Это дает мне еще один хороший способ подумать об этой проблеме. Моя первая реакция заключается в том, что я хочу сам управлять этим взаимодействием, но я могу справиться с этим. - person kd8azz; 12.09.2012
comment
SQL Server выполняет некоторые очень низкоуровневые операции с подкачкой памяти — на самом деле он занимается единственным управлением виртуальной памятью. Это то, что вы не можете сделать в .NET. - person Peter Ritchie; 12.09.2012