RFR: JDK-8302736: Major performance regression in Math.log on aarch64

[Tobias Holenstein]

On Thu, 11 May 2023 01:06:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is day one code for the macOS/Aarch64 port which has been in place for two years. Why is this only now being seen to be a problem?
I think the reason is _because_ this code exists since day one of macOS/Aarch64 port. We only detect performance regressions within the same OS/architecture. The regression was reported because someone ran code with `-XX:DisableIntrinsic=_dlog` and saw a large performance boost, whereas a performance decrease would be expected. Only after some investigation did we find out that the WXWrite lock was responsible. 

> The high-level placement of these calls was done to stop playing whack-a-mole every time we hit a new failure due to a missing `ThreadWXEnable`. I'm all for placing these where they are actually needed but noone seems to be to able to clearly state/identify exactly where that is in the code. The changes in this PR are pushing it down further, but based on the comments e.g.
> 
> ```
> // we might modify the code cache via BarrierSetNMethod::nmethod_entry_barrier
>   MACOS_AARCH64_ONLY(ThreadWXEnable __wx(WXWrite, thread));
>   return ConfigT::thaw(thread, (Continuation::thaw_kind)kind);
> ```
> 
> we are not pushing it down to where it is actually needed. The trade-off of course is that if we push this too far down we may have to execute it far more often and so take a performance hit. So figuring out the optimum placement for these in the call stack seems rather difficult.

I filed https://bugs.openjdk.org/browse/JDK-8307817 for this. But yes, care has to be taken - it seems tricky to get WXWrite lock right. Perhaps @dean-long 's suggestion is a better approach.

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

PR Comment: https://git.openjdk.org/jdk/pull/13606#issuecomment-1544168359