RFR: 8349102: Test compiler/arguments/TestCodeEntryAlignment.java failed: assert(allocates2(pc)) failed: not in CodeBuffer memory
Andrew Dinn
adinn at openjdk.org
Thu Feb 6 09:14:06 UTC 2025
On Wed, 5 Feb 2025 22:03:37 GMT, Dean Long <dlong at openjdk.org> wrote:
>> …assert(allocates2(pc)) failed: not in CodeBuffer memory
>>
>> The StubGenenerator compiler blob runs out of space when TestCodeEntryAlignment is run on macos/x86_64 on an avx2-only CPU. This only happens in the worst case with command line options `-XX:CodeCacheSegmentSize=1024 -XX:CodeEntryAlignment=1024`.
>>
>> On linux/x86_64 the test succeeds in that worst case when run on an avx512-enabled CPU but with only 980 bytes of headroom.
>>
>> This patch increments the buffer size on x86_64 to ensure both the avx2 and avx3 cases have enough headroom.
>>
>> n.b. the increment has deliberately been made x86_64-specific rather than macos-specific, even though this problem manifests when testing MacOS and does not manifest when testing Linux. The disparity in generated stubs size actually relates to the capabilities of the CPU and is independent of OS.
>
> This seems fine, but it has always bothered me that we have to set and occasionally adjust these constant sizes at all. If we were multi-threaded when doing the allocations I guess it would make sense, but since we are single-threaded, why not use the entire available space and then give back whatever we don't use?
@dean-long "why not use the entire available space and then give back whatever we don't use?"
We could probably do something along those lines. I'll look into it. Meanwhile I'll integrate this fix.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23439#issuecomment-2639230735
More information about the hotspot-compiler-dev
mailing list