In this interview with Artima, Gil Tene, CTO of Azul Systems, shows how recent research in garbage collection and JVM implementation helps overcome the JVM's memory barrier, resulting in new types of applications:

http://www.artima.com/lejava/articles/javaone_2008_gil_tene.html

What has been your experience working with large amounts of JVM memory?

This reads like an advertisement. It points out some of the underlying limitations of garbage collection algorithms, and *claims* that they are solvable... but then doesn't give *any details whatsoever* about how they are actually solved.

What? Have you built a better garbage collector? Well.. what is it? What's the algorithm? Are there journal articles on this? Example code? Anything aside from hyperbole?

> This reads like an advertisement. It points out some of
> the underlying limitations of garbage collection
> algorithms, and *claims* that they are solvable... but
> then doesn't give *any details whatsoever* about how they
> are actually solved.

Hmm, this is an issue with what we did *not* publish with this interview, which is about the specific ways in which Azul solved this garbage-collection problem. They have a hardware-based solution, i.e., a specialized, hardware-based VM. Although Gil Tene spoke about their product in the interview, we felt that it was not appropriate to include those product-specific parts in the published interview. We included those portions only that discuss the problem with allocating large amounts of memory in general-purpose VMs.

The problems described in the article are relevant for the most common serial and parallel garbage collectors, which stop the entire application, go do their thing, and then resume the application.

I've had much better experience for interactive online systems using the Concurent Mark-Sweep collector built into the standard JVM. Especially when I use the Incremental mode of this collector.

This collector is continuously running in the background without stopping the application for the long periods that are required by the other collectors.

The benefit of the azul solution is that it can use hardware support at the memory controller level to support a theoretically pauseless GC on a heap of any size. So for most applications, the Sun JVM's tunability allows the GC pause times to be limited, but they will still occur, and in length they will somehow correlate with the size of the heap. There are simply some applications that need 50GB of heap space and no full stop GC ..

Peace,

Cameron Purdy | Oracle
http://www.oracle.com/technology/products/coherence/index.html

6GB heap - no issues. JVM 1.5 and 1.6 are easily tuned to avoid this. Just read the manual & various articles on how to use concurrent collector.

Java gives projects a pass on memory management for simple tasks.

Any seasoned system architect must understand how to manage objects and memory for large running systems. There is no get out of jail free card in the form of a product.

http://java.sun.com/performance/reference/whitepapers/tuning.html
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
http://www.tagtraum.com/gcviewer-vmflags.html

> 6GB heap - no issues. JVM 1.5 and 1.6 are easily tuned to
> avoid this. Just read the manual & various articles on
> how to use concurrent collector.

Sure, unless you count the full GC's.

Lots of developers assume that because they can tune the incremental GCs down, that they've tamed the beast. However, even with a well-tuned 6GB heap, most applications will see an unacceptable pause when full GC hits.

Peace,

Cameron Purdy | Oracle
http://www.oracle.com/technology/products/coherence/index.html

I have a new memory related question, but i didnt find any link to create a new topic. can any body help me.
i don't want to disturb this topic, by posing my question in the same thread. Please help.