8294053: Unneeded local variable in handle_safefetch()

[fbredber]

The input argument "pc" is shadowed by a local variable with the same type and name, and is initialized to the same value as is passed into the handle_safefetch() function by its callers. The local "pc" variable can therefore be removed from handle_safefetch().

Tested tier1, tier2 and tier3 without any new problems.

---

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

• JDK-8294053: Unneeded local variable in handle_safefetch()

Reviewers

• Robbin Ehn (@robehn - Reviewer)
• Thomas Stuefe (@tstuefe - Reviewer)
• Aleksey Shipilev (@shipilev - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/10373/head:pull/10373
$ git checkout pull/10373

Update a local copy of the PR:
$ git checkout pull/10373
$ git pull https://git.openjdk.org/jdk pull/10373/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 10373

View PR using the GUI difftool:
$ git pr show -t 10373

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/10373.diff

[bridgekeeper]

Hi @fbredber, welcome to this OpenJDK project and thanks for contributing!

We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing /signed in a comment in this pull request.

If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user fbredber" as summary for the issue.

If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing /covered in a comment in this pull request.

[openjdk]

@fbredber The following label will be automatically applied to this pull request:

• hotspot-runtime

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 pull request command.

[fbredber]

/signed

[bridgekeeper]

Thank you! Please allow for up to two weeks to process your OCA, although it is usually done within one to two business days. Also, please note that pull requests that are pending an OCA check will not usually be evaluated, so your patience is appreciated!

[fbredber]

/covered

[bridgekeeper]

Thank you! Please allow for a few business days to verify that your employer has signed the OCA. Also, please note that pull requests that are pending an OCA check will not usually be evaluated, so your patience is appreciated!

[mlbridge]

Webrevs

• 00: Full (6d831b04)

[robehn]

Looks good, thanks!

[openjdk]

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

8294053: Unneeded local variable in handle_safefetch()

Reviewed-by: rehn, stuefe, shade

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

• 0b56b82: 8293991: java/lang/Float/Binary16ConversionNaN.java fails on silent NaN conversions
• acd5bcf: 8289610: Degrade Thread.stop
• 05c8cab: 8293532: Use lighter jmod compression levels in build config
• eec992c: 8292602: ZGC: C2 late barrier analysis uses invalid dominator information
• f6d78cd: 8293657: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 failed with "SSLHandshakeException: Remote host terminated the handshake"
• a4dc035: 8290910: Wrong memory state is picked in SuperWord::co_locate_pack()
• f3ba332: 8294183: AArch64: Wrong macro check in SharedRuntime::generate_deopt_blob
• df53fa7: 8292328: AccessibleActionsTest.java test instruction for show popup on JLabel did not specify shift key
• 5285035: 8294075: gtest/AsyncLogGtest crashes with SEGV
• 696287d: 8294037: Using alias template to unify hashtables in AsyncLogWriter
• ... and 165 more: https://git.openjdk.org/jdk/compare/98da03af50e2372817a7b5e381eea5ee6f2cb919...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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@robehn, @dholmes-ora, @tstuefe, @shipilev) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[dholmes-ora]

and is initialized to the same value as is passed into the handle_safefetch() function by its callers.

Took me a bit to check that due to some confusing logic around SIGILL and SIGFPE handling.
But I'm not clear about what will happen on Zero - it will always pass a pc of NULL where currently we will get it from ucontext_get_pc(uc).

Thanks

[shipilev]

and is initialized to the same value as is passed into the handle_safefetch() function by its callers.

Took me a bit to check that due to some confusing logic around SIGILL and SIGFPE handling. But I'm not clear about what will happen on Zero - it will always pass a pc of NULL where currently we will get it from ucontext_get_pc(uc).

On Zero, os::Posix::ucontext_get_pc(uc) would fail with ShouldNotReachHere(), so this patch does not make it worse. JVM_HANDLE_XXX_SIGNAL makes a special provision for Zero by always taking pc = NULL route. Zero signal handling fell victim to last years POSIX signal refactorings, and I still have it in my TODO to try and revive it. In fact, I am not even sure safefetch ever worked with Zero.

[fbredber]

I assumed that if it was possible to get hold of the pc on Zero, that would have been done by calling os::Posix::ucontext_get_pc(uc) in JVM_HANDLE_XXX_SIGNAL prior to calling handle_safefetch().
I hope this patch haven't done things worse. My intention was just to remove a "local variable shadows a parameter" issue, which I don't think should be in any code base.

[tstuefe]

Kim marked this and other issues in https://bugs.openjdk.org/browse/JDK-8292166. If this RFE gets pushed, https://bugs.openjdk.org/browse/JDK-8292166 should get adapted.

On Zero, os::Posix::ucontext_get_pc(uc) would fail with ShouldNotReachHere(), so this patch does not make it worse.

Nothing prevents us from reading the PC from the context apart from aesthetics (CPU-specific sections inside os_linux_zero), right?

JVM_HANDLE_XXX_SIGNAL makes a special provision for Zero by always taking pc = NULL route. Zero signal handling fell victim to last years POSIX signal refactorings, and I still have it in my TODO to try and revive it. In fact, I am not even sure safefetch ever worked with Zero.

Safefetch worked, we made it so (see https://bugs.openjdk.org/browse/JDK-8076185). It is also covered by tests, or at least should be unless someone deactivated them.

[dholmes-ora]

My intention was just to remove a "local variable shadows a parameter" issue

Yes but based on JDK-8292166 the problem may not be the local, but the passing of the unused argument. It may be better to just drop this PR and let JDK-8292166 perform a broader cleanup of this code.

[shipilev]

On Zero, os::Posix::ucontext_get_pc(uc) would fail with ShouldNotReachHere(), so this patch does not make it worse.

Nothing prevents us from reading the PC from the context apart from aesthetics (CPU-specific sections inside os_linux_zero), right?

Quite right, I actually started doing that today in https://bugs.openjdk.org/browse/JDK-8294211. My point is that removing the os::Posix::ucontext_get_pc(uc); in this PR does nothing bad for Zero AFAICS, because current (shadowd) pc is nullptr, and calling ucontext_get_pc(uc) would just meet ShouldNotReachHere(). After JDK-8294211 is done, the pc would be from ucontext_get_pc(uc) anyway.

JVM_HANDLE_XXX_SIGNAL makes a special provision for Zero by always taking pc = NULL route. Zero signal handling fell victim to last years POSIX signal refactorings, and I still have it in my TODO to try and revive it. In fact, I am not even sure safefetch ever worked with Zero.

Safefetch worked, we made it so (see https://bugs.openjdk.org/browse/JDK-8076185). It is also covered by tests, or at least should be unless someone deactivated them.

Yes, so I discovered when working on JDK-8294211. My patch seems to work with safefetch, at least I can gdb my way trough safefetch_sigjmp code at Linux x86_65 Zero.

[tstuefe]

On Zero, os::Posix::ucontext_get_pc(uc) would fail with ShouldNotReachHere(), so this patch does not make it worse.

Nothing prevents us from reading the PC from the context apart from aesthetics (CPU-specific sections inside os_linux_zero), right?

Quite right, I actually started doing that today in https://bugs.openjdk.org/browse/JDK-8294211. My point is that removing the os::Posix::ucontext_get_pc(uc); in this PR does nothing bad for Zero AFAICS, because current (shadowd) pc is nullptr, and calling ucontext_get_pc(uc) would just meet ShouldNotReachHere(). After JDK-8294211 is done, the pc would be from ucontext_get_pc(uc) anyway.

Makes sense.

JVM_HANDLE_XXX_SIGNAL makes a special provision for Zero by always taking pc = NULL route. Zero signal handling fell victim to last years POSIX signal refactorings, and I still have it in my TODO to try and revive it. In fact, I am not even sure safefetch ever worked with Zero.

Safefetch worked, we made it so (see https://bugs.openjdk.org/browse/JDK-8076185). It is also covered by tests, or at least should be unless someone deactivated them.

Yes, so I discovered when working on JDK-8294211. My patch seems to work with safefetch, at least I can gdb my way trough safefetch_sigjmp code at Linux x86_65 Zero.

We have gtests for SafeFetch (https://github.com/openjdk/jdk/blob/master/test/hotspot/gtest/runtime/test_safefetch.cpp) and jtreg tests for SafeFetch during signal handling (eg. when writing hs-err files) https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java . If those are green, all is well.

[robehn]

@shipilev and @tstuefe, if you are fine with this going in now can you please review it, otherwise advice @fbredber to close, thanks.

[tstuefe]

I think its fine as it is. One thing less to cleanup with JDK-8292166.

[shipilev]

I don't mind this going in.

[fbredber]

Thank you for the review comments and "providing the bigger picture".

[fbredber]

/integrate

[openjdk]

@fbredber
Your change (at version 6d831b0) is now ready to be sponsored by a Committer.

[robehn]

/sponsor

[openjdk]

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

• 0b56b82: 8293991: java/lang/Float/Binary16ConversionNaN.java fails on silent NaN conversions
• acd5bcf: 8289610: Degrade Thread.stop
• 05c8cab: 8293532: Use lighter jmod compression levels in build config
• eec992c: 8292602: ZGC: C2 late barrier analysis uses invalid dominator information
• f6d78cd: 8293657: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 failed with "SSLHandshakeException: Remote host terminated the handshake"
• a4dc035: 8290910: Wrong memory state is picked in SuperWord::co_locate_pack()
• f3ba332: 8294183: AArch64: Wrong macro check in SharedRuntime::generate_deopt_blob
• df53fa7: 8292328: AccessibleActionsTest.java test instruction for show popup on JLabel did not specify shift key
• 5285035: 8294075: gtest/AsyncLogGtest crashes with SEGV
• 696287d: 8294037: Using alias template to unify hashtables in AsyncLogWriter
• ... and 165 more: https://git.openjdk.org/jdk/compare/98da03af50e2372817a7b5e381eea5ee6f2cb919...master

Your commit was automatically rebased without conflicts.

[openjdk]

@robehn @fbredber Pushed as commit acd75e0.

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