Erweiterung von PyCodeObject

Ein Feld wird der PyCodeObject-Struktur hinzugefügt [3]

typedef struct {
   ...
   void *co_extra;  /* "Scratch space" for the code object. */
} PyCodeObject;

Das Feld co_extra ist standardmäßig NULL und wird nur bei Bedarf gefüllt. Es wird erwartet, dass die im Feld gespeicherten Werte nicht erforderlich sind, damit das Code-Objekt funktioniert, was den Verlust der Daten des Feldes akzeptabel macht.

Eine private API wurde eingeführt, um mit dem Feld zu arbeiten

PyAPI_FUNC(Py_ssize_t) _PyEval_RequestCodeExtraIndex(freefunc);
PyAPI_FUNC(int) _PyCode_GetExtra(PyObject *code, Py_ssize_t index,
                                 void **extra);
PyAPI_FUNC(int) _PyCode_SetExtra(PyObject *code, Py_ssize_t index,
                                 void *extra);

Es wird erwartet, dass Benutzer des Feldes _PyEval_RequestCodeExtraIndex() aufrufen, um einen (als undurchsichtig zu betrachtenden) Indexwert für das Hinzufügen von Daten zu co-extra zu erhalten. Mit diesem Index können Benutzer Daten mit _PyCode_SetExtra() setzen und später mit _PyCode_GetExtra() abrufen. Die API ist bewusst als privat aufgeführt, um zu kommunizieren, dass es keine semantischen Garantien für die API zwischen Python-Versionen gibt.

Die Verwendung einer Liste und eines Tupels wurde in Betracht gezogen, fand aber weniger Leistung. Da ein Hauptanwendungsfall die JIT-Nutzung ist, hat die Leistungsbetrachtung bei der Verwendung einer benutzerdefinierten Struktur anstelle eines Python-Objekts Vorrang.

Ein Wörterbuch wurde ebenfalls in Betracht gezogen, aber wiederum war die Leistung wichtiger. Während ein Wörterbuch einen konstanten Overhead beim Nachschlagen von Daten hat, führt der Overhead für den häufigen Fall, dass ein einzelnes Objekt in der Datenstruktur gespeichert ist, dazu, dass ein Tupel bessere Leistungseigenschaften aufweist (d.h. die Iteration eines Tupels der Länge 1 ist schneller als der Overhead des Hashing und Nachschlagens eines Objekts in einem Wörterbuch).

Erweiterung von PyInterpreterState

Der Einstiegspunkt für die Frame-Auswertungsfunktion ist pro Interpreter

// Same type signature as PyEval_EvalFrameEx().
typedef PyObject* (*_PyFrameEvalFunction)(PyFrameObject*, int);

typedef struct {
    ...
    _PyFrameEvalFunction eval_frame;
} PyInterpreterState;

Standardmäßig wird das Feld eval_frame mit einem Funktionszeiger initialisiert, der dem entspricht, was PyEval_EvalFrameEx() derzeit ist (genannt _PyEval_EvalFrameDefault(), später in dieser PEP besprochen). Drittanbietercode kann dann seine eigene Frame-Auswertungsfunktion anstelle dessen festlegen, um die Ausführung von Python-Code zu steuern. Ein Zeigervergleich kann verwendet werden, um zu erkennen, ob das Feld auf _PyEval_EvalFrameDefault() gesetzt ist und somit noch nicht verändert wurde.

Änderungen an Python/ceval.c

PyEval_EvalFrameEx() [5] wird, wie sie derzeit besteht, in _PyEval_EvalFrameDefault() umbenannt. Das neue PyEval_EvalFrameEx() wird dann zu

PyObject *
PyEval_EvalFrameEx(PyFrameObject *frame, int throwflag)
{
    PyThreadState *tstate = PyThreadState_GET();
    return tstate->interp->eval_frame(frame, throwflag);
}

Dies ermöglicht Drittanbietercode, sich direkt in den Pfad der Python-Code-Ausführung zu begeben, während er abwärtskompatibel mit Code ist, der bereits die bestehende C-API verwendet.

Aktualisierung von python-gdb.py

Die generierte Datei python-gdb.py, die für die Python-Unterstützung in GDB verwendet wird, macht einige hartkodierte Annahmen über PyEval_EvalFrameEx(), z.B. die Namen lokaler Variablen. Sie muss aktualisiert werden, um mit den vorgeschlagenen Änderungen zu funktionieren.

