Я прочитал статью в LinuxJournal о Boehm-Demers-Weiser библиотеке сборщика "мусора". Я интересен использовать его в своей библиотеке вместо моей собственной реализации подсчета ссылок.
У меня есть только один вопрос: действительно ли возможно использовать gc только для моей общей библиотеки и все еще использовать malloc/free в главном приложении? Я, не совсем понимают, как gc проверяет "кучу", таким образом, я волнуюсь о производительности gc в этом случае и возможных побочных эффектов.
Обычно лучше не смешивать выделение памяти со сборкой мусора с системным
malloc
-free
. Если вы это сделаете, вы должны быть осторожны, чтобы не хранить указатели на кучу со сборкой мусора в памяти, выделенной с помощью системыmalloc
.
И более конкретно для C ++:
В случае C ++ нужно быть особенно осторожным, чтобы не хранить указатели на кучу с собранным мусором в областях, которые не отслеживаются сборщиком. Сборщик включает несколько альтернативных интерфейсов , чтобы упростить эту задачу.
Взглянув на исходный код в руководстве, вы увидите, что память со сборщиком мусора обрабатывается посредством определенных вызовов, следовательно, управление осуществляется отдельно (либо сборщиком, либо вручную). Итак, пока ваша библиотека правильно обрабатывает свои внутренние компоненты и не предоставляет собранную память, все должно быть в порядке. Вы не знаете, как другие библиотеки управляют своей памятью, и вы тоже можете их использовать, не так ли? :)
Я считаю, что да, вы можете смешивать эти два варианта: однако если вы выделяете объект с помощью обычного аллокатора, который содержит ссылку на объект, который вы выделяете с помощью аллокатора, собирающего мусор, то эта ссылка не будет видна GC, поэтому объект может быть преждевременно деаллоцирован.
Посмотрите спецификацию функции GC_MALLOC_UNCOLLECTABLE, если вам нужно, чтобы GC учитывал ссылки в памяти, которые не должны собираться.
В общем, да, но здесь водятся драконы, если вы не будете осторожны!