On Mon, 9 Feb 2026 08:25:25 GMT, Thomas Stuefe <[email protected]> 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
