RFR: 8372703: Test compiler/arguments/TestCodeEntryAlignment.java failed: assert(allocates2(pc)) failed: not in CodeBuffer memory
Volodymyr Paprotski
vpaprotski at openjdk.org
Tue Dec 2 15:30:43 UTC 2025
On Tue, 2 Dec 2025 14:39:15 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:
>> Requires a Broadwell machine, but was able to reproduce with an emulator:
>>
>>
>> ~/sde-external-9.58.0-2025-06-16-lin/sde64 -follow-subprocess -bdw -- ./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -XX:-UseMulAddIntrinsic -XX:+UseDilithiumIntrinsics -XX:+UnlockExperimentalVMOptions -XX:CodeCacheSegmentSi
>> ze=1024 -XX:CodeEntryAlignment=1024 -cp build/linux-x86_64-server-fastdebug/support/test/lib/test-lib.jar test/hotspot/jtreg/compiler/arguments/TestCodeEntryAlignment.java run
>
> src/hotspot/cpu/x86/stubDeclarations_x86.hpp line 76:
>
>> 74: do_arch_entry, \
>> 75: do_arch_entry_init) \
>> 76: do_arch_blob(compiler, 120000 WINDOWS_ONLY(+2000)) \
>
> I was wondering if there are any reason for this value (apart that it is enough for the test to pass. I just noticed that it has been increased already in the past).
The assert was suggesting 119k (and change..) so I rounded slightly up. I was going to ask (i.e. @TobiHartmann ?) if thats enough..
(Similarly, I am concerned that I am contributing to a larger JVM footprint, with my changes.. but I suppose 11k is comparatively insignificant in the grand scheme of things...)
Thanks for the review!
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28588#discussion_r2581685779
More information about the hotspot-compiler-dev
mailing list