RFR (S/M) expose L1_data_cache_line_size for diagnostic/sanity checks (8049717)

[Daniel D. Daugherty]

Thanks for the suggested rewrite. I'll merge that with some of the
other edits I made (e.g., fixed the URL).

Another webrev will be out shortly...

Dan


On 7/14/14 5:44 PM, David Holmes wrote:
> Hi Dan,
>
> I think the performance comment has lost a bit of context. May I 
> suggest just a slight change to the original that puts it into 
> historical perspective:
>
>  // Performance concern:
>  // OrderAccess::storestore() calls release() which at one time stored 0
>  // into the global volatile OrderAccess::Dummy variable.  This store was
>  // unnecessary for correctness. Many threads storing into a common 
> location
>  // causes considerable cache migration or "sloshing" on large SMP 
> systems.
>  // As such, I avoided using OrderAccess::storestore(). In some cases
>  // OrderAccess::fence() -- which incurs local latency on the 
> executing processor
>  //  -- is a better choice as it scales on SMP systems.  See
>  // http://blogs.sun.com/dave/entry/biased_locking_in_hotspot for a 
> discussion
>  // of coherency costs.  Note that all our current reference platforms 
> provide
>  // strong ST-ST order, so the issue is moot on IA32, x64, and SPARC.
>
>
> Though I also note that there is no a single OrderAccess call in 
> synchronizer.cpp :)
>
> Thanks,
> David
>
> On 15/07/2014 3:47 AM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> I've tweaked the fix based on David H's feedback.
>>
>> Here is the URL for the third round webrev:
>>
>> http://cr.openjdk.java.net/~dcubed/8049717-webrev/2-jdk9-hs-rt/
>>
>> The following files changed between round 1 and round 2:
>>
>> src/share/vm/runtime/objectMonitor.cpp
>> src/share/vm/runtime/synchronizer.cpp
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Dan
>>
>>
>> On 7/11/14 2:14 PM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> I've tweaked the fix based on Vladimir's feedback.
>>>
>>> Here is the URL for the second round webrev:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8049717-webrev/1-jdk9-hs-rt/
>>>
>>> The following files changed between round 0 and round 1:
>>>
>>> src/cpu/sparc/vm/vm_version_sparc.cpp
>>> src/cpu/x86/vm/vm_version_x86.cpp
>>> src/cpu/x86/vm/vm_version_x86.hpp
>>> src/share/vm/runtime/objectMonitor.cpp
>>> src/share/vm/runtime/synchronizer.cpp
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 7/9/14 10:42 AM, Daniel D. Daugherty wrote:
>>>> Greetings,
>>>>
>>>> I have the fix for the following bug ready for JDK9 RT_Baseline:
>>>>
>>>>     JDK-8049717 expose L1_data_cache_line_size for diagnostic/sanity
>>>>                 checks
>>>>     https://bugs.openjdk.java.net/browse/JDK-8049717
>>>>
>>>> Here is the URL for the webrev:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8049717-webrev/0-jdk9-hs-rt/
>>>>
>>>> This fix is a standalone piece from my Contended Locking reorder
>>>> and cache-line bucket. I've split it off as an independent bug fix
>>>> in order to make the reorder and cache-line bucket more clear.
>>>>
>>>> Testing:
>>>>
>>>> - JPRT test jobs
>>>> - manual testing of the new output via existing options:
>>>>   -XX:+UnlockExperimentalVMOptions -XX:SyncKnobs=Verbose=1
>>>>   -XX:+ExecuteInternalVMTests -XX:+VerboseInternalVMTests
>>>> - Aurora Adhoc nsk.sajdi and vm.parallel_class_loading as part of
>>>>   testing for my Contended Locking reorder and cache-line bucket
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>