<br><br><div class="gmail_quote">On Fri, Feb 10, 2012 at 7:46 PM, Dino Viehland <span dir="ltr"><<a href="mailto:dinov@microsoft.com">dinov@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
Jeff wrote:<br>
> I'm taking a stab off the top of my head based on my limited knowledge of the<br>
> internals, but I do know that debug code is not collectable.<br>
> It's possible that the code itself may be holding references that keep objects<br>
> alive longer than expected.<br>
><br>
> I believe if you run the code in a separate AppDomain you can unload the<br>
> AppDomain and the code will be collected, which should take everything else<br>
> with it.<br>
><br>
> ><br>
> > I've also tried running in the release mode and turning on the<br>
> > options["LightweightScopes"] = true mode, which seems to help. But I<br>
> > cannot find any information about what this option actually does and<br>
> > what happens with the scope variables in general. Any info would be<br>
> appreciated.<br>
><br>
> That one I'll have to leave to Dino.<br>
<br>
</div>The difference between the different types of scopes just comes down to how<br>
we hold onto global variable and call site objects.<br>
<br>
The most efficient way to hold onto these is to use CLR static fields to store the<br>
global variables. That allows the CLR to generate a direct access to the field and<br>
we can quickly access the global variables. But it comes at the cost of not being<br>
able to recover the static fields and leaking the values that are stored in there.<br>
<br>
The light weight scopes store the variables in a field or an array instead of storing<br>
them in static fields. To do that we need to pass in the field or close over it and then<br>
on each access we need to do the field or array access (and if it's an array access, it<br>
needs to be bounds checked). But the end result is that the only thing which is keeping<br>
the global variable / call site objects alive are the delegate which implements the<br>
ScriptCode. Once the ScriptCode goes away all of those call sites and PythonGlobal<br>
objects can be collected.<br>
<br>
So lightweight scopes come at a performance cost, but they are more applicable<br>
Where you're actually re-compiling code regularly.<br>
<br>
<br>
</blockquote></div><br><div>Thanks for that explanation, Dino.</div><div><br></div><div>Another question that pops up: what happens with Disposable objects (like files, GDI+ bitmaps etc.) created within the Py scope (if they are not referenced from the outside)?
</div><div><br></div><div>Igor</div>