Комментарии 24
Решил перевести одну интересную статью, но обнаружил, что она ссылается на другую. А другая — на третью, вот на эту. Так что буду переводить эту матрёшку изнутри наружу.
Как обычно, просьба об ошибках, опечатках и неправильном использовании терминов писать в личку, я так быстрее смогу среагировать.
Как обычно, просьба об ошибках, опечатках и неправильном использовании терминов писать в личку, я так быстрее смогу среагировать.
Мне кажется, что эта статья уже была переведена тут.
А зачем строковые литералы в сегменте текста?
НЛО прилетело и опубликовало эту надпись здесь
одно другому не мешает.
С# маппирует нужные библиотеки фреимворка .Net.
Java по сути говоря имеет единственный исполняемый файл, который просто интерпретирует байткод. А всю осталъную структуру в виде куч, стека и прочих данных организует внутру запрошенного исполняемым файлом пространства.
С# маппирует нужные библиотеки фреимворка .Net.
Java по сути говоря имеет единственный исполняемый файл, который просто интерпретирует байткод. А всю осталъную структуру в виде куч, стека и прочих данных организует внутру запрошенного исполняемым файлом пространства.
А все таки, кто же будет писать вам рантаймы на С#, Java?Кроме C# и Java есть и другие языки. Ada какая-нибудь вполне совмещает безопасность и низкоуровневость. Вот только писать на ней тяжко — много разных ограничений.
Тема 64 бит не раскрыта
А я бы еще про физическую память почитал в таком формате с картинками. Со всякими DMA и прочими соответствиями адресов регистрам физических устройств.
Там будет слишком специфично для конкретного процессора даже внутри одной архитектуры.
Вот тут есть немного, но почти без деталей, плюс в память отображается далеко не все, очень многое по прежнему реализовано только через CPU IO и PCI IO.
Добавлю к написанному там, что 0xC0000000 — это TOLUD = 3Gb, популярное значение по умолчанию, но иногда его дают перенастроить через BIOS Setup.
Вот тут есть немного, но почти без деталей, плюс в память отображается далеко не все, очень многое по прежнему реализовано только через CPU IO и PCI IO.
Добавлю к написанному там, что 0xC0000000 — это TOLUD = 3Gb, популярное значение по умолчанию, но иногда его дают перенастроить через BIOS Setup.
people.freebsd.org/~lstewart/articles/cpumemory.pdf — What Every Programmer Should Know About Memory
И даже по-русски Что каждый программист должен знать о памяти
Но если мы начинаем использовать виртуальную адресацию, приходится использовать её для всех программ, работающих на компьютере – включая и само ядро. Поэтому часть пространства виртуальных адресов необходимо резервировать под ядро.
Отсюда совершенно не следует необходимость резервирования виртуальной памяти под ядро. Вот если по какой-то причине любому процессу надо напрямую обращаться к памяти ядра, пусть и через системные библиотеки, тогда да. Но этого не было сказано.
Строго говоря не следует (и в природе существует даже такое явление, как 4G/4G split), но на практике — это страшный костыль, который чудовищно замедляет работу ядра.
Вы верно заметили, что приложениям не нужно обращаться к памяти ядра. Никак — ни «напрямую», ни «накривую». Иначе бы даже на 64-битной операционке 32-битные процессы имели бы доступ к 3GiB, а не 4GiB, как это происходит на практике.
А вот ядру — нужно обращаться и к своей памяти и с к памяти процесса. Проще и быстрее всего это сделать если ядро может видеть оба диапазона одновременно и без извращений, потому разделение адресного пространства на «ядрёную» и «пользовательскую» — решение, принятое почти всеми операционками.
Вы верно заметили, что приложениям не нужно обращаться к памяти ядра. Никак — ни «напрямую», ни «накривую». Иначе бы даже на 64-битной операционке 32-битные процессы имели бы доступ к 3GiB, а не 4GiB, как это происходит на практике.
А вот ядру — нужно обращаться и к своей памяти и с к памяти процесса. Проще и быстрее всего это сделать если ядро может видеть оба диапазона одновременно и без извращений, потому разделение адресного пространства на «ядрёную» и «пользовательскую» — решение, принятое почти всеми операционками.
Для чего ядро резервирует так много памяти? 1 ГБ «должно хватить всем» с лихвой. Если я не ошибаюсь, и в линуксе, и в окнах размеры ядра в памяти исчисляются всего лишь десятками мегабайт.
Кстати, а /3GB разве не 3.5 ГБ процессу даёт на деле?
Кстати, а /3GB разве не 3.5 ГБ процессу даёт на деле?
Я понимаю, что «чукча не читатель — чукча писатель», но как бы размещать вопрос непосредственно после ранее написанного ответа на него странно.
Глядя же на ваш послдений вопрос вспоминаешь бессмертное "Правда ли, что шахматист Петросян выиграл в лотерею тысячу рублей? Правда, только не шахматист Петросян, а футболист «Арарата» Акопян, и не тысячу, а десять тысяч, и не рублей, а долларов, и не в лотерею, а в карты, и не выиграл, а проиграл." У вас в голове, похоже, всё смешалось в кучу. Таки да, ключ /3GB даёт процессу именно-что 3GB. А 3.5GB (примерно) — это максимум, который может адресовать вся оперционка, если она 32-битная. А чтобы 32-битный процесс получил больше — ядро должно быть 64-битное.
Глядя же на ваш послдений вопрос вспоминаешь бессмертное "Правда ли, что шахматист Петросян выиграл в лотерею тысячу рублей? Правда, только не шахматист Петросян, а футболист «Арарата» Акопян, и не тысячу, а десять тысяч, и не рублей, а долларов, и не в лотерею, а в карты, и не выиграл, а проиграл." У вас в голове, похоже, всё смешалось в кучу. Таки да, ключ /3GB даёт процессу именно-что 3GB. А 3.5GB (примерно) — это максимум, который может адресовать вся оперционка, если она 32-битная. А чтобы 32-битный процесс получил больше — ядро должно быть 64-битное.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Анатомия программы в памяти