RFR: 8363996: Obsolete UseCompressedClassPointers [v5]

[Thomas Stuefe]

On Mon, 9 Feb 2026 08:25:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointers.java line 294:
>> 
>>> 292:     }
>>> 293: 
>>> 294:     public static void heapBaseMinAddressTestNoCoop() throws Exception {
>> 
>> It is not obvious to me why this test case was deleted.
>
> Related to the change here: https://github.com/openjdk/jdk/pull/28366/changes#diff-027490ce3f4a92be9b489d9d2e54c7baaea87b7489399b198543c79f1ce1e2e3L1576
> 
> This test only worked by accident, and never made sense. 
> 
> `HeapBaseMinAddress`: in `+UseCompressedOops` mode, it forces the heap to this address (arguably, the name is a misnomer); failing that, it will treat it as a low barrier in further reservation attempts. But not always: if we cannot get any preferred address, we will use whatever address the OS gives us, which may be lower than a high value for `HeapBaseMinAddress`. (Writing this now, I think that should be a bug).
> 
> In `-UseCompressedClassPointers` mode, the flag does nothing. The test always worked because the value of 1M is so low that no OS will accidentally map into that area.
> 
> ---
> 
> Note that it's a different question of whether we *should* honor the flag for `-UseCompressedOops +UseCompressedClassPointers`. Could a barrier like that be useful to keep the heap away from low-address regions to increase the chance for a low-address class space? But looking closely, probably not worth it for two reasons: on all 64-bit platforms, the chance of "OS-determined" mappings to hit the low address regions < 32GB is so rare its not worth the complexity. And low-address heap is more useful performance-wise than low-address class space anyway.

I opened https://bugs.openjdk.org/browse/JDK-8377452 to track a possible change to HeapBaseMinAddress.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2781575093