OberonCore

поскольку добрый компилятор в typedesc записей сохраняет все поля (для неэкспортированых записей/полей они безымянные — ну и что?), то записи на предмет указателей на процедуры можно просканировать без дополнительной информации.

только у меня один глобальный динамический массив куда-то пропал, зараза. вот он был — и вот его не стало. гондолин, вылезай, я тебя видел!

в принципе, задача почти решена (гондолин, падла, выходи!). маркер маркает всё из живых модулей (заодно сканируя глобалы-указатели-на-процедуры). потом свипер проверяет все отмеченые блоки, заглядывая в type tag. если type tag указывает куда-то в память одного из освобождаемых модулей — то всё, приехали. иначе массивы и записи сканируются на предмет наличия указателей-на-процедуры, и оные тоже проверяются. если в результате всех мучений по освобождаемым модулям так и не стукнули — значит, их память можно безопасно релизнуть.

натурально, для записей проверяются тэги всей иерархии «отсюда и вниз» (на всякий случай).

вроде бы вся эта весёлая механика должна работать. эх, Фёдор Васильевич не дожил: он, помнится, хотел эту фичу.

Предложение по UltraPascal: можно добавить тип именованного множества. Может выглядеть так:

Да, я не согласен с позицией Вирта. Множества всё таки не просто битовые поля, а имеют свою семантику. И лучше бы ее выражать явно, а также контролировать компилятором.

ЗЫ. Компилятор для меня слишком сложная штука, иначе давно бы сам добавил.

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

если очень нужно строго контролировать присваиваемые типы, то как раз записи в этом плане отлично помогают. нечто вроде:

теперь мы можем создавать такой тип только этими конструкторами. если сделать его EXTENSIBLE — можно ещё и расширять, не меняя старый код.

точно таким же образом можно обернуть и SET, и что угодно. и определить возможные операции над типом без перегрузки операторов.

так что это тот случай, когда я не вижу необходимости в фиче, которую уже можно реализовать имеющимися средствами.

вообще, строгость стандартной типизации в Обероне — это не про то, чтобы исключить все возможные ошибки программиста. это про то, чтобы исключить фатальные ошибки, при которых можно разрушить систему, нагадив в чужую память, или подобное. плюс записи как универсальный механизм построения любой более сложной контролируемой системы типов, со своим множеством операций.

если рассматривать понятие «строгая типизация» именно в этом аспекте, то становится видно, что язык не нуждается в дополнительных (косметических, замечу) средствах обеспечения типизации: всё учесть невозможно. поэтому есть основа для безопасного (с точки зрения целостности системы) кода, и инструменты для построения более сложных абстракций.

как-то вот так я это вижу.

Естественно не настаиваю.


Вот это уже я не понимаю, зачем. Именованные множества использовал в Ада и F#, и никогда не возникало такой потребности.


Возможно. Я не только про строгую типизацию, но и про удобство чтения программы. Да, то что есть уже работает, но почему бы не сделать чуть лучше?

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

я не вижу особого усиления удобства по сравнению с чем-то типа:

поскольку и CP, и UP позволяют чередовать CONST и TYPE, то объявления можно хранить рядом. читаемость не хуже, чем у отдельной синтаксической конструкции, но без добавления этой конструкции.

а для опускания квалификации имени можно делать реимпорт констант, в UP как раз для этого есть `CONST IMPORT FROM Xyz (a, b, c);`. ;-)

предложения — это нормально, даже хорошо! ;-)

я просто кроме: «нет, не буду» — пытаюсь ещё и пояснить, почему именно не буду, из каких рассуждений исхожу.

сохранение минимализма языка — это довольно весомый фактор. надо что-то очень сильное, чтобы его перебить. в основном это практическая задача, в которой без добавления очень плохо.

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

правда, есть один вариант, когда она будет опасной: если какой-то морон схоронил у себя указатель на `Kernel.Module`: этот указатель untagged, и его никак не проверишь. считаем так, что если кто-то лазит в Kernel, то он понимает, как может развалить систему, и отдаёт себе отчёт в своих трюках. это, тащемта, справедливо для многих ситуаций, не только для выгрузки.

