I am a bit confused about the storage of large objects within the heap.. Like at what size is the object cosidered large? What types are more likely to be treated as large objects?is there any clear fragmentation methods adapted to manage such objects.
Add a comment
|
2 Answers
This article has a lot of details, although you should be aware of changes coming in .NET 4.5 too.
The only types which are likely to end up on the LOH are strings and arrays - because they're the only types which can basically be given a size at execution time. I'm not sure it's even valid to create a type with so many fields that it would end up on the LOH as a single object - it may well be, but I can't imagine it happening in reality.
According to the linked article, the limit is currently 85,000 bytes. It's an implementation detail really though - you should rarely need to think about it.
3 Comments
SShebly
Thanks jon this would help until 4.5 :)
supercat
Are they still going to keep the annoying behavior of only doing LOH collections when generation 2 is collected? I asked a question regarding Microsoft's reason for it, and still I don't understand what performance benefit one obtains from exempting LOH objects from L0/L1 GC. From what I can tell, a live LOH object has to tag all L0/L1 objects to which it holds references on its first L0 or L1 collection after its instantiation; is there some trick that allows Microsoft to skip that step?
Jon Skeet
@BarışAkkurt: Fixed, thanks - fortunately the author moved it to a blog post :)
The general rule is: If the size of the object is 85000 bytes or more it is considered large and will be place on the LOH.
For some reason double[] is treated differently, so any array of doubles with 1000 or more elements go on the LOH as well. I haven't seen any official documentation for this implementation detail, but it is fairly easy to verify.
