RFR: 8253064: monitor list simplifications and getting rid of TSM

[David Holmes]

Hi Dan,

On 8/11/2020 3:40 am, Daniel D.Daugherty wrote:
> 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...

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
>