Bug ID: 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: 2024-03-25
Resolved: 2014-09-17

JDK 9
9 b34Fixed

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.

URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/dd9c5bca096c User: lana Date: 2014-10-08 16:43:31 +0000
08-10-2014
URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/39231c6e51fe User: lana Date: 2014-10-08 16:43:27 +0000
08-10-2014
URL: http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/dd9c5bca096c User: thartmann Date: 2014-09-17 09:25:21 +0000
17-09-2014
URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/39231c6e51fe User: thartmann Date: 2014-09-17 07:03:29 +0000
17-09-2014
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

Relates :	JDK-8058712 - [TESTBUG] serviceability/dcmd/CodeCacheTest.java fails with java.lang.Exception
Relates :	JDK-8043304 - JEP 197: Segmented Code Cache
Relates :	JDK-8005885 - enhance PrintCodeCache to print more data
Relates :	JDK-8043304 - JEP 197: Segmented Code Cache
Relates :	JDK-8059611 - Improve logic of 'Arguments::set_tiered_flags'
Relates :	JDK-8058611 - Investigate more efficient code cache sweeping
Relates :	JDK-8059653 - VM startup fails with 'Invalid code heap sizes' if -XX:ReservedCodeCacheSize is set
Relates :	JDK-8059390 - code cache fills up for bigapps/Weblogic+medrec/nowarnings
Relates :	JDK-8314837 - 5 compiled/codecache tests ignore VM flags
Relates :	JDK-8086068 - VM crashes with "-Xint -XX:+UseCompiler" options
Relates :	JDK-8271008 - appcds/*/MethodHandlesAsCollectorTest.java tests time out because of excessive GC (CodeCache GC Threshold) in loom
Relates :	JDK-8059559 - SIGSEGV at CodeHeap::allocate(unsigned int, bool)
Relates :	JDK-8059137 - MemoryPoolMXBeans for different code heaps should contain 'Code heap' in their names
Relates :	JDK-8328862 - Remove unused GrowableArrayFilterIterator
Relates :	JDK-8039498 - Add iterators to GrowableArray