RFR: 8212107: VMThread issues and cleanup [v6]

[Daniel D.Daugherty]

On Fri, 25 Sep 2020 06:58:29 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/share/runtime/vmThread.cpp line 316:
>> 
>>> 314:   bool max_time_exceeded = GuaranteedSafepointInterval != 0 &&
>>> 315:                            (interval_ms >= GuaranteedSafepointInterval);
>>> 316:   if (!max_time_exceeded) {
>> 
>> You've changed the meaning of SafepointALot here. If max_time_exceeded
>> is false, then you never check the SafepointALot flag and miss causing a
>> safepointALot_op to happen next.
>> 
>> Here's the old code:
>> 
>> 394   if (max_time_exceeded && SafepointSynchronize::is_cleanup_needed()) {
>> 395     return &cleanup_op;
>> 396   }
>> 397   if (SafepointALot) {
>> 398     return &safepointALot_op;
>> 399   }
>> 
>> In the old code if max_time_exceeded and we need a cleanup,
>> then cleanup_op is the priority, but if that wasn't the case, then
>> we always checked the SafepointALot flag.
>
> The old behavior could create a SafepointALot when we had no 'safepoint priority' ops in queue when woken.
> To get this behavior we need more logic to avoid back to back SafepointALot and we need to peek at _next_vm_operation
> to determine if it's a safepoint op or not (handshake).
> During a normal test run the old behavior only creates around 1% more safepoints.
> And if you want more safepoints you can decrease GuaranteedSafepointInterval (not exactly the same).
> 
> So I didn't think adding that complexity to exactly mimic the old behavior was worth it.
> 
> What you want me to do?

Hmmm.... The old SafepointALot was intended to safepoint as frequently
as possible to stress the system. Now we do very little at safepoints so
maybe it is time for SafepointALot to evolve. Can you make it so that a
SafepointALot happens some fraction of GuaranteedSafepointInterval, e.g.,
(GuaranteedSafepointInterval / 4) so four times as often?

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

PR: https://git.openjdk.java.net/jdk/pull/228