Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JDK-8312018: Improve reservation of class space and CDS #15041

Conversation

tstuefe
Copy link
Member

@tstuefe tstuefe commented Jul 26, 2023

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-0x0000000840000000, reserved size: 1073741824
[0.019s][info][gc,metaspace] Narrow klass base: 0x0000000800000000, Narrow klass shift: 0, Narrow klass range: 0x40000000
...
[0,112s][info][gc,heap,exit]  garbage-first heap   total 1032192K, used 4915K [0x0000000080000000, 0x0000000800000000)

In the patched JDK, the heap will also be placed at 2G (0x8000_0000). But the class space will be nestled below that, at a random location lower than 2G (in this run, at 0x1f00_0000):

thomas@starfish $ ./images-new/jdk/bin/java -Xshare:off -Xmx30g -Xlog:gc+heap+exit -Xlog:gc+metaspace -version
[0.017s][info][gc,metaspace] Compressed class space mapped at: 0x000000001f000000-0x000000005f000000, reserved size: 1073741824
[0.017s][info][gc,metaspace] Narrow klass base: 0x0000000000000000, Narrow klass shift: 0, Narrow klass range: 0x5f000000
...
[0,107s][info][gc,heap,exit]  garbage-first heap   total 1032192K, used 5898K [0x0000000080000000, 0x0000000800000000)

And it will be randomized, see output from multiple runs - every time we end up with a zero-base, but the actual start address of the class space differs:

[0.019s][info][gc,metaspace] Compressed class space mapped at: 0x0000000025000000-0x0000000065000000, reserved size: 1073741824
[0.019s][info][gc,metaspace] Narrow klass base: 0x0000000000000000, Narrow klass shift: 0, Narrow klass range: 0x65000000
...
[0.017s][info][gc,metaspace] Compressed class space mapped at: 0x0000000035000000-0x0000000075000000, reserved size: 1073741824
[0.017s][info][gc,metaspace] Narrow klass base: 0x0000000000000000, Narrow klass shift: 0, Narrow klass range: 0x75000000
...
[0.018s][info][gc,metaspace] Compressed class space mapped at: 0x000000001f000000-0x000000005f000000, reserved size: 1073741824
[0.018s][info][gc,metaspace] Narrow klass base: 0x0000000000000000, Narrow klass shift: 0, Narrow klass range: 0x5f000000
...
[0.016s][info][gc,metaspace] Compressed class space mapped at: 0x000000001c000000-0x000000005c000000, reserved size: 1073741824
[0.016s][info][gc,metaspace] Narrow klass base: 0x0000000000000000, Narrow klass shift: 0, Narrow klass range: 0x5c000000

Tests:

The patch comes with a full set of gtests that test the new API from all angles, all of which have been executed on many platforms.

GHAs are green, too.


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Issues

  • JDK-8312018: Improve reservation of class space and CDS (Enhancement - P3)
  • JDK-8313669: Reduced chance for zero-based nKlass encoding since JDK-8296565 (Bug - P4)

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/15041/head:pull/15041
$ git checkout pull/15041

Update a local copy of the PR:
$ git checkout pull/15041
$ git pull https://git.openjdk.org/jdk.git pull/15041/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 15041

View PR using the GUI difftool:
$ git pr show -t 15041

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/15041.diff

Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Jul 26, 2023

👋 Welcome back stuefe! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented Jul 26, 2023

