New Relic has released a new JVM report based on an analysis of data reported by customer JVMs running in production across the globe. Unlike other self-reported surveys, the data produced here is from JVMs that are running in production. As would be expected, the resulting data set consists of New Relic customers, but it paints a picture of what is being used in production as opposed to what developers are working and testing against.
In particular, the report highlights that the majority of JVMs that are running in production are doing so with LTS releases of Java; and only a fraction over 11% are running on Java 11. The majority of JVMs (over 85%) are running on Java 8, with Java 7 following behind with a few percent. Non-LTS releases are responsible for just over 1% of reported machines running. In addition, the report highlights that JVM users are often slow to upgrade in production; there are more versions of Java running before 7 than on either 9 or 10 (which are both EOL) or 12 and 13 (which are both EOL or about to become EOL). The report also highlights that a number of JVMs are running on outdated versions of Java 8, some of which are known to have security vulnerabilities.
The other interesting aspect of the data is that it shows that Oracle, while still the major supplier of JVMs at just under 75%, has seen a number of other providers step up to provide runtimes. Adopt OpenJDK is the next highest provider at 7%, followed by Iced Tea at just over 5% (used by GNU distributions), and with Azul, IBM, and Amazon taking just under 3% share each, with a long tail of other providers.
The report also highlights the use of garbage collectors for use in production; Parallel remains the garbage collector of choice at over 57% of JVMs, with G1 taking just under 25% of configurations, and CMS at just over 17%. Partly these differences may be explained by versions of the JVM, as the G1 collector was available in Java 8 and became default in Java 9 but grew in maturity since the release. Although one result is broken out – CMS is used just over 14% of JVMs on Java 8, with G1 13% – being able to see how the changes have evolved over Java releases would have been an interesting stat. Perhaps unsurprisingly, no serious production use of Shenandoah or ZGC was seen in the results, with only a fraction of a percent seeing either configuration.
Finally, the memory configurations of the JVMs show a variety of memory sizes, from 256Mb to 16384Mb – although, curiously about 2.5% of the JVMs seen use a maximum size of 819Mb, which is likely a copy and paste error of 8192Mb, as seen here for example. Over a third of the JVMs reported run with the same -Xmx and -Xms flags; the suggestion is that while this was necessary for older JVMs, newer garbage collector heuristics may work better when the initial and maximal size are allowed to be different.
InfoQ has asked if it is possible to get an anonymised copy of the data for further analysis, and will update this story if it is released.