RFR: 8286302: Port JEP 425 to PPC64 [v9]

[Leonid Mesnik]

On Tue, 22 Nov 2022 20:40:52 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Hi,
>> 
>> this is the port of [JEP 425: Virtual Threads (Preview)](https://openjdk.org/jeps/425)) to PPC64.
>> More precisely it is the port of vm continuations in hotspot to PPC64. It allows to run with `-XX:+VMContinuations` which is a prerequisit for 'real' virtual threads (oxymoron?).
>> 
>> Most of the shared code changes are related to a new platform dependent constant `frame::metadata_words_at_top`. It is either added or subtracted to a frame address or size.
>> 
>> The following is supposed to explain (without real life details) why it is needed in addition to the existing `frame::metadata_words`. The diagram shows a frame at `SP` and its stack arguments. The caller frame is located at `callers_SP`.
>> 
>> 
>>   X86 / AARCH64                             PPC64:
>> 
>>   :                 :                       :                 :
>>   :                 :                       :                 :
>>   |                 |                       |                 |
>>   |-----------------|                       |-----------------|
>>   |                 |                       |                 |
>>   | stack arguments |                       | stack arguments |
>>   |                 |<- callers_SP          |                 |
>>   ===================                       |-----------------|
>>   |                 |                       |                 |
>>   | metadata at bottom |                       | metadata at top    |
>>   |                 |                       |                 |<- callers_SP
>>   |-----------------|                       ===================
>>   |                 |                       |                 |
>>   |                 |                       |                 |
>>   |                 |                       |                 |
>>   |                 |                       |                 |
>>   |                 |<- SP                  |                 |
>>   ===================                       |-----------------|
>>                                             |                 |
>>                                             | metadata at top    |
>>                                             |                 |<- SP
>>                                             ===================
>> 
>> 
>> On X86 and AARCH64 metadata (that's return address, saved SP/FP, etc.) is stored at the frame bottom (`metadata at bottom`). On PPC64 it is stored at the frame top (`metadata at top`) where it affects size and address calculations. Shared code deals with this by making use of the platform dependent constant `frame::metadata_words_at_top`.
>> 
>> * size required to 'freeze' a single frame with its stack arguments in a `StackChunk`:
>>   `sizeof(frame) + sizeof(stack arguments) + frame::metadata_words_at_top`
>> 
>> * address of stack arguments:
>>   `callers_SP + frame::metadata_words_at_top`
>> 
>> * The value of `frame::metadata_words_at_top` is 0 words on X86 and AARCH64. On PPC64 it is 4 words.
>> 
>> Please refer to comments I've added for more details (e.g. the comment on StackChunkFrameStream<frame_kind>::frame_size()). Recently I've given a talk about vm continuations and the PPC64 port to my colleagues. It's rather an overview than a deep dive. [The slides](http://cr.openjdk.java.net/~rrich/webrevs/2022/8286302/202210_loom_ppc64_port.pdf) might serve as well as an intro to the matter.
>> 
>> The pr includes the new test jdk/jdk/internal/vm/Continuation/BasicExp.java which I wrote while doing the port. The test cases vary from simple to not-so-simple. One of the main features is that a CompilationPolicy passed as argument controls which frames are compiled/interpreted when freezing by defining a sliding window of compiled / interpreted frames which produces interesting transitions with and without stack arguments. There is overlap with Basic.java and Fuzz.java. Let me know wether to remove or keep BasicExp.java. Runtime with fastdebug: 2m on Apple M1 Pro and 3m on Intel Xeon E5-2660 v3 @ 2.60GHz. Note that -XX:+VerifyContinuations is explicitly set as a found it very useful, it increases the runtime quite a bit though.
>> 
>> Testing: the change passed our CI testing: most JCK and JTREG tests, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite and SAP specific tests with fastdebug and release builds on the standard platforms plus PPC64. These tests do include hotspot_loom and jdk_loom JTREG tests which I've also run with TEST_VM_OPTS="-XX:+VerifyContinuations" on X86_64, PPC64, and AARCH64.
>> 
>> Thanks, Richard.
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More Feedback Leonid

Thanks for fixing the test.
I haven't done the full review, not adding myself as a reviewer. Don't have any additional comments.

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

PR: https://git.openjdk.org/jdk/pull/10961