jlaskey@3: This document describes system properties that are used for internal jlaskey@3: debugging and instrumentation purposes, along with the system loggers, jlaskey@3: which are used for the same thing. jlaskey@3: jlaskey@3: This document is intended as a developer resource, and it is not jlaskey@3: needed as Nashorn documentation for normal usage. Flags and system jlaskey@3: properties described herein are subject to change without notice. jlaskey@3: jlaskey@3: ===================================== jlaskey@3: 1. System properties used internally jlaskey@3: ===================================== jlaskey@3: jlaskey@3: This documentation of the system property flags assume that the jlaskey@3: default value of the flag is false, unless otherwise specified. jlaskey@3: lagergren@147: SYSTEM PROPERTY: -Dnashorn.args= lagergren@147: lagergren@147: This property takes as its value a space separated list of Nashorn lagergren@526: command line options that should be passed to Nashorn. This might be lagergren@526: useful in environments where it is hard to tell how a nashorn.jar is lagergren@526: launched. lagergren@147: lagergren@147: Example: lagergren@147: lagergren@147: > java -Dnashorn.args="--lazy-complation --log=compiler" large-java-app-with-nashorn.jar lagergren@147: > ant -Dnashorn.args="--log=codegen" antjob lagergren@147: hannesw@1068: SYSTEM PROPERTY: -Dnashorn.args.prepend= hannesw@1068: hannesw@1068: This property behaves like nashorn.args, but adds the given arguments hannesw@1068: before the existing ones instead of after them. Later arguments will hannesw@1068: overwrite earlier ones, so this is useful for setting default arguments hannesw@1068: that can be overwritten. hannesw@1068: hannesw@1068: lagergren@8: SYSTEM PROPERTY: -Dnashorn.unstable.relink.threshold=x lagergren@8: lagergren@8: This property controls how many call site misses are allowed before a lagergren@8: callsite is relinked with "apply" semantics to never change again. lagergren@8: In the case of megamorphic callsites, this is necessary, or the lagergren@8: program would spend all its time swapping out callsite targets. Dynalink lagergren@8: has a default value (currently 8 relinks) for this property if it lagergren@8: is not explicitly set. lagergren@8: jlaskey@3: hannesw@83: SYSTEM PROPERTY: -Dnashorn.compiler.splitter.threshold=x lagergren@24: lagergren@24: This will change the node weight that requires a subgraph of the IR to lagergren@24: be split into several classes in order not to run out of bytecode space. lagergren@24: The default value is 0x8000 (32768). lagergren@24: lagergren@24: hannesw@1068: SYSTEM PROPERTY: -Dnashorn.serialize.compression= jlaskey@3: hannesw@1068: This property sets the compression level used when deflating serialized hannesw@1068: AST structures of anonymous split functions. Valid values range from 0 to 9, hannesw@1068: the default value is 4. Higher values will reduce memory size of serialized hannesw@1068: AST but increase CPU usage required for compression. lagergren@526: lagergren@526: hannesw@1068: SYSTEM PROPERTY: -Dnashorn.codegen.debug.trace= jlaskey@3: jlaskey@3: See the description of the codegen logger below. jlaskey@3: jlaskey@3: hannesw@1330: SYSTEM PROPERTY: -Dnashorn.fields.objects, -Dnashorn.fields.dual jlaskey@3: hannesw@1330: When the nashorn.fields.objects property is true, Nashorn will always hannesw@1330: use object fields for AccessorProperties, requiring boxing for all hannesw@1330: primitive property values. When nashorn.fields.dual is set, Nashorn hannesw@1330: will always use dual long/object fields, which allows primitives to be hannesw@1330: stored without boxing. When neither system property is set, Nashorn hannesw@1330: chooses a setting depending on the optimistic types setting (dual hannesw@1330: fields when optimistic types are enabled, object-only fields otherwise). jlaskey@3: hannesw@1330: With dual fields, Nashorn uses long fields to store primitive values. hannesw@1330: Ints are represented as the 32 low bits of the long fields. Doubles hannesw@1330: are represented as the doubleToLongBits of their value. This way a hannesw@1068: single field can be used for all primitive types. Packing and hannesw@1068: unpacking doubles to their bit representation is intrinsified by hannesw@1068: the JVM and extremely fast. jlaskey@3: jlaskey@3: In the future, this might complement or be replaced by experimental jlaskey@3: feature sun.misc.TaggedArray, which has been discussed on the mlvm jlaskey@3: mailing list. TaggedArrays are basically a way to share data space jlaskey@3: between primitives and references, and have the GC understand this. jlaskey@3: jlaskey@3: lagergren@57: SYSTEM PROPERTY: -Dnashorn.compiler.symbol.trace=[[,*]], lagergren@57: -Dnashorn.compiler.symbol.stacktrace=[[,*]] jlaskey@3: jlaskey@3: When this property is set, creation and manipulation of any symbol jlaskey@3: named "x" will show information about when the compiler changes its jlaskey@3: type assumption, bytecode local variable slot assignment and other jlaskey@3: data. This is useful if, for example, a symbol shows up as an Object, jlaskey@3: when you believe it should be a primitive. Usually there is an jlaskey@3: explanation for this, for example that it exists in the global scope lagergren@57: and type analysis has to be more conservative. lagergren@57: lagergren@57: Several symbols names to watch can be specified by comma separation. lagergren@57: lagergren@57: If no variable name is specified (and no equals sign), all symbols lagergren@57: will be watched lagergren@57: lagergren@57: By using "stacktrace" instead of or together with "trace", stack lagergren@57: traces will be displayed upon symbol changes according to the same lagergren@57: semantics. jlaskey@3: jlaskey@3: lagergren@526: SYSTEM PROPERTY: -Dnashorn.lexer.xmlliterals jlaskey@3: jlaskey@3: If this property it set, it means that the Lexer should attempt to jlaskey@3: parse XML literals, which would otherwise generate syntax jlaskey@3: errors. Warning: there are currently no unit tests for this jlaskey@3: functionality. jlaskey@3: jlaskey@3: XML literals, when this is enabled, end up as standard LiteralNodes in jlaskey@3: the IR. jlaskey@3: jlaskey@3: lagergren@526: SYSTEM_PROPERTY: -Dnashorn.debug jlaskey@3: jlaskey@3: If this property is set to true, Nashorn runs in Debug mode. Debug jlaskey@3: mode is slightly slower, as for example statistics counters are enabled jlaskey@3: during the run. Debug mode makes available a NativeDebug instance jlaskey@3: called "Debug" in the global space that can be used to print property jlaskey@3: maps and layout for script objects, as well as a "dumpCounters" method jlaskey@3: that will print the current values of the previously mentioned stats jlaskey@3: counters. jlaskey@3: jlaskey@3: These functions currently exists for Debug: jlaskey@3: jlaskey@3: "map" - print(Debug.map(x)) will dump the PropertyMap for object x to jlaskey@3: stdout (currently there also exist functions called "embedX", where X jlaskey@3: is a value from 0 to 3, that will dump the contents of the embed pool jlaskey@3: for the first spill properties in any script object and "spill", that jlaskey@3: will dump the contents of the growing spill pool of spill properties jlaskey@3: in any script object. This is of course subject to change without jlaskey@3: notice, should we change the script object layout. jlaskey@3: jlaskey@3: "methodHandle" - this method returns the method handle that is used jlaskey@3: for invoking a particular script function. jlaskey@3: jlaskey@3: "identical" - this method compares two script objects for reference jlaskey@3: equality. It is a == Java comparison jlaskey@3: hannesw@1068: "equals" - Returns true if two objects are either referentially hannesw@1068: identical or equal as defined by java.lang.Object.equals. hannesw@1068: jlaskey@3: "dumpCounters" - will dump the debug counters' current values to jlaskey@3: stdout. jlaskey@3: jlaskey@3: Currently we count number of ScriptObjects in the system, number of jlaskey@3: Scope objects in the system, number of ScriptObject listeners added, jlaskey@3: removed and dead (without references). jlaskey@3: jlaskey@3: We also count number of ScriptFunctions, ScriptFunction invocations jlaskey@3: and ScriptFunction allocations. jlaskey@3: jlaskey@3: Furthermore we count PropertyMap statistics: how many property maps jlaskey@3: exist, how many times were property maps cloned, how many times did jlaskey@3: the property map history cache hit, prevent new allocations, how many jlaskey@3: prototype invalidations were done, how many time the property map jlaskey@3: proto cache hit. jlaskey@3: jlaskey@3: Finally we count callsite misses on a per callsite bases, which occur jlaskey@3: when a callsite has to be relinked, due to a previous assumption of jlaskey@3: object layout being invalidated. jlaskey@3: hannesw@1068: "getContext" - return the current Nashorn context. jlaskey@3: hannesw@1068: "equalWithoutType" - Returns true if if the two objects are both hannesw@1068: property maps, and they have identical properties in the same order, hannesw@1068: but allows the properties to differ in their types. jlaskey@3: hannesw@1068: "diffPropertyMaps" Returns a diagnostic string representing the difference hannesw@1068: of two property maps. jlaskey@3: hannesw@1068: "getClass" - Returns the Java class of an object, or undefined if null. hannesw@1068: hannesw@1068: "toJavaString" - Returns the Java toString representation of an object. hannesw@1068: hannesw@1068: "toIdentString" - Returns a string representation of an object consisting hannesw@1068: of its java class name and hash code. hannesw@1068: hannesw@1068: "getListenerCount" - Return the number of property listeners for a hannesw@1068: script object. hannesw@1068: hannesw@1068: "getEventQueueCapacity" - Get the capacity of the event queue. hannesw@1068: hannesw@1068: "setEventQueueCapacity" - Set the event queue capacity. hannesw@1068: hannesw@1068: "addRuntimeEvent" - Add a runtime event to the runtime event queue. hannesw@1068: The queue has a fixed size (see -Dnashorn.runtime.event.queue.size) hannesw@1068: and the oldest entry will be thrown out of the queue is about to overflow. hannesw@1068: hannesw@1068: "expandEventQueueCapacity" - Expands the event queue capacity, hannesw@1068: or truncates if capacity is lower than current capacity. Then only hannesw@1068: the newest entries are kept. hannesw@1068: hannesw@1068: "clearRuntimeEvents" - Clear the runtime event queue. hannesw@1068: hannesw@1068: "removeRuntimeEvent" - Remove a specific runtime event from the event queue. hannesw@1068: hannesw@1068: "getRuntimeEvents" - Return all runtime events in the queue as an array. hannesw@1068: hannesw@1068: "getLastRuntimeEvent" - Return the last runtime event in the queue. jlaskey@3: jlaskey@3: lagergren@526: SYSTEM PROPERTY: -Dnashorn.methodhandles.debug.stacktrace jlaskey@3: hannesw@1068: This enhances methodhandles logging (see below) to also dump the hannesw@1068: stack trace for every instrumented method handle operation. hannesw@1068: Warning: This is enormously verbose, but provides a pretty jlaskey@3: decent "grep:able" picture of where the calls are coming from. jlaskey@3: jlaskey@3: hannesw@1068: SYSTEM PROPERTY: -Dnashorn.cce jlaskey@3: hannesw@1068: Setting this system property causes the Nashorn linker to rely on hannesw@1068: ClassCastExceptions for triggering a callsite relink. If not set, the linker hannesw@1068: will add an explicit instanceof guard. jlaskey@3: jlaskey@3: hannesw@1068: SYSTEM PROPERTY: -Dnashorn.spill.threshold= jlaskey@3: hannesw@1068: This property sets the number of fields in an object from which to use hannesw@1068: generic array based spill storage instead of Java fields. The default value hannesw@1068: is 256. jlaskey@3: jlaskey@3: lagergren@526: SYSTEM PROPERTY: -Dnashorn.tcs.miss.samplePercent= jlaskey@3: jlaskey@3: When running with the trace callsite option (-tcs), Nashorn will count jlaskey@3: and instrument any callsite misses that require relinking. As the jlaskey@3: number of relinks is large and usually produces a lot of output, this jlaskey@3: system property can be used to constrain the percentage of misses that jlaskey@3: should be logged. Typically this is set to 1 or 5 (percent). 1% is the jlaskey@3: default value. jlaskey@3: hannesw@1068: SYSTEM PROPERTY: -Dnashorn.persistent.code.cache jlaskey@3: hannesw@1068: This property can be used to set the directory where Nashorn stores hannesw@1068: serialized script classes generated with the -pcc/--persistent-code-cache hannesw@1068: option. The default directory name is "nashorn_code_cache". hannesw@1068: hannesw@1068: hannesw@1068: SYSTEM PROPERTY: -Dnashorn.typeInfo.maxFiles hannesw@1068: hannesw@1068: Maximum number of files to store in the type info cache. The type info cache hannesw@1068: is used to cache type data of JavaScript functions when running with hannesw@1068: optimistic types (-ot/--optimistic-types). There is one file per JavaScript hannesw@1068: function in the cache. hannesw@1068: hannesw@1068: The default value is 0 which means the feature is disabled. Setting this hannesw@1068: to something like 20000 is probably good enough for most applications and hannesw@1068: will usually cap the cache directory to about 80MB presuming a 4kB hannesw@1068: filesystem allocation unit. Set this to "unlimited" to run without limit. hannesw@1068: hannesw@1068: If the value is not 0 or "unlimited", Nashorn will spawn a cleanup thread hannesw@1068: that makes sure the number of files in the cache does not exceed the given hannesw@1068: value by deleting the least recently modified files. hannesw@1068: hannesw@1068: hannesw@1068: SYSTEM PROPERTY: -Dnashorn.typeInfo.cacheDir hannesw@1068: hannesw@1068: This property can be used to set the directory where Nashorn stores the hannesw@1068: type info cache when -Dnashorn.typeInfo.maxFiles is set to a nonzero hannesw@1068: value. The default location is platform specific. On Windows, it is hannesw@1068: "${java.io.tmpdir}\com.oracle.java.NashornTypeInfo". On Linux and hannesw@1068: Solaris it is "~/.cache/com.oracle.java.NashornTypeInfo". On Mac OS X, hannesw@1068: it is "~/Library/Caches/com.oracle.java.NashornTypeInfo". hannesw@1068: hannesw@1068: hannesw@1068: SYSTEM PROPERTY: -Dnashorn.typeInfo.cleanupDelaySeconds= hannesw@1068: hannesw@1068: This sets the delay between cleanups of the typeInfo cache, in seconds. hannesw@1068: The default delay is 20 seconds. hannesw@1068: hannesw@1068: hannesw@1068: SYSTEM PROPERTY: -Dnashorn.profilefile= jlaskey@3: jlaskey@3: When running with the profile callsite options (-pcs), Nashorn will jlaskey@3: dump profiling data for all callsites to stderr as a shutdown hook. To jlaskey@3: instead redirect this to a file, specify the path to the file using jlaskey@3: this system property. jlaskey@3: jlaskey@3: lagergren@526: SYSTEM_PROPERTY: -Dnashorn.regexp.impl=[jdk|joni] hannesw@115: hannesw@115: This property defines the regular expression engine to be used by lagergren@526: Nashorn. Set this flag to "jdk" to get an implementation based on the hannesw@115: JDK's java.util.regex package. Set this property to "joni" to install hannesw@115: an implementation based on Joni, the regular expression engine used by lagergren@526: the JRuby project. The default value for this flag is "joni" hannesw@115: hannesw@1068: SYSTEM PROPERTY: -Dnashorn.runtime.event.queue.size= hannesw@1068: hannesw@1068: Nashorn provides a fixed sized runtime event queue for debugging purposes. hannesw@1068: See -Dnashorn.debug for methods to access the event queue. hannesw@1068: The default value is 1024. hannesw@115: jlaskey@3: =============== jlaskey@3: 2. The loggers. jlaskey@3: =============== jlaskey@3: lagergren@57: It is very simple to create your own logger. Use the DebugLogger class lagergren@57: and give the subsystem name as a constructor argument. lagergren@57: jlaskey@3: The Nashorn loggers can be used to print per-module or per-subsystem jlaskey@3: debug information with different levels of verbosity. The loggers for jlaskey@3: a given subsystem are available are enabled by using jlaskey@3: jlaskey@3: --log=[:] jlaskey@3: jlaskey@3: on the command line. jlaskey@3: jlaskey@3: Here identifies the name of the subsystem to be logged jlaskey@3: and the optional colon and level argument is a standard jlaskey@3: java.util.logging.Level name (severe, warning, info, config, fine, jlaskey@3: finer, finest). If the level is left out for a particular subsystem, jlaskey@3: it defaults to "info". Any log message logged as the level or a level jlaskey@3: that is more important will be output to stderr by the logger. jlaskey@3: jlaskey@3: Several loggers can be enabled by a single command line option, by jlaskey@3: putting a comma after each subsystem/level tuple (or each subsystem if jlaskey@3: level is unspecified). The --log option can also be given multiple jlaskey@3: times on the same command line, with the same effect. jlaskey@3: jlaskey@3: For example: --log=codegen,fields:finest is equivalent to jlaskey@3: --log=codegen:info --log=fields:finest jlaskey@3: hannesw@1068: The following is an incomplete list of subsystems that currently hannesw@1068: support logging. Look for classes implementing hannesw@1068: jdk.nashorn.internal.runtime.logging.Loggable for more loggers. jlaskey@3: jlaskey@3: jlaskey@3: * compiler jlaskey@3: jlaskey@3: The compiler is in charge of turning source code and function nodes jlaskey@3: into byte code, and installs the classes into a class loader jlaskey@3: controlled from the Context. Log messages are, for example, about jlaskey@3: things like new compile units being allocated. The compiler has global jlaskey@3: settings that all the tiers of codegen (e.g. Lower and CodeGenerator) lagergren@57: use.s jlaskey@3: jlaskey@3: hannesw@1068: * recompile hannesw@1068: hannesw@1068: This logger shows information about recompilation of scripts and hannesw@1068: functions at runtime. Recompilation may happen because a function hannesw@1068: was called with different parameter types, or because an optimistic hannesw@1068: assumption failed while executing a function with -ot/--optimistic-types. hannesw@1068: hannesw@1068: jlaskey@3: * codegen jlaskey@3: jlaskey@3: The code generator is the emitter stage of the code pipeline, and jlaskey@3: turns the lowest tier of a FunctionNode into bytecode. Codegen logging jlaskey@3: shows byte codes as they are being emitted, line number information jlaskey@3: and jumps. It also shows the contents of the bytecode stack prior to jlaskey@3: each instruction being emitted. This is a good debugging aid. For jlaskey@3: example: jlaskey@3: jlaskey@3: [codegen] #41 line:2 (f)_afc824e jlaskey@3: [codegen] #42 load symbol x slot=2 jlaskey@3: [codegen] #43 {1:O} load int 0 jlaskey@3: [codegen] #44 {2:I O} dynamic_runtime_call GT:ZOI_I args=2 returnType=boolean jlaskey@3: [codegen] #45 signature (Ljava/lang/Object;I)Z jlaskey@3: [codegen] #46 {1:Z} ifeq ternary_false_5402fe28 jlaskey@3: [codegen] #47 load symbol x slot=2 jlaskey@3: [codegen] #48 {1:O} goto ternary_exit_107c1f2f jlaskey@3: [codegen] #49 ternary_false_5402fe28 jlaskey@3: [codegen] #50 load symbol x slot=2 jlaskey@3: [codegen] #51 {1:O} convert object -> double jlaskey@3: [codegen] #52 {1:D} neg jlaskey@3: [codegen] #53 {1:D} convert double -> object jlaskey@3: [codegen] #54 {1:O} ternary_exit_107c1f2f jlaskey@3: [codegen] #55 {1:O} return object jlaskey@3: jlaskey@3: shows a ternary node being generated for the sequence "return x > 0 ? jlaskey@3: x : -x" jlaskey@3: jlaskey@3: The first number on the log line is a unique monotonically increasing jlaskey@3: emission id per bytecode. There is no guarantee this is the same id jlaskey@3: between runs. depending on non deterministic code jlaskey@3: execution/compilation, but for small applications it usually is. If jlaskey@3: the system variable -Dnashorn.codegen.debug.trace= is set, where x jlaskey@3: is a bytecode emission id, a stack trace will be shown as the jlaskey@3: particular bytecode is about to be emitted. This can be a quick way to jlaskey@3: determine where it comes from without attaching the debugger. "Who jlaskey@3: generated that neg?" jlaskey@3: jlaskey@3: The --log=codegen option is equivalent to setting the system variable jlaskey@3: "nashorn.codegen.debug" to true. jlaskey@3: lagergren@526: * fold lagergren@526: lagergren@526: Shows constant folding taking place before lowering jlaskey@3: jlaskey@3: * lower jlaskey@3: lagergren@57: This is the first lowering pass. lagergren@57: lagergren@57: Lower is a code generation pass that turns high level IR nodes into lagergren@57: lower level one, for example substituting comparisons to RuntimeNodes lagergren@57: and inlining finally blocks. lagergren@57: lagergren@57: Lower is also responsible for determining control flow information lagergren@57: like end points. lagergren@57: hannesw@1068: * symbols lagergren@57: hannesw@1068: The symbols logger tracks the assignment os symbols to identifiers. lagergren@57: hannesw@1068: * scopedepths jlaskey@3: hannesw@1068: This logs the calculation of scope depths for non-local symbols. jlaskey@3: jlaskey@3: * fields jlaskey@3: jlaskey@3: The --log=fields option (at info level) is equivalent to setting the jlaskey@3: system variable "nashorn.fields.debug" to true. At the info level it jlaskey@3: will only show info about type assumptions that were invalidated. If jlaskey@3: the level is set to finest, it will also trace every AccessorProperty jlaskey@3: getter and setter in the program, show arguments, return values jlaskey@3: etc. It will also show the internal representation of respective field jlaskey@3: (Object in the normal case, unless running with the dual field lagergren@24: representation) lagergren@526: attila@963: * time attila@963: attila@963: This enables timers for various phases of script compilation. The timers attila@963: will be dumped when the Nashorn process exits. We see a percentage value attila@963: of how much time was spent not executing bytecode (i.e. compilation and attila@963: internal tasks) at the end of the report. attila@963: attila@963: A finer level than "info" will show individual compilation timings as they attila@963: happen. attila@963: attila@963: Here is an example: attila@963: attila@963: [time] Accumulated complation phase Timings: attila@963: [time] attila@963: [time] 'JavaScript Parsing' 1076 ms attila@963: [time] 'Constant Folding' 159 ms attila@963: [time] 'Control Flow Lowering' 303 ms attila@963: [time] 'Program Point Calculation' 282 ms attila@963: [time] 'Builtin Replacement' 71 ms attila@963: [time] 'Code Splitting' 670 ms attila@963: [time] 'Symbol Assignment' 474 ms attila@963: [time] 'Scope Depth Computation' 249 ms attila@963: [time] 'Optimistic Type Assignment' 186 ms attila@963: [time] 'Local Variable Type Calculation' 526 ms attila@963: [time] 'Bytecode Generation' 5177 ms attila@963: [time] 'Class Installation' 1854 ms attila@963: [time] attila@963: [time] Total runtime: 11994 ms (Non-runtime: 11027 ms [91%]) lagergren@526: hannesw@1068: * methodhandles hannesw@1068: hannesw@1068: If this logger is enabled, each MethodHandle related call that uses hannesw@1068: the java.lang.invoke package gets its MethodHandle intercepted and an hannesw@1068: instrumentation printout of arguments and return value appended to hannesw@1068: it. This shows exactly which method handles are executed and from hannesw@1068: where. (Also MethodTypes and SwitchPoints). hannesw@1068: hannesw@1068: * classcache hannesw@1068: hannesw@1068: This logger shows information about reusing code classes using the hannesw@1068: in-memory class cache. Nashorn will try to avoid compilation of hannesw@1068: scripts by using existing classes. This can significantly improve hannesw@1068: performance when repeatedly evaluating the same script. hannesw@1068: lagergren@526: ======================= lagergren@526: 3. Undocumented options lagergren@526: ======================= lagergren@526: lagergren@526: Here follows a short description of undocumented options for Nashorn. lagergren@526: To see a list of all undocumented options, use the (undocumented) flag lagergren@526: "-xhelp". lagergren@526: lagergren@526: i.e. jjs -xhelp or java -jar nashorn.jar -xhelp lagergren@526: lagergren@526: Undocumented options are not guaranteed to work, run correctly or be lagergren@526: bug free. They are experimental and for internal or debugging use. lagergren@526: They are also subject to change without notice. lagergren@526: lagergren@526: In practice, though, all options below not explicitly documented as lagergren@526: EXPERIMENTAL can be relied upon, for example --dump-on-error is useful lagergren@526: for any JavaScript/Nashorn developer, but there is no guarantee. lagergren@526: lagergren@526: A short summary follows: lagergren@526: lagergren@526: -D (-Dname=value. Set a system property. This option can be repeated.) lagergren@526: lagergren@526: -ccs, --class-cache-size (Size of the Class cache size per global scope.) lagergren@526: lagergren@526: -cp, -classpath (-cp path. Specify where to find user class files.) lagergren@526: attila@963: -co, --compile-only (Compile without running.) lagergren@526: param: [true|false] default: false lagergren@526: attila@963: -d, --dump-debug-dir (specify a destination directory to dump class files.) lagergren@526: param: lagergren@526: lagergren@526: --debug-lines (Generate line number table in .class files.) lagergren@526: param: [true|false] default: true lagergren@526: lagergren@526: --debug-locals (Generate local variable table in .class files.) lagergren@526: param: [true|false] default: false lagergren@526: lagergren@526: -doe, -dump-on-error (Dump a stack trace on errors.) lagergren@526: param: [true|false] default: false lagergren@526: lagergren@526: --early-lvalue-error (invalid lvalue expressions should be reported as early errors.) lagergren@526: param: [true|false] default: true lagergren@526: lagergren@526: --empty-statements (Preserve empty statements in AST.) lagergren@526: param: [true|false] default: false lagergren@526: lagergren@526: -fv, -fullversion (Print full version info of Nashorn.) lagergren@526: param: [true|false] default: false lagergren@526: lagergren@526: --function-statement-error (Report an error when function declaration is used as a statement.) lagergren@526: param: [true|false] default: false lagergren@526: lagergren@526: --function-statement-warning (Warn when function declaration is used as a statement.) lagergren@526: param: [true|false] default: false lagergren@526: lagergren@526: -fx (Launch script as an fx application.) lagergren@526: param: [true|false] default: false lagergren@526: lagergren@526: --global-per-engine (Use single Global instance per script engine instance.) lagergren@526: param: [true|false] default: false lagergren@526: lagergren@526: -h, -help (Print help for command line flags.) lagergren@526: param: [true|false] default: false lagergren@526: lagergren@526: --loader-per-compile (Create a new class loader per compile.) lagergren@526: param: [true|false] default: true lagergren@526: lagergren@526: -l, --locale (Set Locale for script execution.) lagergren@526: param: default: en-US lagergren@526: lagergren@526: --log (Enable logging of a given level for a given number of sub systems. attila@963: [for example: --log=fields:finest,codegen:info].) lagergren@526: param: ,* lagergren@526: attila@963: -nj, --no-java (Disable Java support.) lagergren@526: param: [true|false] default: false lagergren@526: attila@963: -nse, --no-syntax-extensions (Disallow non-standard syntax extensions.) lagergren@526: param: [true|false] default: false lagergren@526: attila@963: -nta, --no-typed-arrays (Disable typed arrays support.) lagergren@526: param: [true|false] default: false lagergren@526: lagergren@526: --parse-only (Parse without compiling.) lagergren@526: param: [true|false] default: false lagergren@526: lagergren@526: --print-ast (Print abstract syntax tree.) lagergren@526: param: [true|false] default: false lagergren@526: attila@963: -pc, --print-code (Print generated bytecode. If a directory is specified, nothing will attila@963: be dumped to stderr. Also, in that case, .dot files will be generated attila@963: for all functions or for the function with the specified name only.) attila@963: param: [dir:,function:] lagergren@526: lagergren@526: --print-lower-ast (Print lowered abstract syntax tree.) lagergren@526: param: [true|false] default: false lagergren@526: attila@963: -plp, --print-lower-parse (Print the parse tree after lowering.) lagergren@526: param: [true|false] default: false lagergren@526: lagergren@526: --print-mem-usage (Print memory usage of IR after each compile stage.) lagergren@526: param: [true|false] default: false lagergren@526: lagergren@526: --print-no-newline (Print function will not print new line char.) lagergren@526: param: [true|false] default: false lagergren@526: attila@963: -pp, --print-parse (Print the parse tree.) lagergren@526: param: [true|false] default: false lagergren@526: lagergren@526: --print-symbols (Print the symbol table.) lagergren@526: param: [true|false] default: false lagergren@526: lagergren@526: -pcs, --profile-callsites (Dump callsite profile data.) lagergren@526: param: [true|false] default: false lagergren@526: lagergren@526: -scripting (Enable scripting features.) lagergren@526: param: [true|false] default: false lagergren@526: attila@963: --stderr (Redirect stderr to a filename or to another tty, e.g. stdout.) lagergren@526: param: lagergren@526: attila@963: --stdout (Redirect stdout to a filename or to another tty, e.g. stderr.) lagergren@526: param: lagergren@526: lagergren@526: -strict (Run scripts in strict mode.) lagergren@526: param: [true|false] default: false lagergren@526: lagergren@526: -t, -timezone (Set timezone for script execution.) lagergren@526: param: default: Europe/Stockholm lagergren@526: lagergren@526: -tcs, --trace-callsites (Enable callsite trace mode. Options are: miss [trace callsite misses] attila@963: enterexit [trace callsite enter/exit], objects [print object properties].) lagergren@526: param: [=[option,]*] lagergren@526: lagergren@526: --verify-code (Verify byte code before running.) lagergren@526: param: [true|false] default: false lagergren@526: lagergren@526: -v, -version (Print version info of Nashorn.) lagergren@526: param: [true|false] default: false lagergren@526: lagergren@526: -xhelp (Print extended help for command line flags.) lagergren@526: param: [true|false] default: false lagergren@526: