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.

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.

Observe:

$ 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. With dirty patch and sleep 1:

real 0m0.025s
real 0m0.024s
real 0m0.024s

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. Given JDK-8249672 had been backported to update releases, let's do a pointed fix for this regression first.