[ANNOUNCE] Garbage collection for Python

[Bjorn Pettersen]

Helge Hess wrote:
> 
> Bjorn Pettersen wrote:
> > Helge Hess wrote:
> > > I think what he wants to do (me too ;-) is to run several copies of the
> > > interpreter in *one* process, possibly in multiple threads.
> > > But I'm not sure whether this is a GC issue though (RC isn't thread-safe
> > > anyway, right ?).
> >
> > Well, it actually can be -- at least on Windows :-)
> 
> The question is, what overhead is involved here. If these Windows
> functions wrap the RC ops in locks you have gained nothing (wrapping RCs
> in locks breaks performance in a big way). Note that std-RC is often
> only one CPU op (incr,decr).
> 
> Also note that not only the ++ or -- needs to be protected, but the
> '==0' check as well. Eg:
> 
>    [task1]            [task2]
>    dec(obj);          inc(obj);

Note that both task 1 and task two must have a reference to the object
for this to be possible, so the ref count must at least be two. (unless
you're thinking of sharing names between tasks without locking -- that
would make rc much more resource intensive...)

> could be
>    [task1]            [task2]
>    obj->rc--;
>    if (obj->rc==0)
>      <task-switch>    obj->rc++;
>      free(obj);       <task-switch>
>    object-freed       assumes to have a valid obj

If the reference count was one, adding mutexes wouldn't help:

    aquire(obj->mutex)
    obj->rc--;
    if (obj->rc==0)
      free(obj);   
    release(obj->mutex)

                         aquire(obj->mutex)  // does it crash here
                         obj->rc++           // or here?
                         ...

> [note that checking for 0 in task2 doesn't solve the problem, since the
> check wouldn't be atomic again, but maybe I'm missing something].
> 
> A (m&s) GC is somewhat in advantage here, since it is run only at
> specified (safe) points, so there is no locking required at such high
> frequency.

No argument from me there :-)

The api calls are direct wrappers around the processors
increment-and-test or test-and-set instructions, and are extremely fast
compared to a mutex solution (which makes it interesting to see other
people on this thread claim that it would be _way_ to slow without even
testing it...).  Our tests showed an order of magnitude difference on
some tests...

-- bjorn