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