VM: cache line size?

[Martijn Verburg]

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/d3a874b0/attachment.html