A couple garbage collector questions
Hannah Schroeter
hannah at schlund.de
Mon Apr 23 12:05:35 EDT 2001
Hello!
In article <mailman.986918018.20813.python-list at python.org>,
Jeremy Hylton <jeremy at digicool.com> wrote:
[reference count updating optimizations]
>This would be a mammoth project for Python. The Python VM performs
>reference counting without any compiler support. The compiler emits
>an instruction like DUP_TOP (duplicate object on top of stack). The
>VM incremenents the reference count of the object as part of the
>DUP_TOP implementation.
Yes, agree. From a practical POV, it'd probably be difficult both
to switch completely to a GC (e.g. a generational one), and to
optimize RC updates.
Except... I don't know python's internal implementation structures,
but if it could be possible to change the current VM interpreter
into either a load-time VM->native compiler (doing some dataflow
analysis on the VM level for optimizations), or some JIT based
interpreter/compiler hybrid, you'd perhaps be able to gain some speed
even with retaining the external interface to the rest of the
runtime as well as extension modules.
>The Python VM instructions are high level and, thus, fairly
>expensive. To get compiler support for managing reference counts,
>we'd need to go with a completely different VM that included reference
>count operations as part of the instruction set. The current
>per-instruction overhead would dwarf the cost of the ref counts. So
>without a significant redesign, this approach would probably slow down
>the interpreter enormously.
>The idea seems reasonable, so far as I can tell. But we have neither
>the compiler infrastructure nor the VM support we would need to make
>it work.
Yep. And it seems, there is not too much real pressure for a change
of that complexity either, as Python will surely be fast enough for
most of its usage areas, anyway.
>Jeremy
Kind regards,
Hannah.
More information about the Python-list
mailing list