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

[David Holmes]

Hi Dan,

Looks okay generally, a couple of comments:

- when you print the uint values use %u instead of %d.

- I noticed this comment in relation to the GlobalVars is out of date:

// Performance concern:
// OrderAccess::storestore() calls release() which STs 0 into the global 
volatile
// OrderAccess::Dummy variable.

We got rid of the global dummy quite some time ago now.

- In objectMonitor.hpp we have:

volatile markOop   _header;     // displaced object header word - mark
void*     volatile _object;     // backward object pointer - strong root
double SharingPad[1];           // temp to reduce false sharing
void *  volatile _owner;        // pointer to owning thread OR BasicLock

and we check:

+     if ((offset_owner - offset_header) < cache_line_size) {

but on non-486 x86 the cache line size is a minimum of 32 bytes, and 
AFAICS _owner and _header are only spaced 16 bytes apart ??? Unless the 
array has some additional alignment constraints that insert additional 
padding?

Thanks,
David

On 12/07/2014 6:14 AM, 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
>>
>>
>>
>>
>