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

[Daniel D. Daugherty]

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/

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/
>
> 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
>