RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5]

Dean Long dlong at openjdk.org
Thu Aug 14 20:40:17 UTC 2025


On Mon, 4 Aug 2025 21:26:22 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value.  Further, it takes a fast-path that uses the previous direct store when at a safepoint.  Combined, these changes should get us back to almost where we were before in terms of overhead.  If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one unconditional release should be enough

I'm not convinced the ZGC regression is real.  I see a 1% variance between runs even with the same binary and flags, so it looks like just noise.  For this PR I'll stop here.  If it turns out that ZGC or Shenandoah do have a small regression because of CAS, we can use direct stores as long as they are done inside a lock, which should be true already for disarm() but would need to be added for make_not_entrant().

@fisk , can I get you to review this?

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

PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3189805391
PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3189809429


More information about the hotspot-gc-dev mailing list