RFR: 8244340: Handshake processing thread lacks yielding

[David Holmes]

Hi Robbin,

Sorry that I didn't get a chance to look at this earlier.

On 5/05/2020 11:08 pm, Robbin Ehn wrote:
> Hi all, please review.
> 
> As the issue describes there are problems with this infinitely spinning.
> To avoid any performance regression we do not yield while we do or see
> progress. But when we enter a period of no progression we 'quickly' give
> up.

I must admit I'm having trouble understanding the use of the 
HandshakeSpinYield utility class versus the original trivial suggestion 
of adding:

if (!os::is_MP() && !_op->is_completed()) {
   os::naked_yield();
}

I can't quite get my head around the complexity of it.  Can you explain 
the basic principle of operation in a loop like this:

  204     HandshakeSpinYield cbo(start_time_ns);
  205     do {
  206       if (handshake_has_timed_out(start_time_ns)) {
  207         handle_timeout();
  208       }
  209       HandshakeState::ProcessResult pr = 
_target->handshake_try_process(_op);
  210       cbo.add_result(pr);
  211       cbo.process();
  212     } while (!_op->is_completed());

I'm not clear on the role of the _result_count 2D array and exactly what 
state changes we are trying to track here. Do we need an explicitl 
add_result versus passing pr into process()?

And why do we not check pr (or even _op->is_completed()) immediately so 
that we don't make the calls into the HSY unnecessarily?

We already have a number of spin/backoff strategies implemented across 
the VM so it would be good to do some consolidation in this area in the 
future if possible. At a minimum we should be employing the same basic 
spin-then-yield strategies.

> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8244340
> 
> Code:
> http://cr.openjdk.java.net/~rehn/8244340/v1/webrev/
> 
> In the pathologically case we can easily see 10x improvement starting 
> the VM.
> I have found no performance regressions or performance gains in our
> standard benchmark setups.
> But I see much better average completion times for handshakes.
> For example specJVM2008 serial with ZGC shows 4x faster time to
> completion for handshakes in my setup, but little or no effect on score
> (ops/m).

What platforms have you been able to test this on?

Thanks,
David
-----

> Passes t1-3.
> 
> Thanks, Robbin