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

[Erik Österlund]

Hi David,

Thanks for the review.

On 2020-06-23 06:45, David Holmes wrote:
> 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.

Thank you for checking that.

Thanks,
/Erik

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