On 12/1/05, "Martin v. Löwis" <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com