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

Dean Long dlong at openjdk.org
Tue Sep 9 23:31:01 UTC 2025


On Wed, 27 Aug 2025 20:17:07 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> @fisk , can I get you to review this?
>
>> @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.

Thanks @fisk and @theRealAph .

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

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


More information about the hotspot-gc-dev mailing list