RFR: 8300197: Freeze/thaw an interpreter frame using a single copy_to_chunk() call

[Fredrik Bredberg]

On Mon, 17 Apr 2023 06:49:37 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> On certain architectures (like AARCH64) padding may be inserted between the locals and the rest of the stack frame in order to keep the frame pointer 16-byte-aligned.
>> 
>> This padding is currently not freezed, instead freezing of a single interpreter stack frame is done using two separate copy_to_chunk() calls (see recurse_freeze_interpreted_frame). Likewise, thawing is done using two separate copy_from_chunk() calls.
>> 
>> This poses a bit of a problem when trying to relativize stack addresses in interpreter frames ([JDK-8289296](https://bugs.openjdk.org/browse/JDK-8289296)). Since relative offsets may need to be changed during freezing and thawing.
>> 
>> By both freezing and thawing the padding we remove the need to change any relative offsets in runtime.
>> 
>> Tested tier1-tier8 on supported platforms, found no new issues. PowerPC and RISC-V was sanity tested using Qemu.
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2160:
> 
>> 2158:   copy_from_chunk(heap_frame_top, stack_frame_top, fsize);
>> 2159: 
>> 2160:   set_interpreter_frame_bottom(f, stack_frame_bottom); // the copy overwrites the metadata
> 
> Since ThawBase::set_interpreter_frame_bottom has nothing to do after this change, I think it might be cleaner to remove this function at the same time?

I see what you mean, but I chose to keep it because of the assert() in ThawBase::set_interpreter_frame_bottom.
After all, it was this assert that alerted me to the JDK-8305247 bug.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13477#discussion_r1168764973