RFR: 8295214: Generational ZGC: Guard nmethods from cross modifying code

[Erik Österlund]

On Wed, 9 Nov 2022 01:55:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> What are the performance implications here, if any? I don't like that everyone pays for this when it is only needed for genZGC.
> 
> Thanks.

When you don't use the concurrent stack processing code (ie. G1, Serial, Parallel), then the arm value will be disarmed or armed, and we will run the cross_modify_fence once per handshake/safepoint only, when the thread disarms itself. We already did that before, but where update_poll_values is called instead. So in that regard, I suppose there shouldn't be any difference unless concurrent stack processing is being used. And if it is, I measured the effect to be insignificant in aurora, so I didn't think it seemed worth it to introduce some new shared code abstraction to specify in a more fine grained way when exactly you do or do not want this fence. I expect that soon all GCs that use concurrent stack processing also want to do this fence anyway, as you probably still want to have immediate oops embedded in nmethods because that does have a performance edge, which on some platforms does require this fence. We just haven't supported that yet. Hope this explanation makes sense

> src/hotspot/share/runtime/safepointMechanism.cpp line 108:
> 
>> 106:     if (prev_poll_word != poll_word ||
>> 107:         prev_poll_word == _poll_word_armed_value) {
>> 108:       // After updating the poll value, we allow entering new nmethods
> 
> I'm a little confused about the positioning here. The comment says "after updating the poll value", but we haven't updated yet (happens below) so don't we need the fence after that point?

The important thing is that it is called after the handshake/safepoint/stack watermark operation. The wording is just unfortunate. Maybe I should change it to "While updating the poll value" to be less confusing? Does that read better?

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

PR: https://git.openjdk.org/jdk/pull/11042