RFR: JDK-8283249: CompressedClassPointers.java fails on ppc with 'Narrow klass shift: 0' missing

[Thomas Stuefe]

On Wed, 16 Mar 2022 09:43:16 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> These tests are highly vulnerable against ASLR. On PPC, we apparently don't manage to map the heap into the lower 4G region, therefore CCS does not live there either.
> 
> The test requires for "-UseCompressedOops -Xshare:off" and a heap size of 128m and a ccs size of 1G ccs to live in the lower 4G. That is an optimistic assumption.
> 
> The VM attaches instead CCS to 0x100000000 (4GB) and calculates Narrow Base/Shift as 0/3, which is totally correct.
> 
> As a stop-gap measure, the test should be less strict for PPC and PPCLE.
> 
> ---
> 
> Idle thoughts:
> 
> A future solution would be to revise this test. It is maintenance intensive and fragile. Arguably its also not that important, since it tests with CDS disabled, which is not a realistic scenario.
> 
> To me, it is not clear to me what it is supposed to test:
> 1) the ability of the kernel to give us memory segments at preferred addresses?
> 2) the ability of the VM to make the best of it, i.e. to calculate narrow klass base and shift that make sense?
> 3) the ability of the VM to decode/encode with exotic base/shift addresses
> 
> IMHO, 
> - testing (1) makes no sense since we are at the mercy of the kernel.
> - testing (2) makes a bit sense, but honestly, the logic to derive narrow klass base and shift is so simple that I don't think we need to test that. 
> - testing (3) makes a lot of sense, since the CPU dependent logic for decoding and encoding can be complicated and usually only runs with a given set of base and shift (we had e.g. hidden bugs on s390 for years). But that one can be tested way better with our new option `-XX:CompressedClassSpaceBaseAddress`.

Gentle Ping. Its really trivial.

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

PR: https://git.openjdk.java.net/jdk/pull/7837