8305765: CompressedClassPointers.java is unreliable due to ASLR

[calvinccheung]

A new log statement is added to the Metaspace::global_initialize function to indicate that the compress class space is being allocate at an address chosen by the platform. The CompressedClassPointers.java test will base on the log output before checking the expected Narrow klass base output.

Passed tiers 1 - 3 testing.
Also ran the test on linux-aarch64 and linux-aarch64-debug platforms, 30 times each.

---

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

Issue

• JDK-8305765: CompressedClassPointers.java is unreliable due to ASLR (Bug - P4)

Reviewers

• Ioi Lam (@iklam - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 16014

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

Using diff file

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

Webrev

Link to Webrev Comment

[calvinccheung]

/label add hotspot-runtime

[bridgekeeper]

👋 Welcome back ccheung! 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]

@calvinccheung
The hotspot-runtime label was successfully added.

[mlbridge]

Webrevs

• 00: Full (350d64f0)

[iklam]

LGTM.

[openjdk]

@calvinccheung 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:

8305765: CompressedClassPointers.java is unreliable due to ASLR

Reviewed-by: iklam

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 17 new commits pushed to the master branch:

• f985006: 8309356: Read files in includedir in alphanumeric order
• a564d43: 8315692: Parallelize gc/stress/TestStressRSetCoarsening.java test
• 878d27d: 8317273: compiler/codecache/OverflowCodeCacheTest.java fails transiently on Graal
• 2637e8d: 8317314: Remove unimplemented ObjArrayKlass::oop_oop_iterate_elements_bounded
• 8093563: 8317295: ResponseSubscribers.SubscriberAdapter should call the finisher function asynchronously
• 516cfb1: 8316907: Fix nonnull-compare warnings
• 5984792: 8316415: Parallelize sun/security/rsa/SignedObjectChain.java subtests
• eeb63cd: 8316361: C2: assert(!failure) failed: Missed optimization opportunity in PhaseIterGVN with -XX:VerifyIterativeGVN=10
• 6948942: 8317327: Remove JT_JAVA dead code in jib-profiles.js
• 795e5dc: 8315503: G1: Code root scan causes long GC pauses due to imbalanced iteration
• ... and 7 more: https://git.openjdk.org/jdk/compare/5a6aa569aa279141193038dc2e61e18a8b24bc11...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.

[calvinccheung]

Thanks @iklam for the review!

/integrate

[openjdk]

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

• 4195246: 8317354: Serial: Move DirtyCardToOopClosure to gc/serial folder
• 0a3a925: 8316414: C2: large byte array clone triggers "failed: malformed control flow" assertion failure on linux-x86
• b0d6c84: 8316396: Endless loop in C2 compilation triggered by AddNode::IdealIL
• a8549b6: 8280120: [IR Framework] Add attribute to @ir to enable/disable IR matching based on the architecture
• 9718f49: 8317452: [JVMCI] Export symbols used by lightweight locking to JVMCI compilers.
• 0d4de8a: 8316971: Add Lint warning for restricted method calls
• d4c904d: 8317294: Classloading throws exceptions over already pending exceptions
• 48f1a92: 8316679: C2 SuperWord: wrong result, load should not be moved before store if not comparable
• 0b0f8b5: 8219652: [aix] Tests failing with JNI attach problems.
• 8c0d026: 8315042: NPE in PKCS7.parseOldSignedData
• ... and 38 more: https://git.openjdk.org/jdk/compare/5a6aa569aa279141193038dc2e61e18a8b24bc11...master

Your commit was automatically rebased without conflicts.

[openjdk]

@calvinccheung Pushed as commit ddacf92.

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

[tstuefe]

Wait, I don't get this. This test tests the ability of the platform to place the CCS in lower address space regions. Failing that and falling back to reserving anywhere should count as a failure.

To put it another way, if the logic that tries to reserve low address memory is broken, this test should fail, not accept the fallback solution as success.

That is not to say that this test is not fragile. It is. It makes sense to revise it, and tweak it to have a higher success rate. E.g. reduce the CCS size drastically. But with, say, a 64M class space, no CDS, and a tiny heap, it should be possible to find some free space below 32G.

Looking at the test, it also may make sense to remove the dependency on UseCompressedOops.

Side note: Don't we need two reviewers for hotspot code? Or does this rule not apply for tests?

[calvinccheung]

Wait, I don't get this. This test tests the ability of the platform to place the CCS in lower address space regions. Failing that and falling back to reserving anywhere should count as a failure.

To put it another way, if the logic that tries to reserve low address memory is broken, this test should fail, not accept the fallback solution as success.

That is not to say that this test is not fragile. It is. It makes sense to revise it, and tweak it to have a higher success rate. E.g. reduce the CCS size drastically. But with, say, a 64M class space, no CDS, and a tiny heap, it should be possible to find some free space below 32G.

Looking at the test, it also may make sense to remove the dependency on UseCompressedOops.

I agree that we should revise the fix as we are still seeing intermittent failures on Windows-x64 with the fix. See JDK-8317610 which seems to fail similarly to a previous bug JDK-8283249. The CompressedClassSpaceSize is default to 1G. Do you mean we should always set it to 64M for the test case? Also, there are couple of tests using -Xshare:on, should we just remove them? Most of the test cases are using -Xmx128m. Only the largeHeapTest() and the largeHeapAbove32GTest() are using -Xmx30g and -Xmx31g, respectively. Are those two heap sizes too large?

Side note: Don't we need two reviewers for hotspot code? Or does this rule not apply for tests?

For a test only fix, only 1 review is required. Since this fix involves adding a log statement in the hotspot code, I agree that the rule has been followed completely.

(BTW, I'm on vacation for a few days until Oct. 13)

[dholmes-ora]

For a test only fix, only 1 review is required.

If it qualified as trivial yes. The rule for reviews doesn't say anything about test-only changes:

For the HotSpot codebase there are a few additional requirements:

    Your change must have been approved by two reviewers out of which at least one is also a Reviewer
    Your change must have passed through HotSpot tier 1 testing with zero failures (See tier1 definition in test/hotspot/jtreg/TEST.groups.)

https://openjdk.org/guide/index.html#hotspot-development