[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Integrated: JDK-8312018: Improve reservation of class space and CDS
From:       Thomas Stuefe <stuefe () openjdk ! org>
Date:       2023-08-30 17:54:54
Message-ID: ox7_O6fnbH04N-QOt9BQ0GETwl7pxSkkeaVcwX1MEeA=.b3bff704-aaf7-44e2-8606-cb2fe410e617 () github ! com
[Download RAW message or body]

On Wed, 26 Jul 2023 11:34:18 GMT, Thomas Stuefe <stuefe@openjdk.org> wrote:

> This PR rewrites memory reservation of class space and CDS to have ASLR and a much \
> better chance of low-address placement. 
> ------
> 
> Motivation:
> 
> (I was advised to keep PR text short lest I spam the mailing lists with Skara \
> generated mails. So, for motivation, see JBS issue) 
> -------
> 
> The patch introduces a new API to reserve memory within an address range at a \
> randomized location, while trying to be smart about it. The API is generic, and \
> future planned uses of this API could include replacing the zero-based heap \
> allocation and the zero-based reservation of Shenandoah Collection Sets, thereby \
> allowing us to consolidate coding. 
> This PR complements @iklam 's current work that rewrites archive heap \
> initialization at runtime. Once his work is in, we will be able to recalculate \
> narrow Klass IDs for objects loaded from the archive, and that will allow us to \
> reap the benefits of this patch for the CDS runtime case too. 
> -------
> 
> Noteworthy functional changes:
> 
> - class space is now likely to be reserved at a random location in low address \
> ranges; this now includes ranges below 2 GB, which had been excluded before due to \
>                 the use of HeapBaseMinAddress as minimal attach point.
> -  Note that this makes no problem with sbrk() - the only platform still having \
> this problem is AIX, and we solved it differently there, see comment in AIX \
>                 implementation of `os::vm_min_address()`
> - I removed the PPC/AARCH64 specific coding that attempted to map at 4G/32G aligned \
> addresses. That section has a complex history - it was originally introduced to \
> deal with AARCH64 immediate-loading shortcomings, but PPC piggybacked on it for its \
> perceived ability to allocate for zero-based, which got subsequently lost, so its \
> broken now (see https://bugs.openjdk.org/browse/JDK-8313669). The new code is a \
> better replacement for this coding. 
> -------
> 
> Example (linux amd64):
> 
> We start the JVM with a 30GB heap. 
> 
> In the stock JVM, the JVM will place the heap in the lower address ranges starting \
> at 2G (0x8000_0000). But then it is unable to place the class space in lower \
> regions too, so it placed it at 32 GB (0x8_0000_0000), and we don't have zero-based \
> encoding (Narrow klass base: 0x0000000800000000). This scenario repeats for every \
> iteration, so we will always use these two addresses (no ASLR):  
> 
> thomas@starfish $ ./images/jdk/bin/java -Xshare:off -Xmx30g -Xlog:gc+heap+exit \
> -Xlog:gc+metaspace -version [0.019s][info][gc,metaspace] Compressed class space \
> mapped at: 0x0000000800000000-0x00000008400...

This pull request has now been integrated.

Changeset: 89d18ea4
Author:    Thomas Stuefe <stuefe@openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/89d18ea40f3508f4053824fd47f0b0f85fe1d7c2
                
Stats:     824 lines in 17 files changed: 709 ins; 77 del; 38 mod

8312018: Improve reservation of class space and CDS
8313669: Reduced chance for zero-based nKlass encoding since JDK-8296565

Reviewed-by: iklam, adinn

-------------

PR: https://git.openjdk.org/jdk/pull/15041


[prev in list] [next in list] [prev in thread] [next in thread]