RFR: 8247179: Mechanism for VM operations to not take part in safepoint coalescing
robbin.ehn at oracle.com
Tue Jun 23 07:38:16 UTC 2020
Can you remove _coalesced_count also?
Did not find any test that looks for the output from log line in
safepoint cpp, but beware...
On 2020-06-22 17:16, 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:
> 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