Just some comments on this as there's a few issues intertwined here:

1.       Optimized code - this is currently the default and part of the 
original problem.  If you execute code in "optimized" mode we generate an 
uncollectible type.  In 2.6 I'm switching the default to be non-optimized and I 
also am trying out a change that should reduce the amount of leakage when we do 
this.  That will make the out of the box experience much better.

2.       Multiple script runtimes - there's a bug in the DLR when you 
repeatedly create script runtimes that the rules aren't getting collected. This 
is supposed to be fixed in 2.6 but I'm still seeing some leaks in this scenario 
that I'll look into and fix.  Back-porting this to 2.0 would be quite difficult 
as a lot of things have changed but we could certainly look at backporting a 
different fix to 2.0.

3.       There's a repro that defines "TestScriptOldClass" + n which leaks.  
All class / function / member names in code get interned and this is where this 
leak is coming from.  If you remove the + n then everything works.  We may get 
rid of this interning at some point in the future but it's a fairly significant 
change.  I'm inclined to believe this one isn't as much of an issue as usually 
you aren't compiling code with new names every single type.

From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dody Gunawinata
Sent: Sunday, February 22, 2009 2:10 PM
To: Discussion of IronPython
Subject: [IronPython] Please vote up this DLR memory leak bug

There's only 5 votes so far.

http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=20399



--
nomadlife.org<http://nomadlife.org>
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Reply via email to