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

[Vladimir Kozlov]

Hi Dan

vm_version_sparc.cpp:

I don't know where you get 16 byte cache line size:

/usr/sbin/prtpicl -v |grep l1-dcache |more
           :l1-dcache-line-size   32
           :l1-dcache-size        16384
           :l1-dcache-associativity       4

It is 32 for T4 and for T7 it will be larger:

   static intx prefetch_data_size()  {
     return is_T4() && !is_T7() ? 32 : 64;  // default prefetch block 
size on sparc
   }

sun4v could be defined for Fujitsu Sparc64 too:

   static bool is_niagara(int features)  {
     // 'sun4v_m' may be defined on both Sun/Oracle Sparc CPUs as well as
     // on Fujitsu Sparc64 CPUs, but only Sun/Oracle Sparcs can be 
'niagaras'.
     return (features & sun4v_m) != 0 && (features & sparc64_family_m) == 0;


vm_version_x86.hpp, vm_version_x86.cpp

I would like to keep cpuid bit access in .hpp file.
I would suggest to keep code prefetch_data_size() but may be rename it 
as L1_line_size() so that you have in .hpp:

   static intx L1_line_size()  {
     intx result = 0;
     if (is_intel()) {
       result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1);
     } else if (is_amd()) {
       result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size;
     }
     if (result < 32) // not defined ?
       result = 32;   // 32 bytes by default on x86 and other x64
     return result;
   }

   static intx prefetch_data_size()  {
     return L1_line_size();
   }

and in .cpp for > i486 (i486 code is still yours):

_L1_data_cache_line_size = L1_line_size();



objectMonitor.cpp and synchronizer.cpp:

cast to 'int' but destination is 'unsigned' (also you can use 'uint'):

unsigned int offset_stwRandom = (int)

combine two 'if (verbose)' into one.

On 7/9/14 9: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
>
>