RFR: 8247179: Mechanism for VM operations to not take part in safepoint coalescing
david.holmes at oracle.com
Tue Jun 23 04:45:12 UTC 2020
On 23/06/2020 1:16 am, Erik Österlund wrote:
> 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:
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.
> On 2020-06-12 09:41, Erik Österlund wrote:
>> 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.
More information about the hotspot-runtime-dev