@tstuefe The following label will be automatically applied to this pull request:

  • hotspot-runtime

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added the hotspot-runtime hotspot-runtime-dev@openjdk.org label Jul 26, 2023
@tstuefe tstuefe force-pushed the JDK-8312018-Improve-odds-for-zero-base-optimized-reservation-of-class-space branch 3 times, most recently from 8738899 to 1df5f84 Compare August 5, 2023 12:25
@tstuefe tstuefe force-pushed the JDK-8312018-Improve-odds-for-zero-base-optimized-reservation-of-class-space branch from f0b22e6 to 52a9810 Compare August 7, 2023 12:14
@tstuefe tstuefe force-pushed the JDK-8312018-Improve-odds-for-zero-base-optimized-reservation-of-class-space branch from 0d6b5eb to 381d249 Compare August 9, 2023 09:24
@tstuefe tstuefe force-pushed the JDK-8312018-Improve-odds-for-zero-base-optimized-reservation-of-class-space branch from 381d249 to 286a4c3 Compare August 9, 2023 09:36
@tstuefe tstuefe changed the title JDK-8312018: Improve odds for zero-base-optimized reservation of class space JDK-8312018: Improve reservation of class space and CDS Aug 9, 2023
@tstuefe tstuefe marked this pull request as ready for review August 9, 2023 13:51
@tstuefe
Copy link
Member Author

tstuefe commented Aug 9, 2023

Attention @iklam

@openjdk openjdk bot added the rfr Pull request is ready for review label Aug 9, 2023
@mlbridge
Copy link

mlbridge bot commented Aug 9, 2023

@tstuefe
Copy link
Member Author

tstuefe commented Aug 10, 2023

/issue JDK-8313669

@openjdk
Copy link

openjdk bot commented Aug 10, 2023

@tstuefe
Adding additional issue to issue list: 8313669: Reduced chance for zero-based nKlass encoding since JDK-8296565.

Copy link
Member

@iklam iklam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some preliminary comments.

  • I am not sure what "CDS" means in the PR title. It seems like CDS doesn't (yet) benefit from the improvements.
  • I would suggest breaking this PR into smaller steps (see my comments inside Metaspace::reserve_address_space_for_compressed_classes)

src/hotspot/os/linux/os_linux.cpp Outdated Show resolved Hide resolved
src/hotspot/share/cds/metaspaceShared.cpp Outdated Show resolved Hide resolved
src/hotspot/share/runtime/globals.hpp Show resolved Hide resolved
src/hotspot/share/runtime/os.cpp Show resolved Hide resolved
src/hotspot/share/memory/metaspace.cpp Outdated Show resolved Hide resolved
@tstuefe
Copy link
Member Author

tstuefe commented Aug 11, 2023

Some preliminary comments.

  • I am not sure what "CDS" means in the PR title. It seems like CDS doesn't (yet) benefit from the improvements.

CDS uses the new API when reserving memory for the (by default now) relocated archive. So, while it not yet benefits from zero-based encoding, it benefits from the improved entropy the API gives. The old variant was using a randomized start position into an ordered list of 31+7 = 38 value points. The new API gives you entropy based solely on the alignment requirement for metaspace (16M). For unscaled, we have 255 possible attach points, for zero-based 1792.

@tstuefe
Copy link
Member Author

tstuefe commented Aug 11, 2023

Hi @iklam, I addressed some of your concerns, please take another look. Thank you!

Copy link
Member

@iklam iklam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the API looks OK. I need to spend more time looking at the algorithm itself.

src/hotspot/share/memory/metaspace.cpp Outdated Show resolved Hide resolved
src/hotspot/os/linux/os_linux.cpp Outdated Show resolved Hide resolved
@tstuefe
Copy link
Member Author

tstuefe commented Aug 15, 2023

I think the API looks OK. I need to spend more time looking at the algorithm itself.

Thanks, Ioi. I can add some ASCII art if needed. Tell me if its too complex for mere words :-)

Copy link
Contributor

@rkennke rkennke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Thomas,
nice change! I am not very familiar with the actual algorithms and platform specific details, but I have some suggestions regarding the structure.

src/hotspot/share/cds/metaspaceShared.cpp Outdated Show resolved Hide resolved
src/hotspot/share/runtime/os.cpp Show resolved Hide resolved
@tstuefe
Copy link
Member Author

tstuefe commented Aug 16, 2023

Hi Thomas, nice change! I am not very familiar with the actual algorithms and platform specific details, but I have some suggestions regarding the structure.

Many thanks, Roman! See answers inline.

@tstuefe
Copy link
Member Author

tstuefe commented Aug 16, 2023

@iklam @rkennke thanks for the reviews so far.

