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