Оберон-клуб «ВЄДАsoft»

Процедура ADR возвращает адрес переменной. Этот адрес всегда будет адресом этой переменной? Если да, то сборщик мусора не может двигать переменные (хотя бы те, у которых был взят адрес). Я правильно понимаю или нет?

Это процедура из SYSTEM. Т.е., ее поведение прибито к конкретной реализации. В ББ консерватиный GC, который никуда ничего не двигает.

Наверное, было бы неплохо иметь gc с дефрагментатором памяти. Но на практике уровнем выше ещё есть страничная виртуальная память на уровне оси. После неё особо заморачиваться с дефрагментацией памяти смысла нет.
И, надо помнить. От запуска к запуску адреса переменных плавают))

_________________
Действия профессионала предсказуемы. Но в мире полно любителей!

Да, я вот как раз думал недавно, что двигать память в контексте paged памяти не нужно. Хотя с другой стороны, в современных процессорах с их кешем, соседство много значит. При выделении памяти есть корреляция: если объекты выделяются почти одновременно, то они и использоваться будут, скорее всего, почти одновременно. Т.е. их имеет смысл класть рядом, и в этом смысле использование free list -ов проигрывает. Хотя для рилтайма это преимущество недоказуемо, т.к. оно носит статистический характер. Надо тебе, чтобы объекты лежали рядом - будь добр сделать это явно. И поскольку маргинальные системы умирают, как я понимаю, обычно через потерю надёжности, то важнее сохранить отлаживаемость. А отлаживаемость при подвижной памяти резко теряется. Вывод: удачно сделано в ББ.

А так вообще, в случайно взятом Обероне, я понимаю, что поведение ADR не гарантировано. Правильно?

Ну, принято говорить о последнем Обероне без специальной ремарки, или с ремаркой о ранних вариантах.
В последнем Обероне, в переводе репорта которого я тоже успел наследить вообще ничего не говорится о GC, работе с памятью и других грубых механизмах. Всё это отдано на откуп реализации. Касаться физической адресации в Оберонах -- не камильфо. Бывает, что приходится, но если в этом нет такой потребности НА САМОМ ДЕЛЕ -- работа с памятью напрямую скорее говорит о том, что программист не понял, что Оберон -- это не Си))

_________________
Действия профессионала предсказуемы. Но в мире полно любителей!

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

Дефрагминтация актуальна, как минимум, для 32-битных приложений, когда может не оказаться непрерывного участка виритуальных адресов.

Я так понимаю, даже если делать массив из миллиарда элементов, на уровне железа он всё равно будет разбит на страницы, поскольку ОС не умеет выделять страницу памяти размером миллиард слов. Поэтому стоит его разбить на страницы уже на уровне рантайм-среды. Мне приходилось встречаться с такой реализацией массивов, хотя она была сделана очень давно и, возможно, для другого железа, чем сейчас используется. Но есть и другие мотивы разбивать огромные объекты на более мелкие. Например, для сборщика мусора желательно помечать куски памяти, которые не изменились со времени прошлой сборки - это позволяет сэкономить что-нибудь. Если массив огромный, то есть большая вероятность, что в нём изменятся только отдельные небольшие части - тогда выигрыш от страничности может быть значительным.

Хотя надо сказать, я далёк от каких-то системных знаний в этой области.

Оберон без GC по безопасности падает на уровень Си. Т.е., практического смысла не имеет.

Мне не попадалась ни одна реализация Оберона, в которой сборщик мусора перемещает данные. И ни одна, которая вызывает сборщик в непредвиденный момент. Наоборот, сборщик вызывается только при очередном выделении памяти по NEW (или SYSTEM.NEW). Так что работа ADR вполне гарантирована. А иначе какой в нём смысл вообще тогда?

Проблемы же с ADR могут возникнуть при работе с полученным адресом после выгрузки модуля, данные которого были размещены по этому адресу. Впрочем, это же касается и указателей на процедуры.