JDK-8079269 : Optimistic rewrite in object literal causes ArrayIndexOutOfBoundsException
  • Type: Bug
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2015-05-04
  • Updated: 2015-09-29
  • Resolved: 2015-05-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u60Fixed 9 b64Fixed
Description
The following code throws ArrayIndexOutOfBoundsException with JDK9 with optimistic types enabled:

var m = 1;

var obj = {
    p0: m,
    p1: m = "foo",
    p2: m
};

Appearently the restof handle expects a second copy of the JD4 object being initialized on the stack which is not available in the RewriteException's stack array.

The object literal code is generated by FieldObjectCreator, but SpillObjectCreator (used for object literals with >= 256 properties) exhibits the same problem.

Output:
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 4
	at jdk.nashorn.internal.scripts.Script$Recompilation$2$JDK_8078049$cu1$restOf.:program(test/script/basic/JDK-8078049.js:0)
	at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:636)
	at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:228)
	at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
	at jdk.nashorn.tools.Shell.apply(Shell.java:397)
	at jdk.nashorn.tools.Shell.runScripts(Shell.java:326)
	at jdk.nashorn.tools.Shell.run(Shell.java:172)
	at jdk.nashorn.tools.Shell.main(Shell.java:136)
	at jdk.nashorn.tools.Shell.main(Shell.java:112)
Comments
Looks like the continuation code is wrong. The code creting the RewriteException is correct, as at the point it is thrown, there is indeed 4 live locals, not 5. It is probably due to the fact that in the regenerated code there was never a temporary ASTORE of the object being initialized, so the DUP operation never identifies the two values on the stack as being the same value. Replacing the DUPs with ASTORE/ALOAD, or even just doing a temporary ASTORE/ALOAD of the object literal would fix this.
04-05-2015