RFR: 8347830: [premain] UseCompatibleCompressedOops is broken after merging with mainline

Ashutosh Mehra asmehra at openjdk.org
Fri May 16 14:48:09 UTC 2025


On Fri, 16 May 2025 02:33:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> The issue was that we did not allocate space "noaccess prefix" before heap for read-only page when we setup type of encoding  with `UseCompatibleCompressedOops` flag. I update code which reserves heap for compressed oops to take into account this flag.
> 
> An other issue was that `UseCompatibleCompressedOops` flag was set during CDS arguments consistency checkup. But `UseCompressedOops` flag is set by GC ergonomics. I moved code to CDS ergonomics setting method.
> 
> During testing I hit assert that AOT code address table is missing some code blob address. But it was actually card table base address which pointed inside CodeCache. I added special case to check for it early.
> 
> Tested premain-tier1.

src/hotspot/share/cds/cdsConfig.cpp line 140:

> 138:     FLAG_SET_ERGO_IF_DEFAULT(UseCompatibleCompressedOops, true);
> 139:   } else if (!FLAG_IS_DEFAULT(UseCompatibleCompressedOops)) {
> 140:     FLAG_SET_ERGO(UseCompatibleCompressedOops, false);

Why do we need to set it to false explicitly here? If it is not default shouldn't we use whatever value the user specified?

src/hotspot/share/memory/memoryReserver.cpp line 556:

> 554:   bool unscaled  = false;
> 555:   bool zerobased = false;
> 556:   bool heapbased = UseCompatibleCompressedOops;

Use of `heapbased` is a bit confusing to me. Can we restructure it like this:

bool unscaled = false;
bool zerobased = false;
if (UseCompatibleCompressedOops) {
  unscaled = (heap_end_address <= (char*)UnscaledOopHeapMax);
  zerobased = (heap_end_address <= (char*)OopEncodingHeapMax);
}
size_t noaccess_prefix = (UseCompatibleCompressedOops || !zerobased) ? noaccess_prefix_size : 0;

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

PR Review Comment: https://git.openjdk.org/leyden/pull/67#discussion_r2093194599
PR Review Comment: https://git.openjdk.org/leyden/pull/67#discussion_r2093194693


More information about the leyden-dev mailing list