Monday, 12 March 2012
Doug Lea and the folks on the concurrency-interest group have been hard at work on an update of JSR 166 (concurrency utilities) for Java 8 - called JSR 166e. These include some pretty impressive changes in a building-block we’ve all come to rely pretty heavily on, the ConcurrentHashMap.
One if the big drawbacks in the ConcurrentHashMap, since it was introduced in Java 5, has always been memory footprint. It is kinda bulky, especially when compared to a regular HashMap - 1.6 kb in memory versus about 100 bytes! Yes, these are for empty maps.
In Java 8, one of the improvements in the ConcurrentHashMap has been memory footprint - now closer to a regular HashMap. In addition to that, the new Java 8 CHM performs better under concurrent load when compared to its original form. See this discussion and comments in the proposed ConcurrentHashMapV8 sources for more details.
So, Infinispan makes pretty heavy use of ConcurrentHashMaps internally. One change in the recently released Infinispan 5.1.2.Final is these internal CHMs are built using a factory, and we’ve included a version of the Java 8 CHM in Infinispan. So by default, Infinispan uses the JDK’s provided CHM. But if you wish to force Infinispan to use the backported Java 8 CHM, all you need to do is include the following JVM parameter when you start Infinispan:
We’d love to hear what you have to say about this, in terms of memory footprint, garbage collection and overall performance. Please use the Infinispan user forums to provide your feedback.
Tags: event performance community garbage collection concurrency