(Update 4/3/2011: .Net 4 Relevancy)
In the .Net world when objects are greater than 85 thousand bytes they are generally placed in the Large Object Heap (LOH). But there is a caveat to that and certain objects are placed in the LOH way before 85K. The one situation I detail here in this blog is the double array which goes in way sooner.
Don’t believe me? Try this code snippet:
byte Lesthan85K = new byte; byte At85K = new byte; Console.WriteLine("Lesthan85K: " + GC.GetGeneration(Lesthan85K)); // 0 Console.WriteLine("At85K: " + GC.GetGeneration(At85K)); // 2 double array999Double = new double; Console.WriteLine("array999Double: " + GC.GetGeneration(array999Double)); // Returns 0 double array1Kdouble = new double; Console.WriteLine("array1Kdouble: " + GC.GetGeneration(array1Kdouble)); // Returns 2
By looking at the garbage collection generation, we can identify if objects reside the LOH or not. If it is generation 2 then bingo we are in the LOH!
What we see is that a double array resides in the LOH way before the 85 thousand byte yardstick. I had reported this as a bug to Microsoft connect Large Object Heap (LOH) does not behave as expected for Double array placement and was told; this is by design.
It appears that because of performance issues, it is better to insert the double arrays earlier due to the fact that the LOH is aligned in 8 byte increments. This allows better access to those large arrays in normal code processing and the tradeoff point was 1 thousand doubles and was implemented in .Net that way.
That is my piece of Tribal Knowledge that I pass on to you…use it wisely.
Recently I got a chance to explore why this had not changed for .Net 4 and the realm of 64 bit computing when I was at the Microsoft Campus talking to some of the people on the CLR team. One of the Senior Project Managers who works with the CLR team at Microsoft Andrew Pardoe was kind enough to provide this clarification that things are still the same for .Net 4 and 64 bit applications for arrays of 1000 doubles; but that may change going forward:
The CLR’s execution engine aggressively attempts to place these arrays on the LOH because of the performance benefit of accessing aligned doubles. However, there’s no benefit to applying this heuristic on 64-bit architectures because doubles are already aligned on an 8-byte boundary.
Thank you for bringing this to my attention. We’ve made changes to this heuristic that should appear in a future release of the .NET Framework.