Требуются внутренности LOH

Я знаю, это детали реализации, и некоторые считают, что ими нельзя интересоваться. Но я тем не менее хочу найти ссылки и подтверждение следующего:

  1. Куча больших объектов поддерживает свободный список дыр в сегменте. Он использует это для выполнения запросов на выделение больших объектов. Не означает ли это также, что такие выделения потенциально будут более дорогими, чем обычные (с увеличением только указателя выделения) выделения из кучи малых объектов? Справочник

  2. В 32-разрядных процессах нижний предел размера сегмента составляет 16 МБ. Каков этот предел размера для 64-битных процессов?

Примечание. Этот вопрос не требует правильного проектирования объектов (объединения).


.net clr large-object-heap
person user492238    schedule 20.04.2011    source источник
comment
Я не могу вспомнить, где я это прочитал, поэтому это комментарий, а не ответ. Да, выделение LoH может быть дороже, чем распределение Gen1. Но попытка сжать Большой объект (превратить его в Gen2 из Gen1) обошлась бы безумно дорого.   -  person Conrad Frix    schedule 20.04.2011
comment
Вы проверили CLR через С#? Я думаю, что Рихтер говорил об этом там.   -  person Esteban Araya    schedule 20.04.2011
comment
@Conrad: Нет такого понятия, как распределение Gen1. Объекты размещаются в Gen0 или LOH.   -  person Brian Rasmussen    schedule 20.04.2011
comment
@ Брайан Я начал писать Gen0, а затем забеспокоился, что кто-нибудь поправит меня и назовет это Gen 1. Думаю, я слишком много думал. :)   -  person Conrad Frix    schedule 20.04.2011

Ответы (1)


arrow_upward
1
arrow_downward

Я только что узнал вторую часть вопроса с помощью VMMap:

Минимальный размер сегмента

На 32 бит (также сообщается в блоге MS):

Initial segment size for Gen 0,1,2:       16 MB   
Initial segment size for LOH:             16 MB  
Size for larger LOH chunks:multiples of    8 MB

На 64 бит (узнал только при попытке):

Initial segment size for Gen 0,1,2:      256 MB  
Initial segment size for LOH:            128 MB  
Size for larger LOH chunks: multiples of 128 MB
person user492238    schedule 20.04.2011