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