[pypy-dev] Memory management

[Armin Rigo]

Hello Holger,

On Sat, Feb 15, 2003 at 09:46:06AM +0100, holger krekel wrote:
> > 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.

Not only so.  We really want to isolate all memory implementation issues to
some clearly-separated level, and I don't think an advanced GC is one of the
first things to worry about.  As Christian pointed out, a first possible
implementation will just stuff tons of INCREF/DECREF everywhere.  When this
works we can think about being more subtle by optimizing the
memory-implementation-level.

> > 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".

Yes, but the calls to Py_INCREF() and Py_DECREF() have to be algorithmically
present in the C code.  It works well if you need an object for some precise
range of lines in your C function, but it is not so fine with respect to
anything else.  Take parameter passing: the Python C API doc states for each
function if the function returns a new ref or not, and if arguments are
decref'ed or not.  This should be formally declared.  We have the same problem
for containers: any object holding pointers to other objects -- do they hold a
reference or not?  This is not explicitely told in the declaration of the C
structures.

There are a lot of programming languages which only have a GC and no
refcounts, but I know about one (Mercury) in which the compiler is also able
to track which variables hold uniquely referenced objects and which variables
could hold shared values.  We can even specify that a given function argument
must contain a uniquely referenced object (i.e. an object that no one else can
possibly know about).  This lets the function do mutating operations on
immutable objects (cf. _PyString_Resize()).  BTW in Mercury *all* objects are
immutable, but the language is still efficient because the compiler can often
emit code that mutates them under-the-hood using these techniques.


Armin