FYI -- This article amused me, because I had assumed people were generally happy with web pages that were prone to seizures. The whole GC/noGC debate seems to ebb and swell with each order of magnitude increase in memory. How many papers have been written by now about how -- if you just have enough memory -- you won't need garbage collection anymore. Ask any New York City resident circa the late 1970's about how well that idea works out! Maybe I need to go back to doing GC research again... http://java.dzone.com/terracotta-releases-bigmemory Terracotta Says 'Goodbye Java GC, Hello BigMemory' Submitted by Mitchell Pronsc... on Tue, 2010/09/14 - 7:18am 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. <ehcache> <cache name="mycache" maxElementsInMemory="10000" overflowToOffHeap="true" maxMemoryOffHeap="4G"/> </ehcache> "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. 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.