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

8247691: [aarch64] Incorrect handling of VM exceptions in C1 deopt stub/traps #344

Closed
wants to merge 3 commits into from
Closed

Conversation

ghost
Copy link

@ghost ghost commented Sep 24, 2020

The immediate issue that causes the error symptom is due to the procedure link register (LR) not being preserved across the actual call to the "patching" function (in code generated from 'generate_patching()'), invoked as part of the C1 deoptimization traps.

However, this update addresses a larger issue with the current implementation.

Since the Aarch64 implementation does not adopt patching but deoptimization to support load-mirror et.al., the "patching" stub-code does not need to support the exception protocol otherwise necessary when a VM transition might be needed in the actual patching function. The deoptimization is compulsory and the transition to the interpreter will cater for proper interaction with the VM.

The proposed solution is thus:

  1. The version of 'patch_code()' used with DEOPTIMIZE_WHEN_PATCHING should not be modelled as a JRT_ENTRY. The "patching" functions will not transfer control to VM (for up-call or otherwise).
  2. The patch-stub code does not need to handle the VM exception protocol (code can be removed).
  3. The patch-stub code need only to support deoptimization and re-execute (it's a fatal error otherwise).
  4. The patch-stub code does not need to utilise any instruction stream synchronisation barrier as no patching/modifying of the instruction stream is done (including indirectly through a VM transition).

Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8247691: [aarch64] Incorrect handling of VM exceptions in C1 deopt stub/traps

Reviewers

Download

$ git fetch https://git.openjdk.java.net/jdk pull/344/head:pull/344
$ git checkout pull/344

Patric Hedlin added 3 commits Sep 24, 2020
Adding a post condition to 'patch_code()' but retaining a defensive
result check in the patching stub. Some minor clean-up.
Removing the use of 'maybe_isb()' in the patching stub since we are
effectively not patching the instruction stream.
@bridgekeeper
Copy link

bridgekeeper bot commented Sep 24, 2020

👋 Welcome back phedlin! 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.

@openjdk
Copy link

openjdk bot commented Sep 24, 2020

@phedlin The following label will be automatically applied to this pull request: hotspot.

When this pull request is ready to be reviewed, an RFR email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label (add|remove) "label" command.

@openjdk openjdk bot added the hotspot hotspot-dev@openjdk.org label Sep 24, 2020
@ghost ghost changed the title 8247691: Crash in test/hotspot/jtreg/runtime/Thread/StopAtExit.java 8247691: [aarch64] Crash in test/hotspot/jtreg/runtime/Thread/StopAtExit.java Sep 24, 2020
@ghost ghost changed the title 8247691: [aarch64] Crash in test/hotspot/jtreg/runtime/Thread/StopAtExit.java 8247691: [aarch64] Incorrect handling of VM exceptions in C1 deopt stub/traps Sep 25, 2020
@ghost ghost marked this pull request as ready for review Sep 25, 2020
@openjdk openjdk bot added the rfr Pull request is ready for review label Sep 25, 2020
@mlbridge
Copy link

mlbridge bot commented Sep 25, 2020

Webrevs

@ghost
Copy link
Author

ghost commented Sep 25, 2020

Testing [aarch64]: tier1..6, tier8 (almost ready).
Testing (regular): tier1..3

fisk
fisk approved these changes Sep 25, 2020
Copy link
Contributor

@fisk fisk left a comment

Looks good.

@openjdk
Copy link

openjdk bot commented Sep 25, 2020

@phedlin 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 more details.

After integration, the commit message for the final commit will be:

8247691: [aarch64] Incorrect handling of VM exceptions in C1 deopt stub/traps

Reviewed-by: eosterlund, aph

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 28 new commits pushed to the master branch:

  • 79904c1: 8252730: jlink does not create reproducible builds on different servers
  • ea7c47c: 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead.
  • b66fa8f: 8253572: [windows] CDS archive may fail to open with long file names
  • 4167540: 8253647: Remove dead code in os::create_thread() on Linux/BSD
  • 5a57945: 8231591: [TESTBUG] Create additional two phase jpackage tests
  • b159e4e: 8253149: Building an installer from invalid app image fails on Window…
  • 0e855fe: 8252377: Incorrect encoding for EC AlgorithmIdentifier
  • 9150b90: 8253659: ProblemList sun/security/ec/TestEC.java on linux-aarch64
  • 0187567: 8250984: Memory Docker tests fail on some Linux kernels w/o cgroupv1 …
  • a75edc2: 8251188: Update LDAP tests not to use wildcard addresses
  • ... and 18 more: https://git.openjdk.java.net/jdk/compare/bf442c5b9e1eb013f562dd9495ed18a66b7fb648...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.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Sep 25, 2020
@mlbridge
Copy link

mlbridge bot commented Sep 25, 2020

Mailing list message from Andrew Haley on hotspot-dev:

On 25/09/2020 11:27, Patric Hedlin wrote:

Since the Aarch64 implementation does not adopt patching but
deoptimization to support load-mirror et.al., the "patching"
stub-code does not need to support the exception protocol otherwise
necessary when a VM transition might be needed in the actual
patching function. The deoptimization is compulsory and the
transition to the interpreter will cater for proper interaction with
the VM.

The proposed solution is thus:

1. The version of '_patch_code()_' used with
**DEOPTIMIZE_WHEN_PATCHING** should no be modelled as a
**JRT_ENTRY**. The "patching" functions will not transfer control to
VM (for up-call or otherwise).
2. The patch-stub code does not need to handle the VM exception
protocol (code can be removed).
3. The patch-stub code need only to support deoptimization and
re-execute (it's a fatal error otherwise).
4. The patch-stub code does not need to utilise any instruction
stream synchronisation barrier as no patching/modifying of the
instruction stream is done (including indirectly through a VM
transition).

Hmm. I left this code in because there always is a possibility that we
could enable C1 patching in the future. C1 patching does nothing
useful when we have tiered compilation because recompiles due to
tiered are ten times as common as recompiles due to patching needed,
so being able to patch makes almost no difference to run
time. However, there always was a possibility that some form of
"patching" might be possible, given appropriate code generation
strategies. This could be useful in small C1-only systems, in theory,
but I haven't seen any interest in such things.

On the other hand, I don't like dead code in the port and it's
probably time for it to die.

Anyone else have an opinion?

--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

@mlbridge
Copy link

mlbridge bot commented Sep 25, 2020

Mailing list message from Andrew Dinn on hotspot-dev:

On 25/09/2020 17:45, Andrew Haley wrote:

Hmm. I left this code in because there always is a possibility that we
could enable C1 patching in the future. C1 patching does nothing
useful when we have tiered compilation because recompiles due to
tiered are ten times as common as recompiles due to patching needed,
so being able to patch makes almost no difference to run
time. However, there always was a possibility that some form of
"patching" might be possible, given appropriate code generation
strategies. This could be useful in small C1-only systems, in theory,
but I haven't seen any interest in such things.

On the other hand, I don't like dead code in the port and it's
probably time for it to die.

Anyone else have an opinion?

It's dead, Jim. I think it's time to take it away and bury it somewhere.
We can always disinter it should resuscitation ever seem like a good
idea (which doesn't seem too likely).

regards,

Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill

@fisk
Copy link
Contributor

fisk commented Sep 25, 2020

Mailing list message from Andrew Dinn on hotspot-dev:

On 25/09/2020 17:45, Andrew Haley wrote:

Hmm. I left this code in because there always is a possibility that we
could enable C1 patching in the future. C1 patching does nothing
useful when we have tiered compilation because recompiles due to
tiered are ten times as common as recompiles due to patching needed,
so being able to patch makes almost no difference to run
time. However, there always was a possibility that some form of
"patching" might be possible, given appropriate code generation
strategies. This could be useful in small C1-only systems, in theory,
but I haven't seen any interest in such things.

On the other hand, I don't like dead code in the port and it's
probably time for it to die.

Anyone else have an opinion?

It's dead, Jim. I think it's time to take it away and bury it somewhere.
We can always disinter it should resuscitation ever seem like a good
idea (which doesn't seem too likely).

regards,

Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill

+1.

Should we need this stuff in the distant future, we can just revive it then, should that happen.

@mlbridge
Copy link

mlbridge bot commented Sep 26, 2020

Mailing list message from Andrew Haley on hotspot-dev:

On 25/09/2020 18:23, Andrew Dinn wrote:

On 25/09/2020 17:45, Andrew Haley wrote:

Hmm. I left this code in because there always is a possibility that we
could enable C1 patching in the future. C1 patching does nothing
useful when we have tiered compilation because recompiles due to
tiered are ten times as common as recompiles due to patching needed,
so being able to patch makes almost no difference to run
time. However, there always was a possibility that some form of
"patching" might be possible, given appropriate code generation
strategies. This could be useful in small C1-only systems, in theory,
but I haven't seen any interest in such things.

On the other hand, I don't like dead code in the port and it's
probably time for it to die.

Anyone else have an opinion?
It's dead, Jim. I think it's time to take it away and bury it somewhere.
We can always disinter it should resuscitation ever seem like a good
idea (which doesn't seem too likely).

OK.

--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

@openjdk
Copy link

openjdk bot commented Sep 26, 2020

@phedlin Reviewer aph has already made an authenticated review of this PR, and does not need to be credited manually.

@ghost
Copy link
Author

ghost commented Sep 26, 2020

/integrate

@openjdk openjdk bot closed this Sep 26, 2020
@openjdk openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Sep 26, 2020
@openjdk
Copy link

openjdk bot commented Sep 26, 2020

@phedlin Since your change was applied there have been 28 commits pushed to the master branch:

  • 79904c1: 8252730: jlink does not create reproducible builds on different servers
  • ea7c47c: 7179006: [macosx] Print-to-file doesn't work: printing to the default printer instead.
  • b66fa8f: 8253572: [windows] CDS archive may fail to open with long file names
  • 4167540: 8253647: Remove dead code in os::create_thread() on Linux/BSD
  • 5a57945: 8231591: [TESTBUG] Create additional two phase jpackage tests
  • b159e4e: 8253149: Building an installer from invalid app image fails on Window…
  • 0e855fe: 8252377: Incorrect encoding for EC AlgorithmIdentifier
  • 9150b90: 8253659: ProblemList sun/security/ec/TestEC.java on linux-aarch64
  • 0187567: 8250984: Memory Docker tests fail on some Linux kernels w/o cgroupv1 …
  • a75edc2: 8251188: Update LDAP tests not to use wildcard addresses
  • ... and 18 more: https://git.openjdk.java.net/jdk/compare/bf442c5b9e1eb013f562dd9495ed18a66b7fb648...master

Your commit was automatically rebased without conflicts.

Pushed as commit 7817963.

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

@ghost
Copy link
Author

ghost commented Sep 26, 2020

Thanks for reviewing Erik and Andrew.
Additional thanks to Erik for discussing the issue and the proposed solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot hotspot-dev@openjdk.org integrated Pull request has been integrated
2 participants