Andrew Dinn

The OpenJDK Java Virtual Machine presents some interesting challenges when it comes to guarding against potential vulnerabilities. This talk will explain how dynamic class-loading, JIT compilation, speculative compilation and other aspects of the JVM's operation present a moving attack surface that presents some very different challenges to those found in other programs or runtimes.

This talk won't say anything about specific vulnerabilities but it will identify a few areas of the OpenJDK JVM where some of these unique types of vulnerability have been identified and resolved. It may teach you some things you didn't know about the complexity of the JVM and hopefully reassure you that the OpenJDK devs are very aware of what could possibly go wrong. Whether we have got it all right is left as a follow-up exercise for attendees.

The GraalVM project provides, among other options, a means to deliver Java programs as compact, self-contained, fast-startup native images. GraalVM has been moving from research to development for quite a few years now. However, it is only just beginning to be properly integrated with the latest OpenJDK releases and there is still much to be done to get it fully productized and to improve usability and performance.

This talk will recount our joint experiences of trying to add new and/or improved capabilities to the the GraalVM code base. Our story will stumble gracelessly from one pitfall to the next cock-up in the hope that by exposing and explaining our own history of lamentable error and occasional failure you will be able to avoid being doomed to repeat it.

We will provide a guide to getting started and building GraalVM, an overview of the how the compiler, native image generator and other elements of the GraalVM toolkit operate plus a map of what code sits where in the source tree and how it fits together and offer tips for debugging the Graal compiler and native image generator -- all the tasks you will need to perform in order to attain a vantage point from which to change or add to the current functionality.

Other people: Josh Matsuoka

One of the ways Java achieves high performance is to provide a route for accelerated, hand-crafted compilation of certain critical methods via the JIT. This optimization path is available both for native methods implemented as callouts to C code and for methods that are defined in Java. In both cases the method needs to be flagged as a HotspotIntrinsic and provided with a JITted code implementation. The intrinsic implementation defines the hand-crafted definition of as a high-level intermediate representation (IR) graph for the C2 JIT. This means it can be inlined into the IR graph for caller methods, providing even greater opportunities for optimization.

This talk will demonstrate how to implement an intrinsic by walking through a specific real-life example that is currently under review as a JEP candidate. It will start by motivating the need for the intrinsic and defining the candidate as a Java method which relies on an underlying native implementation. It will then show how the candidate can be replaced with an intrinsic implementation, working through the changes required in the VM, the JIT compiler front and back end and, ultimately, the assemblers for x86 and AArch64.

The OpenJDK JVM eats class bytecode and spits out Java heap objects and machine code as part of normal execution. However, the JVM manages more data than just bytecode, Java objects JITted code. In order to manage heap memory and to ensure correct execution, the JVM and JITted code need to retain and, occasionally, interrogate details of the loaded class base. Bytecode is not a very 'efficient' representation for this purpose, nor does it include details of runtime-derived info like class and method implementation dependencies, compile history and JITted code status, or execution profiles.

So, the JVM throws away most bytecode after parsing, in its place constructing and maintaining its own 'efficient' in-memory (C++) data structures which model both the loaded class and method base and runtime-derived state. This is what is known as Class Metadata. Class Metadata is a significant component of the Native Memory storage allocated and managed by the JVM, alongside JIT Compiler Metadata, GC Metadata, Thread Metadata, etc. For small applications that don't create a large number of Java objects Metadata can constitute a large portion of a Java application's resident memory set.

This talk will begin by describing how to use the jcmd tool to measure summary JVM Native Memory storage costs, including overall Class Metadata costs. It will also show how to use jcmd to obtain a detailed breakdown of the latter costs, splitting the overheads along two axes: firstly, by class; and secondly, dividing per-class costs into separate sub-costs associated with different component subsets of the class model: classes per se, constant pools, methods and annotations.

I will go on to explain how Class Metadata is carved out of the memory regions managed by the JVM's Native Memory allocation routines and detail the memory layout of the various C++ types which define the elements of the Class Metadata model, thereby clarifying some of the more detailed statistics available in jcmd output. Real-life use cases will be employed to explain how specific costs arise from code design choices and to suggest how alternative choices might increase or decrease Class Metadata costs.

BMUnit is the package which integrates Byteman into JUnit and TestNG, enabling you to locally redefine the behaviour of application or JDK runtime code for the duration of a single test or group of related tests. BMUnit is very simple to use; just add a few annotations to your test classes and place a few jars in your classpath. This talk will explain how BMUnit works by presenting and executing tests which exemplify the 3 most common use cases:

