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

[Robbin Ehn]

Thanks Erik,

Can you remove _coalesced_count also?
Did not find any test that looks for the output from log line in 
safepoint cpp, but beware...

Looks good!

/Robbin

On 2020-06-22 17:16, 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/
> 
> 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
>