итак, вроде бы работает.

пришлось добавить в OCF скрытую секцию, и заюзать поле `Module.ext` для флажков (оно официально не используется). также подпилить лоадер модулей, чтобы он новую секцию детектил и правильно инитил. модули в старом формате тоже грузятся, но блокируют режим «безопасная выгрузка».

в Kernel добавлений немного, и они портабельны. так что если есть желание — это можно без труда утащить в mainline.

приятная фича фичи (гыг): модули с нулевым количеством ссылок (загруженые через `Dialog.Call()` или через Kernel напрямую) тоже будут тщательно исследованы, и среда не даст их выгрузить, если они где-то реально используются. сейчас это сделать можно, и получим весёлый трап (во многих случаях в нагрузку идёт неработоспособная среда). так что помимо отдачи памяти модуля ОС, мы ещё и имеем более безопасный «выгрузчик».

а ваш BlackBox так умеет? хихи.

p.s.: код немного грязный, немного медленный, и делает некоторые лишние проверки — в том числе на случаи, которые никогда возникнуть не могут. потому что better be safe than sorry.

указатели на процедуры можно проверять консервативно и не нужны никакие модификации компилятора для редких выгрузок (особенно в готовых программах)

а Module.ext вроде используется в cpfront

или вообще рандом кидать. ну, у нас же нет в распоряжении исходников компилятора, чтобы нужную инфу из него добыть. хотя нет, постойте… а ведь есть! ;-)

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

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

откуда почти у всех такая странная фобия по поводу модификаций компилятора-то? никогда мне это не понять. сам Вирт уже открытым текстом говорил, что нет ничего плохого в модификации как языка, так и компилятора под конкретные нужды проекта — а у людей всё фобия.

две Святые Коровы: ядро и компилятор.

тем более в данном случае — вообще просто две дополнительных процедуры в писалке OCF, и всё. после структуры Module можно что угодно совать, это вообще никак не отражается на остальном коде работы с OCF.

а у цпфронт и ядро другое, и ocf там не грузятся. так что совершенно пофигу. и нет, не используется: я ему имя поменял — никто и не квакнул.


p.s.: fun fact. а вы знаете, что `ARRAY OF INTEGER` (и прочие массивы примитивных типов) на самом деле — вовсе даже массивы `ARRAY OF RECORD v: SimpleType END`?

p.p.s.: я, кстати, когда-нибудь не забуду, и сделаю так, чтобы в OCF писали вообще всё. чтобы неэкспортированые записи и неэкспортированые поля в них не были безымянными, например. и про глобалы чтобы всё писали вместе с типами и именами. иба ваистену.

и в связи с прошлым, я подумал такое: если программист на BBCB не лазил ни в ядро, ни в компилятор, ни в views и текстовые модели — то это ненастоящий программист на BBCB. кое-как использовать систему он может, а вот на полную воспользоваться основным преимуществом оберонов — возможностью гибко адаптировать систему под нетипичные задачи силами максимум полутора ленивцев — нет.

очередной конфликт идеологий с мэйнстримом, кстати: «пользуйся даденым и не выпендривайся» vs «вот тебе базовый домик, перестроишь как тебе удобно». впрочем, перестроить под себя какой-нибудь хотя бы дотнет-рантайм — явно нереальная задача для одного человека. кое-как можно прилепить по бокам пару досок Синей Изолентой, но и всё.

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

немного переделал менеджмент свободных кластеров. теперь они сразу уходят в кэш свободных, а GC вызывается, если основные закончились. тогда он собирает фигню, и если не насобирал — берёт из кэша. а кому удалось в кэше просидеть несколько итераций ничего не делая — тот уходит на покой. таким образом пофигу, запускаем ли мы GC периодически, или он приходит когда больше места нет: всё равно через некоторое время свободные кластеры вернут системе.

