Как стать автором
Обновить

Комментарии 24

Решил перевести одну интересную статью, но обнаружил, что она ссылается на другую. А другая — на третью, вот на эту. Так что буду переводить эту матрёшку изнутри наружу.
Как обычно, просьба об ошибках, опечатках и неправильном использовании терминов писать в личку, я так быстрее смогу среагировать.
Мне кажется, что эта статья уже была переведена тут.
Да, жаль что они имя её изменили — поэтому я её и не нашёл.
А ведь можно встроить в Хабрахабр маленькую проверку на уникальность: «Перевод этой статьи уже опубликован по адресу <url_here>».
Они там и остальные статьи попереводили.
А зачем строковые литералы в сегменте текста?
Чтобы их менять было нельзя :-) В эру до NX бита этого хватало. Сейчас — они в отдельном сегменте.
НЛО прилетело и опубликовало эту надпись здесь
одно другому не мешает.

С# маппирует нужные библиотеки фреимворка .Net.

Java по сути говоря имеет единственный исполняемый файл, который просто интерпретирует байткод. А всю осталъную структуру в виде куч, стека и прочих данных организует внутру запрошенного исполняемым файлом пространства.
НЛО прилетело и опубликовало эту надпись здесь
У него и написано на низкоуровневых. К ним можно отнести ассемблеры и «С». Но вот с учетом фреймворков и квази-интерпретаторов байткода я бы к низкоуровневым не относил никак.
НЛО прилетело и опубликовало эту надпись здесь
А все таки, кто же будет писать вам рантаймы на С#, Java?
Кроме C# и Java есть и другие языки. Ada какая-нибудь вполне совмещает безопасность и низкоуровневость. Вот только писать на ней тяжко — много разных ограничений.
Тема 64 бит не раскрыта
А я бы еще про физическую память почитал в таком формате с картинками. Со всякими DMA и прочими соответствиями адресов регистрам физических устройств.
Там будет слишком специфично для конкретного процессора даже внутри одной архитектуры.
Вот тут есть немного, но почти без деталей, плюс в память отображается далеко не все, очень многое по прежнему реализовано только через CPU IO и PCI IO.
Добавлю к написанному там, что 0xC0000000 — это TOLUD = 3Gb, популярное значение по умолчанию, но иногда его дают перенастроить через BIOS Setup.
На некоторых ARM SoC'ах почти всё на памяти, а там еще любопытности вроде гарвардской архитектуры…
Ну и интересна не конкретная конкретика, а сами принципы.
Но если мы начинаем использовать виртуальную адресацию, приходится использовать её для всех программ, работающих на компьютере – включая и само ядро. Поэтому часть пространства виртуальных адресов необходимо резервировать под ядро.

Отсюда совершенно не следует необходимость резервирования виртуальной памяти под ядро. Вот если по какой-то причине любому процессу надо напрямую обращаться к памяти ядра, пусть и через системные библиотеки, тогда да. Но этого не было сказано.
Строго говоря не следует (и в природе существует даже такое явление, как 4G/4G split), но на практике — это страшный костыль, который чудовищно замедляет работу ядра.

Вы верно заметили, что приложениям не нужно обращаться к памяти ядра. Никак — ни «напрямую», ни «накривую». Иначе бы даже на 64-битной операционке 32-битные процессы имели бы доступ к 3GiB, а не 4GiB, как это происходит на практике.

А вот ядру — нужно обращаться и к своей памяти и с к памяти процесса. Проще и быстрее всего это сделать если ядро может видеть оба диапазона одновременно и без извращений, потому разделение адресного пространства на «ядрёную» и «пользовательскую» — решение, принятое почти всеми операционками.
Для чего ядро резервирует так много памяти? 1 ГБ «должно хватить всем» с лихвой. Если я не ошибаюсь, и в линуксе, и в окнах размеры ядра в памяти исчисляются всего лишь десятками мегабайт.

Кстати, а /3GB разве не 3.5 ГБ процессу даёт на деле?
Я понимаю, что «чукча не читатель — чукча писатель», но как бы размещать вопрос непосредственно после ранее написанного ответа на него странно.

Глядя же на ваш послдений вопрос вспоминаешь бессмертное "Правда ли, что шахматист Петросян выиграл в лотерею тысячу рублей? Правда, только не шахматист Петросян, а футболист «Арарата» Акопян, и не тысячу, а десять тысяч, и не рублей, а долларов, и не в лотерею, а в карты, и не выиграл, а проиграл." У вас в голове, похоже, всё смешалось в кучу. Таки да, ключ /3GB даёт процессу именно-что 3GB. А 3.5GB (примерно) — это максимум, который может адресовать вся оперционка, если она 32-битная. А чтобы 32-битный процесс получил больше — ядро должно быть 64-битное.
Таки да, ключ /3GB даёт процессу именно-что 3GB. А 3.5GB (примерно) — это максимум, который может адресовать вся оперционка, если она 32-битная.

Но если вспомнить про PAE…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации