what's the point of rpython?

Paul Rubin http
Tue Jan 20 05:31:36 CET 2009


"Brendan Miller" <catphive at catphive.net> writes:
> As long as you can atomically increment and decrement an integer
> without locking you are pretty much done.

Most cpu's can't do that.

> For a reference implementation of lock free reference counting on all
> common platforms check out boosts implementation of shared_ptr (a
> reference counting smart pointer designed around multithreaded use
> cases).

That sounds very mysterious to me--are you sure it is intended for
multiprocessing and not just multiple threads on a single processor?
Do you have a url for the code?

> I see it the two trade offs that have to be made for GC vs alternative
> techniques. The "embarrassing pause" during compaction which makes it
> impossible to use for applications like interactive video display that
> can't halt to compact a several gigabyte heap without causing stutter,
> and the loose memory profile.

The embarassing pause is characteristic of a so-called "stop the
world" gc.  A gc where any pauses are guaranteed bounded in size
(preferably to a small value) is called a "real time" gc.  I believe
Cheng's algorithm is a real time alg but it's been a while since I
read that thesis.

Anyway, nobody programs interactive video in Python, and Python's ref
counting scheme is not real time since it may have to do arbitrarily
many decrefs when you release a large structure.

> As far as parallelism problems with GC go... the only ones I can
> imagine is that if you had a lot of threads going generating lots of
> garbage you would need to start to compact more frequently. Since
> compaction halts all threads, this could potentially cause very
> frequent compactions? Is that what you were getting at? 

I'm not sure what you're asking.  Parallelism is used for making
things go faster, but making things parallel usually complicates them.
A parallel realtime gc is sort of the holy grail.

Cheng's thesis is pretty readable as I remember, and discusses most of
these issues.  There is also a book by Appel about gc, but it's
perhaps a little bit dated by now.



More information about the Python-list mailing list