по дороге обнаружил интересное: даже после того, как я нежно выправил все волшебные числа 12 на `SIZE(ClusterHeader)`, добавление в заголовок поля всё ломает. видимо, где-то таки что-то пропустил. хорошо, что у меня в заголовке кластера свободное поле есть, но такое поведение всё равно фу. надо будет на свежую голову прошерстить код ядра. вроде бы там ну нигде подвязок на 12 быть не должно — а вот… coincidentally, заголовки блоков тоже 12 байт, но это используется ровно в одном месте: `NewArr()`. загадка.

и что характерно: сразу дошло. данные блока должны быть выравнены на 16 байт. а перед блоком всегда сидит type tag. соответственно, добавляем поле — едет выравнивание: код ядра нигде это специально не проверяет. теория подтверждена тем, что при размере заголовка кластера в 28 байт всё работает как часы. щаз попривинчиваю проверки.

заодно почистил (и ещё почищу) DevHeapSpy и DevDebug: зачем там копипасты ядерных структур? лучше из самого ядра высунуть всё нужное уже тогда.

кстати, по ходу зажигательного секса с ядрами наперевес я примерно треть кода там довёл до bitness-agnostic, заменяя везде `S.VAL(INTEGER, …)` (и сами INTEGER) на новые типы ультрапаскаля `S.ADDRESS` и `S.SIZET`, а `S.VAL` на `S.CAST`. второе — это каст с проверкой исходника и размеров, и исключительно в адрес или размерт. лучше простого перекрашивания тем, что при смене битности код тупо откажется компилироваться без правок, а не молча соберётся в какую-нибудь ерунду.

надо ещё позаимствовать из активоберона касты в конкретные типы. точнее, частный случай «каст с увеличением битности». адреса и сайзты не подходят, потому что это перекраска со сторожами (так специально задумано). а нужен каст из инта в инт или из инта в лонг (но не обратно), второй беззнаковый. сейчас такой универсальный беззнаковый каст не сделать. в смысле, в лонг можно, а если результат инт — то никак не превратить операцию в noop, только писать явные уловия с проверкой рамера результирующего типа. а это словесный мусор в данном случае.

в идеале как минимум ядро и мета должны собираться без опции RelaxedAddress. (это опция, которая позваляет VAL для ADDRESS и SIZET, и ослабляет каст-контроль и ass(ign)-control; нужна для «переходного периода»).


и печальное: `SIZE()` отчего-то не триггерит фиксап forward type decl, поэтому размер кластера не получается сделать константой. это, в принципе, можно в компиляторе починить, зафорсив фикс типов при `SIZE()` в константе, если там используется недоопределённый пока тип. ну да, я в курсе, что `SIZE()` не гарантируется в compile-time, и это абьюз конкретной реализации компилера. ничего страшного, просто напишу для ультрапаскаля новые правила на `SIZE()`, делов-то. хорошо, когда и язык тоже форкнул!

тащемта, у нас теперь камни помощнее и побыстрее, так что имеет смысл при определении записи просто отсканировать уже определённые типы, и сразу же починить все `POINTER TO RecDesc`. скорее всего, я даже не буду делать это именно фичей ультрапаскаля: в конце концов, режим Component Pascal в LC предназначен только для сборки старого кода, и не так важно, пропустит ли он что-то, что в CP не разрешено. поскольку LC всё равно не станет основным 2.0, то нет смысла пытаться держать строгую совместимость.

и, кстати, режим совместимости c обероном я уберу, потому что он всё равно толком не работает, и допиливать его мне лениво. как показывает практика, нет ничего сложного в портировании обероновского кода на ультрапаскаль при помощи мешочка матюгов и коробочки регэкспов.

кстати, раз уж я временно с ядром сожительствую… сделать, что ли, потокобезопасный аллокатор/GC? повторять ABB я нужды не вижу, так что попытки рисовать или прочим непотребством из потоков заниматься всё порушат, конечно. но сделать mailbox'ы, и возможность зашедулить action для исполнения в главном потоке — отчего бы и да.

