Hi Dan,
On 8/11/2020 3:40 am, Daniel D.Daugherty wrote:
On Fri, 6 Nov 2020 02:31:12 GMT, David Holmes <dhol...@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...
So it isn't really an "in-use" monitor, it is a monitor that is still in
the in-use-list - is that right?
Thanks,
David
-----
-------------
PR: https://git.openjdk.java.net/jdk/pull/642
