#системное_программирование — Public Fediverse posts

Память в GoOS, часть 2. Нативные потоки, горутины и GC на SMP

Как я рассказывал в первой части, реализация работы с памятью - довольно непростое занятие, и в первой части я рассказывал про сравнительно лёгкую область этой работы. Пока процесс однопоточный, сборщик мусора имеет дело с одним стеком, одним набором регистров и одной точкой выполнения. Как только появляется второй поток, он уже может одновременно менять кучу на другом процессорном ядре. А после появления горутин выполнение Go-кода вообще перестаёт быть жёстко связано с одним стеком нативного потока. В релизе GoOS 0.2.8 сначала появились нативные потоки пользовательского пространства, а затем поверх них — собственный M:N runtime для горутин. После этого задача сборщика мусора стала заметно неприятнее: перед освобождением объекта нужно быть уверенным, что ссылка на него не осталась в стеке другого потока, в сохранённом контексте горутины, в XMM-регистре или в промежуточном состоянии переключения контекста. Это уже не только задача GC. Здесь пересекаются планировщик, аллокатор, ABI, TLS, виртуальная память и код сохранения регистров.

https://habr.com/ru/articles/1099166/

#go #gc #системное_программирование #многопоточность #планировщик #golang #горутины #runtime #сборщик_мусора #goos

CactOS 2.0.0: последний релиз x86_32

CactOS — гибридное монолитное ядро для i686 на C и Rust. В 2.0.0: ABI сокращён с 95 сисколлов до 15, модули подписываются ECDSA P-256 с vermagic-отпечатком, VFS переписан на Rust, добавлен энергогоvernor для SMP с per-core runqueues. Suspend вырезан из-за ненадёжного resume. Репозиторий x86_32 уходит в архив после тега v2.0.0.

https://habr.com/ru/articles/1099176/

#osdev #системное_программирование

Память в GoOS, часть 1. От bump allocator к собственному heap и GC

В первой статье про GoOS я довольно подробно прошёлся по загрузке, SMP, IPC, capabilities, сети, Linux ABI и устройству сервисов. А в комментариях довольно быстро всплыл вопрос, который я тогда сознательно обошёл стороной: что в системе происходит с динамической памятью и сборщиком мусора. Вопрос был вполне по делу. Я пишу ОС преимущественно на Go, компилирую её TinyGo, но обычный Go runtime мне тут никто не выдаёт. Значит, фраза «Go сам разберётся с памятью» тут совершенно не работает. Кто-то должен дать new , make , слайсам, map, channel и остальным объектам кучу. Кто-то должен вернуть память после того, как объект перестал быть нужен. А если в системе появляется GC , он должен понимать, где искать корни, как останавливаться относительно потоков и что делать с указателями, которые в момент остановки лежат не на стеке, а в регистрах процессора. На момент той дискуссии ответ был сильно проще. Ядро было и остаётся собрано TinyGo с gc: leaking : его Go-куча умеет только выделять. В повторяющихся путях ядра динамические аллокации запрещены архитектурно, а объекты для таких путей заранее выделяются, переиспользуются или живут в специальных таблицах и пулах. В userspace ситуация была хуже: там уже существовал собственный runtime, но runtime.alloc по сути был bump allocator, а runtime.free и runtime.GC были заглушками. В одном из ответов я тогда написал: «И таки да, следующим релизом я этот вопрос решу». 0.2.8 , который я сейчас готовлю — как раз этот самый релиз.

https://habr.com/ru/articles/1098968/

#go #gc #системное_программирование #управление_памятью #runtime #virtual_memory #tinygo #аллокатор_памяти #goos #slab_allocator