Skip to content
0:00 / 0:00

#jvm#azulsystems#garbagecollection

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

Google TechTalks

349K subscribers • 56 videos on Hallway

YouTube
  • Recommended by 5 people: 5 on Hacker News.
  • A classic. People kept recommending it from 2009 to 2025.
  • Presented by Cliff Click, Azul Systems

Advanced. Deep dive for people who know the field.

23K views17 years ago5 recommendations

Systems programmingProgramming languagesCompilers and interpretersPerformance and optimizationConcurrency and parallelism

Cliff Click explains how Azul Systems designed custom hardware and JVM software to run massive Java applications with pauseless garbage collection.

Google Tech Talk August 12, 2009 ABSTRACT Presented by Cliff Click, Azul Systems. Azul Systems designs and builds systems for running business logic applications written in Java. Unlike scientific computing, business logic code tends to be very large and complex (greater than 1MLOC is common), display very irregular data access patterns, and make heavy use of threads and locks. The common unit of parallelism is the transaction or thread-level task. Business logic programs tend to have high allocation rates which scale up with the amount of work accomplished, and they are sensitive to Garbage Collection max-pause-times. Typical JVM implementations for heaps greater than 4 Gigabytes have unacceptable pause times and this forces many applications to run clustered. Our systems support heaps up to 600 Gigabytes and allocation rates up to 35 Gig/s with pause times in the dozen-millisecond range. We have large core counts (up to 864) for running parallel tasks; our memory is Uniform Memory Access (as opposed to the more common NUMA), cache-coherent, and has supercomputer-level bandwidth. The cores are our own design; simple 3-address RISCs with read- & write-barriers to support GC, hardware transactional memory, zero-cost high-rez profiling, and some more modest Java-specific tweaks. This talk is about the business environment which drove the design of the hardware (e.g. why put in HTM support? why our own CPU design and not e.g. MIPS or X86?), some early company history with designing our own chips (1st silicon back from the fab had problems like the bits in the odd-numbered registers bleeding into the even-numbered registers), and finally some wisdom and observations from a tightly integrated hardware/software co-design effort.

Why it's here

5 people recommend this

What people say. Recommended as an excellent talk on JVM internals, custom hardware codesign, and the trade-offs of garbage collection.

Moments people linked to

bokchoion Hacker News • Recommends

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. link to this video

qzncon Hacker News • Recommends

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 link to this video

Alupison Hacker News • Recommends

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.12 1 A JVM Does That? - link 2 Java on a 1000 Cores - link to this video

mcbridematton Hacker News • Recommends

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: link to 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...

hayley-pattonon Hacker News • Recommends

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 link to this video

u/theangeryemacsshibeSWCL, Utenain r/ProgrammingLanguages • Mentions

On “Language VM Hardware?”

Azul specifically did not do that, with Cliff Click saying: > Oh, my God, don't do that. It's been tried before, it's disastrous. What about JIT? Give me a nice JIT target. Nice three-address RISC. I'll make you pretty code for it and it'll run really fast. Don't try and screw around with executing bytecodes directly because after I JIT you won't care for it, and, in any case, you can't handle all the bytecodes, so you'll have to bail out to software anyhow. That's not at all to say that doing a hardware VM can't be fun, but it's not awfully practical, and chips are expensive so most peoples' budgets do not allow having fun here. The VMs are better treated as a somewhat portable compiler…
5View on Reddit

u/theangeryemacsshibeSICL, one-more-re-nightmarein r/ProgrammingLanguages • Mentions

On “How were compilers able to fit and run in computers from the 60s and 70s?”

Other than the read barriers (and hardware transactional memory and better cache policy), the Azul machines were rather plain RISC machines. In particular the Java equivalent to "interpreting S-expressions in hardware" of interpreting JVM bytecodes was shot down early.
3View on Reddit

jeremywon Hacker News • Mentions

On “An Interview with David Moon and Daniel Weinreb”

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

wahernon Hacker News • Mentions

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: link to 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…

nickikon Hacker News • Mentions

On “Java Garbage Collection Distilled (2013)”

…server space. I rember talks by Cliff Click that mentioned that they were really suprised that Sun did not have more intresst in them, considering some simple things that Sun could have to get huge increses in some of the high end server systems they were selling (am searching for the refernce ...). Edit: See Cliff Click talk about intel and sun. link to this video t=54m33s He mentions that the sun shareholders should put there exutive staff into prison.…

hayley-pattonon Hacker News • Mentions

On “Does the Bronze Garbage Collector Make Rust Easier to Use?”

…k-allocated objects by using escape detection rather than analysis 3. At least the Inkscape vector editor uses the Boehm garbage collector 4. There are several programming language implementations which use Boehm and C, but one wonders if it is still a "C codebase" then. 1 link 2 Henry Baker, CONS should not CONS its arguments link 3 link to this video 4 link…

u/theangeryemacsshibeSICL, Utenain r/ProgrammingLanguages • Mentions

On “Can there b memory management at the hardware level?”

> and using it for hardware assisted dynamic dispatch to avoid the branch misprediction cost that can normally be caused by dynamic dispatch. Cliff Click claimed an inline cache eliminated almost all indirect jumps for Java, which must dispatch despite having a static type system. The Self people also found type inference eliminated most of the need for tag checking in hardware too.
2View on Reddit