RFR(L) 8153224 Monitor deflation prolong safepoints (CR6/v2.06/9-for-jdk14)

Daniel D. Daugherty daniel.daugherty at oracle.com
Thu Sep 5 19:55:02 UTC 2019


Greetings,

I have updated the OpenJDK wiki for the project for CR6/v2.06/9-for-jdk14:

https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation

including two new top-level sections for:

     Lock-Free Monitor List Management
https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation#AsyncMonitorDeflation-Lock-FreeMonitorListManagement

and

     Using The New Lock-Free Monitor List Functions
https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation#AsyncMonitorDeflation-UsingTheNewLock-FreeMonitorListFunctions

I still need to make editorial passes over the new content, but I wanted
the reviewers to have access to the new content for their code reviews...

I figured out how to add a "Table of Contents" to the wiki so now the top
of the wiki has links to the top-level sections and subsections. Should
be easier to navigate around...

Dan


On 8/28/19 5:02 PM, Daniel D. Daugherty wrote:
> Greetings,
>
> The Async Monitor Deflation project has rebased to JDK14 so it's time
> for our first code review in that new context!!
>
> I've been focused on changing the monitor list management code to be
> lock-free in order to make SPECjbb2015 happier. Of course with a change
> like that, it takes a while to chase down all the new and wonderful
> races. At this point, I have the code back to the same stability that
> I had with CR5/v2.05/8-for-jdk13.
>
> To lay the ground work for this round of review, I pushed the following
> two fixes to jdk/jdk earlier today:
>
>     JDK-8230184 rename, whitespace, indent and comments changes in 
> preparation
>                 for lock free Monitor lists
>     https://bugs.openjdk.java.net/browse/JDK-8230184
>
>     JDK-8230317 serviceability/sa/ClhsdbPrintStatics.java fails after 
> 8230184
>     https://bugs.openjdk.java.net/browse/JDK-8230317
>
> I have attached the list of fixes from CR5 to CR6 instead of putting
> in the main body of this email.
>
> Main bug URL:
>
>     JDK-8153224 Monitor deflation prolong safepoints
>     https://bugs.openjdk.java.net/browse/JDK-8153224
>
> The project is currently baselined on jdk-14+11 plus the fixes for
> JDK-8230184 and JDK-8230317.
>
> Here's the full webrev URL for those folks that want to see all of the
> current Async Monitor Deflation code in one go (v2.06 full):
>
> http://cr.openjdk.java.net/~dcubed/8153224-webrev/9-for-jdk14.v2.06.full/
>
>
> The primary focus of this review cycle is on the lock-free Monitor List
> management changes so here's a webrev for just that patch (v2.06c):
>
> http://cr.openjdk.java.net/~dcubed/8153224-webrev/9-for-jdk14.v2.06c.inc/
>
> The secondary focus of this review cycle is on the bug fixes that have
> been made since CR5/v2.05/8-for-jdk13 so here's a webrev for just that
> patch (v2.06b):
>
> http://cr.openjdk.java.net/~dcubed/8153224-webrev/9-for-jdk14.v2.06b.inc/
>
> The third and final bucket for this review cycle is the rename, 
> whitespace,
> indent and comments changes made in preparation for lock free Monitor 
> list
> management. Almost all of that was extracted into JDK-8230184 for the
> baseline so this bucket now has just a few comment changes relative to
> CR5/v2.05/8-for-jdk13. Here's a webrev for the remainder (v2.06a):
>
> http://cr.openjdk.java.net/~dcubed/8153224-webrev/9-for-jdk14.v2.06a.inc/
>
>
> Some folks might want to see just what has changed since the last review
> cycle so here's a webrev for that (v2.06 inc):
>
> http://cr.openjdk.java.net/~dcubed/8153224-webrev/9-for-jdk14.v2.06.inc/
>
>
> Last, but not least, some folks might want to see the code before the
> addition of lock-free Monitor List management so here's a webrev for
> that (v2.00 -> v2.05):
>
> http://cr.openjdk.java.net/~dcubed/8153224-webrev/9-for-jdk14.v2.05.inc/
>
> The OpenJDK wiki will need minor updates to match the CR6 changes:
>
> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>
> but that should only be changes to describe per-thread list async monitor
> deflation being done by the ServiceThread.
>
> (I did update the OpenJDK wiki for the CR5 changes back on 2019.08.14)
>
> This version of the patch has been thru Mach5 tier[1-8] testing on
> Oracle's usual set of platforms. It has also been through my usual set
> of stress testing on Linux-X64, macOSX and Solaris-X64.
>
> I did a bunch of SPECjbb2015 testing in Oracle's Aurora Performance lab
> using using their tuned SPECjbb2015 Linux-X64 G1 configs. This was using
> this patch baselined on jdk-13+31 (for stability):
>
>           hbIR           hbIR
>      (max attempted)  (settled)  max-jOPS  critical-jOPS  runtime
>      ---------------  ---------  --------  -------------  -------
>             34282.00   28837.20  27905.20       19817.40  3658.10 base
>             34965.70   29798.80  27814.90       19959.00  3514.60 v2.06d
>             34282.00   29100.70  28042.50       19577.00  3701.90 
> v2.06d_off
>             34282.00   29218.50  27562.80       19397.30  3657.60 
> v2.06d_ocache
>             34965.70   29838.30  26512.40       19170.60  3569.90 v2.05
>             34282.00   28926.10  27734.00       19835.10  3588.40 
> v2.05_off
>
> The "off" configs are with -XX:-AsyncDeflateIdleMonitors specified and
> the "ocache" config is with 128 byte cache line sizes instead of 64 byte
> cache lines sizes. "v2.06d" is the last set of changes that I made before
> those changes were distributed into the "v2.06a", "v2.06b" and "v2.06c"
> buckets for this review recycle.
>
>
> Thanks, in advance, for any questions, comments or suggestions.
>
> Dan
>
>
> On 7/11/19 3:49 PM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> I've been focused on chasing down and fixing the rare test failures
>> that only pop up rarely. So this round is primarily fixes for races
>> with a few additional fixes that came from Karen's review of CR4.
>> Thanks Karen!
>>
>> I have attached the list of fixes from CR4 to CR5 instead of putting
>> in the main body of this email.
>>
>> Main bug URL:
>>
>>     JDK-8153224 Monitor deflation prolong safepoints
>>     https://bugs.openjdk.java.net/browse/JDK-8153224
>>
>> The project is currently baselined on jdk-13+29. This will likely be
>> the last JDK13 baseline for this project and I'll roll to the JDK14
>> (jdk/jdk) repo soon...
>>
>> Here's the full webrev URL:
>>
>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/8-for-jdk13.full/
>>
>> Here's the incremental webrev URL:
>>
>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/8-for-jdk13.inc/
>>
>> I have not yet checked the OpenJDK wiki to see if it needs any updates
>> to match the CR5 changes:
>>
>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>
>> (I did update the OpenJDK wiki for the CR4 changes back on 2019.06.26)
>>
>> 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 follow. I'll kick off the usual stress testing
>> on Linux-X64, macOSX and Solaris-X64 as those machines become available.
>> Since I haven't made any performance changes in this round, I'll only
>> be running SPECjbb2015 to gather the latest monitorinflation logs.
>>
>> Next up:
>>
>> - We're still seeing 4-5% lower performance with SPECjbb2015 on
>>   Linux-X64 and we've determined that some of that comes from
>>   contention on the gListLock. So I'm going to investigate removing
>>   the gListLock. Yes, another lock free set of changes is coming!
>> - Of course, going lock free often causes new races and new failures
>>   so that's a good reason for make those changes isolated in their
>>   own round (and not holding up CR5/v2.05/8-for-jdk13 anymore).
>> - I finally have a potential fix for the Win* failure with
>>     gc/g1/humongousObjects/TestHumongousClassLoader.java
>>   but I haven't run it through Mach5 yet so it'll be in the next round.
>> - Some RTM tests were recently re-enabled in Mach5 and I'm seeing some
>>   monitor related failures there. I suspect that I need to go take a
>>   look at the C2 RTM macro assembler code and look for things that might
>>   conflict if Async Monitor Deflation. If you're interested in that kind
>>   of issue, then see the macroAssembler_x86.cpp sanity check that I
>>   added in this round!
>>
>> Thanks, in advance, for any questions, comments or suggestions.
>>
>> Dan
>>
>>
>> On 5/26/19 8:30 PM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> I have a fix for an issue that came up during performance testing.
>>> Many thanks to Robbin for diagnosing the issue in his SPECjbb2015
>>> experiments.
>>>
>>> Here's the list of changes from CR3 to CR4. The list is a bit
>>> verbose due to the complexity of the issue, but the changes
>>> themselves are not that big.
>>>
>>> Functional:
>>>   - Change SafepointSynchronize::is_cleanup_needed() from calling
>>>     ObjectSynchronizer::is_cleanup_needed() to calling
>>>     ObjectSynchronizer::is_safepoint_deflation_needed():
>>>     - is_safepoint_deflation_needed() returns the result of
>>>       monitors_used_above_threshold() for safepoint based
>>>       monitor deflation (!AsyncDeflateIdleMonitors).
>>>     - For AsyncDeflateIdleMonitors, it only returns true if
>>>       there is a special deflation request, e.g., System.gc()
>>>       - This solves a bug where there are a bunch of Cleanup
>>>         safepoints that simply request async deflation which
>>>         keeps the async JavaThreads from making progress on
>>>         their async deflation work.
>>>   - Add AsyncDeflationInterval diagnostic option. Description:
>>>       Async deflate idle monitors every so many milliseconds when
>>>       MonitorUsedDeflationThreshold is exceeded (0 is off).
>>>   - Replace ObjectSynchronizer::gOmShouldDeflateIdleMonitors() with
>>>     ObjectSynchronizer::is_async_deflation_needed():
>>>     - is_async_deflation_needed() returns true when
>>>       is_async_cleanup_requested() is true or when
>>>       monitors_used_above_threshold() is true (but no more often than
>>>       AsyncDeflationInterval).
>>>     - if AsyncDeflateIdleMonitors Service_lock->wait() now waits for
>>>       at most GuaranteedSafepointInterval millis:
>>>       - This allows is_async_deflation_needed() to be checked at
>>>         the same interval as GuaranteedSafepointInterval.
>>>         (default is 1000 millis/1 second)
>>>       - Once is_async_deflation_needed() has returned true, it
>>>         generally cannot return true for AsyncDeflationInterval.
>>>         This is to prevent async deflation from swamping the
>>>         ServiceThread.
>>>   - The ServiceThread still handles async deflation of the global
>>>     in-use list and now it also marks JavaThreads for async deflation
>>>     of their in-use lists.
>>>     - The ServiceThread will check for async deflation work every
>>>       GuaranteedSafepointInterval.
>>>     - A safepoint can still cause the ServiceThread to check for
>>>       async deflation work via is_async_deflation_requested.
>>>   - Refactor code from ObjectSynchronizer::is_cleanup_needed() into
>>>     monitors_used_above_threshold() and remove is_cleanup_needed().
>>>   - In addition to System.gc(), the VM_Exit VM op and the final
>>>     VMThread safepoint now set the is_special_deflation_requested
>>>     flag to reduce the in-use monitor population that is reported by
>>>     ObjectSynchronizer::log_in_use_monitor_details() at VM exit.
>>>
>>> Test update:
>>>   - test/hotspot/gtest/oops/test_markOop.cpp is updated to work with
>>>     AsyncDeflateIdleMonitors.
>>>
>>> Collateral:
>>>   - Add/clarify/update some logging messages.
>>>
>>> Cleanup:
>>>   - Updated comments based on Karen's code review.
>>>   - Change 'special cleanup' -> 'special deflation' and
>>>     'async cleanup' -> 'async deflation'.
>>>     - comment and function name changes
>>>   - Clarify MonitorUsedDeflationThreshold description;
>>>
>>>
>>> Main bug URL:
>>>
>>>     JDK-8153224 Monitor deflation prolong safepoints
>>>     https://bugs.openjdk.java.net/browse/JDK-8153224
>>>
>>> The project is currently baselined on jdk-13+22.
>>>
>>> Here's the full webrev URL:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/7-for-jdk13.full/
>>>
>>> Here's the incremental webrev URL:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/7-for-jdk13.inc/
>>>
>>> I have not updated the OpenJDK wiki to reflect the CR4 changes:
>>>
>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>
>>> The wiki doesn't say a whole lot about the async deflation invocation
>>> mechanism so I have to figure out how to add that content.
>>>
>>> This version of the patch has been thru Mach5 tier[1-8] testing on
>>> Oracle's usual set of platforms. My Solaris-X64 stress kit run is
>>> running now. Kitchensink8H on product, fastdebug, and slowdebug bits
>>> are running on Linux-X64, MacOSX and Solaris-X64. I still have to run
>>> my stress kit on Linux-X64. I still have to run the SPECjbb2015
>>> baseline and CR4 runs on Linux-X64, MacOSX and Solaris-X64.
>>>
>>> Thanks, in advance, for any questions, comments or suggestions.
>>>
>>> Dan
>>>
>>> On 5/6/19 11:52 AM, Daniel D. Daugherty wrote:
>>>> Greetings,
>>>>
>>>> I had some discussions with Karen about a race that was in the
>>>> ObjectMonitor::enter() code in CR2/v2.02/5-for-jdk13. This race was
>>>> theoretical and I had no test failures due to it. The fix is pretty
>>>> simple: remove the special case code for async deflation in the
>>>> ObjectMonitor::enter() function and rely solely on the ref_count
>>>> for ObjectMonitor::enter() protection.
>>>>
>>>> During those discussions Karen also floated the idea of using the
>>>> ref_count field instead of the contentions field for the Async
>>>> Monitor Deflation protocol. I decided to go ahead and code up that
>>>> change and I have run it through the usual stress and Mach5 testing
>>>> with no issues. It's also known as v2.03 (for those for with the
>>>> patches) and as webrev/6-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
>>>>
>>>> The project is currently baselined on jdk-13+18.
>>>>
>>>> Here's the full webrev URL:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/6-for-jdk13.full/
>>>>
>>>> Here's the incremental webrev URL:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/6-for-jdk13.inc/
>>>>
>>>> I have also updated the OpenJDK wiki to reflect the CR3 changes:
>>>>
>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>
>>>> This version of the patch has been thru Mach5 tier[1-8] testing on
>>>> Oracle's usual set of platforms. My Solaris-X64 stress kit run had
>>>> no issues. Kitchensink8H on product, fastdebug, and slowdebug bits
>>>> had no failures on Linux-X64; MacOSX fastdebug and slowdebug and
>>>> Solaris-X64 release had the usual "Too large time diff" complaints.
>>>> 12 hour Inflate2 runs on product, fastdebug and slowdebug bits on
>>>> Linux-X64, MacOSX and Solaris-X64 had no failures. My Linux-X64
>>>> stress kit is running right now.
>>>>
>>>> I've done the SPECjbb2015 baseline and CR3 runs. I need to gather
>>>> the results and analyze them.
>>>>
>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 4/25/19 12:38 PM, Daniel D. Daugherty wrote:
>>>>> Greetings,
>>>>>
>>>>> I have a small but important bug fix for the Async Monitor Deflation
>>>>> project ready to go. It's also known as v2.02 (for those for with the
>>>>> patches) and as webrev/5-for-jdk13 (for those with webrev URLs). 
>>>>> Sorry
>>>>> for all the names...
>>>>>
>>>>> JDK-8222295 was pushed to jdk/jdk two days ago so that baseline patch
>>>>> is out of our hair.
>>>>>
>>>>> Main bug URL:
>>>>>
>>>>>     JDK-8153224 Monitor deflation prolong safepoints
>>>>>     https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>
>>>>> The project is currently baselined on jdk-13+17.
>>>>>
>>>>> Here's the full webrev URL:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/5-for-jdk13.full/
>>>>>
>>>>> Here's the incremental webrev URL (JDK-8153224):
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/5-for-jdk13.inc/
>>>>>
>>>>> I still have to update the OpenJDK wiki to reflect the CR2 changes:
>>>>>
>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>
>>>>> This version of the patch has been thru Mach5 tier[1-6] testing on
>>>>> Oracle's usual set of platforms. Mach5 tier[7-8] is running now.
>>>>> My stress kit is running on Solaris-X64 now. Kitchensink8H is running
>>>>> now on product, fastdebug, and slowdebug bits on Linux-X64, MacOSX
>>>>> and Solaris-X64. 12 hour Inflate2 runs are running now on product,
>>>>> fastdebug and slowdebug bits on Linux-X64, MacOSX and Solaris-X64.
>>>>> I'll start my my stress kit on Linux-X64 sometime on Sunday (after
>>>>> my jdk-13+18 stress run is done).
>>>>>
>>>>> I'll do SPECjbb2015 baseline and CR2 runs after all the stress
>>>>> testing is done.
>>>>>
>>>>> 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.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>

