JDK-8184893 : jdk8u152 b06 : issues with nashorn when running kraken benchmarks
  • Type: Bug
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Affected Version: 8u152
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-07-18
  • Updated: 2018-02-15
  • Resolved: 2017-07-26
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 10 JDK 8
10 b17Fixed 8u162Fixed
Description
Running the audio-*-data.js scripts from the kraken benchmark (https://hg.mozilla.org/projects/kraken/) with JDK 8u152 or later produces the following error:

jjs tests/kraken-1.1/audio-dft-data.js 
Exception in thread "main" java.lang.RuntimeException: Method code too large!
	at java.base/jdk.internal.org.objectweb.asm.MethodWriter.getSize(MethodWriter.java:2065)
	at java.base/jdk.internal.org.objectweb.asm.ClassWriter.toByteArray(ClassWriter.java:866)
	at jdk.scripting.nashorn/jdk.nashorn.internal.codegen.ClassEmitter.toByteArray(ClassEmitter.java:679)
	at jdk.scripting.nashorn/jdk.nashorn.internal.codegen.CompilationPhase$BytecodeGenerationPhase.transform(CompilationPhase.java:448)
	at jdk.scripting.nashorn/jdk.nashorn.internal.codegen.CompilationPhase.apply(CompilationPhase.java:630)
	at jdk.scripting.nashorn/jdk.nashorn.internal.codegen.Compiler.compile(Compiler.java:656)
	at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.compileTypeSpecialization(RecompilableScriptFunctionData.java:727)
	at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.getBest(RecompilableScriptFunctionData.java:907)
	at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.getGeneric(ScriptFunctionData.java:399)
	at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.createGenericInvoker(ScriptFunctionData.java:297)
	at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.getGenericInvoker(ScriptFunctionData.java:291)
	at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:635)
	at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513)
	at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:517)
	at jdk.scripting.nashorn/jdk.nashorn.tools.Shell.apply(Shell.java:519)
	at jdk.scripting.nashorn/jdk.nashorn.tools.Shell.runScripts(Shell.java:448)
	at jdk.scripting.nashorn/jdk.nashorn.tools.Shell.run(Shell.java:186)
	at jdk.scripting.nashorn.shell/jdk.nashorn.tools.jjs.Main.main(Main.java:104)
	at jdk.scripting.nashorn.shell/jdk.nashorn.tools.jjs.Main.main(Main.java:80)
Comments
URL: http://hg.openjdk.java.net/jdk10/jdk10/nashorn/rev/6ac0ca441ccb User: hannesw Date: 2017-07-26 14:07:43 +0000
26-07-2017
The assumption behind JDK-8169481 was that primitive literal nodes would have uniform code footprint - basically a constant load. However, it turns out that footprint can change quite a bit depending on context. The Kraken benchmark contains the following code pattern in its audio-*-data.js files: new Array(-9.063918018914485e-12,-3.261597155551632e-12,-7.691810383070319e-11, ... ) with 2048 number literals passed to the Array constructor. Each number literal generates the following bytecode: 12 dup 13 iconst_0 14 ldc 3.079756197621464E-6 17 invokestatic Double.valueOf(D)Double; 20 aastore i.e. the array is duplicated, the index is loaded, then the double is loaded and converted to an object, then it is stored in the array. The solution is thus to back out of the change for primitive literals in WeighNodes.java and assume a code footprint of 10 bytes again.
25-07-2017
This is caused by JDK-8169481. The changed node weighing rules prevent splitting from happening for some of the kraken benchmark code. The solution will likely be to undo some or all of these changes.
21-07-2017