1

I know, it is an implementation detail, and some people think it is forbidden to be interested into them. But I nevertheless want to find references for, and confirmation of, the following:

  1. The large object heap maintains a free-list of holes in a segment. It uses this to fullfill allocation requests for large objects. Doesn't that also mean that such allocations would potentially be more expensive than regular (only allocation pointer increasing) allocations from the small object heap? Reference

  2. On 32-bit processes, the lower limit of segment sizes is 16MB. What is that size limit for 64-bit processes?

Remark: This question does not ask for proper object design (pooling) solutions.

Michael Petrotta
  • 59,888
  • 27
  • 145
  • 179
user492238
  • 4,094
  • 1
  • 20
  • 26
  • I can't remember where I read it - which is why this is comment and not an answer - Yes making a LoH allocation can be more expensive than a Gen1 allocation. But trying to compact a Large Object (promoting it to Gen2 from Gen1) would be crazy expensive. – Conrad Frix Apr 20 '11 at 04:50
  • Have yo checked CLR via C#? I think Richter talk about it there. – Esteban Araya Apr 20 '11 at 04:52
  • 2
    @Conrad: There's no such thing as a Gen1 allocation. Objects are allocated in Gen0 or LOH. – Brian Rasmussen Apr 20 '11 at 09:56
  • @Brian I started writing Gen0 and then was concerned someone would correct me and call it Gen 1. Guess I over-thought it. :) – Conrad Frix Apr 20 '11 at 14:30

1 Answers1

1

I just found out the second part of the question with the help of VMMap:

The minimum segment size

On 32 bit (is also reported that way in a MS blog):

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

On 64 bit (only found out by trying):

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
user492238
  • 4,094
  • 1
  • 20
  • 26