[Python-Dev] ast-objects branch created

Jeremy Hylton jeremy at alum.mit.edu
Mon Dec 5 06:37:44 CET 2005


On 12/1/05, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> Jeremy Hylton wrote:
> > I'm not sure what your intent for this work is, but I'd like to create
> > a parallel arena branch and compare the results.  I'll start work on
> > that tomorrow.
>
> I certainly want the PyObject* branch to become "life" at some time;
> I think this is the way to go, and that an arena approach is
> fundamentally flawed.

I have implemented a version of the arena API that handles freeing
memory in ast.c.  It worked out rather like I expected, although I
still haven't thought much about how it would extend to the rest of
the compiler.  It seems like the same approach should apply, although
I think the primary concern was the complexity of memory management in
ast.c.

The way the arena approach works is to free all the AST nodes at the
end of compilation.  This approach isn't all that different than the
one it replaced.  In the trunk, there is a single call to free_mod()
at the end of compilation and it recursively frees all the
sub-objects.  One way to think about the arena changes is to replace a
set of recursive function calls based on the tree structure with a
flat list of all AST nodes created during object creation.  The real
advantage is in the error cases, where all the memory gets freed even
though all the nodes aren't attached to a single tree.

Can you expand on why you think this approach is fundamentally flawed?

> That said: go ahead and create a branch. This is one of the things
> that subversion makes convenient, and it allows people to actually
> judge the results when we are done. I'm personally not worried about
> the duplicated work: if we actually carry out the experiment of
> multiple alternative (or perhaps supplementing) implementations,
> we have much better grounds to pick the approach for the mainline.

Sure does.  It seems like the code generation from the AST description
also makes this kind of experimentation easier.

Jeremy


More information about the Python-Dev mailing list