Konfigurieren der JavaScript-Engine
Die Ausführung von JavaScript-Code kann insbesondere durch einige Umgebungsvariablen beeinflusst werden:
| 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 können. Diese Umgebungsvariable bestimmt, wie oft eine Funktion ausgeführt werden muss, damit sie für die JIT-Kompilierung in Frage kommt. Der Standardwert ist 3 Mal. |
QV4_FORCE_INTERPRETER | Wenn Sie diese Umgebungsvariable setzen, werden alle Funktionen und Ausdrücke durch den Interpreter ausgeführt. Der JIT wird nie verwendet, egal wie oft eine Funktion oder ein Ausdruck aufgerufen wird. Funktionen und Ausdrücke können immer noch im Voraus mit qmlcachegen oder qmlsc kompiliert werden, aber nur der generierte Bytecode wird zur Laufzeit verwendet. Jeder generierte C++-Code und der daraus resultierende Maschinencode wird ignoriert. |
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. Normalerweise 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 Bytes, der als JavaScript-Stack zugewiesen wird. |
QV4_GC_MAX_STACK_SIZE | Zusätzlich zum regulären JavaScript-Stack hält die JavaScript-Engine einen weiteren Stack für den Garbage Collector vor, der normalerweise 2 MB groß ist. Wenn der Garbage Collector eine übermäßige Anzahl von Objekten gleichzeitig verarbeiten muss, kann dieser Stack überlaufen. Wenn sie eine Zahl enthält, wird diese Umgebungsvariable als die Größe des Speicherbereichs in Bytes interpretiert, der als Stack für den Garbage Collector zugewiesen wird. |
QV4_CRASH_ON_STACKOVERFLOW | Normalerweise versucht die JavaScript-Engine, C++-Stack-Überläufe abzufangen, die durch übermäßig rekursiven JavaScript-Code verursacht werden, und erzeugt eine nicht-fatale Fehlerbedingung. Es gibt separate Rekursionsprüfungen für die Kompilierung von JavaScript und die Ausführung von JavaScript. Ein Stapelüberlauf beim Kompilieren von JavaScript zeigt an, dass der Code tief verschachtelte Objekte und Funktionen enthält. Ein Stack-Überlauf zur Laufzeit zeigt an, dass der Code zu einem tief rekursiven Programm führt. Die Prüfung darauf hängt nur indirekt mit der oben erwähnten JavaScript-Stack-Größe zusammen, da jeder JavaScript-Funktionsaufruf sowohl auf dem C++- als auch auf dem JavaScript-Stack Speicherplatz verbraucht. Der Code, der auf übermäßige Rekursion prüft, ist notwendigerweise konservativ, da die verfügbare Stackgröße von vielen Faktoren abhängt und oft vom Benutzer angepasst werden kann. Wenn diese Umgebungsvariable gesetzt ist, prüft die JavaScript-Engine beim Kompilieren oder Ausführen von JavaScript nicht auf Stack-Überläufe und generiert keine Ausnahmen dafür. Wenn der Stack überläuft, versucht das Programm stattdessen einen ungültigen Speicherzugriff. Dies führt höchstwahrscheinlich zum Abbruch des Programms. Im Gegenzug verbraucht das Programm den gesamten Stack-Speicher, den das Betriebssystem zur Verfügung stellen kann. Achtung: Bösartiger Code kann die Beendigung umgehen und auf diese Weise auf unerwartete Speicherplätze zugreifen. |
QV4_MAX_CALL_DEPTH | Stapelüberläufe bei der Ausführung (im Gegensatz zur Kompilierung) von JavaScript werden durch die Kontrolle der Aufruftiefe verhindert: die Anzahl der verschachtelten Funktionsaufrufe. Standardmäßig wird eine Ausnahme erzeugt, wenn die Aufruftiefe eine Höchstzahl überschreitet, die auf die Standard-Stackgröße der Plattform abgestimmt ist. Wenn die Umgebungsvariable QV4_MAX_CALL_DEPTH eine Zahl enthält, wird diese Zahl als maximale Aufruftiefe verwendet. Beachten Sie, dass die Rekursionsgrenze beim Kompilieren von JavaScript nicht beeinflusst wird. Die standardmäßige maximale Aufruftiefe beträgt auf den meisten Plattformen 1234. Auf QNX ist sie 640, da auf QNX die Standard-Stackgröße kleiner ist als auf den meisten Plattformen. |
QV4_MM_AGGRESSIVE_GC | Wenn Sie diese Umgebungsvariable setzen, wird der Garbage Collector vor jeder Speicherzuweisung gestartet. Dies ist zur Laufzeit sehr teuer, deckt aber schnell viele Fehler in der Speicherverwaltung auf, zum Beispiel das manuelle Löschen eines Objekts, das zur QML-Engine von C++ gehört. |
QV4_PROFILE_WRITE_PERF_MAP | Unter Linux kann das Dienstprogramm perf verwendet werden, um Programme zu profilieren. Um JIT-kompilierte JavaScript-Funktionen zu analysieren, muss es deren Namen und Speicherplatz kennen. Um diese Informationen zur Verfügung zu stellen, wird eine spezielle Datei namens perf-<pid>.map in /tmp angelegt, die perf dann liest. Wenn diese Umgebungsvariable gesetzt ist, veranlasst sie das JIT, diese Datei zu erzeugen. |
QV4_SHOW_BYTECODE | Gibt den von Qt erzeugten IR-Bytecode auf der Konsole aus. Muss mit QML_DISABLE_DISK_CACHE kombiniert werden, sonst wird der bereits gecachte Bytecode nicht angezeigt. |
QV4_DUMP_BASIC_BLOCKS | Gibt die Basisblöcke jeder Funktion aus, die im Voraus kompiliert wurde. 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 erzeugt. 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 die Dateien nicht geöffnet werden, werden die Graphen stattdessen nach stdout ausgegeben. |
QV4_VALIDATE_BASIC_BLOCKS | Überprüft die Basisblöcke einer Funktion, die im Voraus kompiliert wurde, um ihre Struktur und Kohärenz zu überprüfen. Wenn die Überprüfung fehlschlägt, wird eine Fehlermeldung auf der Konsole ausgegeben. |
Der QML Disk Cache akzeptiert weitere Umgebungsvariablen, die eine Feinabstimmung seines Verhaltens ermöglichen. Insbesondere QML_DISABLE_DISK_CACHE kann für die Fehlersuche nützlich sein.
© 2025 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.
