OSDev

Нашел время и посмотрел видео о "Фантоме" на CodeFreeze от начала и до конца, чему немало удивился.

То ли в этот раз рассказ о "Фантоме" был более связным, то ли я стал лучше разбираться в особенностях "Фантома", но смотреть оказалось довольно интересно, а местами даже и поучительно. В CC-шных видео я обычно выдерживал лишь первые полчаса, после чего вырубал, не видя для себя ничего полезного.

Поскольку я тоже разрабатываю объектно-ориентированную ОС, то являюсь заинтересованной стороной, и от подробных комментариев воздержусь. Скажу лишь, что своим выступлением Дмитрий блестяще подтвердил мои догадки по "Фантому", и теория фрактальной ОС работает.

Если у кого-то еще хватило терпения всё посмотреть и есть что сказать по существу, было бы интересно услышать комментарии.

_________________
Путь успеха Циолковского — правильно умереть

Пока буду писать комментарии по ходу просмотра видео.
20 мин. Слишком нудная.
Не понимаю зачем нужна сборка мусора. Кто будет определять что есть мусор, а что нет?

Мусор собирают в языках с "управляемым" кодом. Т.е. там где программы работают с хэндлами а не с реальными указателями на память (Java, C#). Он как раз на эти языки и орентируется, значит нужно.

Ещё раз откуда берётся мусор?
Про хэнделы вообще не понял.

В "управляемых" языках при динамическом создании нового объекта в распоряжение программиста передаётся не адрес (указатель) этого объекта, а некая абстрактная величина (хэндл). Все операции с объектом с точки зрения программиста, использующего такой язык, идут аналогично обычной работе с указателями, однако в реальности преобразование хэндл-адрес осуществляет компилятор, его РТЛ или ВМ. Кроме того, ведётся учёт ссылок, т.е. числа использования хэндла. Когда выясняется, что его значения больше нигде не хранятся, происходит автоматическое уничтожение объекта, к которому он относился, ведь этот объект стал мусором (на него больше ничто не указывает).

Кстати говоря, такой подход применяется не только в "управляемых" языках. Это _может иметь место_ (но не обязательно) в Аде: тамошние ссылочные типы (access types), хотя и аналогичны по своему использованию указателям, не обязательно являются адресами памяти, и за освобождением объектов обычно следит компилятор. (Вот GCC поступает просто: там объекты вообще никогда не освобождаются, поскольку они не осилили полноценную поддержку динамической памяти в Аде). Правда, там есть штатная возможность уничтожать такие объекты ручками, т.е. как в обычных языках.

Тогда зачем нужен сборщик мусора если у нас есть счётчик ссылок?

Не понял что значит полноценную?
Для меня динамическая память это GetMem и FreeMem.

Например, чтобы устранять "острова" - группы объектов, которые ссылаются друг на друга, но на которых нет ссылок снаружи.

А кто будет следить за этим счётчиком, увеличивая и уменьшая его по мере необходимости? Кто будет освобождать память, когда счётчик обнулится?



А для Ады это (не в таком виде, правда) -- самый-самый минимум, без которого динамической памяти просто нету. Но это отнюдь не полный набор того, что должен бы обеспечивать хороший компилятор.

1:11 dz видимо напортачил с снепшотом а винит алокатор.

Mr.McD. писал это зимой. А теперь послушайте, что говорит Завалишин с 1:38:31. Это то немногое, в чем я с ним согласен.

_________________
Путь успеха Циолковского — правильно умереть