Konfiguration der JavaScript-Engine
Die Ausführung von JavaScript-Code kann durch einige Umgebungsvariablen beeinflusst werden, insbesondere:
| Umgebungsvariable | Beschreibung |
|---|---|
QV4_JIT_CALL_THRESHOLD | Die JavaScript-Engine enthält einen Just-In-Time-Compiler (JIT). Der JIT kompiliert häufig ausgeführte JavaScript-Funktionen in Maschinencode, damit sie schneller ausgeführt werden. Diese Umgebungsvariable legt fest, wie oft eine Funktion ausgeführt werden muss, damit sie für die JIT-Kompilierung in Betracht kommt. Der Standardwert ist 3 Mal. |
QV4_FORCE_INTERPRETER | Durch das Setzen dieser Umgebungsvariable werden alle Funktionen und Ausdrücke über den Interpreter ausgeführt. Der JIT wird niemals verwendet, unabhängig davon, wie oft eine Funktion oder ein Ausdruck aufgerufen wird. Funktionen und Ausdrücke können weiterhin vorab mit `qmlcachegen` oder `qmlsc` kompiliert werden, doch zur Laufzeit wird nur der generierte Bytecode verwendet. Der generierte C++-Code und der daraus resultierende Maschinencode werden ignoriert. |
QV4_FAIL_ON_INVALID_AOT | In C++ kompilierter QML-Code wird zur Laufzeit validiert. Wenn diese Validierung fehlschlägt, wird der Code standardmäßig interpretiert, anstatt als nativer Code ausgeführt zu werden. Ist diese Umgebungsvariable gesetzt, führt ein Validierungsfehler stattdessen zum Abbruch des Programms. Dies kann nützlich sein, um sicherzustellen, dass der gesamte Code, der als nativer Code ausgeführt werden kann, auch tatsächlich als solcher ausgeführt wird. |
QV4_SKIP_AOT_VALIDATION | Diese Umgebungsvariable überspringt die Laufzeitvalidierung von C++-Code, der für kompilierten QML-Code generiert wurde. Dies kann genutzt werden, um den Overhead der Validierung selbst zu vermeiden. Beachten Sie, dass hiermit lediglich die Validierung übersprungen wird. Es wird nicht verhindert, dass der Validierungscode selbst von `qmlcachegen` generiert wird. Verwenden Sie hierfür die Option ` NO_GENERATE_AOT_VALIDATION ` von `qt_add_qml_module`. |
QV4_JS_MAX_STACK_SIZE | Die JavaScript-Engine reserviert einen speziellen Speicherbereich als Stack für die Ausführung von JavaScript. Dieser Stack ist vom C++-Stack getrennt. In der Regel ist dieser Bereich 4 MB groß. Wenn diese Umgebungsvariable eine Zahl enthält, interpretiert die JavaScript-Engine diese als die Größe des Speicherbereichs in Byte, der als JavaScript-Stack zugewiesen werden soll. |
QV4_GC_MAX_STACK_SIZE | Zusätzlich zum regulären JavaScript-Stack verwaltet die JavaScript-Engine einen weiteren Stack für den Garbage Collector, der in der Regel 2 MB Speicher umfasst. Wenn der Garbage Collector eine übermäßige Anzahl von Objekten gleichzeitig verarbeiten muss, kann dieser Stack überlaufen. Enthält diese Umgebungsvariable eine Zahl, wird diese als Größe des Speicherbereichs in Byte interpretiert, der als Stack für den Garbage Collector zugewiesen wird. |
QV4_STACK_SOFT_LIMIT | Ist diese Umgebungsvariable gesetzt, löst die JavaScript-Engine die Ausnahme „RangeError: Maximum call stack size exceeded“ aus, sobald die Auslastung des Aufrufstapels das definierte Soft-Limit erreicht. Ist die Variable nicht gesetzt, verwendet die Engine je nach Betriebssystem standardmäßig die zur Laufzeit ermittelten oder die von Qt vordefinierten Grenzwerte. |
QV4_CRASH_ON_STACKOVERFLOW | In der Regel versucht die JavaScript-Engine, durch übermäßig rekursiven JavaScript-Code verursachte C++-Stapelüberläufe abzufangen und erzeugt einen nicht schwerwiegenden Fehlerzustand. Es gibt separate Rekursionsprüfungen für das Kompilieren und das Ausführen von JavaScript. Ein Stapelüberlauf beim Kompilieren von JavaScript deutet darauf hin, dass der Code tief verschachtelte Objekte und Funktionen enthält. Ein Stapelüberlauf zur Laufzeit deutet darauf hin, dass der Code zu einem stark rekursiven Programm führt. Die entsprechende Überprüfung steht nur indirekt im Zusammenhang mit der oben erwähnten JavaScript-Stapelgröße, da jeder JavaScript-Funktionsaufruf Stapelplatz sowohl auf dem C++- als auch auf dem JavaScript-Stapel beansprucht. Der Code, der auf übermäßige Rekursion prüft, ist zwangsläufig konservativ, da die verfügbare Stapelgröße von vielen Faktoren abhängt und oft vom Benutzer angepasst werden kann. Ist diese Umgebungsvariable gesetzt, prüft die JavaScript-Engine beim Kompilieren oder Ausführen von JavaScript nicht auf Stapelüberläufe und löst dafür keine Ausnahmen aus. Stattdessen versucht das Programm bei einem Stapelüberlauf einen ungültigen Speicherzugriff. Dies führt höchstwahrscheinlich zum Abbruch des Programms. Im Gegenzug kann das Programm den gesamten Stapelplatz nutzen, den das Betriebssystem zur Verfügung stellt. Warnung: Bösartiger Code könnte auf diese Weise den Abbruch umgehen und auf unerwartete Speicherorte zugreifen. |
QV4_MAX_CALL_DEPTH | Stack-Überläufe bei der Ausführung (im Gegensatz zur Kompilierung) von JavaScript werden durch die Steuerung der Aufruf-Tiefe verhindert: der Anzahl der verschachtelten Funktionsaufrufe. Standardmäßig wird eine Ausnahme ausgelöst, wenn die Aufruf-Tiefe einen Höchstwert überschreitet, der auf die standardmäßige Stack-Größe der Plattform abgestimmt ist. Enthält die Umgebungsvariable ` QV4_MAX_CALL_DEPTH ` eine Zahl, wird diese als maximale Aufruf-Tiefe verwendet. Beachten Sie, dass die Rekursionsgrenze beim Kompilieren von JavaScript davon nicht betroffen ist. Die standardmäßige maximale Aufruf-Tiefe beträgt auf den meisten Plattformen 1234. Auf QNX beträgt sie 640, da die Standard-Stackgröße auf QNX kleiner ist als auf den meisten anderen Plattformen. |
| Dieser Wert dient dazu, der Engine mitzuteilen, wie viel Zeit sie für jeden inkrementellen Garbage-Collection-Schritt aufwenden soll. Er kann entweder eine positive Zahl sein, die das Zeitlimit in Millisekunden angibt, oder 0. Ist der Wert 0, erfolgt die Garbage Collection nicht mehr inkrementell. |
QV4_MM_AGGRESSIVE_GC | Durch das Setzen dieser Umgebungsvariable wird der Garbage Collector vor jeder Speicherzuweisung ausgeführt. Dies ist zur Laufzeit sehr aufwendig, deckt jedoch schnell viele Fehler in der Speicherverwaltung auf, beispielsweise das manuelle Löschen eines zur QML-Engine gehörenden Objekts aus C++. |
QV4_MM_CROSS_VALIDATE_INCREMENTAL_GC | Durch das Setzen dieser Umgebungsvariable werden zusätzliche Debugging-Schritte ausgeführt, um Fälle zu erkennen, in denen sich der inkrementelle Garbage Collector fehlerhaft verhält, indem sein Verhalten mit dem des nicht-inkrementellen Garbage Collectors verglichen wird. |
QV4_PROFILE_WRITE_PERF_MAP | Unter Linux kann das Dienstprogramm „ perf “ zum Profiling von Programmen verwendet werden. Um JIT-kompilierte JavaScript-Funktionen zu analysieren, benötigt es Informationen zu deren Namen und Speicherorten. Um diese Informationen bereitzustellen, gibt es die Konvention, eine spezielle Datei namens „ perf-<pid>.map “ im Verzeichnis /tmp zu erstellen, die dann von „perf“ gelesen wird. Diese Umgebungsvariable bewirkt, sofern sie gesetzt ist, dass der JIT diese Datei generiert. |
QV4_SHOW_BYTECODE | Gibt den von Qt generierten IR-Bytecode auf der Konsole aus. Muss mit „ QML_DISABLE_DISK_CACHE “ kombiniert werden, da sonst bereits zwischengespeicherter Bytecode nicht angezeigt wird. |
QV4_DUMP_BASIC_BLOCKS | Gibt die Basisblöcke jeder vorab kompilierten Funktion aus. Die Details der Blöcke werden auf der Konsole ausgegeben. Zusätzlich werden für jede kompilierte Funktion Kontrollflussgraphen mit dem Bytecode für jeden Block im DOT-Format generiert. Der Wert von ` QV4_DUMP_BASIC_BLOCKS ` wird als Pfad zu dem Ordner verwendet, in dem die DOT-Dateien erzeugt werden sollen. Ist der Pfad einer der Werte ["-", "1", "true"] oder können Dateien nicht geöffnet werden, werden die Graphen stattdessen auf stdout ausgegeben. |
QV4_VALIDATE_BASIC_BLOCKS | Führt Überprüfungen der Grundblöcke einer vorab kompilierten Funktion durch, um deren Struktur und Kohärenz zu validieren. Wenn die Validierung fehlschlägt, wird eine Fehlermeldung auf der Konsole ausgegeben. |
Der QML-Festplatten-Cache akzeptiert weitere Umgebungsvariablen, mit denen sich sein Verhalten feinabstimmen lässt. Insbesondere „ QML_DISABLE_DISK_CACHE “ kann für die Fehlersuche nützlich sein.
© 2026 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.
