Как «закрепить объект» в куче?

Question

[Алексей]

Имеется коллекция элементов, которая может часто обновляться и она постоянно увеличивается в размере. Читал Рихтера, возник вопрос, как объект сделать непереносимым в куче и есть ли возможность сразу отнести его ко 2 поколению? Или избегать его обработки сборщиком мусора? Коллекция как источник новостной ленты.

Comments

[Sergey Mozhaykin]

А с какой целью нужно ее закрепить? Какую задачу вы хотите этим решить? Единственная причина, которая мне приходит на ум, это взаимодействие с неуправляемым кодом. Это ваш случай?

[Алексей]

Sergey Mozhaykin: Рихтер пишет, что объекты более 85 000 байт переносятся в большую кучу и соответственно относятся уже ко 2 поколению, а там сборщик мусора реже работает. НО размер объекта может стать меньше, для этого он советует ее закрепить.

[Mrrl]

Sergey Mozhaykin: А есть ли способ закрепить объект надолго, чтобы отдать массив какому-нибудь драйверу? Ничего, кроме создания специального потока, в котором будет только fixed и потом бесконечное ожидание, в голову не приходит. Можно ли лучше? Просить память прямо у системы не очень хочется.

[Алексей]

Mrrl: Так вот же, Рихтер пишет, что объекты во 2 поколении не перемещаются в памяти из-за лучшей производительности. Но чтобы он не переместился(если станет вдруг меньше), его нужно закрепить специальным флагом Pinned, о котором я ничего не нашел. Или плохо искал.

[Sergey Mozhaykin]

Mrrl: Попробуйте GCHandle.Alloc: https://msdn.microsoft.com/ru-ru/library/1246yz8f(v=vs.110).aspx

Алексей: GCHandle.Alloc принимает это значение вторым параметром, если нужно закрепить объект в памяти.

Но эту технику нужно использовать только для взаимодействия с неуправляемым кодом, которому нужен постоянный адрес объекта в памяти. Т.к. при ее использовании возникает фрагментация памяти. Подробнее можно почитать в книге Under the hood of .NET memory management (доступна бесплатно)

Answer 1

[MrDywar Pichugin]

Вы Рихтера внимательно читали?
Второе поколение - это большие объекты ( конкретный размер зависит от ПК), сразу 2-е поколение.
Объект можно застолбить за определенным адресом в памяти, и об этом тоже написано в книге.
Точно не помню но вроде volatile не только делает объект потоко безопасным, но еще и запрещает компилятору оптимизировать участок кода. (прочитайте еще раз).

Повторял заметки, вот ответ:
Мониторинг и управление сборщиком мусора на объекте.
Вызываем статический метод Alloc объекта GCHandle, передаем ссылку на объект и тип GCHandleType в котором:
1) Weak - мониториг, обнаруживаем что объект более не доступен, финализатор мог выполниться.
2) WeakTrackResurrection - мониторинг, обнаруживаем что объект более не доступен, финализатор точно был выполнен (при его наличии).
3) Normal - контроль, заставляет оставить объект в памяти, память занятая этим объектом может быть сжата.
4) Pinned - контроль, заставляет оставить объект в памяти, память занятая этим объектом не может быть сжата (т.е. перемещена).

Answer 2

[Sergey Mozhaykin]

Если хотите, чтобы при инкрементальной загрузке освобождалась неиспользуемая память, посмотрите в сторону виртуализации. Ссылки давал тут

Comments

[Алексей]

Ооо, кстати, насчет виртуализации, я это использую средствами XAML, я использую ItemsStackPanek, которая поддерживает ItemsControl и при этом ListView поддерживает виртуализацию, таким образом я уменьшил нагрузку на графическую систему за счет того, что происходила виртуализация. Так вот из-за этого у меня часто сборщик мусора работает? Смотрел показатели системы - распределение памяти.

[Sergey Mozhaykin]

Посмотрите время жизни объектов, какие объекты чаще создаются и уничтожаются сборщиком мусора. Возможно, их создание/удаление в куче можно оптимизировать.

[Алексей]

Sergey Mozhaykin: Благодарю) а подскажите, а какими утилитами или средствами пользоваться, чтобы следить за объектами и кучей?

[Sergey Mozhaykin]

В VS Community 2013 есть встроенные средства для анализа. Посмотрите в Analyze -> Performance and Diagnostics

[CookieMonster]

Алексей: dotMemoty очень хорош в этом плане. Что касается вашего вопроса - можно подавить финализацию у объекта (SuppressFinalize), тогда clr перестанет его коллектить.

[Sergey Mozhaykin]

Grigory CookieMonster: SuppressFinalize не предотвращает сборку объекта, этот метод только удаляет объект из finalization queue.

[CookieMonster]

Sergey Mozhaykin: действительно, просто финализатор не будет вызываться у объекта перед сборкой. И на сколько я знаю, мы не можем сами указать поколение у объекта, GC сам определяет поколения и алокацию в куче. Возможно изменение GCLatencyMode в Low поможет избежать сборки коллекции, но только, когда она уже будет во втором поколении и только если не будет недостатка памяти ... если я не прав, то буду рад, если меня поправят.

Answer 3

[CrazyHorse]

"и есть ли возможность сразу отнести его ко 2 поколению?" как говорится это дурно попахивает и в перспективе ведет к проблемам с производительностью.

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

"Коллекция как источник новостной ленты." - если это веб приложение то не вижу проблем в создании каждый раз этой коллекции на основании запроса к базе данных - на странице то у Вас как правило -10-20 новостей выводится от силы.

Comments

[Алексей]

Приложение под WinRT)) Инкрементная загрузка и она содержит много ссылок. Это требует большой работы сборщика мусора. Хочу как-то уменьшить нагрузку)) если возможно

[CookieMonster]

Я не знаю, как ваше приложение устроено, но чтобы оптимизировать его и снизить нагрузку на GC, возможно, поможет в качестве элементов коллекции использовать value типы вместо reference, но важно чтобы у value типов не было "внутри" reference типов, иначе ваша коллекция все равно попадет в кучу.

[Алексей]

CookieMonster: Да я с удовольствием так сделал, но от reference не избавиться)