RFR: 8253064: monitor list simplifications and getting rid of TSM
Daniel D.Daugherty
dcubed at openjdk.java.net
Sat Nov 7 17:40:55 UTC 2020
On Fri, 6 Nov 2020 02:31:12 GMT, David Holmes <dholmes at openjdk.org> 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
More information about the serviceability-dev
mailing list