[IronPython] Lightweight Code Generation?
ld at galador.net
Sat Oct 9 22:53:56 CEST 2004
what about [2.0] DynamicMethod?
I heard they could be garbage collected...
I mean each line of python code could be staright executed in the current
context (without creating new assemblies and stuff), but function could
generated as DynamicMethod
this way you don't have any kind of 'memory leak', do you?
----- Original Message -----
From: "Jim Hugunin" <jim at ironpython.com>
To: "'Alex Hoffman'" <ironpython at alexh.sent.com>;
<users-ironpython.com at lists.ironpython.com>
Sent: Sunday, October 10, 2004 3:08 AM
Subject: RE: [IronPython] Lightweight Code Generation?
> Alex Hoffman write:
>> Unfortunately unloading an assembly from the primary AppDomain surely
>> goes beyond any member of the CLR team's influence. It is core to the
>> architecture of the CLR - not a feature that can just be bolted on or
>> included in the "next release".
> Unloading assemblies is a big issue and one that I'm unlikely to change in
> the very near future. Here's a link to my boss's blog where he talks
> this issue:
> I agree that there is potentially value in hosting embedded scripts in a
> separate AppDomain with restricted permissions in order to increase
> reliability. I really like to ability to monitor scripts and kill them if
> they use too much memory or time. One of the many tasks on my giant todo
> list is to write a hosting example that shows how separate AppDomains can
> used effectively to host a scripting solution. Until I do that, I can't
> really comment on how much of a problem this is in practice.
>> As mentioned it's maybe worth a revisit given LCG and dynamic properties.
> LCG is the right way to fix this problem in the near term. Once again,
> send you off to one of my co-worker's blogs for a concrete example:
> It should be a trivial matter to support this form of generation as an
> option in IronPython that is used only on systems that support
> DynamicMethod. This would mean that 1.1 systems would have an interactive
> interpreter with a memory leak, but that on 2.0 that same interactive
> interpreter would stop leaking making it viable in a greater range of
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
More information about the Ironpython-users