[IronPython] Please vote up this DLR memory leak bug
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.
> 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
> 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.
More information about the Ironpython-users