2

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

Мне нужно это, чтобы я мог сканировать стек для корней (указатели), и мой текущий подход заключается в том, чтобы сохранить указатель стека при вводе нового потока и при вводе main(), а затем сохранить его снова для каждого потока при запуске сборки мусора, используя глобальную блокировку.

(я знаю, что этот подход не является идеальным в долгосрочной перспективе, поскольку она вызывает ненужную блокировку, но сейчас это приемлемо, пока основы не вверх)

Но я действительно хотел бы иметь более " безопасный "способ обнаружения границ, потому что для корней очень легко« убежать »от этого механизма (в зависимости от реализации потока - pthreads легко управлять, но не так с OpenMP или Grand Central Dispatch).

Было бы еще более устрашающе, если бы был переносной способ сделать это, но я не ожидаю, что так будет. В настоящее время я работаю над Mac OS X 10.6, но ответы на любую платформу приветствуются.

ответ

1

Вы можете использовать механизм VM для защиты от записи конца стека и расширения на ловушку записи VM. Тогда вы узнаете границу стека на странице стека.

Но я не уверен, что я согласен с тем, что просто проверяю текущее значение SP для существующего потока *, если вы сделаете предположение о «большом стеке» *, обычно принимаемое небольшим числом -только параллелизм сообщества.

См. this SO article для обсуждения мировой модели, где у вас нет «больших стеков». Тогда вы не можете создать GC, который просто сканирует «стек», потому что это куча, выделенная по требованию (например, запись функции). Теперь вам нужно отсканировать все сегменты стека, которые могут быть живыми.

+0

Благодарим вас за этот ввод. Ваше предложение использовать ловушки для записи в виртуальную память умное, но вы, вероятно, правы, что это необязательно. Кроме того, он будет работать только при выращивании стека, а не при уменьшении требуемого пространства стека, что делает его непригодным для целей GC (так как это приведет к утечке большого количества неиспользуемых корней). В основном меня беспокоят потоковые реализации, которые делают разные предположения о макете и размере стека, но вполне возможно, что мои опасения необоснованны. –

+0

Реализации потоков не имеют большого выбора, учитывая линейные адресные пространства. Каждый поток должен быть запущен с некоторым фиксированным размером максимального линейного количества стека. И Linux, и MS делают это, с (предварительным) распределением типично 1Mb (установленным по умолчанию в объектном файле), но любая вилка потока может указывать сумму. Случай, который мне интересен, заключается в том, что преалоляция мала, а вызовы функций выделяют * новые * линейные сегменты фрейма стека непоследовательно относительно стека вызывающего. Тогда простая линейная проверка «стека» не может работать, потому что есть много кусков. –