RFR(L) 8153224 Monitor deflation prolong safepoints (CR1/v2.01/4-for-jdk13)

[Daniel D. Daugherty]

I just realized that I forgot to include the list of CR0 -> CR1
changes that were made. I meant to include it as an attachment
to the original CR1 email, but here it is in-line:

Functional:
   - Allow a special cleanup request (e.g., System.gc()) to check the
     global in-use list also.
   - Move setting of per-thread omShouldDeflateIdleMonitors flag from
     ObjectSynchronizer::do_safepoint_work() to
     ObjectSynchronizer::deflate_thread_local_monitors().
   - ObjectMonitor::install_displaced_markword_in_object()
     - add 'const oop obj' parameter for the target object
     - catch race with ObjectMonitor's object not matching target object
     - catch 2nd race with cleared ObjectMonitor header
     - use the target object instead of ObjectMonitor's object to
       restore the object's header (via cas_set_mark).
     - clear ObjectMonitor header if it is still marked so a racing
       install_displaced_markword_in_object() can bail out sooner.
     - clarify/update most comments
   - Catch 2nd race with ref_count in deflate_monitor_using_JT().
   - Add more install_displaced_markword_in_object() calls to reduce
     more retries to one iteration.
   - Set allocation state to "Old" in inflate().
   - Make sure ObjectMonitorHandle::_om_ptr is set before publishing
     an ObjectMonitor.
   - Remove work arounds from ObjectMonitor::dec_ref_count() and
     ObjectMonitor::dec_ref_count().
   - ObjectMonitor::clear_using_JT()
     - cannot check or clear ObjectMonitor header value
     - clarify comments
   - ObjectSynchronizer::omAlloc() needs to clear _header field (just
     like _owner and _contentions) when moving an ObjectMonitor from
     the global free list to the per thread free list.
Style:
   - Remove 'goto' from FastHashCode().
   - Refactor common code from deflate_global_idle_monitors_using_JT()
     and deflate_per_thread_idle_monitors_using_JT() into
     deflate_common_idle_monitors_using_JT().
   - Use Atomic::replace_if_null() instead of cmpxchg() with NULL check.
   - Remove unneeded '(address)' casts.
Debugging/Maintenance:
   - Tighten up ObjectMonitorHandle::set_om_ptr() caller checks.
   - Add ADIM_guarantee() for doing guarantee() calls if
     AsyncDeflateIdleMonitors and assert() calls otherwise.
   - Add/update guarantee()'s and assert()'s.
   - Delete some paranoid assert()'s.
   - Add/move/update comments.


Thanks, in advance, for any questions, comments or suggestions.

Dan


On 4/19/19 11:58 AM, Daniel D. Daugherty wrote:
> Greetings,
>
> I finally have CR1 for the Async Monitor Deflation project ready to
> go. It's also known as v2.01 (for those for with the patches) and as
> webrev/4-for-jdk13 (for those with webrev URLs). Sorry for all the
> names...
>
> Main bug URL:
>
>     JDK-8153224 Monitor deflation prolong safepoints
>     https://bugs.openjdk.java.net/browse/JDK-8153224
>
> Baseline bug fixes URL:
>
>     JDK-8222295 more baseline cleanups from Async Monitor Deflation 
> project
>     https://bugs.openjdk.java.net/browse/JDK-8222295
>
> The project is currently baselined on jdk-13+15.
>
> Here's the webrev for the latest baseline changes (JDK-8222295):
>
> http://cr.openjdk.java.net/~dcubed/8153224-webrev/4-for-jdk13.8222295
>
> Here's the full webrev URL (JDK-8153224 only):
>
> http://cr.openjdk.java.net/~dcubed/8153224-webrev/4-for-jdk13.full/
>
> Here's the incremental webrev URL (JDK-8153224):
>
> http://cr.openjdk.java.net/~dcubed/8153224-webrev/4-for-jdk13.inc/
>
> So I'm looking for reviews for both JDK-8222295 and the latest version
> of JDK-8153224...
>
> I still have to update the OpenJDK wiki to reflect the CR changes:
>
> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>
> This version of the patch has been thru Mach5 tier[1-3] testing on
> Oracle's usual set of platforms. Mach5 tier[4-6] is running now and
> Mach5 tier[78] will be run later today. My stress kit on Solaris-X64
> is running now. Linux-X64 stress testing will start on Sunday. I'm
> planning to do Kitchensink runs, SPECjbb2015 runs and my monitor
> inflation stress tests on Linux-X64, MacOSX and Solaris-X64.
>
> Thanks, in advance, for any questions, comments or suggestions.
>
> Dan
>
>
> On 3/24/19 9:57 AM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> Welcome to the OpenJDK review thread for my port of Carsten's work on:
>>
>>     JDK-8153224 Monitor deflation prolong safepoints
>>     https://bugs.openjdk.java.net/browse/JDK-8153224
>>
>> Here's a link to the OpenJDK wiki that describes my port:
>>
>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>
>> Here's the webrev URL:
>>
>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/3-for-jdk13/
>>
>> Here's a link to Carsten's original webrev:
>>
>> http://cr.openjdk.java.net/~cvarming/monitor_deflate_conc/0/
>>
>> Earlier versions of this patch have been through several rounds of
>> preliminary review. Many thanks to Carsten, Coleen, Robbin, and
>> Roman for their preliminary code review comments. A very special
>> thanks to Robbin and Roman for building and testing the patch in
>> their own environments (including specJBB2015).
>>
>> This version of the patch has been thru Mach5 tier[1-8] testing on
>> Oracle's usual set of platforms. Earlier versions have been run
>> through my stress kit on my Linux-X64 and Solaris-X64 servers
>> (product, fastdebug, slowdebug).Earlier versions have run Kitchensink
>> for 12 hours on MacOSX, Linux-X64 and Solaris-X64 (product, fastdebug
>> and slowdebug). Earlier versions have run my monitor inflation stress
>> tests for 12 hours on MacOSX, Linux-X64 and Solaris-X64 (product,
>> fastdebug and slowdebug).
>>
>> All of the testing done on earlier versions will be redone on the
>> latest version of the patch.
>>
>> Thanks, in advance, for any questions, comments or suggestions.
>>
>> Dan
>>
>> P.S.
>> One subtest in gc/g1/humongousObjects/TestHumongousClassLoader.java
>> is currently failing in -Xcomp mode on Win* only. I've been trying
>> to characterize/analyze this failure for more than a week now. At
>> this point I'm convinced that Async Monitor Deflation is aggravating
>> an existing bug. However, I plan to have a better handle on that
>> failure before these bits are pushed to the jdk/jdk repo.
>>
>
>