Hi, Curt, Von: Curt Hagenlocher [mailto:c...@hagenlocher.org] > Von: Markus Schaber > > Von: Curt Hagenlocher [mailto:c...@hagenlocher.org] > > > On Thu, Oct 18, 2012 at 8:52 AM, Markus Schaber > > > <m.scha...@3s-software.com> wrote: > > > > Is it possible to hire some of the IronPython Core developers for > > > > bugfixes, or is there commercial support available? > > > > Especially http://ironpython.codeplex.com/workitem/31764 is a major > > > > issue for some of our users, they fight with Out of Memory exceptions > > > > during automated test runs which fire hundreds of IronPython scripts. > > > > For us, it might be cheaper and faster to pay an expert for this task, > > > > than trying to solve it on our own. > > > This doesn't directly address your question, but as I recall, > > > DefineDynamicAssembly is only used under very particular circumstances. > > > It can be avoided most of the time in non-debug usage of IronPython. The > > > only way to release some of the memory usage forced by > > > DefineDynamicAssembly is to tear down the AppDomain and create a new one. > > > This is a CLR issue. > > > Disclaimer: I haven't worked on this code in about three years. > > Thank you for your answer. Maybe it is possible to utlilise the Collectible > > Assemblies introduced with .NET 4.0 > > (http://msdn.microsoft.com/en-us/library/dd554932%28v=vs.100%29.aspx) - > > they should be fully GC-able... > > We can also live with an explicit "Dispose()"-Method to clean up artifacts > > of old scripts, if that helps further... > I don't want to make it sound like I know more than I do; the discussion on > work item 20399 makes it clear that I don't accurately remember all of the > specifics around this issue. But I do recall that we looked at using > collectible assemblies and decided against it. We were still committed to > supporting .NET 2.0 at the time, so that was one factor. But the real problem > is having a realistic idea of when to stop emitting methods into assembly 1 > and start emitting them into assembly 2. Having small granularity -- too many > assemblies -- is a bad thing (for reasons I no longer remember). But putting > too many methods into a single assembly increases the chance that the > assembly will never be collected because one of its types are still in use. > Running each independent script in its own AppDomain is painful and may have > performance consequences. But ultimately, it gives you the best control over > resource management. On Thu, Oct 18, 2012 at 9:16 AM, Markus Schaber <m.scha...@3s-software.com> wrote:
In our case, it would be possible to use one collectible assembly for one ScriptEngine. Using a separate AppDomain would endanger compatibility with 3rd-party plugins providing functionality to the plugins - they need to update to MarshalByRefObject or serializable objects, and we usually have strict backwards guarantees. But maybe that's the only really workable way. (And maybe we find a way to dynamically create and transparently inject MarshalByRefObject-Wrappers into our official script interfaces.) Just a total different thought, though: Right now, we create a different ScriptEngine for most script runs. The reason is that we want to have a clean environment for each script, without any artifacts from the previous script run. Maybe there is a more lightweight approach to achieve this goal. Is there a way to (re-)create such clean environments using the same script engine? (I hope that this could give us the advantage of re-using the generated code when the same script is re-run, or the same module is re-imported - reducing the leak to a bloat.) Just using a new ScriptScope seems not to be enough, AFAICS, as - for example - sys.modules needs to be re-set (and the modules contents themselves might have been manipulated by the scripts after importing them). A clean way to "Reset" an existing ScriptEngine would be at least a partial solution - this way, we still would need several Engines (for scripts triggering other scripts), but we could at least recycle them. Another idea might be a purely interpreted mode - AFAIR, IronRuby provides such a mode, while IronPython does not... Best regards Markus Schaber -- ___________________________ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org http://mail.python.org/mailman/listinfo/ironpython-users
