19 ms·

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

by brazzy 17y ago

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.

bensummers 17y ago
They've built a many-core microprocessor and architecture specifically designed to run Java at scale. The article would have been better if they'd mentioned that or some details on what they did. See here http://news.ycombinator.com/item?id=806894 http://news.ycombinator.com/item?id=806894 for some links to technical details and discussion.
dkersten 17y ago
The Terracotta JVM clustering software also allows you to use more memory than a single Java process normally can access by, firstly, spreading your app across a cluster and, secondly, by paging ojects to disk to make additional space.
akeefer 17y ago
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 17y ago
  Thanks - your explanation was far more interesting than the article :)

by brazzy 17y ago

bensummers 17y ago

They've built a many-core microprocessor and architecture specifically designed to run Java at scale. The article would have been better if they'd mentioned that or some details on what they did. See here http://news.ycombinator.com/item?id=806894 http://news.ycombinator.com/item?id=806894 for some links to technical details and discussion.

dkersten 17y ago

The Terracotta JVM clustering software also allows you to use more memory than a single Java process normally can access by, firstly, spreading your app across a cluster and, secondly, by paging ojects to disk to make additional space.

akeefer 17y ago

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 17y ago
Thanks - your explanation was far more interesting than the article :)