RFR: 8359963: compiler/c2/aarch64/TestStaticCallStub.java fails with for code cache > 250MB the static call stub is expected to be implemented using far branch
Evgeny Astigeevich
eastigeevich at openjdk.org
Thu Jul 24 10:21:54 UTC 2025
On Mon, 30 Jun 2025 15:24:42 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> wrote:
> The test assumed that hsdis is always available which is not the case. Make the test accept and scan either real or pseudo disassembly.
test/hotspot/jtreg/compiler/c2/aarch64/TestStaticCallStub.java line 272:
> 270: while (itr.hasNext() && extracted.size() < n) {
> 271: int left = n - extracted.size();
> 272: extractOpcodeOrBytecodes(itr.next()).stream().limit(left).forEach(extracted::add);
You can detect whether you have hex codes or disassembly.
See https://github.com/openjdk/jdk/blob/a86dd56de34f730b42593236f17118ef5ce4985a/test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitAArch64.java#L122
In TestOnSpinWaitAArch64 you can see how the checking code is organized not to depend on the instruction representation.
IMO you don't need the Instruction class hierarchy.
You need `nearStaticCallOpcodeSeq` and `farStaticCallOpcodeSeq` to be filled either with opcodes or hex codes. Of course their names need to be changed to something like `nearStaticCallInstSeq`. You will need to change `extractOpcodesN` and `extractOpcode` to `extractInstructionsN` and `extractInstruction`.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26047#discussion_r2228099896
More information about the hotspot-compiler-dev
mailing list