OberonCore

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

а для более хаотичного кода и доступа к данным… а тут больше cache misses уже роялят.

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

естественно, всё это справедливо только для x86, потому что я просто не знаю, как обстоят дела с другими камнями в этом плане. но для BBCB остальные камни пока что совершенно неактуальны. ;-)

так даже на твоем тесте падение производительности на те же ~10%.
Понятно, что если десятки строк кода и одно обращение к массиву, то можно не обращать внимания

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

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

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

p.s.: кстати, и отслеживать источники загрузки модулей через прямые вызовы Kernel. чисто для информации.

В смысле? Комп "молотит", не выключаясь? "Спячка", когда не используется (без присмотра)?

я в принципе технику не выключаю и не усыпляю: это в том числе и личный веб-сервер, и личный почтовый сервер, и всякое другое.

p.s.: именно поэтому мне нужен софт, который может работать минимум месяцами, не течь памятью и не падать. гыг.

(задумался) интересно, а есть какая-то причина, по которой имеет смысл сохранять режим монокластера в memory manager? линукс-версия работает только в мультикластере, и, в общем, нормально себя чувствует.

кстати, а вы в курсе, что reducer'ы имеют смысл только для монокластерного режима? в мультикластере их никто никогда не вызывает.

в принципе, в линуксах тоже можно завести монокластер, если использовать флаг `MAP_NORESERVE`. будет даже проще, потому что получится автокоммит.

из плюсов монокластера то, что он потенциально чуть-чуть быстрее, когда памяти хватает (иначе начинаются танцы с reducer'ами, и будет спайк). а из минусов то, что память системе он никогда не возвращает (а мультикластер довольно активно отдаёт обратно).

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

так что аннигилирую, видимо, все упоминания про монокластер. ненужное — ненужно.

ну, и нюкнул монокластер; заодно упростил интерфейс системного аллокатора. виндоверсия теперь использует `VirtualAlloc()` в мультикластерном режиме. чем меньше в ядре кода — тем меньше в нём ошибок. надеюсь.

ах ты ж едрит твою напополам. чота я не подумал, что блокировать ctrl+c надо бы во всём memory manager — не только при сборе. а то вот удалось удачно сделать ^C прям посреди аллокатора, где евойные структуры тоже стали inconsistent.

кстати, по какой причине free lists идут с шагом 16 байт, и только до 128? надо бы статистику пособирать по этому поводу.

ну и по ходу запилил няшную форму выбора сохранённых десктопов (скорее, проектов) заместо стандартного диалога выбора файла из GTK.

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

и ещё. я страстно возмущён тем, что в стандартной документации нифига не написано, как обрабатывать даблклики на листбоксах, например. о том, что нотифаер получит `(op = Dialog.pressed) & (from = 1)` можно узнать исключительно из исходников, в документации написано, что `from` в этом случае undefined.

а блокировку Ctrl+C для memory manager в виндоверсии решили довольно изящно: просто проверяют PC, и если он внутри модуля Kernel, то делают ничего. жаль, что это не работает в 2.0, потому что там Kernel разделён на две части. хотя в принципе — достаточно добавить ещё проверку на HostKernel, наверное. украду этот код в линукс-обработчик.

кстати, советую сделать то же самое и в mainline.

p.s.: там проверка чуть лучше, на самом деле: Ctrl+C работает только если PC внутри какого-то модуля BBCB. что правильно.

кстати, если кому интересно, то нерекурсивный маркер — это, похоже, Deutsch/Schorr/Waite graph marking algorithm (или что-то по мотивам). он в качестве стека использует поля в заголовке блока, которые по пути наверх (после погружения в дерево) восстанавливает; а свипер потом просто сканирует все кластеры.

блоки в кластере лежат чётко друг за другом, и для сканирования кластера используется маленький хак: первое поле заголовка блока — указатель на type tag. а в type tag первое поле — всегда размер. для свободных блоков tag указывает на следующее поле заголовка, в котором как раз и лежит размер свободного блока. таким образом во-первых, ходилке не надо делать различий между занятыми и свободными блоками, а во-вторых, занятый блок от свободного всегда можно отличить просто проверив, не указывает ли tag на `S.ADR(block.tag) + 4`.

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

нулевой бит в tag используется в маркере: устанавливается маркером для посещённого блока. свипер его сбрасывает обратно. первый бит установлен, если в блоке лежит массив (там тогда немножко другая структура блока).

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

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

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

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

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

само собой, в лучших традициях Оберона по всему Kernel щедрой рукой рассыпаны магические числа. в основном это волшебное число 4 (размер tag), 12 (размер заголовков блоков, и по совместительству размер заголовка кластера), и 19 (которое 16 + 4 - 1 — это потому что тэг в размер блока не входит; используется для выравнивания размеров на 16).

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

собрал простенькую не очень репрезентативную статистику (пересборка всего, и немножко тыканья в гуях). получилось, что омики правы: особого смысла в большем количестве корзинок нет: основное (десятки и сотни тысяч) улетает в корзинки до 64 байт. (а для 64-битной системы, скорее всего, достаточно будет просто бампнуть размеры корзинок с 16 до 32.)

заодно убрал из свипера list reversal: вместо этого сразу делаю списки в правильном порядке.

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

не, можно добавить поле в заголовок кластера, но я не уверен, что везде заменил 12 на правильную константу; а проверять лень и голова болит.

а заодно немного переделал схему выделения: запросы на блоки размеров больше чем размер кластера обрабатываются особенно: такие большие кластеры не участвуют в обычных выделениях памяти.

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

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

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

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

BugReport
---------------
OS: ALT Linux WS 10 64-bit
DE: i3wm
--------------
1. Если открыть текстовый документ и листать его вверх-вниз можно увидеть что потребляемая память _только_ растет.

2. Попытка запуска примера Obx/Open0 приводит к краху системы: FATAL: trap in Kernel. PC=00000000H.

3. Неправильная отрисовка в диалоговых окнах. Связываю с запуском в тайловом оконном менеджере.

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

спасибо. там должен выскакивать модальный диалог открытия файла из GTK, но я где-то лажанул. вообще, режим `ask` в `Views.Old()` толком не поддерживается пока (ни у меня, ни в mainline). тем не менее, падать оно не должно. посмотрю.

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

насчёт полосы прокрутки в диалоге открытия документа: это я, видимо, в скролл-врапере забыл учесть dpi/unit. спасибо, посмотрю.

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

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

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

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

когда эти две штуки решатся — то сканер модулей станет вполне reliable, и будет в состоянии определить, можно ли освободить память выгруженого модуля. proof-of-concept уже работает, правильно детектит использование type tags и глобальных указателей на процедуры.

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

p.s.: да, сканер получается довольно медленный, но вот это меня вообще не парит. идея такая, что его будут звать при попытке выгрузки модуля (или группы модулей). он заодно просканирует и то, что в прошлый раз освободить не вышло. ну, и можно будет пнуть руками. так что нормально, спешить некуда.

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

Проверил. Наперелистывал с 13Мб до 20Мб занятой (allocated) памяти. Подождал 2 часа - размер не уменьшился.
ОБН. Закрытие окна с документом разом освобождает "налистанную" память.

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

ну, и сама среда в стратегических местах вызывает сборщик — как раз когда что-то потенциально большое типа документа исчезает (окно, собственно).

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

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

p.p.s.: ну да, при таких раскладах вероятность возврата кластеров невелика. я забыл, что GC не выскакивает по таймеру просто. надо будет сделать, чтобы выскакивал.