RCU как альтернатива обычной уборке мусора
Read-Copy-Update (RCU) - это метод ручного управления памятью, который становится все более популярным в ядре Linux.
Можно ли спроектировать язык и виртуальную машину, которые используют RCU вместо обычного сборщика мусора для восстановления недоступной памяти?
0 ответов
Возможно ли это: да вроде, ядро Linux - живой пример.
В ядре linux, когда используется RCU, сборка мусора предыдущей версии структуры данных происходит во времяschedule() потому что на этом этапе известно, что все читатели завершили.
Конечно, ядро Linux не имеет сборщика мусора, и восстановление недоступной памяти обычно происходит явным и немедленным образом. Обновление RCU - это особый случай, когда восстановление является явным, но не немедленным.
Возможно ли это для универсальной виртуальной машины, такой как Python или JavaScript: это будет сложно.
- RCU нужен сборщик мусора
- RCU предназначен для рабочих нагрузок, в основном для чтения
- RCU предназначен для коротких критических участков
RCU по-прежнему нужен сборщик мусора; скорее RCU, работающий вместе со сборщиком мусора, в большинстве случаев избегает блокировки, то есть когда критический для чтения раздел завершается без одновременной записи.
Рабочие нагрузки, предназначенные в основном для чтения. Подсчет ссылок особенно трудоемок для записи, настолько, что многопоточная виртуальная машина Python имеет GIL для предотвращения одновременных обновлений refcount, поскольку это повлечет за собой штраф за синхронизацию кеша. Таким образом, требуется какой-то другой метод сборки мусора.
Между тем наивная реализация JavaScript вообще не требует синхронизации, поскольку она однопоточная (хотя можно представить реализацию JavaScript, в которой сборка мусора выгружается в отдельный поток).
Длину критического раздела в виртуальной машине с динамическим языком особенно трудно предсказать из-за постоянного косвенного обращения. Например, рассмотримint(code.replace(" ", "")): int может быть перегружен через __int__, .replace может быть перегружен через свойство, (...) может быть перегружен через __call__. Каждая перегрузка - это код Python, который может занять произвольно много времени. То же самое относится и к встроенным структурам данных, где обновление (последний оператор)c=1; d={c:42}; d[c]=43 может внутренне использовать RCU для чего-то, но это должно быть очень осторожно, потому что c может просто реализовать __hash__ что может занять сколь угодно много времени.
Боюсь, я недостаточно знаю компилируемые языки и их виртуальные машины.
Мне кажется, что новые высокопроизводительные сборщики мусора действительно могут использовать RCU внутри себя, а затем, возможно, предоставить RCU для реализации встроенных структур данных. Я думаю, что ОС может потребоваться предоставить лучший API для привязки выполнения к конкретным ядрам, чтобы извлечь выгоду из локального кеша и / или для запуска пользовательского кода, когда пользовательская область вытесняется.
Хотя это не полный ответ, я надеюсь, что этот расширенный комментарий поможет ограничить исходный вопрос.