RFR: 8315069: Relativize extended_sp in interpreter frames

Andrew Haley aph at openjdk.org
Wed Aug 30 13:31:12 UTC 2023


On Wed, 30 Aug 2023 12:41:32 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 815:
>> 
>>> 813:   __ sub(esp, esp, entry_size);
>>> 814:   __ sub(rscratch1, sp, rfp);
>>> 815:   __ asr(rscratch1, rscratch1, Interpreter::logStackElementSize);
>> 
>> The shifts when calculating the relativized extended SP increase latency and reduce throughput, and they don't do anything useful.
>
>> 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.

OK, fair enough. It's somewhat annoying and pointless, but we can live with it.

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

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


More information about the hotspot-dev mailing list