Сколько куч существует в CLR?

Я — «Папочка Разработки»: пишу о карьере .NET/C#, собесах и том, как продавать свои навыки дороже. Без воды: разборы утечек памяти, практические гайды по интервью, резюме с цифрами и честные кейсы с рынка. Плюс немного про ИИ — как делегировать ему рутину и ускорять работу. Заходи, если нужен понятный план действий, а не мотивационные лозунги.

clrsohloh

Большинство ответили неправильно, поэтому велком🥰

Этот вопрос в той или иной формулировке с вероятностью 80% прозвучит на собеседовании, где спрашивают теорию.

Давайте разбираться.

Изначально их было две — Small Object Heap (SOH) и Large Object Heap (LOH).

SOH — это та самая дефолтная куча, где 3 поколения, там чаще других отрабатывает GC и двигает объекты туда-сюда.

LOH нужна для больших объектов, которые занимают более 85 тысяч байт, а в старых версиях дотнета и массивы типа double более 1000 элементов попадали туда же.

Зачем она нужна? Всё достаточно просто — большие объекты затратно перемещать по куче, поэтому фазу сжатия GC для этого поколения пропускает, да и такие объекты проверять часто тоже не надо, поэтому в LOH сборка мусора происходит только во время сборки мусора во втором (третьем по счёту) поколении SOH.

Этот ответ устроит большинство интервьюеров, но если хотите показать, насколько вам нечего делать, изучая кишки гарбейдж коллектора, то 🐒:

Pinned Object Heap (POH) — появилась в 5-ом дотнете и в ней хранятся объекты, адрес которых не должен меняться.

Никогда не пинил объекты и не особо хочу знать, зачем оно надо. Говорят, что как-то связано с неуправляемым кодом 🤔

Frozen Object Heap (FOH) — совсем новая и модная оптимизация, которая появилась в 8-ом дотнете. Тут располагаются объекты, которые живут всё время жизни приложения, не изменяются после создания и не ссылаются на объекты не из FOH.

Благодаря ей мы лишний раз не проверяем объекты, которые точно никогда не удаляются, что уменьшает накладные расходы на сборку мусора.

Что? Техника 🌟. Тут надо тыщу реакций собрать иначе дальше только кружочки

Дискуссия

Andrey
А High-frequency heap отдельно не выделяется?
Aleksandr Alekseev
Антон Honey Badger
Если я правильно помню, то в poh лежат всякие константы, например.
Будто логичнее было бы разместить в FOH, но не претендую на истину
Aleksandr Alekseev
Andrey
А High-frequency heap отдельно не выделяется?
Тут уже стоит разделять с Low Frequency Heap, но конкретно про это вообще не особо где-то слышал
initale
Антон Honey Badger
Если я правильно помню, то в poh лежат всякие константы, например.
константы хранятся в статической памяти
Anton
есть еще process heap, code heap (loader heap)
WannaCrypt
Aleksandr Alekseev
Не нашел информации по process heap, скинь плиз почитать Loader heap == High frequency heap и это более высокоуровневые категории, т.е. не очень корректно её будет ставить в один ряд с LOH, POH, FOH, кмк
Ну, не сказал бы конечно Всё таки на них работает рефлексия, да и GC стартует сборку тоже оттуда. Я сам в целом перестал путаться в наследовании только когда про виртуальную таблицу методов прочитал Вот мне бы скорее было интересно как clr менеджит стек, т.к. получается что код на шарпе преобразовывается в MSIL и запускается в clr, но у clr же тоже есть свой стек, выделенный при создании основного потока, не значит ли это, что у dotnet приложений по дефолту стек главного потока меньше, чем у приложений на компилируемых языках. . .
WannaCrypt
Aleksandr Alekseev
Не нашел информации по process heap, скинь плиз почитать Loader heap == High frequency heap и это более высокоуровневые категории, т.е. не очень корректно её будет ставить в один ряд с LOH, POH, FOH, кмк
Жаль 2005 года, но я еще нигде столько материала не видел https://learn.microsoft.com/en-us/archive/msdn-magazine/2005/may/net-framework-internals-how-the-clr-creates-runtime-objects
Присоединиться к обсуждению →

Читайте так же