RFR: 8283199: Linux os::cpu_microcode_revision() stalls cold startup [v2]

[Aleksey Shipilev]

> Noticed this when staring at timeline profiles for JVM startup. If you run any small startup workload on Linux, there is a significant time gap where JVM does nothing. I pinpointed that to fopen of `/proc/cpuinfo` due to [JDK-8249672](https://bugs.openjdk.java.net/browse/JDK-8249672). 
> 
> This *does not* reproduce if you run startup workloads continuously, as it looks as if `/proc/cpuinfo` is cached for about a second, and stalls reads after that, I suspect for CPU info updates, like frequency. This reproduces on at least two of my systems running Linux kernels 5.4 and 5.15.
> 
> Observe:
> 
> 
> $ for I in `seq 1 5`; do sleep 0.99; time cat /proc/cpuinfo > /dev/null; done
> real	0m0.022s
> real	0m0.003s
> real	0m0.004s
> real	0m0.004s
> real	0m0.004s
> 
> $ for I in `seq 1 5`; do sleep 1.00; time cat /proc/cpuinfo > /dev/null; done
> real	0m0.022s
> real	0m0.022s
> real	0m0.022s
> real	0m0.022s
> real	0m0.022s
> 
> 
> It directly impacts JVM startup:
> 
> 
> $ for I in `seq 1 3`; do sleep 1; time build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m -version > /dev/null 2>&1 ; done
> 
> real	0m0.046s
> real	0m0.045s
> real	0m0.046s
> 
> 
> Without the sleep:
> 
> 
> $ for I in `seq 1 3`; do time build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m -version > /dev/null 2>&1 ; done
> 
> real	0m0.026s
> real	0m0.026s
> real	0m0.023s
> 
> 
> There is another way to do this: read `/sys/devices/system/cpu/cpu0/microcode/version`, this is what this patch does. With `sleep 1`:
> 
> 
> $ for I in `seq 1 3`; do sleep 1; time build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m -version > /dev/null 2>&1 ; done
> 
> real	0m0.025s
> real	0m0.024s
> real	0m0.024s
> 
> 
> Which means it improves startup time from ~45ms to ~25ms, or about 1.8x!
> 
> `os::cpu_microcode_revision()` is currently used to generate the VM features string. It raises a bigger question if VM features string should be generated on startup, but it seems to take negligible time otherwise, see [JDK-8283200](https://bugs.openjdk.java.net/browse/JDK-8283200). Given [JDK-8249672](https://bugs.openjdk.java.net/browse/JDK-8249672) had been backported to update releases, let's do a pointed fix for this regression first.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x] Eyeballing reported microcode number with/without the fix -- same thing reported

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Reflow a bit
 - Merge branch 'master' into JDK-8283199-cpu-microcode-revision
 - Add comment
 - Fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7825/files
  - new: https://git.openjdk.java.net/jdk/pull/7825/files/1ea9505d..78b56b39

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7825&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7825&range=00-01

  Stats: 8951 lines in 280 files changed: 4891 ins; 2168 del; 1892 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7825.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7825/head:pull/7825

PR: https://git.openjdk.java.net/jdk/pull/7825