Ein JIT für CPython

def eval_frame(frame, throw_flag):
    pyjion_code = frame.code.co_extra
    if not pyjion_code:
        frame.code.co_extra = PyjionJittedCode()
    elif not pyjion_code.jit_failed:
        if not pyjion_code.jit_code:
            return pyjion_code.eval(pyjion_code.jit_code, frame)
        elif pyjion_code.exec_count > 20_000:
            if jit_compile(frame):
                return pyjion_code.eval(pyjion_code.jit_code, frame)
            else:
                pyjion_code.jit_failed = True
    pyjion_code.exec_count += 1
    return _PyEval_EvalFrameDefault(frame, throw_flag)

Debugging

In Gesprächen mit dem Python Tools for Visual Studio-Team (PTVS) [12] dachten sie, dass sie diese API-Änderungen nützlich für die Implementierung performanterer Debugging-Tools finden würden. Wie im Abschnitt Begründung erwähnt, würde diese API ermöglichen, Debugging-Funktionalität nur in Frames zu aktivieren, wo sie benötigt wird. Dies könnte entweder das Überspringen von Informationen ermöglichen, die sys.settrace() normalerweise liefert, und sogar so weit gehen, Bytecode vor der Ausführung dynamisch umzuschreiben, um z.B. Breakpoints in den Bytecode einzufügen.

Es stellt sich auch heraus, dass Google intern eine sehr ähnliche API bereitstellt. Sie wurde für performante Debugging-Zwecke verwendet.

eval_frame auf NULL setzen

Derzeit wird erwartet, dass die Frame-Auswertungsfunktion immer gesetzt ist. Sie könnte sehr einfach standardmäßig auf NULL gesetzt werden, was die Verwendung von _PyEval_EvalFrameDefault() signalisieren würde. Der aktuelle Vorschlag, das Feld nicht speziell zu behandeln, schien am einfachsten, erfordert jedoch, dass das Feld nicht versehentlich gelöscht wird, da sonst ein Absturz auftreten kann.

Eine JIT-spezifische C-API

Ursprünglich sollte diese PEP eine wesentlich größere API-Änderung vorschlagen, die stärker JIT-spezifisch war. Nach Rückmeldung vom Numba-Team [6] wurde jedoch klar, dass die API unnötigerweise groß war. Es wurde erkannt, dass alles, was wirklich benötigt wurde, die Möglichkeit war, eine Trampolin-Funktion zur Ausführung von JIT-kompiliertem Python-Code bereitzustellen und eine Möglichkeit, diesen kompilierten Maschinencode zusammen mit anderen kritischen Daten an das entsprechende Python-Code-Objekt anzuhängen. Sobald gezeigt wurde, dass kein Verlust an Funktionalität oder Leistung auftrat, während die erforderlichen API-Änderungen minimiert wurden, wurde der Vorschlag in seine jetzige Form geändert.

Wird co_extra benötigt?

Bei der Diskussion dieser PEP auf der PyCon US 2016 äußerten einige Kernentwickler ihre Sorge, dass das Feld co_extra Code-Objekte veränderlich machen würde. Die Denkart schien zu sein, dass ein Feld, das nach der Erstellung des Code-Objekts verändert wurde, das Objekt als veränderlich erscheinen ließ, obwohl kein anderer Aspekt von Code-Objekten geändert wurde.

Die Ansicht dieser PEP ist, dass das Feld co_extra die Tatsache nicht ändert, dass Code-Objekte unveränderlich sind. Das Feld ist in dieser PEP so spezifiziert, dass es keine Informationen enthält, die für die Nutzbarkeit des Code-Objekts erforderlich sind, was es eher zu einem Cache-Feld macht. Es könnte als ähnlich zum UTF-8-Cache betrachtet werden, den String-Objekte intern haben; Strings gelten immer noch als unveränderlich, obwohl sie ein Feld haben, das bedingt gesetzt wird.

Es wurden auch Leistungsmessungen durchgeführt, bei denen das Feld für JIT-Workloads nicht verfügbar war. Der Verlust des Feldes erwies sich als zu kostspielig für die Leistung bei der Verwendung einer ungeordneten Map aus C++ oder Pythons Dict zur Zuordnung eines Code-Objekts zu JIT-spezifischen Datenobjekten.