-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8286302: Port JEP 425 to PPC64 #10961
Conversation
👋 Welcome back rrich! A progress list of the required criteria for merging this PR into |
/label hotspot-compiler,hotspot-runtime |
@reinrich The |
Webrevs
|
Hi, I also tested this on my Linux RISC-V platform which has support for virtual threads. Test results look good. Thanks.
|
Great. Thanks for the testing. Richard. |
I see a couple failures on Linux/ppc64le when testing with jdk/internal/vm/Continuation/Fuzz.java#default It may be reasonable to add these to a ProblemList.txt and address them at a different time. |
Thanks for looking at the pr. The failures are due to timeouts. Depending on the load on your test system it might be necessary to increment the timeout factor (JTREG="TIMEOUT_FACTOR=8"). There were issues with the test before (see https://bugs.openjdk.org/browse/JDK-8290211). |
The failures are indeed time-dependant, and pass with JTREG="TIMEOUT_FACTOR=16". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes are significant. They appear well thought out and well executed. Thanks for submitting this PR.
Thanks for your review @backwaterred |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work! Looks very good to me. I'm requesting precise node sizes in C2 (let's keep this invariant: nodes should either have a precisely precomputed size or use dynamic computation). The rest are just minor comments and suggestions.
I need more time to study all explanations and to review the test, but I can't see anything which prevents us from shipping it with JDK 20.
Thanks for the ASCII art pictures!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the updates! I'll look more into the explanations and the test, but you don't have to wait for that after you got your 2nd review.
@reinrich This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 17 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
Thanks a lot indeed! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for mitigating the risk of test timeouts!
Yes I had to adjust the timeout a little. Also it's not necessary to set -XX:+VerifyContinuations again in the runs that call System.gc(). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a complete review but some notes about test style.
Thanks for your feedback @lmesnik. It help reducing the runtime of the test significantly. |
Thanks for fixing the test. |
Thanks a lot for the reviews and feedback! |
/integrate |
Going to push as commit 43d1173.
Your commit was automatically rebased without conflicts. |
Hi,
this is the port of JEP 425: Virtual Threads (Preview)) 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 atSP
and its stack arguments. The caller frame is located atcallers_SP
.On X86 and AARCH64 metadata (that's return address, saved SP/FP, etc.) is stored at the frame bottom (
metadata@bottom
). On PPC64 it is stored at the frame top (metadata@top
) where it affects size and address calculations. Shared code deals with this by making use of the platform dependent constantframe::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 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.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/10961/head:pull/10961
$ git checkout pull/10961
Update a local copy of the PR:
$ git checkout pull/10961
$ git pull https://git.openjdk.org/jdk pull/10961/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 10961
View PR using the GUI difftool:
$ git pr show -t 10961
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/10961.diff