RFR: 8305765: CompressedClassPointers.java is unreliable due to ASLR

[Calvin Cheung]

On Wed, 4 Oct 2023 17:55:28 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> 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](https://bugs.openjdk.org/browse/JDK-8317610) which seems to fail similarly to a previous bug [JDK-8283249](https://bugs.openjdk.org/browse/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)

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

PR Comment: https://git.openjdk.org/jdk/pull/16014#issuecomment-1749712935