конечно, в идеале хватило бы просто `fork()` и IPC. но есть ма-а-аленькая проблема: безопасный `fork()` невозможен. то есть, в принципе ваще. то есть, возможен, но для этого надо отказаться от всех системных библиотек (включая libc), и делать жёсткий статический бинарь. иначе нет никакой гарантии, что какая-то идиотская библиотека не стартанёт из себя поток — и приехали.

если бы не вышеописаное, то можно было бы просто форкаться, когда нужно, да и всё (а винда идёт в). но имеем что имеем, и иногда потоки полезны. единственная проблема — в пинусах, распронаедрит их напополам, нет никакого аналога виндового `SuspendThread()`. потому что авторы пинусов уверены, что знают все возможные задачи на свете, и среди них нет ни одной, которая потребовала бы такого Очень Небезопасного API. то, что это единственный нормальный способ получить снапшот софтины для GC — их не волнует, потому что о такой задаче в их ПТУ для умственно осталых не рассказывали.

конечно, через задний проход задача решается (в пинусах всё делают через задний проход, чтобы не заскучать). но для этого надо зарезервировать себе один системный сигнал — из двух доступных USR. два. на всё. без какого-либо механизма получить unique signal id. угадайте, есть ли на свете библиотеки, которые уже используют SIGUSR1 и SIGUSR2 для своих целей.

конечно, кому-то в межушный ганглий пришла идея, что софту могут понадобиться свои личные сигналы, и они изобрели real-time signals. зарезервировали номера, и — как полагается — не сделали никаких общих механизмов для резервирования этих номеров в софте. потому что POSIX — это про то, как никогда не надо делать что-то практически полезное.

самое смешное, что в пинусах есть SIGSTOP и SIGCONT… но они тормозят всю софтину сразу. при некоторых условиях ними можно тормознуть и поток, но в принципе нигде не описано толком как, и будет ли это нормально работать.

самое близкое к независимому от сигналов решение — сделать `clone()` (сискол), послать родителю SIGSTOP, просканировать все его потоки, прогнать GC в форке, послать SIGCONT и помереть. отвратительно.

правда, с клоном можно провернуть другую штуку: псевдопараллельный GC. если у нас закончилось место в кластерах, но есть подходящий в кэше свободных — мы пинаем клон на сборку (клонируем в режиме COW), а сами берём свободный кластер и продолжаем. таким образом GC происходит в другом процессе, а когда он закончил — сигнализирует папе, и мы мержим списки свободного места. это я писать не буду, конечно: у меня нет задач, где такое важно.

на самом деле можно вообще сделать инкрементальный GC, чуть-чуть модифицировав компилятор. если использовать quad-color GC вместо классического 3-color, то оно даже будет не очень сильно тормозить. но мне откровенно лень, и я это бесплатно делать не буду. ;-)

p.s.: quad-color GC я уже пилил у себя в одном скриптовом язычке. ну… он работает.

В Modula-3 сборщик мусора с поддержкой многопоточности.

P.S.

Отсутствие поддержки ReactOs и её TUW - "это ошибка, хуже чем..."

Критикую за это GNU Modula-2
И не вижу повода, чтобы не пополнить список...

да сделать-то потокобезопасный аллокатор/GC я могу. вопрос в том, как это сделать красиво, и чтобы оно не добавляло бесполезного overhead для основного однопоточного случая.

вариантов реализации GC очень много, и каждый хорош в некоторой специфической нише. GC в ящике хорош тем, что в большинстве случаев его достаточно, и при этом он очень простой в плане кода. ну да, его можно ускорить, и значительно — но зачем? код станет на несколько порядков сложнее, но выигрыш по времени будет не на порядки, а в лучшем случае в разы, и то на специфических сценариях. мне не надо.

потоки же мне иногда нужны, поэтому я думаю.


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

p.s.: если уж интегрировать поддержку странного — то я лучше гайку интегрирую тогда.

кстати сказать: не вижу ни одной причины, по которой вложеные процедуры, не использующие outer locals, следует трактовать как особенные. сейчас, например, их нельзя передать как процедурный параметр — а почему? что характерно: компилятор-то в курсе, какие вложеные процедуры «чистые», и не генерирует для них context link (EBX).