On Tue, 3 Nov 2026 13:46:18 GMT, Gui Cao <[email protected]> wrote:
> Hi, please condiser.
> SA currently computes continuation entry frame pointers using the raw
> sizeof(ContinuationEntry), whereas HotSpot uses that size rounded up to two
> machine words.
> With the current 64-bit layout, the raw size is 56 bytes and the aligned size
> is 64 bytes. Consequently, SA computes frame pointers eight bytes too low on
> x86-64, AArch64, and RISC-V64.
>
> This change:
> - Aligns the size in the shared SA implementation, matching
> ContinuationEntry::size().
> - Preserves RISC-V’s additional two-word FP adjustment.
> - Adds a cross-platform jtreg test that checks FP offsets using the attached
> JVM’s type metadata and a synthetic entry address, without depending on
> stack-walking behavior or virtual-thread timing.
>
> Testing: github ci
>
> ---------
> - [x] I confirm that I make this contribution in accordance with the [OpenJDK
> Interim AI Policy](https://openjdk.org/legal/ai).
test/hotspot/jtreg/serviceability/sa/TestContinuationEntry.java line 61:
> 59: long alignedSize = ((rawSize + alignment - 1) / alignment) *
> alignment;
> 60: String cpu = agent.getDebugger().getCPU();
> 61: long expectedOffset = alignedSize + (cpu.equals("riscv64") ?
> 2 * wordSize : 0);
It would be nice to have a comment on why the extra logic is needed for
riscv64, and maybe reference the hotspot riscv64 ContinuationEntry::entry_fp()
and/or the SA RISCV64ContinuationEntry.getEntryFP() code.
Also, it appears this PR is based on a revision of openjdk that does not yet
include the fix to RISCV64ContinuationEntry.getEntryFP(). How is this test
passing for you on riscv64?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/33695#discussion_r4457578042
