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

Очень спорное утверждение.

У меня на контроллере stm32 только 32к памяти. Там ничего не выделяется, и ничего не освобождается. Зачем ТАМ -- сборщик мусора?))

Посмотрите на реализацию от Дагаева. Память выделяется только при запуске. Во время работы GC отключается для целей рилтайм. Что-то у него ничего не течёт, не падает и не глючит. Не просто не глючит -- исчезли ранее непобедимые глюки.


Не как минимум. Разбиение памяти на страницы 4к\1М\4М и всё. Дефрагментация бесполезна. Стоящие подряд два блока данных могут оказаться: один в кеше, второй в свопе. Если нет способов управлять режимом работы ЦП.

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

Весь модуль SYSTEM не гарантирован.

Я имел ввиду случай, когда сборщик мусора заменяется ручным DISPOSE.

Дело не в кэше и не в страницах. Дело в том, что твоя прога не сможет выделить массив в 100Mb, при доступных 3Gb, если в этих 3Gb нет свободного участка [addr, addr + 100Mb]. Потому что у тебя адреса в проге 32-битные. И не важно сколько при этом у тебя доступно физической/виртуальной памяти в твоей 64-битной ОС.

> А иначе какой в нём смысл вообще тогда?
А иначе смысл в том, что он постоянен между двумя вызовами сборщика мусора, что SBCL успешно и использует для хеш-таблиц.
> не сможет выделить массив в 100Mb
Я потому и написал про постраничную организацию массивов, и объяснил, какие у них плюсы (с минусами и так ясно).
> Ну, принято говорить о последнем Обероне
Ок.
> сборщик вызывается только при очередном выделении памяти по NEW (или SYSTEM.NEW).
Теоретически обработчик прерывания тоже может выделять память. Или другой тред (в многотредовых системах, возможно, это не про Оберон). Наверное, так не принято и плохо. Но, например, в лиспе можно отправить программе сигнал и вызвать отладчик. А в отладчике можно делать всё. Я не знаю деталей реализации, например, есть реализации с safepoint-ами, т.е. всё же отладчик будет вызван не прямо в любой момент времени. Но всё же довольно сложно утверждать, что в таком-то куске не будет выделения памяти (я говорю про CL).

Ну в общем я так понял, что в целом сборщик НЕ двигает объекты - и это прекрасно.

Мне кажется никто так и непонял зачем тебе на самом деле этот ADDR нужен... Какие хэш таблицы? Чего там лежать будет? Произвольные объекты, которые потом надо лукапить по адресу? Почему по адресу, а не по какому-нибудь более прикладному свойству?

Если памяти достаточно, то надо использовать соответствующую реализацию Оберона. Каждой задаче -- свой инструмент. Не новый язык, а его пропорциональная реализация.


Прога сможет выделить 100 МБ, если они есть. Но никакой прямой связи между адресацией виртуальной памяти и окнах в памяти нет. Этим занимается операционная система.


И, кстати, не только NEW. Загрузка модуля и установление необходимых ссылок на него -- это тоже выделение памяти.


А вот это правильно. Я тоже не пониманию в чём такая крайняя нужда)) Про ADR в Обероне -- надо забыть, если речь не идёт о драйверах, бутсекторе и т.п.

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

Адрес - это уже готовая заготовка для хеш-функции. Тогда объекту не нужно никакое поле для того, чтобы его можно было запихать в хеш-таблицу. Тем самым хеш-таблица позволяет ассоциировать с любым объектом (в т.ч. с чужим объектом) свою произвольную информацию и эффективно её находить. Если ещё и слабые хеш-таблицы, то эта ассоциированная информация автоматически забудется вместе с объектом.

Если адрес движется, то хеш-таблицы нужно перехешировать после каждой сборки мусора или добавлять суррогатный хеш-код - это дороже, сложнее и медленнее работает.

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

Конечно, хеш-таблицы, в т.ч. слабые, должны быть реализованы на системном уровне. Зачем они нужны - для многих вещей. Например, в ClozureCL слово make-hash-table упоминается в 115 файлах. Хеш-таблица в лиспе используется как эффективная реализация отображения.

Так значит, все-таки, оберон - язык под задачу?



Ох. Вот смотри, на пальцах. Для 32-битной реализации:
1. NEW 4 миллиарда объектов размером 1 байт. Адреса всех объектов различаются на 1.
2. Убрали ссылку на каждый 40-й объект. GC собрал 100 миллионов объектов. При этом в памяти у тебя 100 миллионов свободных дырок размером в 1 байт и отстоящих друг от другая ровно на 40 байт.
3. Теперь делаем NEW 1 массив на 100Mb. Недвигающий GC говорит "упс". Двигающий GC собрал все дырки в один непрерывный сегмент 100Mb и смог выделить такой массив.

Т.е., тебе нужен неинтрузивный контейнер произвольных объектов. Ну да, штатными языковыми средствами оберона задача не решается, нужен SYSTEM или специфичный runtime. В толстых шарпах/джавах для этого в базовом Object есть hash code.