RFR: 8315069: Relativize extended_sp in interpreter frames

[Fredrik Bredberg]

On Wed, 30 Aug 2023 08:14:25 GMT, Andrew Haley <aph at openjdk.org> wrote:

> The shifts when calculating the relativized extended SP increase latency and reduce throughput, and they don't do anything useful.

It's true that the shift instructions add a bit of unnecessary overhead, but all the relativize and derelativize code today is based on pointer arithmetic. For instance interpreter frame locals are found at:

   `fp() + *addr_at(interpreter_frame_locals_offset)`

So in order to get rid of the shifts we would need to move away from pointer arithmetic, which means adding a lot of explicit casts in the C++ code. To get the pointer to the locals the code above would have to be changed into:

   `(intptr_t*)((char *)fp() + (char *)*addr_at(interpreter_frame_locals_offset))`

I choose to stick to the definition where a relativized value is "a word index from the frame pointer" and not change it to "number of bytes from the frame pointer", because it meant less changes to the C++ code.

Some interpreter frame members (such as `extended_sp`) doesn't show up in the C++ code as much as `locals`, but I didn't want to have different representations for a relativized pointer, so all of them are "word index from the frame pointer".

Also, the overhead of the shifts is likely negligibly since we now calculate the relativized value once, and not every time we freeze and thaw.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15468#discussion_r1310213478