JDK-8015774 : Add support for multiple code heaps
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-06-03
  • Updated: 2017-03-17
  • Resolved: 2014-09-17
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 9
9 b34Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
Support for multiple code heaps is required for AOT compilation. In addition, the instruction cache hit rate might be higher, if, e.g., a separate code heap is used for each tier and the meta-data that is attached to each compiled method is stored in a separate heap.
Comments
An alternative implementation is to take a hint from G1 and implement a regionalized code cache. A logical heap would consist of a set of regions, with multiple logical heaps co-existing in the code cache. The metadata for each logical heap could reside in region headers, a per-logical-heap region set (meta-circularity of a sort) or a per-logical-heap arena. Logical heaps can be traversed or collected independently. Internal fragmentation can be avoided by linking code in one region to code in another by a branch at the end of the code in the source region. I.e., instead of segmentation, think paging. This design avoids adding to JVM tuning complexity, code cache fragmentation and potential sub-heap overflow, all as noted in the JEP (http://openjdk.java.net/jeps/197). It would also remove the need to make the size of non-method code a constant: this estimate has often been incorrect in the past, leading to annoying crashes.
23-07-2014

Most recent benchmark results on a 32 core machine using Octane with Nashorn, SPECjbb2005 and SPECjbb2013.
14-04-2014

Most recent benchmark results on a 32 core machine using Octane with Nashorn, SPECjbb2005 and SPECjbb2013.
14-04-2014

RFR file
02-10-2013

RFR file
02-10-2013

RFR file
02-10-2013

Files for RFR
02-10-2013

Performance impact of sweep time for Dacapo benchmarks (256m code cache)
20-09-2013

Performance impact of reduced sweeping time on Octane + Nashorn
20-09-2013

Preliminary patch
20-09-2013

Performance evaluation of multiple code heaps with Octane benchmarks running with Nashorn
20-09-2013

Can you attach this graph to the bug so we don't lose it?
20-09-2013

First results: Sweep time is reduced significantly: https://github.com/TobiHartmann/hotspot/blob/master/benchmarks/results/OctaneSweepTime/OctaneSweepTime.png
20-09-2013