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

[Vladimir Kozlov]

In sharedRuntime.cpp you could use BasicObjectLock::size() as you did in c1_LIRAssembler_x86.cpp

Do runtime group have plan to remove EmitSync?:

   experimental(intx, EmitSync, 0,                                           \
                "(Unsafe, Unstable) "                                        \
                "Control emission of inline sync fast-path code")            \

I (and many other I am sure) dont' have any clue what values could be used.
There is a lot of code for different values in MacroAssembler::fast_unlock() and most of them are not tested. When I 
worked on RTM I only guessed what should be done. I am not surprise that you found problem in it: orptr instead of xorptr.

Thanks,
Vladimir

On 3/22/16 2: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