[IronPython] Embedding IronPython

[Dino Viehland]

Yeah, it was surprising to me too :)  But your assumption is correct - it'll be collected like just any other object.

Also Rauhotz has commented on the bug 20399 that if you move the CreateRuntime/GetEngine calls into the loop that we still leak memory though :(  That definitely looks like a bad bug but I think I'll need to talk to the DLR team about it.  Once we have a fix that seems like a definite candidate for 2.0x.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dody Gunawinata
Sent: Friday, January 02, 2009 6:21 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Embedding IronPython

OK, this is definitely surprising.

Is it correct to  assume that by setting the compilation to non-optimized mode, the compilation result will behave like a normal .Net object in being subjected to normal GC collection when it's out of scope? Or do I have to explicitly set GC collection after usage?

Dody G.

On Fri, Jan 2, 2009 at 7:59 PM, Dino Viehland <dinov at microsoft.com<mailto:dinov at microsoft.com>> wrote:

This would appear to be a bad default value for compiling.  You can explicitly disable compiling the code as optimized and it will be fully collectible:



var runtime = Python.CreateRuntime();

var engine = runtime.GetEngine("py");

var sum = 0.0;

PythonCompilerOptions pco = (PythonCompilerOptions)engine.GetCompilerOptions();

pco.Module &= ~ModuleOptions.Optimized;



while (true)

{

var code = engine.CreateScriptSourceFromString("1.0+2.0").Compile(pco);

sum += code.Execute<double>();

GC.Collect();

GC.WaitForPendingFinalizers();

GC.Collect();

Console.WriteLine(sum);

}



I am inclined to change this, or at least add some other way that makes this more discoverable (e.g. via the Python class).  But I think changing the default should probably wait until 2.1 as it could have some small perf surprises for people who are expecting it to be in the more optimal form (globals will be ~10% slower).  Longer term we're working w/ the CLR team to get the best of both worlds.





From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com>] On Behalf Of Dody Gunawinata
Sent: Wednesday, December 31, 2008 4:35 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Embedding IronPython



Please we need more vote on the memory leak issue because it has huge impact on the usage of Iron Python for the web environment as well.

On Wed, Dec 31, 2008 at 11:50 AM, Christian Schmidt <christian2.schmidt at gmx.de<mailto:christian2.schmidt at gmx.de>> wrote:

Hi Josh,

CompiledCode cc = src.Compile();

This will leak memory. So you will run out of memory after a while (in our case after 100'000 compiles on x86).
[http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=20399]



Is this going to work or will I run into threading problems?  In other words, is the ScriptEngine thread-safe?  Will it serialize all of my cc.Execute() calls?  Any other insight into its behavior in this regard would be appreciated.



I think globals and imports will be shared. So modifying them might give unexpected results.

Cheers,
Christian

_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



--
nomadlife.org<http://nomadlife.org>



--
nomadlife.org<http://nomadlife.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20090102/2e146efc/attachment.html>