Skip to content
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

Closed
wants to merge 13 commits into from

Conversation

reinrich
Copy link
Member

@reinrich reinrich commented Nov 2, 2022

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 at SP and its stack arguments. The caller frame is located at callers_SP.

  X86 / AARCH64                             PPC64:

  :                 :                       :                 :
  :                 :                       :                 :
  |                 |                       |                 |
  |-----------------|                       |-----------------|
  |                 |                       |                 |
  | stack arguments |                       | stack arguments |
  |                 |<- callers_SP          |                 |
  ===================                       |-----------------|
  |                 |                       |                 |
  | metadata@bottom |                       | metadata@top    |
  |                 |                       |                 |<- callers_SP
  |-----------------|                       ===================
  |                 |                       |                 |
  |                 |                       |                 |
  |                 |                       |                 |
  |                 |                       |                 |
  |                 |<- SP                  |                 |
  ===================                       |-----------------|
                                            |                 |
                                            | metadata@top    |
                                            |                 |<- 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 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 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

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

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

@bridgekeeper
Copy link

bridgekeeper bot commented Nov 2, 2022

👋 Welcome back rrich! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@reinrich
Copy link
Member Author

reinrich commented Nov 2, 2022

/label hotspot-compiler,hotspot-runtime

@openjdk openjdk bot added hotspot-compiler hotspot-compiler-dev@openjdk.org hotspot-runtime hotspot-runtime-dev@openjdk.org labels Nov 2, 2022
@openjdk
Copy link

openjdk bot commented Nov 2, 2022

@reinrich
The hotspot-compiler label was successfully added.

The hotspot-runtime label was successfully added.

@reinrich reinrich marked this pull request as ready for review November 2, 2022 23:11
@openjdk openjdk bot added the rfr Pull request is ready for review label Nov 2, 2022
@mlbridge
Copy link

mlbridge bot commented Nov 2, 2022

@RealFYang
Copy link
Member

RealFYang commented Nov 10, 2022

Hi, I also tested this on my Linux RISC-V platform which has support for virtual threads. Test results look good. Thanks.

  • Tier1-4 tests
  • Tests under test/jdk/java/lang/Thread/virtual with extra options "-XX:+VerifyContinuations -XX:+VerifyStack"
  • Non-trivial benchmark workloads, like Renaissance, SPECjvm2008, SPECjbb2015, etc.

@reinrich
Copy link
Member Author

Hi, I also tested this on my Linux RISC-V platform which has support for virtual threads. Test results look good. Thanks.

* Tier1-4 tests

* Tests under test/jdk/java/lang/Thread/virtual with extra options "-XX:+VerifyContinuations -XX:+VerifyStack"

* Non-trivial benchmark workloads, like Renaissance, SPECjvm2008, SPECjbb2015, etc.

Great. Thanks for the testing.

Richard.

@backwaterred
Copy link
Contributor

I see a couple failures on Linux/ppc64le when testing with -XX:+VerifyContinuations.

jdk/internal/vm/Continuation/Fuzz.java#default
jdk/internal/vm/Continuation/Fuzz.java#preserve-fp

It may be reasonable to add these to a ProblemList.txt and address them at a different time.

@reinrich
Copy link
Member Author

I see a couple failures on Linux/ppc64le when testing with -XX:+VerifyContinuations.

jdk/internal/vm/Continuation/Fuzz.java#default jdk/internal/vm/Continuation/Fuzz.java#preserve-fp

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).

@backwaterred
Copy link
Contributor

The failures are indeed time-dependant, and pass with JTREG="TIMEOUT_FACTOR=16".

Copy link
Contributor

@backwaterred backwaterred left a 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.

@reinrich
Copy link
Member Author

These changes are significant. They appear well thought out and well executed. Thanks for submitting this PR.

Thanks for your review @backwaterred

Copy link
Contributor

@TheRealMDoerr TheRealMDoerr left a 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!

Copy link
Contributor

@TheRealMDoerr TheRealMDoerr left a 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.

