Commented Issue: Continuous Allocation of V8ScriptEngine Can Crash Application [106]

When allocating a V8ScriptEngine objects within a loop causes memory to remain allocated even if you force all references to the object to null and eventually crashes the application with a System.AccessViolationException. The details of the crash is below.

_Currently coding against version 5.4.5.0 of ClearScript._

__This Code Snippet Fails (Normally at iteration 134 the failure occurs)__
for (int i = 1; i <= 1000; i++)
{
var v8Engine = new Microsoft.ClearScript.V8ScriptEngine();
v8Engine = null;
}

__This Code Snippet Works:__
for (int i = 1; i <= 1000; i++)
{
var v8Engine = new Microsoft.ClearScript.V8ScriptEngine();
v8Engine = null;
//Invoking Garbage Collection Every 50 V8ScriptEngine object allocated
//Fixes the issue
if(i%50 == 0)
GC.Collect();
}

__Here are the details of the crash:__
Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: ClearScriptDemo.exe
Problem Signature 02: 1.0.0.0
Problem Signature 03: 572a5c94
Problem Signature 04: ClearScriptV8-32
Problem Signature 05: 5.4.5.0
Problem Signature 06: 56e184c1
Problem Signature 07: e6
Problem Signature 08: 78
Problem Signature 09: System.AccessViolationException
OS Version: 6.1.7601.2.1.0.256.4
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Comments: Thanks again for posting the images. The Performance Graph screen shots clearly demonstrate a difference, but we're not sure there's anything unexpected there. Disposing a V8 runtime instantly releases all of its unmanaged memory. That includes all the memory occupied by its garbage-collected heap, which holds the objects of all its child engines. If you don't dispose the runtime, then its heap keeps growing as new engines are created. You may be wondering why disposing an engine doesn't deallocate its objects immediately. That's simply due to the garbage-collected nature of the runtime's heap. With a shared runtime, disposing an engine makes its objects _eligible_ for garbage collection, but the garbage collector doesn't run immediately; in fact, V8's garbage collector is rather lazy. Instead of disposing your runtime periodically, try invoking its garbage collector via `V8Runtime.CollectGarbage(true)`. That should yield similar results. Good luck!