Оберон-клуб «ВЄДАsoft»
https://zx.oberon.org/forum/

ADR и сборщик мусора
https://zx.oberon.org/forum/viewtopic.php?f=79&t=354		 Страница 1 из 4
Автор:  budden [ 21 янв 2018, 22:53 ]
Заголовок сообщения:  ADR и сборщик мусора
Процедура ADR возвращает адрес переменной. Этот адрес всегда будет адресом этой переменной? Если да, то сборщик мусора не может двигать переменные (хотя бы те, у которых был взят адрес). Я правильно понимаю или нет?
Автор:  vlad [ 22 янв 2018, 05:51 ]
Заголовок сообщения:  Re: ADR и сборщик мусора
budden писал(а):
Процедура ADR возвращает адрес переменной. Этот адрес всегда будет адресом этой переменной? Если да, то сборщик мусора не может двигать переменные (хотя бы те, у которых был взят адрес). Я правильно понимаю или нет?


Это процедура из SYSTEM. Т.е., ее поведение прибито к конкретной реализации. В ББ консерватиный GC, который никуда ничего не двигает.
Автор:  prospero78su [ 22 янв 2018, 10:56 ]
Заголовок сообщения:  Re: ADR и сборщик мусора
Наверное, было бы неплохо иметь gc с дефрагментатором памяти. Но на практике уровнем выше ещё есть страничная виртуальная память на уровне оси. После неё особо заморачиваться с дефрагментацией памяти смысла нет.
И, надо помнить. От запуска к запуску адреса переменных плавают))
Автор:  budden [ 22 янв 2018, 11:27 ]
Заголовок сообщения:  Re: ADR и сборщик мусора
Да, я вот как раз думал недавно, что двигать память в контексте paged памяти не нужно. Хотя с другой стороны, в современных процессорах с их кешем, соседство много значит. При выделении памяти есть корреляция: если объекты выделяются почти одновременно, то они и использоваться будут, скорее всего, почти одновременно. Т.е. их имеет смысл класть рядом, и в этом смысле использование free list -ов проигрывает. Хотя для рилтайма это преимущество недоказуемо, т.к. оно носит статистический характер. Надо тебе, чтобы объекты лежали рядом - будь добр сделать это явно. И поскольку маргинальные системы умирают, как я понимаю, обычно через потерю надёжности, то важнее сохранить отлаживаемость. А отлаживаемость при подвижной памяти резко теряется. Вывод: удачно сделано в ББ.

А так вообще, в случайно взятом Обероне, я понимаю, что поведение ADR не гарантировано. Правильно?
Автор:  prospero78su [ 22 янв 2018, 18:22 ]
Заголовок сообщения:  Re: ADR и сборщик мусора
Ну, принято говорить о последнем Обероне без специальной ремарки, или с ремаркой о ранних вариантах.
В последнем Обероне, в переводе репорта которого я тоже успел наследить вообще ничего не говорится о GC, работе с памятью и других грубых механизмах. Всё это отдано на откуп реализации. Касаться физической адресации в Оберонах -- не камильфо. Бывает, что приходится, но если в этом нет такой потребности НА САМОМ ДЕЛЕ -- работа с памятью напрямую скорее говорит о том, что программист не понял, что Оберон -- это не Си))
Автор:  budden [ 22 янв 2018, 19:04 ]
Заголовок сообщения:  Re: ADR и сборщик мусора
Ну, я ещё не совсем разобрался с системой типов Оберона, но в лиспе адрес объекта служит для построения эффективных хеш-таблиц. Думаю, что и в Обероне это может иметь смысл. В этом контексте имеет большой значение, движется он или нет. Ну и для отладки это тоже очень важно. Поскольку в языке со сборщиком мусора я не вижу надёжной защиты от того, что GC может вызваться в любой момент. Поэтому подвижный адрес - это примерно то же, что вообще никакого адреса.
Автор:  vlad [ 22 янв 2018, 19:44 ]
Заголовок сообщения:  Re: ADR и сборщик мусора
prospero78su писал(а):
Наверное, было бы неплохо иметь gc с дефрагментатором памяти. Но на практике уровнем выше ещё есть страничная виртуальная память на уровне оси. После неё особо заморачиваться с дефрагментацией памяти смысла нет.


Дефрагминтация актуальна, как минимум, для 32-битных приложений, когда может не оказаться непрерывного участка виритуальных адресов.
Автор:  budden [ 22 янв 2018, 19:53 ]
Заголовок сообщения:  Re: ADR и сборщик мусора
Я так понимаю, даже если делать массив из миллиарда элементов, на уровне железа он всё равно будет разбит на страницы, поскольку ОС не умеет выделять страницу памяти размером миллиард слов. Поэтому стоит его разбить на страницы уже на уровне рантайм-среды. Мне приходилось встречаться с такой реализацией массивов, хотя она была сделана очень давно и, возможно, для другого железа, чем сейчас используется. Но есть и другие мотивы разбивать огромные объекты на более мелкие. Например, для сборщика мусора желательно помечать куски памяти, которые не изменились со времени прошлой сборки - это позволяет сэкономить что-нибудь. Если массив огромный, то есть большая вероятность, что в нём изменятся только отдельные небольшие части - тогда выигрыш от страничности может быть значительным.

Хотя надо сказать, я далёк от каких-то системных знаний в этой области.
Автор:  vlad [ 22 янв 2018, 20:02 ]
Заголовок сообщения:  Re: ADR и сборщик мусора
prospero78su писал(а):
Ну, принято говорить о последнем Обероне без специальной ремарки, или с ремаркой о ранних вариантах.
В последнем Обероне, в переводе репорта которого я тоже успел наследить вообще ничего не говорится о GC, работе с памятью и других грубых механизмах. Всё это отдано на откуп реализации. Касаться физической адресации в Оберонах -- не камильфо. Бывает, что приходится, но если в этом нет такой потребности НА САМОМ ДЕЛЕ -- работа с памятью напрямую скорее говорит о том, что программист не понял, что Оберон -- это не Си))


Оберон без GC по безопасности падает на уровень Си. Т.е., практического смысла не имеет.
Автор:  Zorko [ 22 янв 2018, 20:34 ]
Заголовок сообщения:  Re: ADR и сборщик мусора
budden писал(а):
А так вообще, в случайно взятом Обероне, я понимаю, что поведение ADR не гарантировано. Правильно?
Мне не попадалась ни одна реализация Оберона, в которой сборщик мусора перемещает данные. И ни одна, которая вызывает сборщик в непредвиденный момент. Наоборот, сборщик вызывается только при очередном выделении памяти по NEW (или SYSTEM.NEW). Так что работа ADR вполне гарантирована. А иначе какой в нём смысл вообще тогда?

Проблемы же с ADR могут возникнуть при работе с полученным адресом после выгрузки модуля, данные которого были размещены по этому адресу. Впрочем, это же касается и указателей на процедуры.
Страница 1 из 4 Часовой пояс: UTC + 2 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/