-------------- next part --------------
Functional:
  - Monitor list management is now lock-free and refactored into
    separate functions. Almost all of the new functions are static
    in synchronizer.cpp to reduce visibility.
  - Several functions required major algorithm updates to be both
    async and lock-free:
    - ObjectSynchronizer::om_release()
    - ObjectSynchronizer::om_flush()
    - ObjectSynchronizer::deflate_monitor_list_using_JT()
    - These three functions will need the most review scrutiny!
  - ServiceThread now does the per-thread async monitor deflation
    instead of a thread cleaning up after itself.
  - Change ObjectMonitorHandle::save_om_ptr() to only return true
    when ref_count >= 1. This prevents races with an async deflation
    that is bailing out in assert() and guarantee() calls.
  - ObjectSynchronizer::monitors_iterate() should use ref_count < 0
    as the bailout trigger instead of _owner == DEFLATER_MARKER to
    avoid bug where a deflation bailout leads to a missed visit.

Test update:
  - WB_G1StartMarkCycle() and WB_FullGC() now request special cleanups
    as needed.
  - test/jdk/tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java
    work around is backed out now that the ServiceThread is doing
    per-thread async monitor deflation.

Collateral:
  - Add OM_CACHE_LINE_SIZE so that ObjectMonitor cache line sizes
    can be experimented with independently of DEFAULT_CACHE_LINE_SIZE;
    for SPARC and X64 configs that use 128 for DEFAULT_CACHE_LINE_SIZE,
    we are experimenting with 64.
  - ObjectMonitor cache line changes:
    - _allocation_state field now shares the _header field cache line.
    - _ref_count field is now on its own cache line
    - _next_om field is now on its own cache line
    - See the comment additions/updates in objectMonitor.hpp.

Cleanup:
  - Reduced visibility of a number of things in ObjectSynchronizer
    from class visible to static in synchronizer.cpp.

Temporary:
  - -XX:[+-]CheckMonitorLists diagnostic option (default false) and
    supporting code is in place during the stress testing phase to
    chase down any issues with the lock-free monitor list management
    code. I have not seen a failure due to the lock-free monitor list
    code for several weeks.
  - unmark_next() is currently unused. If we don't make any changes
    to use it during this code review cycle, then it can be deleted.


More information about the hotspot-runtime-dev mailing list