RFR(S): 8152358 - code and comment cleanups found during the hunt for 8077392

[Daniel D. Daugherty]

Carsten,

Thanks for the fast re-review!

Dan


On 3/30/16 6:43 PM, Carsten Varming wrote:
> Dear Dan,
>
> I like the updates to synchronizer.cpp. Nice change.
>
> Carsten
>
> On Wed, Mar 30, 2016 at 8:01 PM, Daniel D. Daugherty 
> <daniel.daugherty at oracle.com <mailto:daniel.daugherty at oracle.com>> wrote:
>
>     I've updated the fix for 8152358 based on code review comments and
>     test results. Reminder that 8152358 is a superset of the fixes for
>     8077392 and 8131715...
>
>     Here is the webrev URL:
>
>     http://cr.openjdk.java.net/~dcubed/8152358-webrev/1-jdk9-hs-rt/
>     <http://cr.openjdk.java.net/%7Edcubed/8152358-webrev/1-jdk9-hs-rt/>
>
>     The files changed in this round relative to round 0:
>
>     src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
>         Copyright update.
>
>     src/share/vm/runtime/sharedRuntime.cpp
>        <same as the 8077392 and 8131715 review thread>
>
>        Changed to disable ObjectSynchronizer::quick_enter() for ARM64
>        since testing has shown that ARM64 still has hangs when the
>        quick_enter() optimization is enabled. See:
>
>        JDK-8153107 enabling ObjectSynchronizer::quick_enter() on ARM64
>     causes hangs
>     https://bugs.openjdk.java.net/browse/JDK-8153107
>
>        I suspect a mis-match between the quick_enter() optimization
>        and the ARM64 MacroAssembler code...
>
>     src/share/vm/runtime/synchronizer.cpp
>        <same as the 8077392 and 8131715 review thread>
>
>        Moved the init of the BasicLock's displaced_header to be
>        unconditional instead of only when Atomic::cmpxchg_ptr()
>        works. See the more detailed comments.
>
>        Also fixed a code review request to rename the 'Lock' param.
>
>        <changes for this thread>
>
>        Rework ObjectSynchronizer::fast_exit() comments, assert()'s
>        and included code due to code review comments. This includes
>        new comments explaining the special case where the BasicLock's
>        displaced_header is marked as a recursive enter and we have an
>        inflated Java Monitor (ObjectMonitor). The updated assert()'s
>        and comments also address the markOopDesc::INFLATING special
>        case in this function. Absolutely exciting reading here!
>
>     Redoing all the same testing... plus adding a fastdebug instance
>     to the stress config...
>
>     As always, comments, suggestions and/or questions are welcome.
>
>     Dan
>
>
>     On 3/22/16 3:35 PM, Daniel D. Daugherty wrote:
>
>         Greetings,
>
>         As a follow on to my fix for the following bugs:
>
>             JDK-8077392 Stream fork/join tasks occasionally fail to
>         complete
>         https://bugs.openjdk.java.net/browse/JDK-8077392
>
>             JDK-8131715 backout the fix for JDK-8079359 when
>         JDK-8077392 is fixed
>         https://bugs.openjdk.java.net/browse/JDK-8131715
>
>         I have a fix for the following bug:
>
>             JDK-8152358 code and comment cleanups found during the
>         hunt for 8077392
>         https://bugs.openjdk.java.net/browse/JDK-8152358
>
>         These cleanups are pretty straight forward so I'm not going to
>         include the usual long, detailed analysis... :-)
>
>         Here is the webrev URL:
>
>         http://cr.openjdk.java.net/~dcubed/8152358-webrev/0-jdk9-hs-rt/ <http://cr.openjdk.java.net/%7Edcubed/8152358-webrev/0-jdk9-hs-rt/>
>
>         This webrev is a superset of the webrev for the JDK-8077392 and
>         JDK-8131715 fixes and is the code that I'm currently testing...
>
>         Testing:
>
>         - the original failing test is running in a parallel stress config
>           on my Solaris X64 server; just under 23 hours and just under
>           3000 iterations without a failure in either instance; I'm
>         planning
>           to let the stress run go for at least 72 hours.
>         - RT/SVC nightly equivalent (in progress)
>
>         As always, comments, suggestions and/or questions are welcome.
>
>         Dan
>
>
>