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