• injecting trace code so you can be sure your tests enter the expected code paths

• injecting validation rules so you can assert that specific outcomes do occur

• injecting 'faults' to modify state or control flow, driving the application or JDK runtime down the path needed to exercise a desired test scenario

(Please note that this talk replaces 'Displaying Application Events in Thermostat Using Byteman')

What really happens to your Java code along the way to becoming machine code?

Red Hat has been developing an almost pauseless GC for OpenJDK which requires adding read barriers to every object access. We've also developed ARM64 versions of both the server and the client compilers. This has given us quite a bit of experience with the internals of the various methods of generating machine code inside the JVM. This talk will start with a brief tour of the various levels of code generation available and then open up the floor for questions from our panel.

Other people: Andrew Haley Roman Kennke Christine H Flood

Red Hat's project of porting OpenJDK to run on ARM's new 64-bit architecture began about 18 months ago. This talk will describe the work we have performed over the last year, explaining how we went about implementing the client and server JIT compilers. In particular, we will give details and examples of how we have tuned the server compiler to generate code that has been optimized to make use of the AArch64 instruction set.

Red Hat's project of porting OpenJDK to run on ARM's new 64-bit architecture began about 18 months ago. Our rapid progress implementing the interpreted runtime was demonstrated at last year's FOSDEM. Since then we have completed our implementation of both the client and server JIT compilers and the project is now approaching its finishing stages. All of which implies that the first high quality, high performance Java runtime available to AArch64 developers will be Free Software.

This talk will describe the work we have performed over the last year, explaining how we went about implementing the two JIT compilers. In particular, we will give details of how we have tuned the server compiler to generate code that has been optimized to make use of the AArch64 instruction set. We will demonstrate the latter by running some example programs, displaying the generated AArch64 machine code and comparing it with the code generated by the x86 JIT compiler.

Other people: Andrew Haley

ARM's new, 64 bit ARMv8 architecture, is a break from the past in two regards. The change of scale from 32 to 64 bit implies a broadening of ARM's target market from (mostly) embedded devices to address the requirements of high end consumer devices and servers. The 64 bit mode (AArch64) programming model is significantly different from the existing 32 bit model. If ARM's change of direction does indeed grab a significant share of this market then there are two corresponding implications for the Free Java community. We need a high quality free Java implementation to ensure that the market is not colonised solely by commercial Java vendors. We need to provide this implementation from scratch rather than try to modify existing 32 bit Java implementations. Red Hat has decided to port OpenJDK to AArch64 precisely to meet these implications head on.

This talk will describe the significant progress we have made in porting OpenJDK to AArch64 since the project began in earnest in July 2012, even though real hardware is not yet available and will not be for many months to come.

During the talk we will:

outline our plan for converting the runtime JIT components of OpenJDK to generate AArch64 code -- the (generated AArch64 code) template interpreter and the C1/C2 JIT compilers

explain how we have already managed to execute and debug generated ARM code using our own ARMv8 functional simulator integrated into an x86 JVM

display execution of a Java program using the template interpreter running on our simulator

show both ARM instruction-level and Java bytecode-level stepping and debugging of generated code within gdb

Other people: Andrew Haley

The Hotspot/OpenJDK Java agent capability and its associated java.lang.instrument API provide support for runtime bytecode transformation, either initially at class load time or, since JDK6, retrospectively after classes have been loaded and instantiated. This API has been adopted as a de facto standard by several other industrial strength JVMs. The uses of this API extend far beyond simple code instrumentation and suggest that more widespread adoption of the OpenJDK Java agent model and use of Java agents is highly desirable. Byteman is a Java agent program and suite of associated tools which supports tracing, monitoring and testing of Java applications via bytecode transformation. This has many advantages over conventional approaches, in particular being much more flexible and far less invasive. This talk will demonstrate Byteman in action showing you how to install and run it both standalone from the java command line and integrated with the JUnit and TestNG test frameworks driven from ant or maven. The examples progress from injecting simple debug trace to displaying a timing bug in a multi-threaded application. Along the way you should learn how Java agent programs work and how much freedom they have to manipulate the JVM runtime. I hope to encourage many of you to use Byteman and to contribute suggestions for new features. Also, maybe a few of you will be inspired to implement your own agent programs or to provide support for agents in other JVMs.