Out Of Memory: state of the art

Hi All,

Due to popular demand, I will presently describe what we have come up with
investigating OutOfMemory issue (RSRP-18766) that plagues ReSharper since
version 2.0.

As it happens, there can be three different circumstances under which System.OutOfMemory
may be thrown:

1) "True OutOfMemory": ReSharper demands the amount of memory that is greater
that physically available on system (RAM+Pagefile). We believe that on a
reasonable box this never happens in ReSharper 2.5.2. We sometimes eat lots
of memory, but essentialy if you can open your solution in plain VS on given
box without trashing, you shouid be able to do so in VS+ReSharper, although
for small RAMs you will trash a lot. We do work on reducing our memory footprint,
but of course ReSharper features come at a price. You cant expect us to do
more that VS in the same amount of memory. Anyway, I am not aware of ReSharper
encountering 'true OutOfMemory' on any projects.

2) "hResult= E_OUTOFMEMORY". Many COM calls indicate some generic errors
by returning hresult E_OUTOFMEMORY. .NET COM Interop chooses to communicate
this fact to the managed code by throwing OutOfMemory exception. ReSharper
uses Visual Studio COM classes heavily, and, as you may have guessed, the
conditions under which various COM calls fail with E_OUTOFMEMORY are, to
say the least, somewhat underdocumented. What we do in that case is try to
figure out these conditions, not call the offending methods in these cases,
and, as the last resort, just put these call under try/catch(OutOfMemory)
and fail gracefully. As you may understand, this is an ongoing battle, and
we will try to fix all these calls in 3.0.

3) Large Object Heap troubles. See: http://www.codeproject.com/csharp/Large_Objects____Trouble.asp
Apperently 32bit XP version of .NET 2.0 may fail to allocate big arrays in
some conditions when there are plenty of memory. Worse, Large Obejct Heap
becomes corrupted in that case, and subsequent memory allocation requests
may randomly fail with OutOfMemory exception. ReSharper currently sometimes
tries to allocate big arrays, and we are currenly in the process of replacing

these big arrays with fragmented arrays. I am afraid we will not be able
to backport all of these fixes to 2.5, although we will try to backport the
most critical ones.

These are results of our investigations for RSRP-18766 so far. Addressing
OutOfMemory issues one of our priorities for ReSharper 3.0 release, and,
I believe, we have by now identified the main causes for them and we hope
to fix all of those in 3.0 release.

I do not think there is much need to fly anyone anywhere yet :)

Hope this helps,

Dmitry Lomov
Technical Lead/Software Architect
JetBrains, Inc.
"Develop With Pleasure!"

Please sign in to leave a comment.