VM: cache line size?

Aleksey Shipilev aleksey.shipilev at oracle.com
Wed Nov 21 13:25:31 PST 2012


HotSpot actually uses CPUID to get that info (and Linux should use that
too), we can parse out the cache line sizes for all levels of caches
from there.

Ok, for my case, I will probably need to get the max over all cache line
sizes just in case we have different cache line sizes. I will provide
this change some time soon.

Thanks,
Aleksey.

On 11/22/2012 01:07 AM, Srinivas Ramakrishna wrote:
> Haven't looked at the implementation code in HotSpot, but I'd guess most
> Unix'es would probably give you the value from a suitable sysconf() call
> when the JVM sis started up, yes? e.g. here's o/p from an Ubuntu
> system... (don't know if all of them do a faithful job of populating the
> table with the right values, but you'd hope so, at least for the more
> reputable OS's). Also haven't checked if this is required by the
> appropriate posix/open group or other standard.
> 
> $ getconf -a | grep -i cache
> LEVEL1_ICACHE_SIZE                 32768
> LEVEL1_ICACHE_ASSOC                4
> LEVEL1_ICACHE_LINESIZE             32
> LEVEL1_DCACHE_SIZE                 32768
> LEVEL1_DCACHE_ASSOC                8
> LEVEL1_DCACHE_LINESIZE             64
> LEVEL2_CACHE_SIZE                  262144
> LEVEL2_CACHE_ASSOC                 8
> LEVEL2_CACHE_LINESIZE              64
> LEVEL3_CACHE_SIZE                  2097152
> LEVEL3_CACHE_ASSOC                 16
> LEVEL3_CACHE_LINESIZE              64
> LEVEL4_CACHE_SIZE                  0
> LEVEL4_CACHE_ASSOC                 0
> LEVEL4_CACHE_LINESIZE              0
> 
> -- ramki
> 
> On Wed, Nov 21, 2012 at 11:22 AM, Vladimir Kozlov
> <Vladimir.Kozlov at oracle.com <mailto:Vladimir.Kozlov at oracle.com>> wrote:
> 
>     > 0. Is this the method one should use to determine the cache line size?
> 
>     Depending for what use.
> 
> 
>     > 1. Shouldn't that method be called cache_line_size()?
> 
>     It is intentionally called prefetch_data_size() because it could be
>     not accurate (different cache levels may have different cache line
>     sizes, and on Sparc it is even worser). Which is fine for data
>     prefetching since it is only affect performance and not correctness.
>     But if you want the exact size you may need to add new functionality.
> 
> 
>     >  2. Is that correct at this point that we default to 32-byte cache
>     >     lines on x86? Should we instead default for 64?
> 
>     It is fine since current code does not rely on precise value.
> 
>     Regards,
>     Vladimir
> 
> 
>     On 11/21/12 10:52, Martijn Verburg wrote:
> 
>         Hi Aleksey,
> 
>         Disclaimer: "I have *not* dived deeply into this".  SOme
>         thoughts inline.
> 
>             Hi,
> 
>             I need the VM to get the info about the cache line size on
>         the current
>             system. Looking around the Hotspot code, I had found the
>         usages like
>             this:
>                  intx cache_line_size = prefetch_data_size();
> 
>             ...where:
> 
>             vm_version_sparc.hpp:
>                static intx prefetch_data_size()  {
>                  return is_T4() ? 32 : 64;  // default prefetch block
>         size on sparc
>                }
> 
>             vm_version_x86.hpp:
>                static intx prefetch_data_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;
>                }
> 
>             At this point, I have a few questions:
>               0. Is this the method one should use to determine the
>         cache line size?
> 
> 
>         Not sure, but it seems that way after a quick spelunk through
>         the code.
> 
>               1. Shouldn't that method be called cache_line_size()?
> 
> 
>         I would argue yes, *unless* there's a broader intent by the original
>         author here. Perhaps reading multiple cache lines? Or reading
>         data in a
>         unit that isn't a cache line? But both of those seem unlikely :-).
> 
>               2. Is that correct at this point that we default to
>         32-byte cache
>             lines
>             on x86? Should we instead default for 64?
> 
> 
>         It wouldn't be safe to assume 64bytes. If you were running on a
>         32byte
>         cache line based CPU (still common enough) and had this
>         assumption then
>         I'm not sure the results would be..... The other assumption is (32
>         bytes) id probably safer although not really that safe if you
>         consider
>         the possibility of 16 byte cache line CPUs.
> 
>         I haven't heard of any exploding JVMs caused by this code so it
>         might be
>         that it's safe enough as it stands.
> 
>         Cheers,
>         Martijn
> 
> 



More information about the hotspot-runtime-dev mailing list