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

[Erik Österlund]

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