JDK-8062490 : JDK-8061391 regresses typescript: OOME with too fat SparseArrayData instances
  • Type: Bug
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Affected Version: 8u40
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-10-29
  • Updated: 2015-06-04
  • Resolved: 2014-11-03
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
8u40Fixed 9 b39Fixed
Related Reports
Blocks :  
Relates :  
Description
Running current jdk9-dev with Nashorn/Octane/typescript yields an OOM error:

$ ~/trunks/jdk9-dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -XX:+HeapDumpOnOutOfMemoryError -jar ~/trunks/jdk9-dev/build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/ext/nashorn.jar -Dnashorn.typeInfo.disabled=false --class-cache-size=0 --persistent-code-cache=false -scripting --log=time test/script/basic/run-octane.js -- --iterations 1 typescript

java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid29803.hprof ...
Heap dump file created [5862982767 bytes in 9.437 secs]
[typescript] *** Aborted and setting score to zero. Reason: java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
	at jdk.nashorn.internal.runtime.arrays.IntArrayData.<init>(IntArrayData.java:51)
	at jdk.nashorn.internal.runtime.arrays.ArrayData$UntouchedArrayData.toRealArrayData(ArrayData.java:76)
	at jdk.nashorn.internal.runtime.arrays.ArrayData$UntouchedArrayData.ensure(ArrayData.java:101)
	at jdk.nashorn.internal.runtime.ScriptObject.doesNotHaveEnsureLength(ScriptObject.java:3073)
	at jdk.nashorn.internal.runtime.ScriptObject.doesNotHave(ScriptObject.java:3121)
	at jdk.nashorn.internal.runtime.ScriptObject.set(ScriptObject.java:3487)
	at java.lang.invoke.LambdaForm$DMH/480886755.invokeVirtual_LILI_V(LambdaForm$DMH)
	at java.lang.invoke.LambdaForm$BMH/1956590999.reinvoke(LambdaForm$BMH)
	at java.lang.invoke.LambdaForm$NFI/641853239.invoke_LIL_V(LambdaForm$NFI)
	at java.lang.invoke.LambdaForm$DMH/440434003.invokeStatic_LL_L(LambdaForm$DMH)
	at java.lang.invoke.LambdaForm$NamedFunction.invokeWithArguments(LambdaForm.java:1184)
	at java.lang.invoke.LambdaForm.interpretName(LambdaForm.java:767)
	at java.lang.invoke.LambdaForm.interpretWithArguments(LambdaForm.java:744)
	at java.lang.invoke.LambdaForm$LFI/1780132728.interpret_V(LambdaForm$LFI)
	at java.lang.invoke.LambdaForm$MH/490216598.exactInvoker(LambdaForm$MH)
	at java.lang.invoke.LambdaForm$MH/31761217.delegate(LambdaForm$MH)
	at java.lang.invoke.LambdaForm$NFI/1920467934.invoke_LLIL_V(LambdaForm$NFI)
	at java.lang.invoke.LambdaForm$DMH/440434003.invokeStatic_LL_L(LambdaForm$DMH)
	at java.lang.invoke.LambdaForm$NamedFunction.invokeWithArguments(LambdaForm.java:1184)
	at java.lang.invoke.LambdaForm.interpretName(LambdaForm.java:767)
	at java.lang.invoke.LambdaForm.interpretWithArguments(LambdaForm.java:744)
	at java.lang.invoke.LambdaForm$LFI/1780132728.interpret_V(LambdaForm$LFI)
	at java.lang.invoke.LambdaForm$MH/1058561002.linkToCallSite(LambdaForm$MH)
	at jdk.nashorn.internal.scripts.Script$Recompilation$1946$833928AAZAA$typescript_compiler.L:16271$TypeChecker$sourceIsRelatableToTarget(/home/shade/trunks/jdk9-dev/nashorn/test/script/basic/../external/octane/typescript-compiler.js:17669)
	at java.lang.invoke.LambdaForm$DMH/746757727.invokeStatic_L4ILL_L(LambdaForm$DMH)
	at java.lang.invoke.LambdaForm$MH/845020685.guardWithCatch(LambdaForm$MH)
	at java.lang.invoke.LambdaForm$MH/905972407.convert(LambdaForm$MH)
	at java.lang.invoke.LambdaForm$MH/1781696541.guard(LambdaForm$MH)
	at java.lang.invoke.LambdaForm$MH/1781696541.guard(LambdaForm$MH)
	at java.lang.invoke.LambdaForm$MH/570788108.linkToCallSite(LambdaForm$MH)
	at jdk.nashorn.internal.scripts.Script$Recompilation$1947$833260AAA$typescript_compiler.L:16271$TypeChecker$sourceIsAssignableToTarget(/home/shade/trunks/jdk9-dev/nashorn/test/script/basic/../external/octane/typescript-compiler.js:17622)
	at java.lang.invoke.LambdaForm$DMH/1753447031.invokeStatic_L4_L(LambdaForm$DMH)
[typescript] 0
[time] Accumulated compilation phase timings:
[time] 
[time] 'JavaScript Parsing'               508 ms
[time] 'Constant Folding'                  57 ms
[time] 'Control Flow Lowering'             98 ms
[time] 'Builtin Replacement'               36 ms
[time] 'Code Splitting'                   212 ms
[time] 'Program Point Calculation'         99 ms
[time] 'Serialize Split Functions'        156 ms
[time] 'Symbol Assignment'                266 ms
[time] 'Scope Depth Computation'          111 ms
[time] 'Optimistic Type Assignment'       140 ms
[time] 'Local Variable Type Calculation'  374 ms
[time] 'Bytecode Generation'             3616 ms
[time] 'Class Installation'              1931 ms
[time] 'Reuse Compile Units'               86 ms
[time] 'Deserialize'                      908 ms
[time] 
[time] Total runtime: 72161 ms (Non-runtime: 8603 ms [11%])
[time] 
[time] Emitted compile units: 3389

It runs successfully with -Xmx20g -Xms20g.
Comments
OK I will investigate
31-10-2014

Assigning to Marcus, since it was his commit that regressed the typescript.
29-10-2014

This is a blocker for performance work.
29-10-2014

hg bisect... The first bad revision is: changeset: 1072:06c06c8443fd user: lagergren date: Thu Oct 23 15:19:00 2014 +0400 summary: 8061391: concat as a builtin optimistic form, had to remove NoTypedArrayData and replace it, as we throw away a lot of optimistic link opportunities with NoTypedArrayData not being Continuous
29-10-2014

This is what heap dump shows right after the OOME: http://cr.openjdk.java.net/~shade/8062490/mat-1.txt That is, we have two objects of SparseArrayData type, 2 Gb worth each. It would seem sparse arrays are not really sparse?
29-10-2014