IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Configuring the JavaScript Engine

Describes the environment variables available, to control how Javascript is run.

Article lu   fois.

L'auteur

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

Configuring the JavaScript Engine

Running JavaScript code can be influenced by a few environment variables, particularly:

Environment Variable

Description

QV4_JIT_CALL_THRESHOLD

The JavaScript engine contains a Just-In-Time compiler (JIT). The JIT will compile frequently run JavaScript functions into machine code to run faster. This environment variable determines how often a function needs to be run to be considered for JIT compilation. The default value is 3 times.

QV4_FORCE_INTERPRETER

Setting this environment variable disables the JIT and runs all functions through the interpreter, no matter how often they are called.

QV4_JS_MAX_STACK_SIZE

The JavaScript engine reserves a special memory area as a stack to run JavaScript. This stack is separate from the C++ stack. Usually this area is 4MB in size. If this environment variable contains a number, the JavaScript engine interprets it as the size of the memory area, in bytes, to be allocated as the JavaScript stack.

QV4_GC_MAX_STACK_SIZE

In addition to the regular JavaScript stack, the JavaScript engine keeps another stack for the garbage collector, usually 2MB of memory. If the garbage collector needs to handle an excessive number of objects at the same time, this stack might overrun. If it contains a number, this environment variable is interpreted as the size in bytes of the memory area that will be allocated as the stack for the garbage collector.

QV4_CRASH_ON_STACKOVERFLOW

Usually the JavaScript engine tries to catch C++ stack overflows caused by excessively recursive JavaScript code, and generates a non-fatal error condition. There are separate recursion checks for compiling JavaScript and running JavaScript. A stack overflow when compiling JavaScript indicates that the code contains deeply nested objects and functions. A stack overflow at run-time indicates that the code results in a deeply recursive program. The check for this is only indirectly related to the JavaScript stack size mentioned above, as each JavaScript function call consumes stack space on both, the C++ and the JavaScript stack. The code that checks for excessive recursion is necessarily conservative, as the available stack size depends on many factors and can often be customized by the user. With this environment variable set, the JavaScript engine does not check for stack overflows when compiling or running JavaScript and will not generate exceptions for them. Instead, when the stack overflows the program attempts an invalid memory access. This most likely terminates the program. In turn, the program gets to use up all the stack space the operating system can provide.

malicious code may be able to evade the termination and access unexpected memory locations this way.

QV4_MAX_CALL_DEPTH

Stack overflows when running (as opposed to compiling) JavaScript are prevented by controlling the call depth: the number of nested function invocations. By default, an exception is generated if the call depth exceeds a maximum number tuned to the platform's default stack size. If the QV4_MAX_CALL_DEPTH environment variable contains a number, this number is used as maximum call depth. Beware that the recursion limit when compiling JavaScript is not affected. The default maximum call depth is 1234 on most platforms. On QNX it is 640 because on QNX the default stack size is smaller than on most platforms.

QV4_MM_AGGRESSIVE_GC

Setting this environment variable runs the garbage collector before each memory allocation. This is very expensive at run-time, but it quickly uncovers many memory management errors, for example the manual deletion of an object belonging to the QML engine from C++.

QV4_PROFILE_WRITE_PERF_MAP

On Linux, the perf utility can be used to profile programs. To analyze JIT-compiled JavaScript functions, it needs to know about their names and locations in memory. To provide this information, there's a convention to create a special file called perf-<pid>.map in /tmp which perf then reads. This environment variable, if set, causes the JIT to generate this file.

QML_DISABLE_DISK_CACHE

Disables the disk cache. See The QML Disk Cache.

QV4_SHOW_BYTECODE

Outputs the IR bytecode generated by Qt to the console. Has to be combined with QML_DISABLE_DISK_CACHE or already cached bytecode will not be shown.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+