[pypy-dev] support for 64-bit processors and eliminating global state

[Armin Rigo]

Hi Jeff,

On Wed, Sep 30, 2009 at 11:19:06AM -0700, Jeff Anderson-Lee wrote:
> > It's true that we don't have a good story here and we need one. Something
> > a'la Jython would work (unlike in CPython), but it's work.
> >   
> The last time I looked, Hoard didn't support x86_64 although it did seem 
> to work for threaded environments fairly efficiently if I recall.  
> Having a separate arena for each thread (or each virtual processor) 
> helps to avoid a lot of locking for frequent/small allocations in a VM.  
> That may mean factoring out the allocation so that it calls something 
> like myalloc(pool,size) rather than just malloc(size).  I read that pypy 
> was trying to factor out the GC code to support multiple back-ends.  
> Having an API that supports multiple concurrent allocator pools can be 
> useful in that regard.

That's all true, but the primary issue with the GIL in Python (either in
CPython or PyPy) is more fundamental.  Its purpose is to protect
concurrent object accesses.  It is to avoid getting random nonsense or
crashing the interpreter if you do two lst.append() on the same list in
two threads in parallel, for example.  The Python language reference
itself says that doing this gives you the "expected" result, i.e. the
same as if the lst.append() was protected with locking.  From there to
the GIL the distance is not very large.

We could ignore this point and try to implement a free multithreading
interpreter in PyPy -- and we would then hit all the issues you describe
above, and have to solve them somehow.  But the point is that it would
no longer be a fully compliant Python interpreter.  Depending on the use
case it might be either a very useful quasi-Python interpreter, or a
useless one that crashes randomly when running any large body of code
that otherwise works on CPython or Jython.

Of course it's not the end of the story, as shown e.g. by Jython, in
which the locking exists too but is more fine-grained.  There is one
lock per list or dictionary, which itself costs very little because the
Java platform is extremely good at optimizing such locks.


A bientot,

Armin.