This article is an outside part of the OpenJDK compilation and debugging guide (Ubuntu 16.04 + MacOS 10.15). It is mainly used to record some problems encountered in the process of debugging OpenJDK and the solutions.

How to build the “zero-Assembler” OpenJDK

In debugging the OpenJDK with JetBrains CLion, we found that sometimes parts of the Call Stack were assembly code, which prevented us from fully exploring its internal implementation. Is there a way not to use this part of assembly code?

First let’s look at why does part assembly code exist?

Why does partial assembly code exist?

HotSpot uses Template based Interpreter to interpret and execute JAVA VIRTUAL machine instructions to improve performance. The JVM generates the interpreter at startup based on the TemplateTable (assembly code for each bytecode), so the interpreter is partially based on assembly code. In addition to the interpreter, some parts of the OpenJDK project are based on assembly code, such as just-in-time (JIT) compilers (C1 compiler, C2 compiler), but assembly code is dependent on hardware architecture, which improves performance but reduces portability.

The OpenJDK community’s IcedTea project provides a more general approach to porting, enabling OpenJDK to be built on all Linux systems without further porting.

IcedTea project

The IcedTea project first emerged because when Sun released the JDK, some parts of the class library were not distributed in source code for property rights reasons, but were made available only as binary plug-ins because the source code belonged to copyrighted third parties. The main goal of IcedTea is to provide a free equivalent alternative to these binary plug-ins, making it possible to build the JDK entirely with free open source software.

In addition, IdeaTea has done a lot of work to make it easier for users to build and deploy the JDK, including porting the OpenJDK to more platforms.

This is because OpenJDK code contains a lot of assembly code in addition to C++ code, and OpenJDK supports a limited hardware platform architecture, much less than Linux systems support. Thus came IcedTea’s sub-project Zero, which was designed to build on any Linux system without further porting, by removing the platformer related assembly code from the OpenJDK project code and replacing it with pure C++.

This is what “zero assembly” in the title means, that is, building the OpenJDK without assembly code.

OpenJDK’s virtual machine relies heavily on JIT (Just-in-time compiler) compilation to improve performance. Zero, which contains only a pure C++ interpreter, is much slower than the original (vanilla) OpenJDK on the same hardware. This led to the emergence of another subproject, Shark, which uses LLVM to compile Java methods on the go, thereby improving performance without introducing system-specific code.

How to implement zero-Assembler

So far we’ve seen that building the OpenJDK with Zero makes for “zero-Assembler”, so how do we use it? Zero and Shark are now integrated into the OpenJDK main branch. When you configure OpenJDK, use the with-jvm-variants= Zero parameter to recompile.

Variants =zero; / /configure --with-jvm-variants=zeroCopy the code

The resources

  1. HotSpot Runtime Overview – Interpreter
  2. Sustaining the zero assembler port in OpenJDK: An inside perspective of CPU specific issues
  3. Demystifying the JVM: JVM Variants, Cppinterpreter and TemplateInterpreter
  4. OpenJDK: IcedTea Project
  5. IcedTea – Wikipedia
  6. Main Page – IcedTea
  7. Zero-Assembler Project
  8. ZeroSharkFaq – IcedTea
  9. The New Hotspot Build System