Ваши идеи хороши, но я полагаю, что есть много тонких проблем, которые потребуют большой работы, и после их решения вы не сможете достичь конкурентоспособной производительности.
каждый поток имеет свое собственное пространство кучи для управления и хранит список принадлежащих ему указателей, которые используются другими потоками. При этом сборка мусора работает полностью асинхронно с запущенными потоками и:
Если существует общий объект, какой поток владеет им?Если к параллельной коллекции добавляются объекты из разных потоков, будет ли много указателей между кучами?Как вы справляетесь с циклами между кучами?
Фаза 1 начинается с корней потоков и помечает все объекты, которые они могут восстановить.Если мы попадаем в пространство другого потока, мы перестаем следовать этому указателю и помечаем этот указатель как «используемый» в потоке владельца
Если это делается одновременно с работающим мутатором, как вы можете предотвратить это?условия гонки, когда мутаторы изменяют топологию, чтобы ввести или исключить ссылки между кучами, пока GC выполняет эту маркировку?
после того, как мы отметили все области, мы выбираем область (возможно, с большинством мертвых ссылокнасколько это возможно), и начните копировать ссылки на живой объект в другое пространство.(это может быть целое пространство кучи потока, но я думаю, что эта операция может потребовать слишком много памяти)
Если это многоядерный процесс, копирование насыщает глобальную пропускную способность памяти и разрушает масштабируемость.
копирование начинается с установки с помощью CAS флага, который указывает, что объект копируется.Любое изменяемое действие, которое будет выполнено с этим конкретным объектом, пока установлен этот флаг, будет блокировать вращение до тех пор, пока потоком gc не будет установлен новый адрес.Когда копирование заканчивается, новый адрес устанавливается на старый, и любая изменяемая ссылка, которая будет выполнена на объекте, будет перенаправлена на новый объект
Без блокировки сложно.Вы делаете предположения о моделях памяти.Вам могут понадобиться барьеры памяти.Похоже, вы просто эмулируете блокировку, и в этом случае вы говорите о получении и освобождении блокировки вокруг каждой записи ссылки в кучу, что будет непомерно дорого.
Спин-блокировки также вредны дляпараллелизм, потому что вы не только связываете поток, но и сжигаете ядро, которое больше не может выполнять работу, которую вы ожидаете!Смотрите ошибку последнее замедление ядра в GHC.Решение без ожидания будет использовать CAS, чтобы поток мутатора помогал с работой GC, а не блокировать ожидание выполнения другим потоком.
после обновления всех ссылок на эти указатели, использующие CAS,старое пространство, наконец, освобождается (новые указатели не будут обновляться с неправильным адресом, так как каждый мутатор сначала проверит, изменилась ли ссылка на места)
Ok.