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

[Erik Österlund]

Hi Robbin,

On 2020-06-23 09:38, Robbin Ehn wrote:
> Thanks Erik,
>
> Can you remove _coalesced_count also?

Sure, will do before pushing.

> Did not find any test that looks for the output from log line in 
> safepoint cpp, but beware...

Same here.

> Looks good!

Thanks Robbin!

/Erik

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