OberonCore

Использую BlackBox 1.6 rc6.
Написал такой модуль:


Собираю exe файл при помощи команды:
DevLinker.LinkExe Test.exe := Sample~
Генерируется exe файл размером почти в 2 мегабайта.

Кто-нибудь может объяснить почему так происходит?

"Смерд на выдумки горазд" (с)

-------
Пож., не обижайтесь на "смерда".

Размер связан не с EXE, а с самим модулем. Посмотрите на размер OCF.

Происходит следующее.
Для любого RECORD компилятор кладёт в дескриптор типа информацию о смещениях указателей в этой записи. Эта информация потом используется при сборке мусора, отладке и т.п.

При этом в дескриптор добавляются смещения и всех подэлементов. Т.е. вообще - позиции, на которых в экземпляре данной записи находятся указатели.

Таким образом, для Вашей записи сгенерировано 500000 пунктов. * 4 - как раз 2 Мб. Размер дескриптора типа.

Используйте поле POINTER TO ARRAY.

Попробовал сделать с помощью POINTER TO ARRAY, размер стал гораздо меньше.
Хотелось бы конечно, чтобы компилятор автоматически распознавал такую ситуацию и не генерировал для каждого указателя запись.

А как он должен поступать ещё?

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

Ситуация-то ненормальная с таким массивом, зафигаченным в поле.

Если я определяю тип
p = POINTER TO ARRAY 500000 OF some_pointer;
то компилятор не генерирует большой exe файл. Конечно, когда выполнится оператор NEW(p) то выделиться память под массив и под дополнительную информацию.

Когда я пишу
r = POINTER TO RECORD a: ARRAY 500000 OF some_pointer; END;
то я ожидаю, что компилятор не будет генерировать большой exe файл (а он почему-то генерирует большой файл), а когда я выполню NEW(r), то выделиться память под массив и под дополнительную информацию.

До этого случая я считал, что те две записи, которые я привел, почти эквиваленты, за исключением того, что в первом случае надо будет обращаться к элементу как p[i], а во втором, как r.a[i].
Возможно я не понимаю какой-то принципиальной разницы между POINTER TO ARRAY и POINTER TO RECORD.

Тут надо понимать, что с точки зрения времени выполнения есть понятие "объект в куче". Указатели указывают на такие "объекты в куче".

Объекты в куче делятся на два вида: динамические массивы и записи.
Сборщик мусора для массивов смотрит, есть в элементах массива указатели. Если да, то обходит каждый элемент.
В случае для записи сборщик обращается к её описателю типа, в котором есть список всех позиций, на которых в экземпляре записи лежат указатели. И идёт по этим указателям.

В Вашем первом варианте у Вас нет массива в куче. У Вас в куче лежит именно огромная запись.
Следовательно, работает вторая схема. Которая требует, чтобы для данной записи компилятор поместил в дескриптор типа список указательных позиций (которых 500 тыс.). А дескриптор типа - это статический объект. Помещаемый в кодовый файл модуля (и напрямую копируемый потом в память). Вот он и кушает память.

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

Да, кое-что на быструю руку сделано. А кое-что вообще с ОС Оберон идёт.

GC вообще, насколько я смотрел, даже и в Бутылке совпадает с Блэкбоксовым почти 1-к-1.