Здравствуйте, netch80, Вы писали:

N>Звучит как тяжёлая недоработка конкретных рантаймов.
N>Потому что если он упирается в жёсткий предел памяти, он обязан вызвать полный GC. Но желательно делать инкрементальный и раньше.
N>Мне в этом смысле особенно нравится, как сделано в Lua. По умолчанию — превысили двойной размер после прошлой сборки — запускаем новую. Тяжёлого разрастания без причин там в итоге не бывает, есть чёткое представление, на сколько делать запас.
N>В ранних Java, да, было с этим хуже, там обычно пока операционка не скажет "фиг тебе, а не страничка", не собиралось. Но и то исправили достаточно давно.

N>Я вначале подумал, что вы про случай, когда на какое-то уже ненужное дерево объектов висит забытая ссылка из одного из тех, что должны сейчас жить. Такие вещи, да, диагностируются тяжело, если нет возможности у системы спросить и проитерировать множество вообще всех объектов.
N>Не знаю про типовые реализации JS, но в дотнете, вроде бы, такое есть везде?
Бегло почитал, вроде сейчас GC поумнели и циклические ссылки всегда разруливаются, в JS было по таймеру создание разных объектов ссылающихся друг на друга и на DOM, а в C# на каждое подключение, и плюс там еще с замыканием что то было, давно это было подробностей не помню, GC точно вызывался и отрабатывал, но он не мог убрать эти объекты, искать было трудней чем в С++.

I>>rapidjson, boost, qt5, xerces, xalan, xsec, sqlite, odb, openssl, curl, protobuf, ncreport, zlib, soci, librsync

N>Полный список не знаю, и не могу сказать, кто из них на самом деле покемон, но в пределах моих знаний тут нет проприетарных либ всяких тематических коннекторов, в которых больше всего подобных граблей (на OCI, кажется, только ленивый не ругался).
Это Oracle C++ Call Interface? Хм, не было у нас с ним проблем, правда и запросы были простые, с libpqxx тоже проблем нет, с MySql только через Qt работал, тоже ничего не текло.