Changes to os::vm_min_address

  • I encoded the a default value for os::vm_min_address() (16 MB) centrally
  • I changes the linux implementation to actually read vm.mmap_min_address.
  • I changed the interface to return size_t since char* seemed weird
    Other changes:
  • tried to come up with a better comment for the cds_runtime path in MetaspaceShared. I somewhat regret now not staying with strict_base, since in hindsight that describes behavior much better; but cds_runtime is fine and we hopefully will remove this code path soon when we recalc nKlass IDs on archive load.

src/hotspot/share/memory/metaspace.cpp Show resolved Hide resolved
src/hotspot/share/memory/metaspace.cpp Show resolved Hide resolved
src/hotspot/share/runtime/os.cpp Show resolved Hide resolved
src/hotspot/share/runtime/os.cpp Show resolved Hide resolved
@tstuefe
Copy link
Member Author

tstuefe commented Aug 28, 2023

@iklam is there anything missing from your point of view?

@iklam
Copy link
Member

iklam commented Aug 28, 2023

@iklam is there anything missing from your point of view?

I just realized this -- for the above 32GB allocations, do we need to use the new algorithm for all platforms? As far as I know, only aarch64 and ppc64 need it because they want to use a single "load immediate" instruction.

For the other CPUs, we can just ask the OS. That will be faster, always succeed, and be at the "right" location as decided by the OS.

@tstuefe
Copy link
Member Author

tstuefe commented Aug 28, 2023

@iklam is there anything missing from your point of view?

I just realized this -- for the above 32GB allocations, do we need to use the new algorithm for all platforms? As far as I know, only aarch64 and ppc64 need it because they want to use a single "load immediate" instruction.

For the other CPUs, we can just ask the OS. That will be faster, always succeed, and be at the "right" location as decided by the OS.

The argument for doing it on the remaining platforms (x64 and risc) would be that those, too, could profit from using 16-bit moves and short immediates, instead of - e.g. in the case of x64 - always emitting a giant 8-byte immediate for addi. And that the code would be better tested, since all platforms run through it.

OTOH, this could also be done in a follow-up. So, if you prefer it that way, I make that section aarch/ppc only.

@iklam
Copy link
Member

iklam commented Aug 28, 2023

@iklam is there anything missing from your point of view?

I just realized this -- for the above 32GB allocations, do we need to use the new algorithm for all platforms? As far as I know, only aarch64 and ppc64 need it because they want to use a single "load immediate" instruction.
For the other CPUs, we can just ask the OS. That will be faster, always succeed, and be at the "right" location as decided by the OS.

The argument for doing it on the remaining platforms (x64 and risc) would be that those, too, could profit from using 16-bit moves and short immediates, instead of - e.g. in the case of x64 - always emitting a giant 8-byte immediate for addi.

Do you mean this?

  0x00007f13e73204e9:   mov    0x8(%rax),%ebx               ;; 1141:   __ load_klass(rbx, rax, rscratch1);
  0x00007f13e73204ec:   movabs $0x800000000,%r10
  0x00007f13e73204f6:   add    %r10,%rbx

I am not familiar with x64 instructions. I thought 64-bit immediate moves to a register must be 10 bytes (8 byte immediate value), if the value is larger than 32 bits. So you can't make the movabs instruction any shorter.

And that the code would be better tested, since all platforms run through it.

OTOH, this could also be done in a follow-up. So, if you prefer it that way, I make that section aarch/ppc only.

For this PR, I would prefer doing it only on aarch64/ppc for the above 32GB allocations (otherwise we will have a regression for the other platforms -- there's now a chance of failure, at least theoretically).

The algorithm is still used on all plaforms for the lower allocations, right? So we will get some test mileage that way.

Copy link
Contributor

@adinn adinn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work.

// At CDS runtime, there is no need bothering with low-address reservation since we cannot set
// the encoding base to zero anyway: the encoding base has to be the base of the mapped archive
// (ultimately, the start address of the region we are reserving here).
const bool try_in_low_address_ranges = !cds_runtime;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think try_in_low_address_range would be a far better name for the method param than either the current cds_runtime or your original strict_base, following the principle that it does what it says on the tin.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bike shedding done, you may stick with the current name if you wish.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like try_in_low_address_range, I will use that. Note that we hopefully can remove this clutch in the future.

}
}

