Azul uses dirty VM tricks to achieve incredible performance feats. They're incredibly inefficient on x86-based hardware, so that's why it requires a lot of RAM. And since most of their customers are financial institutions - they don't care much about it.
Azul also produces their own hardware with a hardware acceleration of garbage collection. It works MUCH better.
Posted Jul 17, 2012 8:16 UTC (Tue) by man_ls (subscriber, #15091)
[Link]
Throwing memory at problems is always a good way to speed them up. That is essentially what IBM does with WebSphere and its many frankenstenian by-products: initialize everything in advance, take ages to start and consume lots of RAM. After that it goes fast. It looks like a good idea until you find out that dev machines also have to be top of the line machines with 4 GB RAM -- it may not look much today, but not everyone can buy hardware every two years. Or provide VMs with so much memory.
Good opportunity for Java update
Posted Jul 17, 2012 8:24 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
[Link]
It's not like they need a lot of ram, it's just that their GC algorithms have very high overhead. In fact, large amounts of ram on normal GCs is a receipt for failure because of lengthy pauses during full collections.
Good opportunity for Java update
Posted Jul 17, 2012 8:29 UTC (Tue) by man_ls (subscriber, #15091)
[Link]
Yes, GC can be a problem if you allocate and free large amounts of RAM (especially in a lot of objects or string manipulations). The IBM trick is to never release the objects (i.e. keep object references around) so the GC does not have to work.
I understand that what Azul does is keep lots of object references so GC doesn't have to do much work. It might be inferred that object allocations must also be penalized, right?
Good opportunity for Java update
Posted Jul 17, 2012 8:44 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
[Link]
Nope, they need a lot of ram to make their GC pauseless(in tech speak: to allow the mutator work in parallel with the collector). They do this by simulating forwarding pointers using vm.