

Breaking Through JVM Memory Limits - yarapavan
http://www.artima.com/lejava/articles/javaone_2009_gil_tene.html

======
brazzy
That's a lot of words spent explaining the problem five times over, and none
whatsoever describing the solution - just two paragraphs about a mysterious
"device" that has to be contacted over the network to run this wondrous 100GB-
JVM.

Having a JVM that transparently executes your app on a remote server is an
interesting idea that might be useful for some kinds of apps and very bad for
others, but I can't see what it has to do with the problem of JVMs not making
use of lots of RAM.

All in all, it sounds like a rather contrived setup to justify selling a very
expensive hardware dongle instead of a straightforward server.

~~~
akeefer
The presentation by Cliff Click at the JVM language conference made that all a
lot more clear; it's a shame the article on Artima doesn't go into much in the
way of details.

Basically, the limitations on conventional VMs are at least somewhat imposed
by the underlying x86 architecture. The Azul box is a custom processor
specifically designed for the JVM, so it can do things like write barriers
around gc in a single hardware instruction. That, in turn, allows them to
produce a fairly pauseless garbage collector: I believe he claimed something
like 10-20ms at most for a 100GB+ heap. Contrast that to the several second GC
pauses you'll often get on a conventional VM with just a few GB of heap.

Their boxes are also designed to massively scale up; up to 54 cores per chip
and 16 chips in a single box. I believe they use localized L1-caches, shared
L2-caches (between each 9 cores, I think), and uniform memory accesses across
all the chips in the box. The end result is incredibly high memory bandwidth.
The other bit Click talked about was how they can profile under load with
basically no overhead, unlike the standard JVMTI interface.

They used to sell a lot of gear to financial services companies, as I
understand it: I get the impression that for high-load transaction processing
their boxes would pretty much smoke anything remotely resembling a convention
server or array of servers.

Again, it's a shame the Artima article didn't really talk about any of that.
The fundamental limitations are more primarily in the JVM interaction with
conventional x86 chips and the really cool work Azul has done is to create a
chip (not unlike the Lisp machine of yore) specifically designed to make the
JVM run fast and scale up.

~~~
brazzy
Thanks - your explanation was far more interesting than the article :)

