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

Dean Long dlong at openjdk.org
Thu Aug 28 20:21:59 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, that's a good theory, but it is not what I am seeing.  For G1, lock contention does seem to explain the issue, and this PR fixes the regression.  (Also the lock overhead I measured seemed to agree with the regression in GC phase time and benchmark scores.)  For ZGC, I am not seeing an increase in calls to BarrierSetAssembler::increment_patching_epoch().  And increment_patching_epoch() is only called when disarming -- that part hasn't changed.

I think the suspected ZGC regression is just noise in the benchmark, as the benchmark can show a regression across multiple runs even with the same build, flags, and host.

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

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


More information about the hotspot-dev mailing list