[IronPython] Please vote up this DLR memory leak bug

[Dino Viehland]

Your approach should be perfectly fine (it's basically what CompiledCode was designed for) and it's not clear to me what would be leaking in this scenario.  

One suggestion I'd have for you is to download and install windbg (http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx).  

Then attach to your process which is using all the memory and type in:

.loadby sos mscorwks
!DumpHeap -stat

And send back the about the last 25 lines of that output.  That'll give us the most common objects which are using memory in the GC heap and we might be able to track it down from there.  If that's not sufficient maybe we can iterate and figure out what's going on.

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Dody Gunawinata
> Sent: Wednesday, February 25, 2009 8:38 AM
> To: Dino Viehland
> Cc: Discussion of IronPython
> Subject: Re: [IronPython] Please vote up this DLR memory leak bug
> 
> 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
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com