RFR: JDK-8318485: Narrow klass shift should be zero if encoding range extends to 0x1_0000_0000

[Thomas Stuefe]

On Fri, 20 Oct 2023 23:06:51 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> See JBS issue.
>> 
>> The real fix, trivial, is the comparison change in compressedKlass.cpp.
>> 
>> This patch then also adds a test that checks that for a given (forced) class space location the VM chose the correct encoding scheme. In this case, if class space nestles below and ends at 4G, we should use a shift of 0.
>> 
>> The test can be easily extended to test more narrow Klass encoding schemes. Note that the test is skipped if the VM could not map at the expected address to begin with.
>> 
>> Finally, to analyze test errors, I print out the mappings at the force address if metaspace logging is debug.
>> 
>> Tests: manual, GHA. x86 GHA errors unrelated.
>> 
>> 
>> Attention @iklam and @calvinccheung
>
> test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java line 78:
> 
>> 76:         test(4 * G - 128 * M, 128 * M, 0, 0);
>> 77: 
>> 78:         // add more...
> 
> The following works on my linux dev host.
> 
>         test(0xa0000000L, 1 * G, 0, 0);
>         test(0x100000000L, 2 * G, 0, 3);
> 
> Maybe you can consider adding them to the test?

I'd rather expand this in a separate RFE. Second one *should* work on all platforms, but I am not 100% sure some would encode this with base=4g shift=0 instead. Probably not, but it is better to stay focused on one issue. Makes also for clearer backporting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16261#discussion_r1368549077