[pypy-dev] Memory management

holger krekel hpk at trillke.net
Sat Feb 15 09:46:06 CET 2003


[Christian Tismer Sat, Feb 15, 2003 at 06:19:57AM +0100]
> Richard Emslie wrote:
> > I have a naive question which I hope some kind sole will help me out on.
> > I have been waiting for memory management (lower level than garbage
> > collecting / ref counting) to be discussed.  I'm probably barking up the
> > wrong tree - but a "pypy python" object has to be resident in memory
> > somehow - and this needs a physical representation and heap allocation /
> > deallocation presumably?
> 
> Sure it needs that.
> 
> > Perhaps this is a post-bootstrap issue as we can piggy back on the
> > existing CPython infra-structure during development - but as far as I can
> > reason this will have to be ultimately handled by a minimal statically
> > compiled python which we do we do use in bootstrapping our pypy python?
> > Is this true?
> 
> Well, we are not intending to re-implement the GC in Python,
> yet. Instead, we assume it exists or we don't need it.

Especially since we don't have anybody really intimate with 
GC issues, i guess. 

> Garbage collection is very visible in the current implementation.
> You see Py_INCREF and Py_(X)DECREF in many places right now.
> This is there by tradition, introduced by early optimization.
> It is also a draw-back. By doing explicit refcount handling,
> the source code gets cluttered, and it is hard to be optmized.

I agree that we would like to avoid INCREF/DECREF everywhere.  
 
> One of PyPy's intentions is to get stuff like that
> onto another level of abstraction. A function with
> a parameter should not need to spell an extra reference
> to the parameter, but it should tell the RTL that it need
> this parameter to stay alive while it needs it.
> This might have the same implementation, but is very
> different from an algorithmic view.

Hmm, this i don't understand.  It sounds much like current
INCREF/DECREF which means exactly this: "i want to use
this object"/"i don't want to use it anymore".  Objects
can be shared in many places so i don't yet see how your
"tell the runtime that it needs this paramater to stay
alive while it needs it" beeing different from 
current CPython's scheme.  Can you give a more concrete
example how this would work and/or be spelled?  Or
anyone else? 

cheers,

    holger


More information about the Pypy-dev mailing list