OberonCore :: - Оберон и ручное управление памятью

Preface
TinyGC is an independent implementation of the API of the well-known Boehm-Demers-Weiser Conservative GC ("BDWGC" or "BoehmGC" for short).
TinyGC has been initially developed as a part of the JCGO project to be used as a BoehmGC replacement. At present, TinyGC is a standalone project.

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

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

Очевидно, что самое эффективное хранилище (в частности кэш) — то, которое всегда находится в оперативной памяти и доступно процессу приложения без какого-либо сетевого взаимодействия. Для приложений, написанных на java, вполне разумным является реализация хранилища тоже на языке программирования java, так как пропадает проблема интеграции. К тому же любой программист, работающий над системой, может легко разобраться в тонкостях его работы, посмотрев исходники. Но так как при большом heap практически любая java программа начинает страдать от пауз GC, то при суммарном размере данных в несколько гигабайт и выше, система становится недееспособной (если только весь Heap это не просто один большой массив байтов). Настройка GC — задача не из тривиальных. Если же ваш heap уже содержит десятки гигабайт, то настроить GС, чтобы паузы были адекватны, для приложения, с которым взаимодействует пользователь, практически нереально. А так как большая оперативная память становится все более и более доступной, то подход с java off-heap кэшом приобретает все больше и больше популярности.

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

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

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

Цитата:

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

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

Автор:	Rifat [ Вторник, 30 Июнь, 2015 12:06 ]
Заголовок сообщения:	Оберон и ручное управление памятью
Иногда критикуют языки со сборщиком мусора из-за того, что сборщик мусора может вносить непредвиденные задержки в работу программы и это служит оправданием использования других языков, например, C++, где память обычно освобождается в деструкторе. Подумал над тем, что, по идее, на Обероне тоже можно программировать в стиле C++. Допустим, есть дерево динамических записей, тогда, когда дерево стало не нужным, можно не просто забыть про этот указатель с целью чтобы сборщик мусора его освободил, а вручную пройти по дереву и изменить все ссылки на NIL, тогда если сборщик мусора сработает, ему не нужно будет проходить все дерево и тем самым сборщик мусора сработает гораздо быстрее.

Автор:	Роман М. [ Вторник, 30 Июнь, 2015 12:45 ]
Заголовок сообщения:	Re: Оберон и ручное управление памятью
Пометка NIL не избавит сборщик мусора от прохода по дереву записей и от последующей маркировки областей как свободными. Именно этот проход может блокировать дальнейшее выполнение программы. Полагаю, для того чтобы периодическая сборка мусора не сказывалась на работе программы, сборка должна быть равномерно "размазана" по времени.

Автор:	Роман М. [ Вторник, 30 Июнь, 2015 12:48 ]
Заголовок сообщения:	Re: Оберон и ручное управление памятью
Немного не в тему, но как-то наткнулся на минималистичный аналог Boehm GC, именуемый TinyGC Цитата: Preface TinyGC is an independent implementation of the API of the well-known Boehm-Demers-Weiser Conservative GC ("BDWGC" or "BoehmGC" for short). TinyGC has been initially developed as a part of the JCGO project to be used as a BoehmGC replacement. At present, TinyGC is a standalone project.

Автор:	Rifat [ Вторник, 30 Июнь, 2015 14:28 ]
Заголовок сообщения:	Re: Оберон и ручное управление памятью
Да, уже понял, что глупость написал. Сборщик мусора же проходит по дереву, на которое есть ссылка из программы (глобальные переменные, локальные переменные и т.д.), если же ссылки на дерево нет, то сборщик мусора и не будет проходить по дереву, поэтому обход дерева и присваивание всем ссылкам NIL, ничего кроме дополнительной задержки не даёт.

Автор:	Илья Ермаков [ Вторник, 30 Июнь, 2015 21:17 ]
Заголовок сообщения:	Re: Оберон и ручное управление памятью
Нуу, тут есть всякие компромиссные пути. Если экономно мусорить (ну, там всякие строки в куче не выделять, какие-нибудь XML-и держать не в DOM-е, а на линейных буферах с навигационным доступом - т.е. перемещаем Reader по узлам, ну и т.п.), и всякие мелкие объекты использовать повторно через пулы - то можно добиться, что либо вообще почти память не утекает, либо утекает с какой-то известной небольшой скоростью (допустим, N мегабайт в час). Тогда даже и во многих РВ-системах можно подобрать момент, видимо, когда stop-the-world на определенный краткий период допустим. Ну, вообще есть алгоритмы сборки и без stop-the-world. Кроме того, если мы не мусорим обломками структур данных (как я описал выше - используем навигационные интерфейсы к структурам данным), то резко уменьшаем количество объектов, подлежащих обходу сборщиком. Обойти список страниц двоичного буфера, в котором лежит какой-нибудь XML, доступный навигационно - это не то же самое, что обойти его DOM-дерево, где каждый атрибут - это объект... Не буду говорить за РВ, ибо у меня нет соответствующего серьёзного опыта. Но в системах массового обслуживания значительно уменьшить нагрузку на менеджер памяти и сборку таким образом можно.

