Java on a 1000 Cores - Tales of Hardware / Software CoDesign

What Hacker News said

Strong rec bokchoi · 2009-10 · on “JOP: A Tiny Java Processor Core for FPGA”

Here's an excellent google tech talk by Cliff Click of Azul talking about their hardware. Among the firehose of information in that talk, he mentions that the hardware guys wanted to add directly execute JVM bytecode. He told them not to bother since he could JIT it better and they wouldn't be able to support all the bytecodes anyway. I'd love to know more about why that is. [this video]

Strong rec qznc · 2013-04 · on “Ask HN: What's the best technical talk you've heard?”

Probably this one: [LINK] Anything from Cliff Click is quite good. This guy has a very deep understanding of compilers, virtual-machines, CPUs, and their interactions. A JVM does that? [LINK] Java on a 1000 Cores [this video]

Recommends Alupis · 2015-03 · on “Peter Lawrey Describes Petabyte JVMs”

There are some interesting challenging when scaling this large with any system. Peter referenced some of Azul System's stuff and their custom GC. Cliff Click from Azul has done some great Google Tech Talks about JVM development and scaling JVM's out to really big systems.[1][2] [1] A JVM Does That? - [LINK] [2] Java on a 1000 Cores - [this video]

Recommends mcbridematt · 2020-07 · on “Java Optimized Processor (2005)”

Azul Systems (who today are mainly a JVM vendor) started by building large multicore boxes (Vega) to do Java workloads - there is an interesting tech talk about it: [this video] (2009) They built a "really good JIT target" rather than direct bytecode for reasons explained in the video. Curious to hear from anyone who ever used one...

Recommends hayley-patton · 2025-11 · on “Implementation of a Java Processor on a FPGA (2016)”

> What I can imagine is a purpose-built CPU that would make the JIT's job a lot easier and faster than compiling for x86 or ARM. Such a machine wouldn't execute raw Java bytecode, rather, something a tiny bit more low-level. This is approximately exactly what Azul Systems did, doing a bog-standard RISC with hardware GC barriers and transactional memory. Cliff Click gave an excellent talk on it [0] and makes your argument around 20:14. [0] [this video]

Cites jeremyw · 2009-10 · on “An Interview with David Moon and Daniel Weinreb”

As Click discusses in his Google tech talk ( [this video] ) Intel could implement a hardware read-barrier and radically change the GC performance picture for commodity systems.

Cites wahern · 2014-10 · on “What sort of allocation rates can servers handle?”

I don't think that there's anything magical about C4. All the basics are discernible from this presentation: [this video] Azul originally started out as a hardware company. A pauseless collector is easy as long as you have transactional memory (at a minimum hardware which supports strong LL/SC, allowing you to build the rest in software). No commodity CPUs support this, then or now, so Azul's first product was a specialized CPU and memory architecture with real transactional memory semantics. But nobody wants to buy specialized hardware these days. So they ended up having to emulate transactional memory on x86. That means _emulating_ the memory architecture of their original CPU. Again, there's n

Cites nickik · 2014-11 · on “Java Garbage Collection Distilled (2013)”

I have not suggested that they put C4 or the orginal passless as a standard. While they did focuse on a perticular market segment the performance and paustime numbers they showed could easly have been usful for tons and tons of other markets. While C4 does currently require OS enhancements, they could make it without it, it would just be slower. However the problem that Azul has tried to overcome with the OS could have been much more powerful attacked with the full force of oracle/sun behind it. They once put some linux patches but it was never there focus and it never went upstream. At a big company this technogoly could have had a bigger impact, they could have talked to microsoft, apple a