RFR: 8294053: Unneeded local variable in handle_safefetch()

[Thomas Stuefe]

On Wed, 21 Sep 2022 10:11:55 GMT, Fredrik Bredberg <duke at openjdk.org> wrote:

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

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.

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

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