@openjdk
Copy link

openjdk bot commented Nov 18, 2022

@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:

8286302: Port JEP 425 to PPC64

Reviewed-by: tsteele, mdoerr

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 master branch:

  • fd910f7: 8297384: Add IR tests for existing idealizations of arithmetic nodes
  • cfe5a37: 8297556: Parse::check_interpreter_type fails with assert "must constrain OSR typestate"
  • 74d3bac: 8297417: Poly1305IntrinsicFuzzTest fails with tag mismatch exception
  • 0ed8b33: 8297385: Remove duplicated null typos in javadoc
  • 1fb9dad: 8296419: [REDO] JDK-8295319: pending_cards_at_gc_start doesn't include cards in thread buffers
  • 2f47f83: 8297569: URLPermission constructor throws IllegalArgumentException: Invalid characters in hostname after JDK-8294378
  • 87d1097: 8297530: java.lang.IllegalArgumentException: Negative length on strings concatenation
  • 390e69a: 8297150: Add a @sealedGraph tag to Reference
  • 8effaa8: 8223783: sun/net/www/http/HttpClient/MultiThreadTest.java sometimes detect threads+1 connections
  • ab1f9ff: 8051627: Invariants about java.net.URI resolve and relativize are wrong
  • ... and 7 more: https://git.openjdk.org/jdk/compare/9c77e41b81ebd28bd92ea7adad605981a5519046...master

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 master branch, type /integrate in a new comment.

@reinrich
Copy link
Member Author

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.

Thanks a lot indeed!

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Nov 18, 2022
Copy link
Contributor

@TheRealMDoerr TheRealMDoerr left a 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!

@reinrich
Copy link
Member Author

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().

Copy link
Member

@lmesnik lmesnik left a 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.

@reinrich
Copy link
Member Author

Thanks for your feedback @lmesnik. It help reducing the runtime of the test significantly.

@lmesnik
Copy link
Member

lmesnik commented Nov 23, 2022

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

@reinrich
Copy link
Member Author

Thanks a lot for the reviews and feedback!
My own testing and GHA have succeeded after merging master.
I'm intending to integrate the port on Monday since I don't expect more feedback.

@reinrich
Copy link
Member Author

/integrate

@openjdk
Copy link

openjdk bot commented Nov 28, 2022

Going to push as commit 43d1173.
Since your change was applied there have been 28 commits pushed to the master branch:

  • d610211: 8297408: Consolidate code in runtime/ErrorHandling
  • 2f83b5c: 8297640: Increase buffer size for buf (insert_features_names) in Abstract_VM_Version::insert_features_names
  • 50f9043: 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread
  • 99d3840: 8297359: RISC-V: improve performance of floating Max Min intrinsics
  • 6c05771: 8295447: NullPointerException with invalid pattern matching construct in constructor call
  • 76a24c3: 8297145: Add a @sealedGraph tag to ConstantDesc
  • 099b42f: 8297148: Add a @sealedGraph tag to CallSite
  • 85ddd8f: 8295253: Remove kludge from v1_0/PerfDataBuffer.java
  • 952e100: 8297431: [JVMCI] HotSpotJVMCIRuntime.encodeThrowable should not throw an exception
  • 08e6a82: 8297590: [TESTBUG] HotSpotResolvedJavaFieldTest does not run
  • ... and 18 more: https://git.openjdk.org/jdk/compare/9c77e41b81ebd28bd92ea7adad605981a5519046...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Nov 28, 2022
@openjdk openjdk bot closed this Nov 28, 2022
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Nov 28, 2022
@openjdk
Copy link

openjdk bot commented Nov 28, 2022

@reinrich Pushed as commit 43d1173.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@reinrich reinrich deleted the 8286302_Port_JEP_425_to_PPC64 branch January 24, 2025 08:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot-compiler hotspot-compiler-dev@openjdk.org hotspot-runtime hotspot-runtime-dev@openjdk.org integrated Pull request has been integrated
Development

Successfully merging this pull request may close these issues.

6 participants