This document describes system properties that are used for internal

debugging and instrumentation purposes, along with the system loggers,

which are used for the same thing.

This document is intended as a developer resource, and it is not

needed as Nashorn documentation for normal usage. Flags and system

properties described herein are subject to change without notice.

=====================================

1. System properties used internally

=====================================

This documentation of the system property flags assume that the

default value of the flag is false, unless otherwise specified.

SYSTEM PROPERTY: -Dnashorn.args=<string>

This property takes as its value a space separated list of Nashorn

command line options that should be passed to Nashorn. This might be

useful in environments where it is hard to tell how a nashorn.jar is

launched.

Example:

> java -Dnashorn.args="--lazy-complation --log=compiler" large-java-app-with-nashorn.jar 

> ant -Dnashorn.args="--log=codegen" antjob

SYSTEM PROPERTY: -Dnashorn.unstable.relink.threshold=x

This property controls how many call site misses are allowed before a 

callsite is relinked with "apply" semantics to never change again. 

In the case of megamorphic callsites, this is necessary, or the 

program would spend all its time swapping out callsite targets. Dynalink 

has a default value (currently 8 relinks) for this property if it 

is not explicitly set.

SYSTEM PROPERTY: -Dnashorn.compiler.splitter.threshold=x

This will change the node weight that requires a subgraph of the IR to

be split into several classes in order not to run out of bytecode space.

The default value is 0x8000 (32768).

SYSTEM PROPERTY: -Dnashorn.compiler.intarithmetic

(and integer arithmetic in general)

<currently disabled - this is being refactored for update releases> 

Arithmetic operations in Nashorn (except bitwise ones) typically

coerce the operands to doubles (as per the JavaScript spec). To switch

this off and remain in integer mode, for example for "var x = a&b; var

y = c&d; var z = x*y;", use this flag. This will force the

multiplication of variables that are ints to be done with the IMUL

bytecode and the result "z" to become an int.

WARNING: Note that is is experimental only to ensure that type support

exists for all primitive types. The generated code is unsound. This

will be the case until we do optimizations based on it. There is a CR

in Nashorn to do better range analysis, and ensure that this is only

done where the operation can't overflow into a wider type. Currently

no overflow checking is done, so at the moment, until range analysis

has been completed, this option is turned off.

We've experimented by using int arithmetic for everything and putting

overflow checks afterwards, which would recompute the operation with

the correct precision, but have yet to find a configuration where this

is faster than just using doubles directly, even if the int operation

does not overflow. Getting access to a JVM intrinsic that does branch

on overflow would probably alleviate this.

The future:

We are transitioning to an optimistic type system that uses int

arithmetic everywhere until proven wrong. The problem here is mostly

catch an overflow exception and rolling back the state to a new method

with less optimistic assumptions for an operation at a particular

program point. This will most likely not be in the Java 8.0 release

but likely end up in an update release

For Java 8, several java.lang.Math methods like addExact, subExact and

mulExact are available to help us. Experiments intrinsifying these

show a lot of promise, and we have devised a system that basically

does on stack replacement with exceptions in bytecode to revert

erroneous assumptions. An explanation of how this works and what we

are doing can be found here:

http://www.slideshare.net/lagergren/lagergren-jvmls2013final

Experiments with this show significant ~x2-3 performance increases on

pretty much everything, provided that optimistic assumptions don't

fail much. It will affect warmup time negatively, depending on how

many erroneous too optimistic assumptions are placed in the code at

compile time. We don't think this will be much of an issue.

For example for a small benchmark that repeatedly executes this

method taken from the Crypto Octane benchmark 

function am3(i,x,w,j,c,n) {

  var this_array = this.array;

  var w_array    = w.array;

  var xl = x&0x3fff, xh = x>>14;

  while(--n >= 0) {

    var l = this_array[i]&0x3fff;

    var h = this_array[i++]>>14;

    var m = xh*l+h*xl;

    l = xl*l+((m&0x3fff)<<14)+w_array[j]+c;

    c = (l>>28)+(m>>14)+xh*h;

    w_array[j++] = l&0xfffffff;

  }

  return c;

}

The performance increase more than doubles. We are also working hard

with the code generation team in the Java Virtual Machine to fix

things that are lacking in invokedynamic performance, which is another

area where a lot of ongoing performance work takes place

"Pessimistic" bytecode for am3, guaranteed to be semantically correct:

