Zing - A JVM for virtualized x86 platforms with pauseless GC

I really, really hate sales sites that don't list prices.<p>I also think their use cases are either a joke or written by a fool. "Scary for Apps"? Seriously? <a href="http://www.azulsystems.com/products/zing/use-cases" rel="nofollow">http://www.azulsystems.com/products/zing/use-cases</a> Also makes a lot of bold statements that it doesn't even try to back up with numbers like "Better application performance under hypervisors than if run natively".<p>My scam sense tells me to run for the hills just from that one page. I hope for their sake that they redo that page in a hurry.

Azul is a great innovator in the JVM space, and I think their innovation will start to trickle down to other VM based languages like Ruby, Python, PHP, JavaScript etc. They've already open sourced some of their innovations: <a href="http://www.managedruntime.org" rel="nofollow">http://www.managedruntime.org</a>

I'm actually more interested in the "elastic memory" bit: <a href="http://www.azulsystems.com/products/zing/elastic-memory" rel="nofollow">http://www.azulsystems.com/products/zing/elastic-memory</a><p>When I used to work with JVM's all day I was always frustrated about having to decide how big a maximum heap for a given app would be. We had some xml processing tasks that almost never used much memory but every now and then would need tons. It was one part I couldn't thin-provision.<p>Am I right in interpreting this as shipping the JVM work off to a dedicated appliance-like server? Does that mean the memory profile on the appliance is the one that can be thin-provisioned?<p>Heap size tuning is one of those things that made me hate the JVM.

Previous discussion about the (awesome) GC: <a href="http://news.ycombinator.com/item?id=2022723" rel="nofollow">http://news.ycombinator.com/item?id=2022723</a>

This technology could be extremely interesting -- especially if they make it easy to provision on EC2. Getting rid of the overhead to customize OS distributions simply to run a JVM would reduce TCO and time to market not to mention better resource utilization.

Simply regarding the pauseless GC aspect, what is preventing someone from adding an existing realtime garbage collector like Rollendurchmesserzeitsammler (hereinafter rdmzs) to OpenJDK? Obviously rdmzs is designed for audio processing, as it bases its heap size on the audio processing cycle time, but are these similar GC concepts, or is the "pauseless GC" mentioned here something completely different from what rdmzs does?

I wonder when a real time GC will be available for openjdk.