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

Erik Österlund eosterlund at openjdk.org
Wed Aug 27 20:19:46 UTC 2025


On Thu, 14 Aug 2025 20:37:51 GMT, Dean Long <dlong at openjdk.org> wrote:

> @fisk , can I get you to review this?

Sure! Based on the symptoms you described, my main comment is that we might be looking at the wrong places. I don't know if this is really about lock contention. Perhaps it is indirectly. But you mention there is still so e regression with ZGC.

My hypothesis would be that it is the unnecessary incrementing of the global patching epoch that causes the regression when using ZGC. It is only really needed when disarming the nmethod - in orher words when the guard value is set to the good value.

The point of incrementing the patching epoch is to protect other threads from entering the nmethod without executing an instruction cross modication fence. And all other threads will have to do that.

Only ZGC uses the mode of nmethod entry barriers that does this due to being the only GC that updates instructions in a concurrent phase on AArch64. We are conservative on AArch64 and ensure the use of appropriate synchronous cross modifying code. But that's not needed when arming, which is what we do when making the bmethod not entrant.

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

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


More information about the hotspot-dev mailing list