RFR: 8330174: Protection zone for easier detection of accidental zero-nKlass use [v6]

[Thomas Stuefe]

On Sat, 22 Feb 2025 21:33:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
>> 
>>  - copyrights
>>  - Redo everything, including Iois changes
>>  - reverse everything
>>  - Merge branch 'master' into JDK-8330174-Protection-zone-for-easier-detection-of-accidental-zero-nKlass-use
>>  - fix whitespace error
>>  - fix test
>>  - test-fixes
>>  - fix bug found with jtreg test where metaspace buddy allocator would accidentally replace the protection mapping
>>  - add jtreg test; replaces the gtest
>>  - Merge branch 'master' into JDK-8330174-Protection-zone-for-easier-detection-of-accidental-zero-nKlass-use
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/7ada9801...6d85e1fe
>
> src/hotspot/share/memory/metaspace.cpp line 812:
> 
>> 810:     // After narrowKlass encoding scheme is decided: if the encoding base points to class space start,
>> 811:     // establish a protection zone.
>> 812:     if (CompressedKlassPointers::base() == (address)rs.base()) {
> 
> What happens if this condition is not true? Do we need  to check for encoded values of zero?
> 
> Or, is the following true?
> 
> 
> } else {
>     assert((unitx)(CompressedKlassPointers::base()) == 0x0, "must be zero based");
> }
> 
> 
> Is the `else` part covered by your new test case?

Its the latter (even though base could be anywhere in front of the Klass range as long as the encoding covers the class space, I never used that since I planned to do this zero-access page for a while now). I added the else assert.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23190#discussion_r1967112894