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

David Simms david.simms at oracle.com
Thu Jul 10 07:53:05 UTC 2014


All in all, looks good Dan,

Minor comment:

vm_version_sparc.cpp:


Shame cache line size needed be hard-coded (but good comments btw). I 
assume were not already using "libpicl" in the JVM and it's not worth 
adding for this ?

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
>
>



More information about the hotspot-runtime-dev mailing list