RFR: 8331911: Reconsider locking for recently disarmed nmethods [v3]

[Aleksey Shipilev]

On Thu, 6 Jun 2024 11:44:08 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

> Having said that, perhaps we should file a separate issue to remove that check, since it seems to fix an actual bug, while I guess this was meant more as an optimization. What do you think?

FTR, I don't mind executing cross-modify-fence unconditionally. I do mind going into deopts too often. I do also think that we want to stay on performance-positive side for at least an easy variant of fix, and do potentially regressing things separately. The initial motivation for this work was to resolve an issue in a service workload that runs many threads with similar stacks, and get something that we are sure about for a prompt backport.

To that end, we can continue working out the final shape of the patch here, while we mitigate our current service problems with picking up a limited version of this patch with [JDK-8333716](https://bugs.openjdk.org/browse/JDK-8333716) -- it resolves only Shenandoah parts of it, though. Or, we can integrate this patch in its current form, resolving the issue on both Shenandoah and ZGC paths, and work out the check removal as the follow up of [JDK-8310239](https://bugs.openjdk.org/browse/JDK-8310239).

I think the latter alternative is more pragmatic.

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

PR Comment: https://git.openjdk.org/jdk/pull/19285#issuecomment-2152603188