[Python-3000] Delayed reference counting idea

[Michael Chermside]

Greg Ewing writes:
> A worry about that is whether the architecture required to
> allow pluggable GC implementations introduces inefficiencies
> of its own that would skew the results.

Bob Ippolito
> There's no need to worry about that in the case of PyPy. Those kinds
> of choices are made way before runtime, so there's no required
> indirection.


Someone who knows PyPy better than me feel free to chime in if I
get things wrong, but I *think* that when it happens well before
runtime, well before compile-time, more equivalent to "time at
which the interpreter is compiled". So if you have PyPy set up to
compile to C and use reference counting GC, then it generates
calls to INCR and DECR before and after variable accesses, but
if you have it set up to compile to the LLVM which has its own
tracing GC then it doesn't generate anything before and after
variable accesses.


Greg again:
> Even so, we're talking about machine-generated code rather
> than the sort of hand-crafting you need to get the best
> out of something critical like GC. There could still be
> room for inefficiencies.

Quite true. As further illustration Python's GC is written in
C and thus you can't get the kind of efficiency you might out
of hand-crafted assembly. Unless of course the machine generating
the code is actually smarter about optimization than the hand
that's crafting it, or if the two are close enough in performance
that we don't mind.

I don't think PyPy has anything to teach us about GC performance
*yet*, but I think their approach is quite promissing as a
platform for running this kind of experiment.

-- Michael Chermside