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