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-boun...@lists.ironpython.com [mailto:users-boun...@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 <di...@microsoft.com<mailto:di...@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-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com> [mailto:users-boun...@lists.ironpython.com<mailto:users-boun...@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.schm...@gmx.de<mailto:christian2.schm...@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@lists.ironpython.com<mailto:Users@lists.ironpython.com> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- nomadlife.org<http://nomadlife.org> -- nomadlife.org<http://nomadlife.org>
_______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
