JDK 8 backported ConcurrentHashMaps in Infinispan
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.
Published at DZone with permission of Manik Surtani, author and DZone MVB. (source)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:
-Dinfinispan.unsafe.allow_jdk8_chm=true
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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)






Comments
Dapeng Liu replied on Tue, 2012/03/13 - 12:24pm
Henk De Boer replied on Tue, 2012/03/13 - 12:49pm
in response to:
Dapeng Liu
Java 6? That's way too new! I guess they'd better plan to backport it to Java 1.0 first, although that's perhaps still a bit new too. I mean, 1996 is like yesterday isn't it?
Perhaps they should backport it to Oak first, and then consider 1.0. In about ten years time, maybe a backport for Java 6 would be about safe.