JDK-8059236 : Memory leak when executing octane pdfjs with optimistic typing
  • Type: Bug
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Affected Version: 8u40
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-09-26
  • Updated: 2015-06-04
  • Resolved: 2014-10-09
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.
8u40 b10Fixed 9Fixed
Running octane pdfjs with optimistic typing it is visible how occupied OldSpace is increasing in time. It causes performance degradation and OutOfMemoryError at the end.
Used heap increases slowly - required long execution: e.g. with 512M heapsize it requires up to 200-300 iterations before OOM:
java -Xmx512m -Xms512m jdk.nashorn.tools.Shell test/script/basic/run-octane.js --optimistic-types=true -scripting -- pdfjs --runtime nashorn --verbose --iterations 300 

PS There is no memory leak when optimistic typing turned off.
Adding noreg-long as the problem took a long time to manifest.

This is a memory leak within pdfjs after all. The reason why it was originally reported as being related to optimistic typing is probably because it takes longer to manifest without optimistic types. We can fix this by adding a special cleanup hook after each iteration. I filed a bug with octane: https://code.google.com/p/octane-benchmark/issues/detail?id=26

This is most likely a SpillProperty method handle leak

The issue exists in jdk9-b32: java version "1.9.0-ea" Java(TM) SE Runtime Environment (build 1.9.0-ea-b32) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b32, mixed mode)