RFR: 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret

[Ron Pressler]

On Wed, 8 Jun 2022 20:19:44 GMT, Dean Long <dlong at openjdk.org> wrote:

>> The continuation free/thaw mechanism relies on being able to move thread stacks around in memory.  However when PAC is enabled on supported AArch64 CPUs, the saved LR on the stack contains a "pointer authentication code" signed with the stack pointer at the time the frame was created.  When a stack frame is relocated we need to re-sign the LR with the new stack pointer to ensure it authenticates successfully when the method returns.
>> 
>> Introduced `ContinuationHelper::return_pc_at()` to avoid directly reading the saved PC from the stack in shared code.  On AArch64 with PAC it enabled it strips the PAC from the address after reading it, on all other platforms it just loads the PC from the stack as before.
>
> I don't see why we can't use the stack pointer instead of the frame pointer and get rid of the PreserveFramePointer requirement.

@dean-long Which sp, though? The frame's ultimate sp? I I think interpreted frames don't know their sp when they're first constructed (and not sure about when they return). Or it could be the actual location of the return address, but I don't know what that means for the protection mechanism. On the other hand, the preserved fp is always the return address's location minus 1 anyway.

Either way, it's not the right value for Loom. We'll need to consider 1. how important is PAC for _Java_ frames, and 2. if it is important, what second value to use that is invariant under stack copying.

-------------

PR: https://git.openjdk.java.net/jdk/pull/9067