[pypy-dev] Some new first thoughts about pypy

[Michael Hudson]

"Edward K. Ream" <edreamleo at charter.net> writes:

> The pypy tools promise to move programming (not just python
> programming) in new directions.  They may show a way to realize an
> ancient dream of mine, viz., to eliminate the gc for some (most?,
> all?) objects.  For details, see:
>
> http://webpages.charter.net/edreamleo/whitepapers.html#allocating-storage-using-lifetimes

Um, I think this technique is used reasonably often in the
implementation of compilers, is it not?  Even Python 2.5 uses it...

In the context of PyPy it's easy to think of a program where the use
of this technique is less clear: an interpreter.

> Of course, nothing at all may come of this; it's just something to
> keep in the back of my mind. Your (gentle) comments are welcome.

It is certainly the case that memory management is of utmost important
to the performance of pypy (looking at kcachegrind for, oo, half a
second will tell you that) but it is less clear how to do anything
about that.  PyPy already performs an analysis or two designed to
remove allocations, and a few more have been written but are not used
because they didn't help or are buggy.  They are all local to a
function so far though, I think.  Googling around I found this paper:

http://www.cs.cmu.edu/afs/cs/academic/class/15745-s06/web/handouts/lattner-pldi05.pdf

-- would someone like to read it for me and tell me if it applies to
PyPy? :-)

The logical extension of the pool allocation idea is a generational
garbage collector, and I'd dearly like to have one of those for PyPy
but practically speaking you need a copying collector for one to be
worth it and we don't support that yet for grotty reasons.

Cheers,
mwh

-- 
  Ability to type on a computer terminal is no guarantee of sanity,
  intelligence, or common sense. 
                                 -- Gene Spafford's Axiom #2 of Usenet