IBM eXtremeMemory

IBM® eXtremeMemory enables objects to be stored in native memory instead of the Java™ heap. By moving objects off the Java heap, you can avoid garbage collection pauses, leading to more constant performance and predicable response times.

The Java virtual machine (JVM) relies on usage heuristics to collect, compact, and expand process memory. The garbage collector completes these operations. However, running garbage collection has an associated cost. The cost of running garbage collection increases as the size of the Java heap and number of objects in the data grid increase. The JVM provides different heuristics for different use cases and goals: optimum throughput, optimum pause time, generational, balanced, and real-time garbage collection. No heuristic is perfect. A single heuristic cannot suit all possible configurations.

WebSphere® eXtreme Scale uses data caching, with distributed maps that have entries with a well-known lifecycle. This lifecycle includes the following operations: GET, INSERT, DELETE, and UPDATE. By using these well-known map lifecycles, eXtremeMemory can manage memory usage for data grid objects in container servers more efficiently than the standard JVM garbage collector.

The following diagram shows how using eXtremeMemory leads to more consistent relative response times in the environment. As the relative response times reach the higher percentiles, the requests that are using eXtremeMemory have lower relative response times. The diagram shows the 95-100 percentiles.

.
Figure 1. Comparison of eXtremeMemory and Heap Storage Response Times
Relative response time gets higher as the response time percentile increases. The relative response times are much lower for eXtremeMemory than Heap.