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

[Daniel D. Daugherty]

Mr Simms,

Thanks for the review!


On 7/10/14 1:53 AM, David Simms wrote:
> All in all, looks good Dan,

Thanks!


> Minor comment:
>
> vm_version_sparc.cpp:
>
>
> Shame cache line size needed be hard-coded (but good comments btw).

Yes, we (Java org) have requested that support be added to SPARC
so that we can make the same type of queries as we do on X86/X64.
So far that hasn't happened.


> I assume were not already using "libpicl" in the JVM and it's not 
> worth adding for this ?

No, we don't use libpicl currently and this definitely isn't
worth adding another dependent library.

Dan


>
> Cheers
> /David Simms
>
> On 2014-07-09 18:42, 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
>>
>>
>