There is a lot of information available about the .NET LOH and it has been explained in various articles. However, it seems that some articles lack a bit of precision.
Outdated information
In Brian Rasmussen's answer (2009), program manager at Microsoft, he says the limit is 85000 bytes. He also let's us know that there is an even more curious case of double[]
with a size of 1000 elements. The same 85000 limit is stated by Maoni Stephens (MSDN, 2008), member of the CLR team.
In the comments, Brian Rasmussen becomes even more exact and let's us know that it can be reproduced with a byte[]
of 85000 bytes - 12 bytes.
2013 update
Mario Hewardt (author of 'Advanced Windows Debugging') told us in 2013 that .NET 4.5.1 can now compact the LOH as well, if we tell it to do so. Since it is turned off by default, the problem remains unless you're aware of it already.
2015 update
I can't reproduce the byte[]
example any more. With a short brute-force algorithm, I found out that I have to subtract 24 instead (byte[84999-24]
in SOH, byte[85000-24]
in LOH):
static void Main(string[] args)
{
int diff = 0;
int generation = 3;
while (generation > 0)
{
diff++;
byte[] large = new byte[85000-diff];
generation = GC.GetGeneration(large);
}
Console.WriteLine(diff);
}
I also couldn't reproduce the double[]
statement. Brute-forcing gives me 10622 elements as the border (double[10621]
in SOH, double[10622]
in LOH):
static void Main(string[] args)
{
int size = 85000;
int step = 85000/2;
while (step>0)
{
double[] d = new double[size];
int generation = GC.GetGeneration(d);
size += (generation>0)?-step:step;
step /= 2;
}
Console.WriteLine(size);
}
This happens even if I compile the application for older .NET frameworks. It also does not depend on Release or Debug build.
How can the changes be explained?
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…