Details
Description
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. GivenJDK-8249672 had been backported to update releases, let's do a pointed fix for this regression first.
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
Attachments
Issue Links
- relates to
-
JDK-8283200 Generate VMVersion::_futures_string lazily
-
- Open
-
-
JDK-8249672 Include microcode revision in features_string on x86
-
- Resolved
-