OberonCore https://forum.oberoncore.ru/

Оберон и ручное управление памятью https://forum.oberoncore.ru/viewtopic.php?f=86&t=5446	Страница 1 из 1

Автор:	Rifat [ Среда, 01 Июль, 2015 10:59 ]
Заголовок сообщения:	Re: Оберон и ручное управление памятью
Если, допустим, под DOM XML память выделять одним большим блоком, а уже внутри этого блока адресовать память отдельно, то получается как бы двухуровневый менеджер памяти, где один уровень - это сборщик мусора и его менеджер памяти, а второй уровень - это менеджер памяти внутри выделенного блока памяти. Получается, что сложность менеджера памяти выходит на прикладной уровень и усложняет программирование. По хорошему менеджер памяти должен быть только 1, но универсальный, который бы хорошо справлялся и с ситуациями, когда есть много мелких объектов, связанных между собой и нужно их обходить.

Автор:	Илья Ермаков [ Среда, 01 Июль, 2015 17:31 ]
Заголовок сообщения:	Re: Оберон и ручное управление памятью
Ну так этот "менеджер памяти" делает один раз разработчик XML-библиотеки. А Вы пользуетесь. Цитата: По хорошему менеджер памяти должен быть только 1, но универсальный, который бы хорошо справлялся и с ситуациями, когда есть много мелких объектов, связанных между собой и нужно их обходить. Не получается так, увы... Даже в Java и C# с самыми навороченными тюнингуемыми сборщикам с поколениями и проч. известен рубеж: порядка 16Гб ОЗУ при достаточно мелких объектах = >50% процессорного времени на сборку мусора. Этот факт отмечали и разработчики "Одноклассников", и наш тут участник форума Сергей Губанов (который разрабатывает на Шарпе ПО для АТС-ок с миллионами абонентов). Губанов вон постоянно вынужден изобретать ручное распределение всяческих строк, буферов и проч.

Автор:	Пётр Кушнир [ Среда, 01 Июль, 2015 18:48 ]
Заголовок сообщения:	Re: Оберон и ручное управление памятью
Поговаривают, С. Губанов таки ушел на С++

Автор:	Alexey Veselovsky [ Среда, 01 Июль, 2015 19:47 ]
Заголовок сообщения:	Re: Оберон и ручное управление памятью
Илья Ермаков писал(а): Не получается так, увы... Даже в Java и C# с самыми навороченными тюнингуемыми сборщикам с поколениями и проч. известен рубеж: порядка 16Гб ОЗУ при достаточно мелких объектах = >50% процессорного времени на сборку мусора. Откуда этот предел известен, можно источник? Ну и пруф для java. PS. У Губанова, когда он еще писал на С# проблемы были как раз на тупом mono'вском сборщике мусора. На навороченном .net'ом проблем не было. И уж тем более на java проблем будет на порядок меньше, чем на C#, ибо java, в отличие от .net под такие применения затачивалась и затачивается. На эту тему у оракла даже патенты имеются.

Автор:	Илья Ермаков [ Четверг, 02 Июль, 2015 20:10 ]
Заголовок сообщения:	Re: Оберон и ручное управление памятью
Блог компании "Одноклассники Как мы избавились от пауз GC с помощью собственного java off-heap storage решения http://habrahabr.ru/company/odnoklassniki/blog/139185/ http://habrahabr.ru/company/odnoklassniki/blog/148139/ Цитата: Очевидно, что самое эффективное хранилище (в частности кэш) — то, которое всегда находится в оперативной памяти и доступно процессу приложения без какого-либо сетевого взаимодействия. Для приложений, написанных на java, вполне разумным является реализация хранилища тоже на языке программирования java, так как пропадает проблема интеграции. К тому же любой программист, работающий над системой, может легко разобраться в тонкостях его работы, посмотрев исходники. Но так как при большом heap практически любая java программа начинает страдать от пауз GC, то при суммарном размере данных в несколько гигабайт и выше, система становится недееспособной (если только весь Heap это не просто один большой массив байтов). Настройка GC — задача не из тривиальных. Если же ваш heap уже содержит десятки гигабайт, то настроить GС, чтобы паузы были адекватны, для приложения, с которым взаимодействует пользователь, практически нереально. А так как большая оперативная память становится все более и более доступной, то подход с java off-heap кэшом приобретает все больше и больше популярности.

