Сборщик мусора, который будет работать вне моего приложения?

Итак, я ищу кроссплатформенную библиотеку с открытым исходным кодом (по крайней мере, win, lin), которая будет выполнять сборку мусора в каком-то абстрактном потоке / процессе C ++ ... Так сказать, отдельный процесс для управления памятью приложения ... или, по крайней мере, представит я с некоторыми функциями для удаления неиспользуемой памяти просматриваю мой процесс ... Есть ли такие? Может Boost мне в этом поможет?

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

Итак, позвольте мне описать проблему немного подробнее: у меня есть код, который работает и, как правило, сам все управляет. но время от времени он просто помещает 2-3 МБ в память и никогда не пытается использовать ее - я знаю, что это не так - я все-таки написал код ... вот почему мне нужны некоторые поверх моего приложения gc. ..


person Rella    schedule 07.12.2010    source источник
comment
Зачем вам сборщик мусора? Хотя для C ++ существуют сборщики мусора, большая часть кода C ++ написана с предположением, что сборка мусора отсутствует. Не будет сборщика мусора для C ++, который вы можете просто вставить в код C ++ и ожидать, что он заработает из коробки.   -  person In silico    schedule 08.12.2010
comment
Кроме того, этот вопрос является возможным дубликатом сборщиков мусора для C ++.   -  person In silico    schedule 08.12.2010
comment
@In Silico: требование OP о том, чтобы он работал в произвольном потоке или процессе, имеет большое значение. Это не обман.   -  person Puppy    schedule 08.12.2010
comment
@DeadMG: Ой, я это пропустил.   -  person In silico    schedule 08.12.2010
comment
На мой взгляд, умные указатели - это просто мелкозернистая сборка мусора (детерминированная).   -  person Martin York    schedule 08.12.2010
comment
Накладные расходы на введение в ваш код чего-то вроде сборщика мусора по сравнению с запуском инструмента, предназначенного для обнаружения проблем с памятью, для меня это не проблема - используйте valgrind (или, если у вас есть деньги, Purify). Устраните утечку и забудьте о сложностях!   -  person Nim    schedule 08.12.2010
comment
Почему вы продолжаете создавать сложные механизмы, чтобы обойти то, что очевидно является ошибкой в ​​вашей программе?   -  person John Dibling    schedule 08.12.2010
comment
@Kab Сегодня вы задали более ранний вопрос об использовании потоков для уменьшения утечек памяти, что, конечно, не имело никакого смысла. Тогда совет - это совет сейчас: исправьте утечку памяти. И что это за одержимость Boost ?! Это ваш третий вопрос сегодня об использовании Boost для обработки утечек памяти.   -  person chrisaycock    schedule 08.12.2010


Ответы (3)


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

person Rob K    schedule 07.12.2010

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

person Puppy    schedule 07.12.2010
comment
По крайней мере, этот вопрос лучше, чем его предыдущий: stackoverflow.com/questions/4380324/ - person chrisaycock; 08.12.2010

Вы можете попробовать сборщик мусора с консервативной маркировкой Boehm:

http://www.hpl.hp.com/personal/Hans_Boehm/gc/

Я никогда не использовал его сам, но если вы можете заставить ваш целевой поток / процесс связать его функцию выделения и функцию, не требующую ничего делать, у вас может быть шанс. Детали динамического связывания, конечно, зависят от платформы.

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

Вероятно, лучше исправить утечки памяти в вашем коде C ++ ;-p Большинство библиотек C ++ и т. Д. Написаны с предположением, что вы будете использовать типичные методы C ++ для управления ресурсами, и они не обязательно будут хорошо работать с GC.

person Steve Jessop    schedule 07.12.2010