On Fri, 6 Nov 2020 02:31:12 GMT, David Holmes <[email protected]> wrote:
>> Changes from @fisk and @dcubed-ojdk to:
>>
>> - simplify ObjectMonitor list management
>> - get rid of Type-Stable Memory (TSM)
>>
>> This change has been tested with Mach5 Tier[1-3],4,5,6,7,8; no new
>> regressions.
>> Aurora Perf runs have also been done (DaCapo-h2, Quick Startup/Footprint,
>> SPECjbb2015-Tuned-G1, SPECjbb2015-Tuned-ParGC, Volano)
>> - a few minor regressions (<= -0.24%)
>> - Volano is 6.8% better
>>
>> Eric C. has also done promotion perf runs on these bits and says "the
>> results look fine".
>
> src/hotspot/share/runtime/synchronizer.cpp line 1748:
>
>> 1746: int* error_cnt_p) {
>> 1747: if (n->owner_is_DEFLATER_MARKER()) {
>> 1748: // This should not happen, but if it does, it is not fatal.
>
> Deflating an in-use monitor is not fatal? Please explain how things would
> recover.
When the MonitorDeflationThread is doing its final async deflation cycle before
VM shutdown, it is possible for it to finish a deflation pass on the in-use
list and
then block for the final safepoint before unlinking the deflated ObjectMonitors.
If the VMThread happens to be doing an audit_and_print_stats() call when this
happens (see the end of SafepointSynchronize::do_cleanup_tasks()), then we
don't want that audit to FAIL.
As for recovery, if the VMThread is doing a final audit, then when it sees an
already deflated ObjectMonitor on the in-use list, it will take care of the
unlinking
and deleting...
-------------
PR: https://git.openjdk.java.net/jdk/pull/642
