RFR: 8212107: VMThread issues and cleanup [v6]

[Robbin Ehn]

On Fri, 25 Sep 2020 14:36:13 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> 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?

All test using SafepointALot the already set the GuaranteedSafepointInterval to a low value in range of ~1-300ms.
(except for vm boolean flag test which uses SafepointALot  to test a boolean flag)
For example jni/FastGetField sets GuaranteedSafepointInterval to 1.

The only case it would really differ is when adhoc adding SafepointALot without GuaranteedSafepointInterval.

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

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