Если я не понимаю ваш вопрос, вы спрашиваете:
При отображении произвольно большого файла в память, как процесс отображает все это в память?
Это на самом деле очень увлекательный и очень глубокий вопрос.
Естественно, это означает, что ответ будет таким же длинным и запутанным. Так что без лишних слов.
Во-первых, нам нужно выяснить, сколько памяти наш теоретический текстовый редактор может иметь максимум. Первым ограничением будет то, сколько современный компьютер может физически адресовать (при этом упрощая и игнорируя существование файла подкачки, позволяя ему адресовать больше памяти, чем у него), который ограничен адресной шиной. В современных 64-разрядных системах отображаются только младшие 48 бит адресной шины. Это означает, что максимум процессор может физически адресовать 256 терабайт оперативной памяти.
Значительно избыточнее по сравнению с обычной 16-гигабайтной системой.
Однако теперь у нас есть еще одно ограничение; виртуальная память и размер файла подкачки. В современной операционной системе процессы имеют страницы виртуальной памяти, которые ОС выделяет для каждой (именно поэтому каждый процесс может поместить свой код по одному и тому же адресу в память без коллизий и очень плохих событий). Максимальное количество страниц, которое ОС может дать каждому процессу, зависит от платформы и настроек системы. Обычно, однако, это намного меньше, чем даже ограниченный объем физической памяти, который мы обычно видим. Однако это все еще столь же абсурдное количество (обычно настолько, что средняя программа использует только ~ 2% от общего объема памяти)
(Примечание: здесь есть различие между страницами, которые процесс выделил и использует, и теми, которые он выделил, но не коснулся. Когда вы выделяете страницу, она изначально является клоном так называемой «нулевой страницы» ', потому что все страницы инициализируются нулями. Как только вы начинаете запись на страницу, ОС выделяет страницу для этого процесса.)
Итак, это наш следующий предел теоретического текстового редактора.
Во-вторых, нам нужно понять, как эти процессы отображают файлы в память.
Используя Linux в качестве примера, когда вы используете функцию mmap для загрузки файла, вы можете указать окно того, какую часть файла вы хотите отобразить. Таким образом, программа может отображать только часть файла за раз, когда он работает.
С предыдущим утверждением о том, сколько памяти выделено, очевидно, что это не проблема.
В-третьих, мы достигаем как узкого места, так и решения: подкачки.
Процесс может очень хорошо отобразить файл размером в несколько гигабайт в память, однако только небольшая часть этого файла будет одновременно находиться в оперативной памяти. ОС «выложит» разделы, к которым нет доступа к файлу подкачки на диске. (Помните, я упоминал об этом поведении ранее?) Итак, это действительно ответ на ваш вопрос. Нашей маленькой программе для редактирования текста действительно не нужно заботиться о таких проблемах. Он может отображать произвольно большое окно (до некоторого абсурдного предела. Например, в 32-разрядных операционных системах он может одновременно обрабатывать только 4 гигабайта памяти, современные 64-разрядные системы не ограничены аналогичным образом.) И позволить ОС управлять перемещением данные, о которых он заботится как в оперативной памяти, так и вне ее.
Надеюсь, это поможет! :)