Илья Ермаков писал(а):
Роман М. писал(а):
Мне кажется правильным следить за границами памяти модулей и держать наподобие перечня владений, указывающим за кем числятся данные участки памяти. Причём, никакие модули не должны иметь возможности на него влиять.
Вы это не сделаете для единого объектного пространства. Для изолированных - пожалуйста (когда в одном пространстве не может быть указателей на другое). Software Isolation, как в MS Singularity.
Этого не сделать
программно на
интелах. Но, по-моему, здесь подменяется одна проблема другой.
Цель - увеличить производительность совместной работы процессов? При переключении процессов имеет место задержка, связанная с переключением контекстов. И кто-то подумал: "да-а, а во времена ДОСа, когда все программы работали в одном адресном пространстве, таких проблем с переключением контекстов не было, и всё работало быстро". И все кинулись пихать программы, в одно адресное пространство. На самом деле я тут утрирую; всё немного не так - ядра ОС всегда так работали и не спешать работать иначе, но в последнее время эта идея стала популярной во многих местах. И тут появилась проблема, которую вы пытаетесь решить: в случае ненадёжных языков порча чужой памяти - обычное дело, а если язык надёжный, то в целях вредительства кому-нибудь будет не в падлу и ручками в бинарнике поковыряться.
Но изначальная цель-то не в том, чтобы процессы нормально работали в едином адресном пространстве. И настоящая проблема звучит так: как увеличить производительность переключения контекстов? Необходимость адресного пространства для меня на уровне ассемблера остаётся под вопросом, а на уровне ЯВУ мы с ним точно дел никаких не имеем. У нас каждая переменная в своём адресном пространстве, и мне кажется, что от пространства адресов мы вообще должны уйти. Тогда, многие регистры, хранящие в данный момент состояние процесса, можно будет упразднить, а программы сделать более гранулированными, что может уменьшить промахи кэша. В общем, очень похоже на работу в едином адресном пространстве.