// Given an address range [min, max), attempts to reserve memory within this area, with the given alignmend.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... with the given alignment.

@openjdk
Copy link

openjdk bot commented Aug 29, 2023

@tstuefe This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

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

Reviewed-by: iklam, adinn

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 13 new commits pushed to the master branch:

  • ed1ea5f: 8314024: SIGSEGV in PhaseIdealLoop::build_loop_late_post_work due to bad immediate dominator info
  • f3aeb02: 8315213: java/lang/ProcessHandle/TreeTest.java test enhance output of children
  • 1e7e2bc: 8315214: Do not run sun/tools/jhsdb tests concurrently
  • ce2a7ea: 8314056: Remove runtime platform check from frem/drem
  • 1c598c2: 8312428: PKCS11 tests fail with NSS 3.91
  • b2728cb: 8189685: need PerfMemory class update and a volatile_static_field support in VMStructs
  • e22762c: 8314932: G1: Fix -Wconversion warnings for simple cases inside g1 folder
  • 762b652: 8314573: G1: Heap resizing at Remark does not take existing eden regions into account
  • a4e97aa: 8314753: Remove support for @beaninfo, @todo, @since.unbundled, and @note
  • 5cc64cc: 8309463: IGV: Dynamic graph layout algorithm
  • ... and 3 more: https://git.openjdk.org/jdk/compare/3dc266c58bf92b8f072ad5bcc3ac6962c06c35a9...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Aug 29, 2023
@tstuefe
Copy link
Member Author

tstuefe commented Aug 29, 2023

Nice work.

Many thanks, @adinn! I massaged in your feedback.

Copy link
Member

@iklam iklam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@tstuefe
Copy link
Member Author

tstuefe commented Aug 30, 2023

Thanks @iklam , @adinn and @rkennke!

