OberonCore

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

Подумал над тем, что, по идее, на Обероне тоже можно программировать в стиле C++. Допустим, есть дерево динамических записей, тогда, когда дерево стало не нужным, можно не просто забыть про этот указатель с целью чтобы сборщик мусора его освободил, а вручную пройти по дереву и изменить все ссылки на NIL, тогда если сборщик мусора сработает, ему не нужно будет проходить все дерево и тем самым сборщик мусора сработает гораздо быстрее.

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

Немного не в тему, но как-то наткнулся на минималистичный аналог Boehm GC, именуемый TinyGC

Да, уже понял, что глупость написал. Сборщик мусора же проходит по дереву, на которое есть ссылка из программы (глобальные переменные, локальные переменные и т.д.), если же ссылки на дерево нет, то сборщик мусора и не будет проходить по дереву, поэтому обход дерева и присваивание всем ссылкам NIL, ничего кроме дополнительной задержки не даёт.

Нуу, тут есть всякие компромиссные пути.

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

Тогда даже и во многих РВ-системах можно подобрать момент, видимо, когда stop-the-world на определенный краткий период допустим. Ну, вообще есть алгоритмы сборки и без stop-the-world.

Кроме того, если мы не мусорим обломками структур данных (как я описал выше - используем навигационные интерфейсы к структурам данным), то резко уменьшаем количество объектов, подлежащих обходу сборщиком.
Обойти список страниц двоичного буфера, в котором лежит какой-нибудь XML, доступный навигационно - это не то же самое, что обойти его DOM-дерево, где каждый атрибут - это объект...

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

Если, допустим, под DOM XML память выделять одним большим блоком, а уже внутри этого блока адресовать память отдельно, то получается как бы двухуровневый менеджер памяти, где один уровень - это сборщик мусора и его менеджер памяти, а второй уровень - это менеджер памяти внутри выделенного блока памяти. Получается, что сложность менеджера памяти выходит на прикладной уровень и усложняет программирование.
По хорошему менеджер памяти должен быть только 1, но универсальный, который бы хорошо справлялся и с ситуациями, когда есть много мелких объектов, связанных между собой и нужно их обходить.

Ну так этот "менеджер памяти" делает один раз разработчик XML-библиотеки.
А Вы пользуетесь.



Не получается так, увы...
Даже в Java и C# с самыми навороченными тюнингуемыми сборщикам с поколениями и проч. известен рубеж:
порядка 16Гб ОЗУ при достаточно мелких объектах = >50% процессорного времени на сборку мусора.

Этот факт отмечали и разработчики "Одноклассников", и наш тут участник форума Сергей Губанов (который разрабатывает на Шарпе ПО для АТС-ок с миллионами абонентов). Губанов вон постоянно вынужден изобретать ручное распределение всяческих строк, буферов и проч.

Поговаривают, С. Губанов таки ушел на С++

Откуда этот предел известен, можно источник? Ну и пруф для java.

PS. У Губанова, когда он еще писал на С# проблемы были как раз на тупом mono'вском сборщике мусора. На навороченном .net'ом проблем не было. И уж тем более на java проблем будет на порядок меньше, чем на C#, ибо java, в отличие от .net под такие применения затачивалась и затачивается. На эту тему у оракла даже патенты имеются.

Блог компании "Одноклассники

Как мы избавились от пауз GC с помощью собственного java off-heap storage решения
http://habrahabr.ru/company/odnoklassniki/blog/139185/

http://habrahabr.ru/company/odnoklassniki/blog/148139/

2012 год. Еще до нового патентованного сборщику мусора. Подобные утверждения нужно постоянно перепроверять. Скорее всего это уже просто не так.

Нужно поставить эксперимент.

Хорошо бы.

Однако видел лекции и 2014 года (сейчас не нашел с ходу, по-моему, на Лекториуме) "финансистов", которые молотят биржевые данные на Java - т.е. являются поставщиками первичных потоков заинтересованным потребителям (Java в их сегменте корп. стандарт без вариантов).

Все основные структуры данных - на массивах и ссылках по индексам. Иначе, опять же, пролетают в реальном времени, если не управлять вручную.

Насколько я понимаю есть два принципиально разных видов сборщиков мусора:
- mark and sweep
- reference counting.
Время работы mark and sweep пропорционально размеру кучу и количеству живых объектов в этой куче.
Reference counting не зависит от размера кучи, может зависеть только от размера удаляемой структуры (например, если есть дерево и количество ссылок на вершину дерева становится 0, то, как я понимаю, должно удалиться все дерево).
Но у reference counting есть недостаток, что он не может удалять циклические структуры.
Если этот недостаток как-нибудь обойти, то думаю, сборщик мусора на основе reference counting был бы быстрее, чем mark and sweep на больших объёмах памяти и с большим количеством объектов.

Есть еще подход с безопасным ручным управлением памятью.

Например, в старых "Эльбрусах" или IBM AS|400 (вот не помню уже деталей, у кого как именно).

128-бит адресное пространство позволяет выделять неповторяющиеся указатели. И при освобождении никогда уже не сможете обратиться по этому адресу и разрушить память.

Можно сымитировать и меньшем адресном пространстве, с некоторыми ухищрениями на уровне компилятора и при хранении доп. меток внутри указателя вместе с адресом.

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

Ну да. Поэтому GC все же нужен. Но он может выполняться эпизодически, для сборки этих мелких "утечек".
(Собственно, на "Эльбрусах" периодически происходил, если правильно помню и опять не путаю с AS400, процесс сборки мусора, с уплотнением памяти - и перенастройкой адресов).

AS/400 и адресное пространство там 64-битное ("одноуровневая память" - все объекты, в том числе и хранимые на дисках, в этом пространстве).