VM: cache line size?

[Srinivas Ramakrishna]

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> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20121121/1b8a4f33/attachment.html