Call GC.Collect Before Throwing OutOfMemoryException

Is there any way to get GC.Collect() to be called before throwing an OutOfMemoryException?

I suppose I'm looking for a way for it to do the following code flow:

Try to Allocate Memory
On Pass Return
Call GC.Collect()
Try to Allocate Memor开发者_如何学JAVAy
On Fail Throw New OutOfMemoryException()

I'm writing a caching implementation and currently I'm running into memory exceptions so currently to resolve it I am using:

If GC.GetTotalMemory(False) >= cache.CacheMemoryLimit + (100 * 1024 * 1024) Then
    // When Total Memory exceeds CacheMemoryLimit + 100MB
    GC.Collect()
End If

---

Maybe I'm not understanding your question, but wouldn't it be possible for you to just catch OutOfMemoryException's thrown and call GC.Collect there? Toss the try/catch inside a loop that continues until you've finished your task and make sure it has the ability to clean itself up.

bool isFinished = false;
while (isFinished) {
  try {
    // do operations in here
  } catch (OutOfMemoryException oom) {
    GC.Collect();
  }

  // if you're done...
  isFinished = true;
}

Pardon the use of C# pseudo instead of VB, I try not to work in VB unless I have no choice.

---

Actually .NET will happily throw out-of-memory exceptions when instead it could have garbage-collected and succeeded. This is one of my few gripes with Microsoft's .net implementation. Unit tests that allocate and immediately discard a lot of memory in one or more threads appear to pass. I think the problems start, however, once large chunks of older generations go out of scope. That stuff isn't picked up right away.

So for example if you have code that reads a million XmlDocuments from disk one at a time, chances are reasonable that you'll get an OutOfMemory exception unless you GC.Collect() every few documents.

EDIT: http://social.msdn.microsoft.com/forums/en-US/clr/thread/52a7eb17-ac05-470c-b063-a78427cd4406/

---

The whole point of the Out of Memory exception is to let you know that you're out of memory, after all efforts to GC the system have failed. If you're truly working on a caching system, then you should consider looking at Weak or Soft References. These allow the system to discard items when memory gets tight, even though they have references to them.

In a caching system, when you look up an object, one second you'll get the result, the next second you'll get a NULL because memory got tight enough to force the system to discard the weak referenced objects. At this point your cache recreates the object, and puts it back in the cache, and you continue on your way as if it was the first time you referenced the object anyway.

---

Calling GC.Collect can fix timing related OutOfMemory exceptions. As Jugglist mentioned above ".NET will happily throw out-of-memory exceptions when instead it could have garbage-collected and succeeded." I have a high speed soft real time video processing system that would very occasionally throw OutOfMemory exceptions when under heavy load. A strategic placement of GC.Collect calls in a known processing deadband (before the next camera trigger) fixed these problem. Granted another option would have been to manually dispose of the objects as needed but then why the heck are we using a managed environment. This problem wass likely exacerbated by the fact that my app was compiled x86 memory model. So if you are doing something exceptionally memory intensive and feel you have a place in the code where you think it is appropriate to do garbage collection then do it. This has been widely discussed here: What's so wrong about using GC.Collect()?