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

[Carsten Varming]

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