[IronPython] Please vote up this DLR memory leak bug

Dody Gunawinata empirebuilder at gmail.com
Wed Feb 25 17:38:06 CET 2009


What is the impact of caching CompiledCode into this "collectability" issue?

I am working on a CMS that expose functions implemented in IronPython
to a template engine. So I read a directory of 40 or 50 xx.py files,
load it up and compiled them. This is off course a costly operation to
do it in every single HTTP request (and SLOW) so I compiled the source
code to CompiledCode and cache them.

Then for every HTTP request, I retrieve these CompiledCode's from the
Cache and call Execute(scope) to make the frozen code to be a real
function. So with X HTTP request, there will be X scope and  (X * 40)
functions being generated at runtime.

Now our memory consumption is huge and is getting bigger until IIS
gave up and recycle the process.

Dody G.




> 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-bounces at lists.ironpython.com
> [mailto:users-bounces at 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



-- 
nomadlife.org



More information about the Ironpython-users mailing list