Large Object Heap Improvements in .NET 4.5

re: Large Object Heap Improvements in .NET 4.5

Alina Popa — Tue, 21 May 2013 17:52:34 GMT

@Mickey,

What .NET Framework version do you use? Do you still have the high fragmentation problem when running on .NET 4.5?

re: Large Object Heap Improvements in .NET 4.5

Mickey Puri — Mon, 20 May 2013 12:15:35 GMT

Its quite remarkable that something mature such as the .Net platform has such a fundamental issue. What are the guys at MS doing? I mean its all very well to race ahead, but if you've got a weakness in the foundations then surely before you add extra levels sort out the foundations.

I've started work at a company here where they regularly have to recycle their app pools, and I've tracked this down to large amounts of memory being allocated due to fragmentation. Specifically: 165MB allocated of which 90MB were free but due to fragmentation 20MB was the biggest memory fragment available.

still searching for a workaround as not convinced that the object pooling will work here.

re: Large Object Heap Improvements in .NET 4.5

Ray — Tue, 08 Jan 2013 19:38:16 GMT

How about just give us a function called "CompactLargeObjectHeapNow()" for the cases where the developer decides that the tradeoff of spending time to compact the LOH is preferable to OutOfMemoryException?

re: Large Object Heap Improvements in .NET 4.5

Brandon Bray — Mon, 05 Nov 2012 21:08:35 GMT

@Sam, @Rama

You both bring up good issues that I and the garbage collection team would love to learn more about. Given the frustration to your development teams, we do want to understand the situation. It will help us understand the space better as we prioritize and design improvements to the GC. Additionally, it may help us give you advice on further improvements.

Can you reach out to us via the "contact" form located at the top right of the blog? We can then follow up to schedule a phone conversation.

re: Large Object Heap Improvements in .NET 4.5

deherb3185 — Fri, 02 Nov 2012 06:33:51 GMT

@dmitri The memory allocator may not have been able to use them because they were too small to satisfy the allocation requests

-Deon - MSFT

re: Large Object Heap Improvements in .NET 4.5

dmitri — Thu, 01 Nov 2012 10:51:42 GMT

What does "Now the memory allocator will revisit the memory fragments that earlier allocation couldn’t use." mean ?

What are situations where memory allocator couldn't use some fragments ?

P.S. I would also vote for compacting LOH, it is just really annoying to have to manage memory ourselves, isn't it the whole point of managed language ?

re: Large Object Heap Improvements in .NET 4.5

Rama — Tue, 30 Oct 2012 23:17:28 GMT

To deal with LOH fragmentation issues these are some of the following workarounds we put in place:

Moved to using /3Gb switch. This has its own nightmares as it reduces the kernel memory space.

Implemented our on memory manager. Allocates large blocks of double and float arrays (which are the max of what we would ever use in the system). This scheme kills your ability to do any parallel work on the blocks due to the possibility of stomping. Hard to put in place constructs to improve performance using multiple cores.

Every release cycle we spend 2 to 3 months spinning on memory reducing efforts so we can support all of our customer requested features.

We are moving to 64bit env just shifting the problem and issue of LOH to a larger memory env.

Object pooling DOES NOT WORK for us as the content that enters the LOH are double and float arrays not our c# objects. Secondly, the arrays are rapidly allocated and released in less than few seconds. These arrays are NEVER same size, these are VARYING in size and there is NO predictable pattern of allocations to come up with array caching strategies.

Indirectly customers are suffering because of the LOH issues. Customers who PAY for applications DO NOT WISH to see OOM exceptions and crashes due to OOM.

re: Large Object Heap Improvements in .NET 4.5

Sam — Mon, 22 Oct 2012 04:43:07 GMT

@Brandon Bray

Opening 4 modules of our product operates at around 1.2GB for a particular client. If the client refreshes the modules multiple times, the total memory level stays consistent however out of memory exceptions occur and the application must be terminated and restarted. This is confirmed to have not changed in dot net 4.5 and is a great frustration for our customers.

It is very hard to say to a customer "Yes we can spend 40 hours to improve the usage memory by 200MB but if you use the application all day it probably will crash anyway" and have a positive reaction.

I'm sorry if this is coming off as negative and frustrated but this is the reality of our situation. I cannot see why the large object heap is never defragmented under any circumstances. It just does not make sense to me. The performance hit of even a manually triggered event will never ever be anywhere near as impactful as the damage to our reputation that this platform has caused and is causing.

re: Large Object Heap Improvements in .NET 4.5

Sam — Fri, 19 Oct 2012 05:07:16 GMT

@Brandon Bray

I'll complete some concrete analysis and post back.

Sam

re: Large Object Heap Improvements in .NET 4.5

Brandon Bray — Mon, 15 Oct 2012 13:17:15 GMT

@Mani, as this article and the recent article on GC indicates, we have invested a lot in the .NET garbage collector. We have even made improvements to the LOH. I encourage you to try .NET 4.5 to see if you notice these improvements. If you are actually facing the same problems with .NET 4.5, feel free to contact us at dotnet@microsoft.com. We would love to work with you.