 Okay. Hello, everyone. It is a great pleasure for me to have an opportunity to talk in Open Source Summit Japan today. I am Konno Kazuhiro from Japan, and I talk about my work in an Open Source Java Virtual Machine, OpenJ9, adding support for a new processor architecture to it. I am speaking live and I speak in English in this session. I have to show this page and the next page by the rule of my company, disclaimers and notices for the trademarks. Let me start with who I am. I am a software engineer at the Software Development Organization in IBM Japan. I joined the company in 1995, and I have been working on folding and delivering IBM Java to embedded systems for nearly 20 years. My target devices include printers, vending machines, and carnivalation systems, for example. A certain percentage of you may have consumer devices at your home with IBM Java internally or had such devices in the past without knowing that, although I cannot mention the name of the products I have worked on. I became a committer of two Open Source projects, Eclipse OpenJ9 and Eclipse OMR, a year ago. I will talk about the Open Source projects in the following pages. Today's agenda looks like this. I am going to talk about OpenJ9 and my work in the OpenJ9 project to add support for ARC64 Linux. Let me start with OpenJ9. Eclipse OpenJ9 project was created three years ago in 2017. It is an implementation of Java Virtual Machine. It originates from IBM's J9 Virtual Machine, so the name is OpenJ9 now after Open Source. J9, IBM's own Java Virtual Machine implementation is a proven and enterprise-grade Java implementation. It has been the core of IBM Java SDKs for many years and has been available bundled in IBM software such as WebSphere application server. IBM Java SDK supports systems with power architecture and IBM's mainframe system Z, as well as XID6, Linux, Windows, and macOS. J9 was open sourced three years ago to reach developers outside of IBM. IBM Java SDK now uses OpenJ9 as its core. You can see the advantages of OpenJ9 over other Java VM implementation at the OpenJ9 project site. That includes fast startup and smaller footprint. OpenJ9 needs also a cloud-aware. That means it is optimized for use in containers. OpenJ9 has technologies called shared classes and AOT. AOT is ahead-of-time completion. They contribute to faster startup. Please visit the project website for more details of the advantages of OpenJ9. I'd like to talk about the structure of OpenJ9 here. OpenJ9 is an implementation of Java Virtual Machine. You may know that there is another Java Virtual Machine that originates from Sun and Oracle, which is called Hotspot. There is an open-source project called OpenJDK. Hotspot is a virtual machine developed in the OpenJDK project. You can see it on the right side of this page. Hotspot is not the only component in the OpenJDK project. You can see the OpenJDK class library in the box above. IBM has been collaborating with Oracle in the OpenJDK project for the class library since 2010. IBM has used the OpenJDK class library in IBM Java SDKs. Our Java runtime combines the OpenJDK class library and the OpenJ9 Virtual Machine replacing the Hotspot Virtual Machine in OpenJDK. You can see it in the left side of the page. There is the Eclipse OpenJ9 Java Virtual Machine at the bottom. On top of it is the OpenJDK class library. There is an adapter code that bridges between the OpenJ9 VM and the class library. This structure is basically the same as it used to be with IBM Java SDK before OpenSourced. Next page. I'd like to talk about OpenJ9 and OMR. When J9 Virtual Machine was OpenSourced, it was divided into two projects. One is Eclipse OpenJ9 and the other is Eclipse OMR. Eclipse OMR is a project that implements language-independent runtime technologies. That includes garbage collection and compiler and polling layers. The components in OMR can be used to build other languages such as Python and Ruby. There are implementations of such languages based on OMR. Please don't ask me what OMR stands for. It used to be an acronym of something, but it is now OMR is OMR. Eclipse OpenJ9 project is on top of OMR focusing on the Java Virtual Machine implementation and the Java-specific part of the components. You can see the compiler code resized in both projects. In the OMR site, the compiler component is the infrastructure for building compilers. In the OpenJ9 site, it implements the Java-specific part of the JavaJIT compiler. Now, I am moving to the topic of AAC64. It is sometimes called as ARM64 or ARMv8a. Those words sometimes have slightly different meanings, but I mix the use of AAC64 and ARM64 in this slide. Please don't care about that. AAC64 is a 64-bit architecture from ARM and it was announced in 2011, nine years ago. ARM has its 32-bit architecture and that was widely used in embedded devices, but when they introduced 64-bit architecture, they defined a new instruction set and register set. What is important here is that it is not a simple extension from the previous 32-bit architecture and there is no upper compatibility between the instruction sets. You can execute 32-bit instructions when you are running in 64-bit mode of x86 or power architecture, but that does not apply to ARM. Nowadays, most smartphones and both iPhone and Android run on 64-bit ARM processors. Japanese supercomputer, Fugaku, uses CPU cores of AAC64 architecture with vector extension. You may know Fugaku was number one in the recent top 500 lists of supercomputers and you may also know that Apple started to switch the processor in their Macintosh from Intel processors to its 64-bit ARM processor last month. As I mentioned in this talk earlier, I belong to a team in IBM Japan that delivers embedded Java solutions to our customers. It was clear that many of our customers were going to switch from 32-bit ARM to 64-bit ARM in the near future. That is the reason why our team decided to add 64-bit ARM to the list of supported architectures of OpenJ9 in early 2018. The target OS is Linux. In supporting a new processor in OpenJ9, the JIT compiler is the T component. Most of the other components in OpenJ9 are written in TNC++ and you can just run compilers for the target systems to build those components. But the JIT compiler is a compiler. It needs to generate instructions for the target processor and I will explain what the JIT compiler does later. And by the way, most of the developers of J9 and OpenJ9 in IBM are located in countries like Canada and United Kingdom and India. But I had worked with those developers around the world in 2015. That was before J9 was open sourced. I joined the development of IBM Java SDK for 32-bit ARM at that time. And I learned the structure of the JIT compiler and how to debug the JIT compiler at that time. And that's the experiences made it possible for me to work in this project for AX64. I am the main developer for AX64 support, but I was not the only one. There are two others from IBM and also there were nearly 10 students from a Canadian university who are interested in compiler technology. The students were working with an IBM laboratory in Canada through the program called IBM CAS, Centres for Advanced Studies. That is a collaboration program of IBM and universities. We used Slack and JIT Hub and we also had weekly calls to exchange our status. Development timeline looks like this. I started the development by writing calls for the compiler in the OMR project in May 2018. It took me more than half a year to implement functions in the OMR side. That includes the time for learning the AX64 instruction set and the JIT compiler structure. I used single board devices like Raspberry Pi's and Jetson Nano's development platform. Then I built and enabled the Java byte code interpreter in the OMR project in early 2019 last year. By doing this, we were able to run Java programs on AX64 Linux without the JIT compiler at this point. The JIT compiler development continued in the OpenJ9 side from February last year. That implements the Java-specific part of the JIT compiler. That includes writing runtime routines of the compiler and that took very long. It was summer last year when the JIT compiler first generated instructions for very simple Java methods. Just like returning a value past as an argument shown in the slide. Another IBM developer joined in September to accelerate the development and we were able to run many Java programs with the JIT compiler enabled by November. Then we added support for ahead-of-time completion and enabled tests in the network builds at the open source project. We spent a couple of months in dividing before we finally released the first release in April this year. That was JDK 11 only at that time, but we added JDK 8 and 15 in October. Now I'd like to talk a little more detail on what I did starting with the work for building the Java bytecode interpreter. It is written in C and C++ and it is highly portable except that there are some files written in assembly code. I had to add those files for AX64. As you can see in the file names on the right of this page, those assembly files written in M4 macros. You also need to add configuration files and make files for AX64 and add fdev lines for AX64 in many places. I needed to learn how the whole Java runtime was built. It is a very big system and takes a very long time to build. It took me three weeks in total for adding those files and for debugging the interpreter before it started to work. It was the interpreter without the JIT compiler. So it is very slow, but you can run Java programs in an AX64 environment. I'd like to talk about the JIT compiler next. As you may know, JIT is short for just-in-time and JIT compilers are popular these days and they are used not only with Java, but in other environments like JavaScript and .NET and many other languages. In Java, the JIT compiler translates Java bytecodes into native instructions at runtime. Look at the simple example on the right side, translating four bytecodes into three native instructions. In OpenJ9, the JIT compiler is also used for ahead-of-time compilation. AOT stores the compiled codes in OpenJ9's shared class cache, so that the compiled code is reduced. The JIT compiler in OpenJ9 is written in C and C++ and assembly code. Now look at the structure of the source tree in this page. This page focuses on the structure of the compiler directory in OMR. This is an OMR project, but OpenJ9 project also has a similar structure in its compiler directory. On the left side, there are platform-dependent, platform-independent directories that controls the compiler and that performs optimizing the code. The boxes on the right side show the platform-dependent directories. OpenJ9 and OMR used to support P that is power architecture and X for Intel X86 and Z, that is IBM's mainframe and there's a box for 32-bit ARM, but the code for 32-bit ARM is not maintained actively in supporting ARC64. We added a new directory here on the right and we wrote the code in it from scratch. As I mentioned earlier, ARC64 is not upper compatible with 32-bit ARM and you cannot just extend the existing 32-bit ARM code to support ARC64. This page shows the work items in the JIT compiler development. On the OMR side, it contains the capability of generating ARC64 instructions and register assignments. It also has the implementations of more than 300 evaluators. Evaluators are the functions that convert the operations at the intermediate language of OpenJ9 into native instructions. On the top tables of ARC64 native instructions, the initial version of the native instruction table was written by the university students. I mentioned in a couple of pages back, the OpenJ9 side of the JIT compiler implement the Java-specific part of the compiler. That includes evaluators for such as allocating new objects in Java or checking types, check chest or instance of that kind of evaluators. You also need many runtime routines and you also need interface with Java interpreter. We looked at the code in the P and ARM directories as the reference when we implemented code for ARC64. P and Power and ARM risk processes and they are more similar to ARC64 than the other architectures X86 and Z. The size of the code in the ARC64 directories of OMR and OpenJ9 is nearly 40,000 lines in total after two years and a half of work. This page shows the history of my code contribution to the two projects. On the left side is OMR. I started working with the compiler code in the OMR side in May 2018 and worked hard toward the end of the year. Then I switched to the OpenJ9 project in early 2019. I enabled the Java interpreter for ARC64 without the Java JIT compiler first then continued to write code for the JIT compiler. During that time, I also worked on the OMR side too because the features in the OpenJ9 side required some changes in the OMR side. I was elected to be a commander of these two projects at the end of last year and I review and merge pull requests in those projects now. I'd like to talk about challenges in the development activities in this page. First, communication with other contributors. I work in Japan and many other developers in IPM are located in North America and Europe. We had remote meetings weekly but it is not easy to have real-time communication with other developers because of the time zone difference. Second, it was the first news processor architecture that was added to J9 and OpenJ9 in these more than 15 years. People in IBM don't remember how to develop this compiler for new architecture from scratch. The structure of the JIT and the features of the JIT compiler is much different from those in early 2000. Some people in the compiler technologies have already left the company since that time. We have designed documents of the JIT compiler in IBM but they are too old and the code has changed since they were implemented. I had to read the code of other architectures like power and 32-bit arm for understanding what this function does and what that function does, how this function relates to each other. I needed to understand not only the AAC-64 instructions but the instructions of other architectures. Another problem was the computing resource. The number of the AAC-64 servers available in the projects were limited and they are used for daily CI builds and natively builds for testing. I mentioned earlier I used Raspberry Pi and other single-board computers for my development target. I had to use them because of those limited computing resources. Building the OpenJ9 runtime on Raspberry Pi takes very long. I built the runtime on X86 Linux to save time. This page shows the history of the performance improvement. It is a relative speedup compared to the interpreter in early 2019. When the first release was made in April this year, only the low-level optimization was enabled in the JIT compiler because we wanted to focus on the stability in that release. The performance at that time was around five times faster than the interpreter. After that, in May and June this year, we enabled compiler optimization at higher levels, which includes our technique called recompilation. The July release is faster than the interpreter by 16 times. We are implementing more work items in the JIT compiler to improve the performance now. The next page shows the comparison of memory sizes of OpenJ9 and Hotspot running OpenLiberty web server. I said that a smaller footprint is one of the advantages of OpenJ9. As I measured the memory size, that is in VMRSS resident memory size, OpenJ9 is 21% smaller compared to the other JVM implementation. I would like to talk about our future work. To be honest, the AX64 build of OpenJ9 is not as optimized as three other platforms, P and X and Z at this point. We have many work items to be implemented for better performance. That includes methods called improvement and inlining recognized Java methods, such as array copy. That is one example. Also, we need to catch up with new features that will be in new versions of JDK. We now support JDK 8, 11, and 15. 8 and 11 long-term support versions. JDK 16 and 17 will be coming in next year. JDK 17 will be the next long-term support version. We are also interested in supporting Apple Silicon Mac. We found that supporting Apple Silicon Macs is not very easy. That need to be changed because Apple introduced a new restriction with permissions of allocated memory for security reasons. By the way, there are some people in the OpenJ9 community who are working to enable the JIT compiler for RISC 5. The OpenJ9 bytecode interpreter for RISC 5 is already working and Natalie builds available. They are working toward enabling JIT compiler. I am helping them to implement the JIT, sharing the information on what we did with AIK64 in these two years. I am closing the talk by introducing... There is a site called Adopt OpenJDK. If you want to try OpenJ9 with the application, you can download the binaries from this site. This site distributes both hotspot and OpenJ9. Make sure you choose OpenJ9 on the right side of the page. The OpenJ9 community welcomes your participation to the project. There are GitHub repositories for OpenJ9 and OMR. You can open issues and pull requests there. If you want to build OpenJ9 binaries yourself, go to this document shown in this page for building instructions. This is the last page to summarize OpenJ9 is another implementation of Java Virtual Machine that was originally in the IBM Java SDK. I and the team added AIK64 Linux to supported platforms of OpenJ9 after two years of work. The main component that took time was the JIT compiler, as I explained in this session. Again, you can download and try OpenJ9 by downloading from Adopt OpenJDK. That's all from me today. Thank you for visiting this session. I would like to take questions. Of course, I don't mind asking Japanese questions. I see no questions in the chat and Q&A tabs. Again, I'd like to thank you all who joined this session. I'm stopping the broadcast now. Thank you for joining. Bye.