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

[Daniel D. Daugherty]

On 3/24/16 3:27 PM, Vladimir Kozlov wrote:
> In sharedRuntime.cpp you could use BasicObjectLock::size() as you did 
> in c1_LIRAssembler_x86.cpp

I'll take a look. I may leave that cleanup to another pass, if
you would be OK with it... I'm nearing the end of my 72 hour
stress test cycle and don't want to repeat it... :-)


> Do runtime group have plan to remove EmitSync?:
>
>   experimental(intx, EmitSync, 
> 0,                                           \
>                "(Unsafe, Unstable) 
> "                                        \
>                "Control emission of inline sync fast-path 
> code")            \

No immediate plans to do more flag removal in JDK9. Just "downgraded"
a number of the flags to "experimental" in JDK9 so that we have an
easier time with cleaning them up in JDK10...


> I (and many other I am sure) dont' have any clue what values could be 
> used.

I only know when I've read the code recently... I'm sure that only
Dave Dice and Doug Lea know all the special knob values by heart...


> There is a lot of code for different values in 
> MacroAssembler::fast_unlock() and most of them are not tested.

Yes, we're investigating mechanisms for migrating the experimental
code outside of the VM into a loadable module so that Dice and Lea
can do their experiments and the rest of the world can have a
simpler out-of-box code reading and maintaining experience... :-)


> When I worked on RTM I only guessed what should be done.

I remember that from when I reviewed the RTM stuff...


> I am not surprise that you found problem in it: orptr instead of xorptr.

Yup. I have notes to myself that we could sometimes end up with
a non-NULL register at a later jump target because the xorptr
wasn't on the common parent code path, but I have to go back and
verify that note...

Thanks for the review.

Dan


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