Механизм сборщика мусора Boehm Weiser

Question

Я читал газету «Сборщик мусора в неблагополучной среде» и задавался вопросом, насколько сложно будет ее реализовать. В статье описывается необходимость сбора всех адресов с процессора (кроме стека). Часть стека кажется интуитивно понятной. Есть ли способ собрать адреса из регистров, кроме явного перечисления каждого регистра в сборке? Давайте предположим, что x86_64 в POSIX-подобной системе, такой как linux или mac.

SetJmp

Answer 1

Поскольку Бем и Вайзер фактически внедрили свой GC , то основным источником информации является исходный код этой реализации (это с открытым исходным кодом).

Чтобы собрать значения регистров, вы можете захотеть отключить функцию setjmp(), которая сохраняет копию регистров в пользовательской структуре (по крайней мере, те регистры, которые должны сохраняться при вызовах функций). Но эта структура не стандартизирована (ее содержимое номинально непрозрачно), и setjmp() может быть специально обработан компилятором C, что делает его немного деликатным для использования для всего, кроме longjmp() (что уже довольно сложно, так как ). Часть встроенной сборки кажется намного проще и безопаснее.

Первая сложная часть в реализации GC, похоже, способна надежно определять начало и конец стеков (обратите внимание на множественное число: могут быть потоки, каждый со своим собственным стеком). Это требует углубления в плохо документированные детали ОС ABI. Когда моя настольная система представляла собой компьютер Alpha с FreeBSD, реализация Boehm-Weiser не могла работать на ней (хотя она поддерживала Linux на том же процессоре).

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

Answer 2

Нетрудно реализовать наивный сборщик: в конце концов, это всего лишь алгоритм. Жесткие биты такие же, как указано, но я добавлю худшие: отслеживание исключений - это неприятно, а остановка потоков - еще хуже: на некоторых платформах это вообще невозможно сделать. Также существует проблема с перехватом всех указателей, которые временно передаются в ОС и временно теряются из программы (часто происходит в обработчиках сообщений Windows).

Мой собственный многопоточный GC похож на сборщик Boehm и более или менее стандартный C ++ с небольшим количеством хаков (использование jmpbuf более или менее обязательно работает) и немного менее агрессивной средой (без исключений). Но это останавливает мир благодаря сотрудничеству, что очень плохо: если у вас занятый процессор, то простаивают его. Boehm использует сигналы или другие функции ОС, чтобы попытаться остановить потоки, но поддержка очень слабая.

И обратите внимание также, что процессор Intel i64 имеет два стека на поток ... довольно сложно объяснить такие вещи в общем.

Answer 3

Я думаю, что на x86_86 они используют инструкцию сборки flushrs для помещения регистров в стек.Я уверен, что кто-то из переполнения стека исправит меня, если это не так.