История изменений
Исправление wandrien, (текущая версия) :
Нам объясняли по другому. В памяти системы существует лишь одна копия libstdc++, а каждый процесс имеет свои изменяемые данные. А иначе зачем это все затевать, если можно собирать статически? Я вот только не поняла, как прцесс вызывает из этой памяти функции?
Сильно упрощенно, картина следующая:
В памяти системы существует такой объект как «отображение файла в память». Это означает, что система в регион адресов кладёт данные из файла, а если ей не хватает оперативной памяти, может просто выкинуть их. (А когда потребуются, снова загрузить из файла.)
Эти данные, сколько раз файл не отображай, он оперативной памяти съест одинаково. Т.к. отображается в процессы из одних и тех же физических страниц.
Но в общем случае нельзя просто отобразить so в память, и она заработает. Требуется выполнить связывание, т.е. установить правильные ссылки между модулями.
Для этого загрузчик объектов so должен модифицировать память.
Поэтому поверх «отображения файлов в память» прозрачным образом существует еще одно (анонимное) отображение. Как только загрузчик so пытается изменить данные, система автоматически создаёт копию страницы, и дальше процесс работает с этой копией.
Таким образом, с точки зрения системы, есть, например, 95% страниц, которые полностью повторяют содержимое файла (и могут быть выброшены и загружены заново при необходимости) и еще 5% страниц, которые она просто так выбросить не может, т.к. они содержат изменения, необходимые для работы so.
А с точки зрения прикладного кода, он просто загрузил содержимое so-файла в свою память, и его загруженная копия не имеет отношения к другим копиям.
Всё зависит от того, на каком уровне абстракции рассматривать этот механизм.
Исходная версия wandrien, :
Нам объясняли по другому. В памяти системы существует лишь одна копия libstdc++, а каждый процесс имеет свои изменяемые данные. А иначе зачем это все затевать, если можно собирать статически? Я вот только не поняла, как прцесс вызывает из этой памяти функции?
Сильно упрощенно, картина следующая:
В памяти системы существует такой объект как «отображение файла в память». Это означает, что система в регион адресов кладёт данные из файла, а если ей не хватает оперативной памяти, может просто выкинуть их. (А когда потребуются, снова загрузить из файла.)
Но в общем случае нельзя просто отобразить so в память, и она заработает. Требуется выполнить связывание, т.е. установить правильные ссылки между модулями.
Для этого загрузчик объектов so должен модифицировать память.
Поэтому поверх «отображения файлов в память» прозрачным образом существует еще одно (анонимное) отображение. Как только загрузчик so пытается изменить данные, система автоматически создаёт копию страницы, и дальше процесс работает с этой копией.
Таким образом, с точки зрения системы, есть, например, 95% страниц, которые полностью повторяют содержимое файла (и могут быть выброшены и загружены заново при необходимости) и еще 5% страниц, которые она просто так выбросить не может, т.к. они содержат изменения, необходимые для работы so.
А с точки зрения прикладного кода, он просто загрузил содержимое so-файла в свою память, и его загруженная копия не имеет отношения к другим копиям.
Всё зависит от того, на каком уровне абстракции рассматривать этот механизм.