New Relic has released a new JVM report based on analysis of data reported by JVMs from customers running in production around the world. Unlike other self-reported surveys , the data produced here is from JVMs used in production. As you might expect, the dataset is from New Relic customers, but it paints a picture of what is used in production as opposed to what developers are using and testing.
In particular, the report points out that the majority of JVMs in use in production are LTS versions of Java; and only a fraction of over 11% runs on Java 11. The majority of JVMs (over 85%) run on Java 8, with Java 7 following with a few percent. Non-LTS versions are used in just over 1% of the machines run. Additionally, the report points out that JVM users are often slow to update in production; there are more versions of Java running before 7 than 9 or 10 (both of which are EOL) or 12 and 13 (both of which are EOL or about to become EOL). The report also highlights that a number of JVMs run on outdated versions of Java 8,
The other interesting aspect of the data is that it shows that Oracle, while still being the main JVM provider with just under 75%, has seen a number of other providers pull up to provide runtimes. Adopt OpenJDK is the second most used provider with 7%, followed by Iced Tea with just over 5% (used by GNU distributions), and Azul, IBM and Amazon each taking just under 3%, followed by a list of other suppliers.
The report also highlights the use of garbage collectors used in production; Parallel remains the garbage collector of choice in over 57% of JVMs, with G1 occupying just under 25% of configurations and CMS just over 17%. These differences can in part be explained by the versions of the JVM, as the G1 collector became the default in Java 9, but its maturity has increased since its release. Although one result emerges – CMS is used in just over 14% of JVMs on Java 8, with G1 13% – being able to see how changes have evolved over Java releases would have been an interesting statistic. Unsurprisingly, no serious production use of Shenandoah or ZGC was seen in the results, with only a fraction of one percent seen with either.
Finally, JVM memory configurations show a variety of memory sizes, ranging from 256MB to 16384MB – although, oddly enough, about 2.5% of JVMs use a maximum size of 819MB, which is probably an error. copy and paste 8192 MB, as seen here for example. More than a third of JVMs reported being performed with the same indicators -Xmx and -Xms ; the suggestion is that while it was necessary for older JVMs, newer garbage collection heuristics may work better when the initial and maximum sizes are different.
InfoQ has asked if it is possible to obtain an anonymous copy of the data for further analysis, and will update this article if published.