Garbage collections improvements in CLR 4.0

Question

Recently I was running the example provided by Andrew Hunter on his blog "The Dangers of the Large Object Heap" compiled against .NET 4 and I got the following numbers:

With large blocks: 622Mb allocated
With large blocks, frequent garbage collections: 582Mb allocated
Only small blocks: 1803Mb allocated
With large blocks, large blocks not growing: 630Mb allocated

If the same code is compiled against.NET 2.0 I got almost the numbers mentioned in article:

With large blocks: 21Mb allocated
With large blocks, frequent garbage collections: 26Mb allocated
Only small blocks: 1811Mb allocated
With large blocks, large blocks not growing: 707Mb allocated

What is the cause of such dramatical improvement?

Code is compiled for x86 platform and is run on Windows 7

Answer 1

Some much needed work from the CLR team is the reason for the improvements, but apparently there is room for improvement still:

http://mitch-wheat.blogspot.com/2010/11/net-clr-large-object-heap.html

Answer 2

Something changed but it is a well kept secret, I can find nothing about it. I wouldn't put too much stock into it. The code sample was hand-tuned to the make the CLR 2 large object heap look as bad as possible. Even a small change in the algorithm, perhaps inspired by the blog post, will have very large effects.