Автор:	Alexey Veselovsky [ Четверг, 02 Июль, 2015 20:57 ]
Заголовок сообщения:	Re: Оберон и ручное управление памятью
Илья Ермаков писал(а): Блог компании "Одноклассники Как мы избавились от пауз GC с помощью собственного java off-heap storage решения http://habrahabr.ru/company/odnoklassniki/blog/139185/ http://habrahabr.ru/company/odnoklassniki/blog/148139/ Цитата: Очевидно, что самое эффективное хранилище (в частности кэш) — то, которое всегда находится в оперативной памяти и доступно процессу приложения без какого-либо сетевого взаимодействия. Для приложений, написанных на java, вполне разумным является реализация хранилища тоже на языке программирования java, так как пропадает проблема интеграции. К тому же любой программист, работающий над системой, может легко разобраться в тонкостях его работы, посмотрев исходники. Но так как при большом heap практически любая java программа начинает страдать от пауз GC, то при суммарном размере данных в несколько гигабайт и выше, система становится недееспособной (если только весь Heap это не просто один большой массив байтов). Настройка GC — задача не из тривиальных. Если же ваш heap уже содержит десятки гигабайт, то настроить GС, чтобы паузы были адекватны, для приложения, с которым взаимодействует пользователь, практически нереально. А так как большая оперативная память становится все более и более доступной, то подход с java off-heap кэшом приобретает все больше и больше популярности. 2012 год. Еще до нового патентованного сборщику мусора. Подобные утверждения нужно постоянно перепроверять. Скорее всего это уже просто не так. Нужно поставить эксперимент.

Автор:	Илья Ермаков [ Пятница, 03 Июль, 2015 06:35 ]
Заголовок сообщения:	Re: Оберон и ручное управление памятью
Хорошо бы. Однако видел лекции и 2014 года (сейчас не нашел с ходу, по-моему, на Лекториуме) "финансистов", которые молотят биржевые данные на Java - т.е. являются поставщиками первичных потоков заинтересованным потребителям (Java в их сегменте корп. стандарт без вариантов). Все основные структуры данных - на массивах и ссылках по индексам. Иначе, опять же, пролетают в реальном времени, если не управлять вручную.

Автор:	Rifat [ Пятница, 03 Июль, 2015 11:14 ]
Заголовок сообщения:	Re: Оберон и ручное управление памятью
Насколько я понимаю есть два принципиально разных видов сборщиков мусора: - mark and sweep - reference counting. Время работы mark and sweep пропорционально размеру кучу и количеству живых объектов в этой куче. Reference counting не зависит от размера кучи, может зависеть только от размера удаляемой структуры (например, если есть дерево и количество ссылок на вершину дерева становится 0, то, как я понимаю, должно удалиться все дерево). Но у reference counting есть недостаток, что он не может удалять циклические структуры. Если этот недостаток как-нибудь обойти, то думаю, сборщик мусора на основе reference counting был бы быстрее, чем mark and sweep на больших объёмах памяти и с большим количеством объектов.

Автор:	Rifat [ Пятница, 03 Июль, 2015 11:46 ]
Заголовок сообщения:	Re: Оберон и ручное управление памятью
Данный подход избавляет только от некоторых проблем, что нельзя будет обратиться к области памяти, если она уже удалена. Но не избавляет от проблемы утечки памяти, что кто-то может забыть удалить память.

Страница 1 из 1	Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/

Автор:	Борис Рюмшин [ Пятница, 03 Июль, 2015 17:01 ]
Заголовок сообщения:	Re: Оберон и ручное управление памятью
Илья Ермаков писал(а): Например, в старых "Эльбрусах" или IBM AS\|400 (вот не помню уже деталей, у кого как именно). 128-бит адресное пространство позволяет выделять неповторяющиеся указатели. И при освобождении никогда уже не сможете обратиться по этому адресу и разрушить память. AS/400 и адресное пространство там 64-битное ("одноуровневая память" - все объекты, в том числе и хранимые на дисках, в этом пространстве).