[IronPython] Lightweight Code Generation?

[Jim Hugunin]

The current use of the on disk snippets.dll is a total and absolute hack to
make debugging easier during the development of IronPython.  As things get
closer to a 1.0 release of IronPython, this will need to be replaced with an
in-memory only version, plus a debugging mode for developers who have
problems.  If you look at the code from IronPythonConsole, you'll notice
that a try/finally is used to ensure that snippets.dll gets written even
when an exception is going to be thrown.  This should emphasize the
debugging nature of the current design.

This situation can be made a lot better without using any new 2.0 features.
In particular, this particular dll can easily be kept just in memory with
barely any change to the existing code.  In fact, one of the advantages of
continuing to use the 1.1 AssemblyBuilders is that they have this nice
feature of either being just in-memory or being writable to disk.

DynamicMethods, the new LCG mechanism in Whidbey/.NET 2.0, are a different
story.  The HUGE benefit of these methods are that they can be garbage
collected.  This would matter in a long running process that used eval
occasionally, or possibly even in a short-running process that used eval a
lot.  With AssemblyBuilders any generated code uses memory that can never be
reclaimed.  With DynamicMethods you will get back the memory when there are
no more references to the code as you'd hope.  The downside to
DynamicMethods is that they can't be written to disk, which means they can
be a PITA to debug when something goes wrong.

Most of the code for building DynamicMethods is identical to the code for
the AssemblyBuilder approach currently used; however, there will be some
significant differences.  Perhaps the most obvious difference is that the
current Python code generation uses CLR static fields for storing Python
constants.  DynamicMethods are just methods, so they don't let you create
static field, so this code generation would have to be modified to get the
constants from somewhere else.  This is a big enough change to have some
risk of inconsistent behavior and thus will need to be handled carefully.

The huge benefit of being able to reclaim the memory from the code in a
DynamicMethod is so important that I'm sure this feature will be enabled in
some way in IronPython-1.0.  The exact mechanisms used will take some
careful engineering.

-Jim


> -----Original Message-----
> From: users-ironpython.com-bounces at lists.ironpython.com [mailto:users-
> ironpython.com-bounces at lists.ironpython.com] On Behalf Of J. Merrill
> Sent: Friday, September 17, 2004 10:50 AM
> To: users-ironpython.com at lists.ironpython.com
> Subject: Re: [IronPython] Lightweight Code Generation?
> 
> It would certainly be easy enough to get rid of that "single instance per
> directory" side effect.  .NET supports in-memory-only assemblies, but
> having the assembly on disk certainly must make it easier to do certain
> kinds of debugging (e.g. you could run Reflector on it to see what's going
> on, if it doesn't work the way you think it should).
> 
> For at least that reason, I'd want to have the option to have any dynamic
> assemblies be on-disk.  If using the new functionality would mean that
> there'd have to be two different implementations, one to satisfy the "on-
> disk assembly" requirement and one that uses the new functionality, that
> would leave open the possibility that things would work differently in
> those two scenarios -- which I'd think could make people mistrust FePy
> completely.
> 
> But if the new mechanisms lets you save the resulting dynamic code as an
> assembly (if needed), it might be worth the "no .NET 1.1 framework
> support" problems to use those new features.
> 
> At 08:56 PM 9/16/2004, Curt Hagenlocher wrote (in part)
> 
> >Right now, FePy has to generate an assembly to contain all of
> >its dynamic code.  It generates this assembly to the file
> >snippets.dll.  I'm not sure if it has to generate the assembly
> >to a file (versus in-memory), but one side effect of this is
> >that you can only run a single instance of FePy from the same
> >directory at the same time.
> >
> >Being able to generate dynamic code that lives in memory and
> >doesn't have to be part of an on-disk assembly could be very
> >useful.
> >
> >--
> >Curt Hagenlocher
> >curt at hagenlocher.org
> 
> 
> J. Merrill / Analytical Software Corp
> 
> _______________________________________________
> users-ironpython.com mailing list
> users-ironpython.com at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com