// access flags 0x9

  public static am3(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;

   L0

    LINENUMBER 12 L0

    ALOAD 0

    INVOKEDYNAMIC dyn:getProp|getElem|getMethod:array(Ljava/lang/Object;)Ljava/lang/Object; [

      // handle kind 0x6 : INVOKESTATIC

      jdk/nashorn/internal/runtime/linker/Bootstrap.bootstrap((Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/CallSite;)

      // arguments:

      0

    ]

    ASTORE 8

   L1

    LINENUMBER 13 L1

    ALOAD 3

    INVOKEDYNAMIC dyn:getProp|getElem|getMethod:array(Ljava/lang/Object;)Ljava/lang/Object; [

      // handle kind 0x6 : INVOKESTATIC

      jdk/nashorn/internal/runtime/linker/Bootstrap.bootstrap((Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/CallSite;)

      // arguments:

      0

    ]

    ASTORE 9

   L2

    LINENUMBER 14 L2

    ALOAD 2

    INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toInt32 (Ljava/lang/Object;)I

    SIPUSH 16383

    IAND

    ISTORE 10

    ALOAD 2

    INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toInt32 (Ljava/lang/Object;)I

    BIPUSH 14

    ISHR

    ISTORE 11

   L3

    LINENUMBER 15 L3

    GOTO L4

   L5

    LINENUMBER 16 L5

   FRAME FULL [java/lang/Object java/lang/Object java/lang/Object java/lang/Object java/lang/Object java/lang/Object java/lang/Double T java/lang/Object java/lang/Object I I] []

    ALOAD 8

    ALOAD 1

    INVOKEDYNAMIC dyn:getElem|getProp|getMethod(Ljava/lang/Object;Ljava/lang/Object;)I [

      // handle kind 0x6 : INVOKESTATIC

      jdk/nashorn/internal/runtime/linker/Bootstrap.bootstrap((Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/CallSite;)

      // arguments:

      0

    ]

    SIPUSH 16383

    IAND

    INVOKESTATIC java/lang/Integer.valueOf (I)Ljava/lang/Integer;

    ASTORE 12

   L6

    LINENUMBER 17 L6

    ALOAD 8

    ALOAD 1

    INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toNumber (Ljava/lang/Object;)D

    DUP2

    DCONST_1

    DADD

    INVOKESTATIC java/lang/Double.valueOf (D)Ljava/lang/Double;

    ASTORE 1

    INVOKEDYNAMIC dyn:getElem|getProp|getMethod(Ljava/lang/Object;D)I [

      // handle kind 0x6 : INVOKESTATIC

      jdk/nashorn/internal/runtime/linker/Bootstrap.bootstrap((Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/CallSite;)

      // arguments:

      0

    ]

    BIPUSH 14

    ISHR

    ISTORE 13

   L7

    LINENUMBER 18 L7

    ILOAD 11

    I2D

    ALOAD 12

    INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toNumber (Ljava/lang/Object;)D

    DMUL

    ILOAD 13

    I2D

    ILOAD 10

    I2D

    DMUL

    DADD

    DSTORE 14

   L8

    LINENUMBER 19 L8

    ILOAD 10

    I2D

    ALOAD 12

    INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toNumber (Ljava/lang/Object;)D

    DMUL

    DLOAD 14

    INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toInt32 (D)I

    SIPUSH 16383

    IAND

    BIPUSH 14

    ISHL

    I2D

    DADD

    ALOAD 9

    ALOAD 4

    INVOKEDYNAMIC dyn:getElem|getProp|getMethod(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; [

      // handle kind 0x6 : INVOKESTATIC

      jdk/nashorn/internal/runtime/linker/Bootstrap.bootstrap((Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/CallSite;)

      // arguments:

      0

    ]

    INVOKEDYNAMIC ADD:ODO_D(DLjava/lang/Object;)Ljava/lang/Object; [

      // handle kind 0x6 : INVOKESTATIC

      jdk/nashorn/internal/runtime/linker/Bootstrap.runtimeBootstrap((Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;)

      // arguments: none

    ]

    ALOAD 5

    INVOKEDYNAMIC ADD:OOO_I(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; [

      // handle kind 0x6 : INVOKESTATIC

      jdk/nashorn/internal/runtime/linker/Bootstrap.runtimeBootstrap((Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;)

      // arguments: none

    ]

    ASTORE 12

   L9

    LINENUMBER 20 L9

    ALOAD 12

    INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toInt32 (Ljava/lang/Object;)I

    BIPUSH 28

    ISHR

    I2D

    DLOAD 14

    INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toInt32 (D)I

    BIPUSH 14

    ISHR

    I2D

    DADD

    ILOAD 11

    I2D

    ILOAD 13

    I2D

    DMUL

    DADD

    INVOKESTATIC java/lang/Double.valueOf (D)Ljava/lang/Double;

    ASTORE 5

   L10

    LINENUMBER 21 L10

    ALOAD 9

    ALOAD 4

    INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toNumber (Ljava/lang/Object;)D

    DUP2

    DCONST_1

    DADD

    INVOKESTATIC java/lang/Double.valueOf (D)Ljava/lang/Double;

    ASTORE 4

    ALOAD 12

    INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toInt32 (Ljava/lang/Object;)I

    LDC 268435455

    IAND

    INVOKEDYNAMIC dyn:setElem|setProp(Ljava/lang/Object;DI)V [

      // handle kind 0x6 : INVOKESTATIC

      jdk/nashorn/internal/runtime/linker/Bootstrap.bootstrap((Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/CallSite;)

      // arguments:

      0

    ]

   L4

   FRAME FULL [java/lang/Object java/lang/Object java/lang/Object java/lang/Object java/lang/Object java/lang/Object java/lang/Object T java/lang/Object java/lang/Object I I] []

    ALOAD 6

    INVOKESTATIC jdk/nashorn/internal/runtime/JSType.toNumber (Ljava/lang/Object;)D

    LDC -1.0

    DADD

    DUP2

    INVOKESTATIC java/lang/Double.valueOf (D)Ljava/lang/Double;

    ASTORE 6

    DCONST_0

    DCMPL

    IFGE L5

   L11

    LINENUMBER 24 L11

    ALOAD 5

    ARETURN

"Optimistic" bytecode that requires invalidation on e.g overflow. Factor

x2-3 speedup:

public static am3(Ljava/lang/Object;IILjava/lang/Object;III)I

   L0

    LINENUMBER 12 L0

    ALOAD 0

    INVOKEDYNAMIC dyn:getProp|getElem|getMethod:array(Ljava/lang/Object;)Ljava/lang/Object; [

      // handle kind 0x6 : INVOKESTATIC

      jdk/nashorn/internal/runtime/linker/Bootstrap.bootstrap((Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/CallSite;)

      // arguments:

      0

    ]

    ASTORE 8

   L1

    LINENUMBER 13 L1

    ALOAD 3

    INVOKEDYNAMIC dyn:getProp|getElem|getMethod:array(Ljava/lang/Object;)Ljava/lang/Object; [

      // handle kind 0x6 : INVOKESTATIC

      jdk/nashorn/internal/runtime/linker/Bootstrap.bootstrap((Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/CallSite;)

      // arguments:

      0

    ]

    ASTORE 9

   L2

    LINENUMBER 14 L2

    ILOAD 2

    SIPUSH 16383

    IAND

    ISTORE 10

    ILOAD 2

    BIPUSH 14

    ISHR

    ISTORE 11

   L3

    LINENUMBER 15 L3

    GOTO L4

   L5

    LINENUMBER 16 L5

   FRAME FULL [java/lang/Object I I java/lang/Object I I I T java/lang/Object java/lang/Object I I] []

    ALOAD 8

    ILOAD 1

    INVOKEDYNAMIC dyn:getElem|getProp|getMethod(Ljava/lang/Object;I)I [

      // handle kind 0x6 : INVOKESTATIC

      jdk/nashorn/internal/runtime/linker/Bootstrap.bootstrap((Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/CallSite;)

      // arguments:

      0

    ]

    SIPUSH 16383

    IAND

    ISTORE 12

   L6

    LINENUMBER 17 L6

    ALOAD 8

    ILOAD 1

    DUP

    ICONST_1

    IADD

    ISTORE 1

    INVOKEDYNAMIC dyn:getElem|getProp|getMethod(Ljava/lang/Object;I)I [

      // handle kind 0x6 : INVOKESTATIC

      jdk/nashorn/internal/runtime/linker/Bootstrap.bootstrap((Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/CallSite;)

      // arguments:

      0

    ]

    BIPUSH 14

    ISHR

    ISTORE 13

   L7

    LINENUMBER 18 L7

    ILOAD 11

    ILOAD 12

    BIPUSH 8

    INVOKESTATIC jdk/nashorn/internal/runtime/JSType.mulExact (III)I

    ILOAD 13

    ILOAD 10

    BIPUSH 9

    INVOKESTATIC jdk/nashorn/internal/runtime/JSType.mulExact (III)I

    IADD

    ISTORE 14

   L8

    LINENUMBER 19 L8

    ILOAD 10

    ILOAD 12

    BIPUSH 11

    INVOKESTATIC jdk/nashorn/internal/runtime/JSType.mulExact (III)I

    ILOAD 14

    SIPUSH 16383

    IAND

    BIPUSH 14

    ISHL

    IADD

    ALOAD 9

    ILOAD 4

    INVOKEDYNAMIC dyn:getElem|getProp|getMethod(Ljava/lang/Object;I)I [

      // handle kind 0x6 : INVOKESTATIC

      jdk/nashorn/internal/runtime/linker/Bootstrap.bootstrap((Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/CallSite;)

      // arguments:

      0

    ]

    IADD

    ILOAD 5

    IADD

    ISTORE 12

   L9

    LINENUMBER 20 L9

    ILOAD 12

    BIPUSH 28

    ISHR

    ILOAD 14

    BIPUSH 14

    ISHR

    IADD

    ILOAD 11

    ILOAD 13

    BIPUSH 21

    INVOKESTATIC jdk/nashorn/internal/runtime/JSType.mulExact (III)I

    IADD

    ISTORE 5

   L10

    LINENUMBER 21 L10

    ALOAD 9

    ILOAD 4

    DUP

    ICONST_1

    IADD

    ISTORE 4

    ILOAD 12

    LDC 268435455

    IAND

    INVOKEDYNAMIC dyn:setElem|setProp(Ljava/lang/Object;II)V [

      // handle kind 0x6 : INVOKESTATIC

      jdk/nashorn/internal/runtime/linker/Bootstrap.bootstrap((Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;I)Ljava/lang/invoke/CallSite;)

      // arguments:

      0

    ]

   L4

   FRAME SAME

    ILOAD 6

    ICONST_M1

    IADD

    DUP

    ISTORE 6

    ICONST_0

    IF_ICMPGE L5

   L11

    LINENUMBER 24 L11

    ILOAD 5

    IRETURN

SYSTEM PROPERTY: -Dnashorn.codegen.debug, -Dnashorn.codegen.debug.trace=<x>

See the description of the codegen logger below.

SYSTEM_PROPERTY: -Dnashorn.fields.debug

See the description on the fields logger below.

SYSTEM PROPERTY: -Dnashorn.fields.dual

When this property is true, Nashorn will attempt to use primitive

fields for AccessorProperties (currently just AccessorProperties, not

spill properties). Memory footprint for script objects will increase,

as we need to maintain both a primitive field (a long) as well as an

Object field for the property value. Ints are represented as the 32

low bits of the long fields. Doubles are represented as the

doubleToLongBits of their value. This way a single field can be used

for all primitive types. Packing and unpacking doubles to their bit

representation is intrinsified by the JVM and extremely fast.

While dual fields in theory runs significantly faster than Object

fields due to reduction of boxing and memory allocation overhead,

there is still work to be done to make this a general purpose

solution. Research is ongoing.

In the future, this might complement or be replaced by experimental

feature sun.misc.TaggedArray, which has been discussed on the mlvm

mailing list. TaggedArrays are basically a way to share data space

between primitives and references, and have the GC understand this.

As long as only primitive values are written to the fields and enough

type information exists to make sure that any reads don't have to be

uselessly boxed and unboxed, this is significantly faster than the

standard "Objects only" approach that currently is the default. See

test/examples/dual-fields-micro.js for an example that runs twice as

fast with dual fields as without them. Here, the compiler, can

determine that we are dealing with numbers only throughout the entire

property life span of the properties involved.

If a "real" object (not a boxed primitive) is written to a field that

has a primitive representation, its callsite is relinked and an Object

field is used forevermore for that particular field in that

PropertyMap and its children, even if primitives are later assigned to

it.

As the amount of compile time type information is very small in a

dynamic language like JavaScript, it is frequently the case that

something has to be treated as an object, because we don't know any