Точный режим в Boehm Garbage Collector

Question

Я прочитал на веб-странице Mono, что они используют Boehm GC в точном режиме. Я также использую Boehm GC с C ++, однако я не нашел в его документации или заголовках ничего, что указывало бы на точный режим, тем более, как его включить.

Любая информация, имеет ли он на самом деле точный режим по умолчанию и как его включить, или это была просто какая-то модификация разработчиков Mono?

Answer 1

Точный режим в Boehm GC под Mono - это не просто GC_MALLOC_ATOMIC. Это верно только для массивов фундаментальных типов.

Для управляемых типов используется GC_gcj_malloc. Компилятор Mono генерирует дескриптор объекта для каждого управляемого типа, а затем просто вызывает GC_gcj_malloc с аргументом размера и указателем на дескриптор управляемого типа. Затем Boehm GC обращается к дескриптору во время фазы пометки для отслеживания управляемых указателей.

Вы получите только корневые указатели, находящиеся в стеке как необработанные указатели (GC_gcj_malloc возвращает пустоту *, и нет никакого способа сообщить GC, где находятся указатели в стеке, через какой-то дескриптор стека до собирать) По этой причине Mono (до SGen) говорит, что они сканируют стек в консервативном режиме.

Если вы хотите реализовать это в C ++, вы не сможете просто положиться на компилятор C ++ для генерации дескриптора объекта для вас. Давным-давно я предполагал написать промежуточный компилятор, который анализирует все ваши заголовочные файлы C ++ для определений классов, помеченных как управляемый класс (например, _ref class MyManagedObject, где _ref - это просто #define, равный нулю) и генерирует файл заголовка, содержащий эти дескрипторы объекта. Затем вы будете использовать функции GC_make_descriptor и GC_malloc_explicitly_typed для выделения ваших объектов в точном режиме, а не GC_gcj_malloc, поскольку у вас не будет контроля над тем, как ваш компилятор C ++ выделяет свою vtable.

* РЕДАКТИРОВАТЬ: См. Управляемый C ++ для GCC (GPL с открытым исходным кодом v3) .

Answer 2

Файл doc / gcinterface.html из сборщика мусора ( архив здесь ) сообщает:

void * GC_MALLOC_ATOMIC (size_t nbytes) Выделяет нбайт памяти.Требуется (амортизируется) время, пропорциональное nbytes.Полученный объект будет автоматически освобожден, когда на него нет ссылок.Клиент обещает, что полученный объект никогда не будет содержать указателей.Память не очищается.Это предпочтительный способ выделения строк, массивов с плавающей запятой, растровых изображений и т. Д. Более точная информация о расположении указателей может быть передана сборщику с помощью интерфейса в gc_typed.h в дистрибутиве.

Itпохоже, что есть «точный» интерфейс, который можно использовать.

Answer 3

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

Управляемый язык со встроенным отражением сделает это намного проще.