OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 17:43

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 17 ] 
Автор Сообщение
СообщениеДобавлено: Вторник, 30 Июнь, 2015 12:06 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 987
Откуда: Казань
Иногда критикуют языки со сборщиком мусора из-за того, что сборщик мусора может вносить непредвиденные задержки в работу программы и это служит оправданием использования других языков, например, C++, где память обычно освобождается в деструкторе.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 30 Июнь, 2015 12:45 

Зарегистрирован: Пятница, 25 Сентябрь, 2009 13:10
Сообщения: 1177
Откуда: Мариуполь
Пометка NIL не избавит сборщик мусора от прохода по дереву записей и от последующей маркировки областей как свободными. Именно этот проход может блокировать дальнейшее выполнение программы. Полагаю, для того чтобы периодическая сборка мусора не сказывалась на работе программы, сборка должна быть равномерно "размазана" по времени.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 30 Июнь, 2015 12:48 

Зарегистрирован: Пятница, 25 Сентябрь, 2009 13:10
Сообщения: 1177
Откуда: Мариуполь
Немного не в тему, но как-то наткнулся на минималистичный аналог 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.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 30 Июнь, 2015 14:28 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 987
Откуда: Казань
Да, уже понял, что глупость написал. Сборщик мусора же проходит по дереву, на которое есть ссылка из программы (глобальные переменные, локальные переменные и т.д.), если же ссылки на дерево нет, то сборщик мусора и не будет проходить по дереву, поэтому обход дерева и присваивание всем ссылкам NIL, ничего кроме дополнительной задержки не даёт.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 30 Июнь, 2015 21:17 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Нуу, тут есть всякие компромиссные пути.

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

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Июль, 2015 10:59 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 987
Откуда: Казань
Если, допустим, под DOM XML память выделять одним большим блоком, а уже внутри этого блока адресовать память отдельно, то получается как бы двухуровневый менеджер памяти, где один уровень - это сборщик мусора и его менеджер памяти, а второй уровень - это менеджер памяти внутри выделенного блока памяти. Получается, что сложность менеджера памяти выходит на прикладной уровень и усложняет программирование.
По хорошему менеджер памяти должен быть только 1, но универсальный, который бы хорошо справлялся и с ситуациями, когда есть много мелких объектов, связанных между собой и нужно их обходить.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Июль, 2015 17:31 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Ну так этот "менеджер памяти" делает один раз разработчик XML-библиотеки.
А Вы пользуетесь.

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


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Июль, 2015 18:48 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Поговаривают, С. Губанов таки ушел на С++


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Июль, 2015 19:47 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
Не получается так, увы...
Даже в Java и C# с самыми навороченными тюнингуемыми сборщикам с поколениями и проч. известен рубеж:
порядка 16Гб ОЗУ при достаточно мелких объектах = >50% процессорного времени на сборку мусора.


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 02 Июль, 2015 20:10 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Блог компании "Одноклассники

Как мы избавились от пауз 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 кэшом приобретает все больше и больше популярности.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 02 Июль, 2015 20:57 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
Блог компании "Одноклассники

Как мы избавились от пауз 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 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Хорошо бы.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Июль, 2015 11:14 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 987
Откуда: Казань
Насколько я понимаю есть два принципиально разных видов сборщиков мусора:
- mark and sweep
- reference counting.
Время работы mark and sweep пропорционально размеру кучу и количеству живых объектов в этой куче.
Reference counting не зависит от размера кучи, может зависеть только от размера удаляемой структуры (например, если есть дерево и количество ссылок на вершину дерева становится 0, то, как я понимаю, должно удалиться все дерево).
Но у reference counting есть недостаток, что он не может удалять циклические структуры.
Если этот недостаток как-нибудь обойти, то думаю, сборщик мусора на основе reference counting был бы быстрее, чем mark and sweep на больших объёмах памяти и с большим количеством объектов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Июль, 2015 11:38 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Есть еще подход с безопасным ручным управлением памятью.

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Июль, 2015 11:46 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 987
Откуда: Казань
Данный подход избавляет только от некоторых проблем, что нельзя будет обратиться к области памяти, если она уже удалена.
Но не избавляет от проблемы утечки памяти, что кто-то может забыть удалить память.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Июль, 2015 11:49 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Ну да. Поэтому GC все же нужен. Но он может выполняться эпизодически, для сборки этих мелких "утечек".
(Собственно, на "Эльбрусах" периодически происходил, если правильно помню и опять не путаю с AS400, процесс сборки мусора, с уплотнением памяти - и перенастройкой адресов).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Июль, 2015 17:01 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Илья Ермаков писал(а):
Например, в старых "Эльбрусах" или IBM AS|400 (вот не помню уже деталей, у кого как именно).

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 17 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB