Terracotta Says 'Goodbye Java GC, Hello BigMemory'
Last month, Terracotta told DZone that they were working on a module for Ehcache and Hibernate users that would bypass the Java garbage collection bottleneck. The severely limited heap size allowed by the Java garbage collector (if you don't want to have significant performance issues) is a problem that has plagued the industry for years. Terracotta believes that today's memory requirements are finally forcing many to address this issue, and now Terracotta has their own answer - BigMemory.
DZone interviewed Terracotta CEO Amit Pandey about his company's solution to the GC problem in Java. BigMemory is a snap-in module that provides off-heap memory storage. It is a pure Java solution that works with all JVMs and bypasses the Java garbage collector. You don't even need to be in distributed caching mode to use BigMemory, but it works with both standalone and distributed caches. Like most Ehcache features, it requires only a few lines of configuration. BigMemory can also handle hundreds of millions of objects.
Here are the two steps needed to implement BigMemory (when it is released) in Ehcache:
1. Update the Java classpath and startup arguments to include the new
ehcache-2.3 jar and allocate sufficient memory for the BigMemory off-heap
store.
2. Update the cache configuration in ehcache.xml to set the size of the
BigMemory off-heap store.
"People have been trying to make better garbage collectors for years and years. Sun/Oracle have been putting a lot of money into solving this problem, but they're only getting incremental improvements." Terracotta, Pandey says, is able to solve the problem more elegantly because they they "own the cache." So they decided to write their own memory manager and bypass Java GC completely, freeing developers from difficult and time consuming GC tuning.
Currently in the late beta stages, Pandey told DZone that the responses to BigMemory were very positive from early beta users. Testing of the memory manager revealed that the responses to increased memory were fast and flat, meaning that it could be counted on to meet performance requirements in a Service Level Agreement. The greater memory utilization with BigMemory also allows server consolidation.
App Latency Over Time

Terracotta has tested heap sizes up to 350GB without running into a wall like the 2GB threshold in Java GC. Pandey says Terracotta is avoiding many of the problems (fragmentation, poor memory management techniques, etc.) that others have encountered when they tried to build their own memory manager. Pandey says the tagline for BigMemory will be: "Use all the memory you need to get blazingly fast performance."
BigMemory will be available for Ehcache and Hibernate users in October of this year.
DZone interviewed Terracotta CEO Amit Pandey about his company's solution to the GC problem in Java. BigMemory is a snap-in module that provides off-heap memory storage. It is a pure Java solution that works with all JVMs and bypasses the Java garbage collector. You don't even need to be in distributed caching mode to use BigMemory, but it works with both standalone and distributed caches. Like most Ehcache features, it requires only a few lines of configuration. BigMemory can also handle hundreds of millions of objects.
Here are the two steps needed to implement BigMemory (when it is released) in Ehcache:
1. Update the Java classpath and startup arguments to include the new
ehcache-2.3 jar and allocate sufficient memory for the BigMemory off-heap
store.
2. Update the cache configuration in ehcache.xml to set the size of the
BigMemory off-heap store.
<ehcache>
<cache name="mycache" maxElementsInMemory="10000"
overflowToOffHeap="true" maxMemoryOffHeap="4G"/>
</ehcache>
Currently in the late beta stages, Pandey told DZone that the responses to BigMemory were very positive from early beta users. Testing of the memory manager revealed that the responses to increased memory were fast and flat, meaning that it could be counted on to meet performance requirements in a Service Level Agreement. The greater memory utilization with BigMemory also allows server consolidation.
App Latency Over Time

Terracotta has tested heap sizes up to 350GB without running into a wall like the 2GB threshold in Java GC. Pandey says Terracotta is avoiding many of the problems (fragmentation, poor memory management techniques, etc.) that others have encountered when they tried to build their own memory manager. Pandey says the tagline for BigMemory will be: "Use all the memory you need to get blazingly fast performance."
BigMemory will be available for Ehcache and Hibernate users in October of this year.






Comments
sibasisha padhy replied on Tue, 2010/09/14 - 10:18am
Jeff Rade replied on Tue, 2010/09/14 - 10:47am
Fabrizio Giudici replied on Tue, 2010/09/14 - 12:26pm
Peter Monks replied on Tue, 2010/09/14 - 1:03pm
Alessandro Santini replied on Tue, 2010/09/14 - 2:35pm
in response to:
Peter Monks
Steven Harris replied on Tue, 2010/09/14 - 3:06pm
in response to:
Alessandro Santini
Sergio Bossa replied on Tue, 2010/09/14 - 4:16pm
Greg Luck replied on Tue, 2010/09/14 - 10:08pm
in response to:
Sergio Bossa
With some very clever usage of DirectByteBuffer, which has been there since Java 1.4. It is in-process but off-heap. We have just released the technical documentation where you can read all about it: ehcache.org/documentation/offheap_store.html
Greg
Sergio Bossa replied on Wed, 2010/09/15 - 2:39am
Alois Cochard replied on Wed, 2010/09/15 - 3:20am
I'm exited about these new feature, and gonna try it ASAP.
I wonder how performance would compare with the experimental Azul GC we see some months ago, an hardware optimized GC (using module in linux kernel, if I remember correctly).
Perhaps both technology can be complementary !
Alois Cochard
http://aloiscochard.blogspot.com
http: //www.twitter.com/aloiscochard
Sergio Bossa replied on Wed, 2010/09/15 - 5:39am
RIchard replied on Wed, 2010/09/15 - 3:11pm
in response to:
Fabrizio Giudici
Henk De Boer replied on Wed, 2010/09/15 - 4:17pm
in response to:
Steven Harris
So, basically this is 'just' a cache right? As a user you need to allocate your objects with the new operator, then put them in this cache, and eventually when you think you're done with the object instance you call some method to remove it from the cache.
Nice as this might be, I'm not sure you can really compare this to GC or say you solved the GC problem. What happens when you forget to remove an object from the cache? This will open up an entire new class of memory leaks in Java, one that isn't really new in general of course since C++ programmers among others have been dealing with this for a long time.
Of course, as a pure cache it's a really nice solution ;)
Saravanan Subbiah replied on Wed, 2010/09/15 - 7:59pm
in response to:
Henk De Boer
Regarding the problem about forgetting to remove, the problem is the same for any java application, all data structures will leak if you forget to remove. Atleast with a cache you could configure it to be evicted on full capacity or be evicted on expiry after a timeout etc. to circumvent those issues.
Henk De Boer replied on Thu, 2010/09/16 - 1:39pm
in response to:
Saravanan Subbiah
Indeed, it's a cache, nothing more, nothing less. An efficient one maybe, and one that isn't bothered by the GC (the GC has nothing to do in memory areas that are caches), but the various titles of articles about this are a little over the top really ;)
This of course only applies for data that is truly just cached data. In generally you can't just randomly evict live objects in a JVM. Only those objects that you explicitly store in a cache and are able to be recreated if they suddenly happen to be not there anymore qualify for that.
This is perfectly fine for a cache, but again, this is not a general replacement for the heap and Java GC as the articles initially seem to suggest.
Kunal Bhasin replied on Fri, 2010/09/17 - 1:54pm
Hal Mo replied on Mon, 2010/09/20 - 5:31am
in response to:
sibasisha padhy
Steven Harris replied on Mon, 2010/09/27 - 8:19pm
James Kear replied on Tue, 2011/09/06 - 2:35pm
Carla Brian replied on Tue, 2012/05/15 - 5:57pm