[16] RFR: 8247179: Mechanism for VM operations to not take part in safepoint coalescing

[David Holmes]

Hi Erik,

On 23/06/2020 1:16 am, Erik Österlund wrote:
> Hi,
> 
> An alternative approach which I am also okay with, is to remove 
> safepoint coalescing all together. It's an optimization opportunity that 
> almost never kicks in, especially after biased locking has been fixed to 
> use handshakes (and soon removed). Yet it has caused several bugs over 
> the years where assumptions break when operations are coalesced once in 
> a blue moon.
> 
> Patch that removes safepoint coalescing instead:
> http://cr.openjdk.java.net/~eosterlund/8247179/webrev.01/

This looks much simpler and cleaner. I added that version of the 
coalescing code back in 2006 (under 6409450). :)

Just out of interest I ran some tests to see if we presently encounter 
an actual queue of safepoint VM operations. It does still happen but may 
be an artefact of the tests involved e.g.

- multiple DeoptimizeAll with DeoptimizeALot
- multiple SuspendThread in a handshake suspend test

but neither of these are a concern.

Thanks,
David
-----

> Thanks,
> /Erik
> 
> On 2020-06-12 09:41, Erik Österlund wrote:
>> Hi,
>>
>> When we have a chain of safepoint operations, we coalesce them to run 
>> in a single safepoint operation.
>> Today that is fine, but in the near future, there will be a need for 
>> certain safepoint operations (my GC safepoints) to not be coalesced to 
>> run together with other safepoint operations.
>> The reason relates to concurrent stack scanning, and there are more 
>> details about the rationale in the bug comments.
>>
>> I also cleaned up the nested looping when evaluating VM operations in 
>> safepoints, to be a single loop. I found it unnecessarily hard to deal 
>> with the nested loop logic.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8247179
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8247179/webrev.00/
>>
>> Thanks,
>> /Erik
>