Also thanks to @TheRealMDoerr for testing at SAP. There is one remaining test issue on AIX, but I identified it as an old problem (https://bugs.openjdk.org/browse/JDK-8315321) and already opened a PR for it. For now, I disabled the test on AIX until that is fixed.

I decided to push now, rather than after my vacation, to give this patch more time to test before 22 close.

/integrate

@openjdk
Copy link

openjdk bot commented Aug 30, 2023

Going to push as commit 89d18ea.
Since your change was applied there have been 23 commits pushed to the master branch:

  • dd64a4a: 8315241: (fs) Move toRealPath tests in java/nio/file/Path/Misc.java to separate JUnit 5 test
  • 8e4cda0: 8314834: serviceability/jdwp/AllModulesCommandTest.java ignores VM flags
  • 1ea6463: 8314835: gtest wrappers should be marked as flagless
  • 93e82c0: 8314824: Fix serviceability/jvmti/8036666/GetObjectLockCount.java to use vm flags
  • 7daae1f: 8314263: Signed jars triggering Logger finder recursion and StackOverflowError
  • 6701eba: 8315117: Update Zlib Data Compression Library to Version 1.3
  • e29f0c2: 8297777: Convert jdk.jlink StringSharingPlugin to use Class File API
  • bf63945: 8298992: runtime/NMT/SummarySanityCheck.java failed with "Total committed (MMMMMM) did not match the summarized committed (NNNNNN)"
  • cb3f968: 8314651: G1: Fix -Wconversion warnings in static fields of HeapRegion
  • 876a725: 8315206: RISC-V: hwprobe query is_set return wrong value
  • ... and 13 more: https://git.openjdk.org/jdk/compare/3dc266c58bf92b8f072ad5bcc3ac6962c06c35a9...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Aug 30, 2023
@openjdk openjdk bot closed this Aug 30, 2023
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Aug 30, 2023
@openjdk
Copy link

openjdk bot commented Aug 30, 2023

@tstuefe Pushed as commit 89d18ea.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@wenshao
Copy link
Contributor

wenshao commented Oct 15, 2023

This PR cause compilation errors on Orange Pi5 Plus (http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-plus.html)

The error message is as follows:

orangepi5plus:jdk:# make images                                                                                                           <89d18ea40f3 ✗>
Building target 'images' in configuration 'linux-aarch64-server-release'
Creating support/modules_libs/java.base/jrt-fs.jar
Updating support/modules_libs/java.base/server/libjvm.so due to 6 file(s)
Creating interim java.base.jmod
Creating support/demos/image/jfc/FileChooserDemo/FileChooserDemo.jar
Creating support/demos/image/jfc/CodePointIM/CodePointIM.jar
Creating support/demos/image/jfc/SwingSet2/SwingSet2.jar
Creating support/demos/image/jfc/Font2DTest/Font2DTest.jar
Creating support/demos/image/jfc/J2Ddemo/J2Ddemo.jar
Creating support/demos/image/jfc/Metalworks/Metalworks.jar
Creating support/demos/image/jfc/Notepad/Notepad.jar
Creating support/demos/image/jfc/Stylepad/Stylepad.jar
Creating support/demos/image/jfc/SampleTree/SampleTree.jar
Creating support/demos/image/jfc/TableExample/TableExample.jar
Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar
Creating interim jimage
Creating support/classlist.jar
/usr/bin/bash: line 15: 1795239 Aborted                 (core dumped) /root/git/jdk/build/linux-aarch64-server-release/support/interim-image/bin/java -XX:DumpLoadedClassList=/root/git/jdk/build/linux-aarch64-server-release/support/link_opt/classlist.raw.2 -XX:SharedClassListFile=/root/git/jdk/build/linux-aarch64-server-release/support/link_opt/classlist.interim -XX:SharedArchiveFile=/root/git/jdk/build/linux-aarch64-server-release/support/link_opt/classlist.jsa -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true -Duser.language=en -Duser.country=US --module-path /root/git/jdk/build/linux-aarch64-server-release/support/classlist.jar -cp /root/git/jdk/build/linux-aarch64-server-release/support/classlist.jar build.tools.classlist.HelloClasslist 2> /root/git/jdk/build/linux-aarch64-server-release/support/link_opt/stderr > /root/git/jdk/build/linux-aarch64-server-release/support/link_opt/default_jli_trace.txt
ERROR: Failed to generate link optimization data. This is likely a problem with the newly built JVM/JDK.
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (macroAssembler_aarch64.cpp:4550), pid=1795239, tid=1795240
#  guarantee((shifted_base & 0xffff0000ffffffff) == 0) failed: compressed class base bad alignment
#
# JRE version:  (22.0) (build )
# Java VM: OpenJDK 64-Bit Server VM (22-internal-adhoc.root.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0xae1ca0]  MacroAssembler::decode_klass_not_null(Register, Register)+0x250
#
# Core dump will be written. Default location: /root/git/jdk/make/core
#
# An error report file with more information is saved as:
# /root/git/jdk/make/hs_err_pid1795239.log
#
#
gmake[3]: *** [GenerateLinkOptData.gmk:71: /root/git/jdk/build/linux-aarch64-server-release/support/link_opt/classlist] Error 134
gmake[2]: *** [make/Main.gmk:649: generate-link-opt-data] Error 2

ERROR: Build failed for target 'images' in configuration 'linux-aarch64-server-release' (exit code 2) 

No indication of failed target found.
HELP: Try searching the build log for '] Error'.
HELP: Run 'make doctor' to diagnose build problems.

make[1]: *** [/root/git/jdk/make/Init.gmk:323: main] Error 2
make: *** [/root/git/jdk/make/Init.gmk:189: images] Error 2

hs_err_pid1795239.log

// we impose a minimum value if vm.mmap_min_addr is too low, for increased protection.
static size_t value = 0;
if (value == 0) {
assert(is_aligned(_vm_min_address_default, os::vm_allocation_granularity()), "Sanity");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tstuefe
Copy link
Member Author

tstuefe commented Nov 27, 2023

This PR cause compilation errors on Orange Pi5 Plus (http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-plus.html)

The error message is as follows:

orangepi5plus:jdk:# make images                                                                                                           <89d18ea40f3 ✗>
Building target 'images' in configuration 'linux-aarch64-server-release'
Creating support/modules_libs/java.base/jrt-fs.jar
Updating support/modules_libs/java.base/server/libjvm.so due to 6 file(s)
Creating interim java.base.jmod
Creating support/demos/image/jfc/FileChooserDemo/FileChooserDemo.jar
Creating support/demos/image/jfc/CodePointIM/CodePointIM.jar
Creating support/demos/image/jfc/SwingSet2/SwingSet2.jar
Creating support/demos/image/jfc/Font2DTest/Font2DTest.jar
Creating support/demos/image/jfc/J2Ddemo/J2Ddemo.jar
Creating support/demos/image/jfc/Metalworks/Metalworks.jar
Creating support/demos/image/jfc/Notepad/Notepad.jar
Creating support/demos/image/jfc/Stylepad/Stylepad.jar
Creating support/demos/image/jfc/SampleTree/SampleTree.jar
Creating support/demos/image/jfc/TableExample/TableExample.jar
Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar
Creating interim jimage
Creating support/classlist.jar
/usr/bin/bash: line 15: 1795239 Aborted                 (core dumped) /root/git/jdk/build/linux-aarch64-server-release/support/interim-image/bin/java -XX:DumpLoadedClassList=/root/git/jdk/build/linux-aarch64-server-release/support/link_opt/classlist.raw.2 -XX:SharedClassListFile=/root/git/jdk/build/linux-aarch64-server-release/support/link_opt/classlist.interim -XX:SharedArchiveFile=/root/git/jdk/build/linux-aarch64-server-release/support/link_opt/classlist.jsa -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true -Duser.language=en -Duser.country=US --module-path /root/git/jdk/build/linux-aarch64-server-release/support/classlist.jar -cp /root/git/jdk/build/linux-aarch64-server-release/support/classlist.jar build.tools.classlist.HelloClasslist 2> /root/git/jdk/build/linux-aarch64-server-release/support/link_opt/stderr > /root/git/jdk/build/linux-aarch64-server-release/support/link_opt/default_jli_trace.txt
ERROR: Failed to generate link optimization data. This is likely a problem with the newly built JVM/JDK.
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (macroAssembler_aarch64.cpp:4550), pid=1795239, tid=1795240
#  guarantee((shifted_base & 0xffff0000ffffffff) == 0) failed: compressed class base bad alignment
#
# JRE version:  (22.0) (build )
# Java VM: OpenJDK 64-Bit Server VM (22-internal-adhoc.root.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0xae1ca0]  MacroAssembler::decode_klass_not_null(Register, Register)+0x250
#
# Core dump will be written. Default location: /root/git/jdk/make/core
#
# An error report file with more information is saved as:
# /root/git/jdk/make/hs_err_pid1795239.log
#
#
gmake[3]: *** [GenerateLinkOptData.gmk:71: /root/git/jdk/build/linux-aarch64-server-release/support/link_opt/classlist] Error 134
gmake[2]: *** [make/Main.gmk:649: generate-link-opt-data] Error 2

ERROR: Build failed for target 'images' in configuration 'linux-aarch64-server-release' (exit code 2) 

No indication of failed target found.
HELP: Try searching the build log for '] Error'.
HELP: Run 'make doctor' to diagnose build problems.

make[1]: *** [/root/git/jdk/make/Init.gmk:323: main] Error 2
make: *** [/root/git/jdk/make/Init.gmk:189: images] Error 2

hs_err_pid1795239.log

@wenshao Could you please test whether #16743 fixes your problem?

If it still crashes, could you please reproduce the crash with

java -Xlog:os*=trace -Xlog:metaspace*=trace -version

and send the output?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot-runtime hotspot-runtime-dev@openjdk.org integrated Pull request has been integrated
5 participants