A tour of Java and the JVM

Java
And the Java Virtual Machine

What is Java?
• Language
• Platform

What’s a Java Platform?
• Enables you to develop and run code on varied hardware and OSes
• API specification
• Runtime environment (JRE)
• Libraries (which implement the platform API)
• Execution engine (VM)
• Development kit (JDK)
• Includes JRE (above)
• Compiler, debugger, profiler, disassembler…

Show me some Java Platforms
• Java SE (Standard Edition)
• Jakarta EE (Enterprise Edition)
• Open-sourced to the Eclipse Foundation
• Oracle is keeping the Java EE trademark
• Java ME (Micro Edition)
• Mobile devices
• Java Card
• Embedded devices, IoT
• Security-sensitive applications

Diagram of the Java SE Platform
• (Next slide)

What’s Jakarta EE?
• Java SE + specs and APIs for “enterprise” features
• Servlet (handle a client request, frequently HTTP)
• JPA (map JVM classes to database tables)
• JTA (transactions)
• JAX-RS (describe a RESTful web service)
• JAXB (un)marshalling of JSON, XML
• A Jakarta EE application server provides libraries fulfilling these APIs
• Only a handful of servers are certified as complete implementations
• There’s a (smaller) “Web Profile” with the bits people actually use

Do I need Jakarta EE?
• You could try your luck with a server that’s not certified as compatible
• TomCat remains popular, and was once certified
• You can cherry-pick the bits you want
• If you like JPA, you can have it (e.g. via Hibernate)
• You can disagree on some design points (see Spring)
• Building to a standard may protect you from vendor lock-in
• Beware drama: Oracle has restricted Eclipse’s use of trademarks
• Jakarta EE will be forced to make a big breaking change to rename packages

What’s the deal with Spring?
• Application framework
• Frequently served via an application server (e.g. TomCat)
• Spring integrates with some Jakarta EE specs
• Servlet, Bean Validation, JPA
• Differs philosophically in some places
• Spring MVC instead of JAX-RS for describing REST APIs
• “Controllers” rather than “Resources”
• You can still use JAX-RS if you want
• Jackson/Gson for (un)marshalling
• You can still use JAX-B if desired

Breaking news (May 2019)
• .NET Core now has most capabilities of .NET Framework 4.8
• .NET Framework is now deprecated
• .NET Core is rebranded as .NET
• Skips version 4
• So now we’re on .NET 5
• The upcoming slides were once correct

In case any of this sounds familiar…
Java SE .NET
Bytecode format Java bytecode CIL (e.g. MSIL)
Execution engine JVM VES (e.g. CLR)
Standard library Java SE APIs .NET Standard
Extended library Java EE APIs Additional APIs within .NET Core / .NET
Framework

Differences between .NET and Java Platform
• Bytecode-compatibility
• Old Java bytecode will run on new JVMs
• .NET bytecode breaks forward-compatibility to enable new features
• Linking
• Java “links” via an execution engine option (classpath)
• .NET libraries are dynamically linked, and can also load assemblies at runtime
• Execution
• Java has no executable; main class is an argument to execution engine
• .NET executables are libraries plus metadata

Differences between .NET and Java Platform
• Generics
• Java bytecode has no concept of generics (compilers “erase” them)
• Generics exist at runtime in .NET bytecode, and can be reified
• Special features supported in .NET bytecode
• Value types, stackalloc, pointers
• Move program counter / time-travel debugging
• JIT
• JVM JIT implementations use ambitious and complex optimizations
• .NET JIT is simpler. Performance through language features instead

Aside: .NET Framework vs .NET Core
• Original .NET specification was coupled to Windows and IIS
• Same GC and JIT (RyuJIT), same base class libraries (.NET Standard)
• Core is refactored to be modular and with fewer dependencies
• Core provides .NET Native; ahead-of-time compile CIL to native code
• Core Lacks features like Application Domains, Code Access Security
• Both implement Microsoft’s Common Language Infrastructure
• Program structure
• CIL bytecode format (e.g. MSIL)
• Virtual Execution System (e.g. CLR)

Aside: Mono
• An open-source implementation of .NET Framework
• Cross-platform
• Microsoft-sponsored non-Microsoft project
• Supported by Xamarin… who were bought by Microsoft
• Implements Microsoft’s specifications for C# and the CIL
(standardized by ECMA and ISO)
• Pretty cool until .NET Core was announced

Java is a poor man’s Docker
• Application servers (e.g. Tomcat) are basically k8s worker nodes
• JRE is basically a Container OS
• JVM is basically runc
• Java SE APIs are basically system libraries
• EAR/WAR artefacts are basically Container Images
• Compile your application once, deploy anywhere

Method signatures
• These impossible classes are possible in JVM bytecode, but not Java
• Overload method on return type
• Two fields with same name (but different types)
class C {
void a(String s) {}
int a(String s) { return 0; }
}
class C {
int a;
String a;
}

JVM for ultra low-latency computing
• Industry will pay $150k/month for a 3ms edge on the competition
• JVM GC pauses are frequently bigger than this
• Consider a Direct Market Access application
• Parse, validate, serialize message, check risk, read market data, serialize, send
• JVM can do this in ~10 microsecs, just as fast as C/C++
• Admittedly you have to write very non-idiomatic code, and complete warmup
• FPGA ~1 microsec
• ASIC ~400 nanosecs
• Python 50x slower

Should I run Java on the JVM?
1. Should I run Java on the JVM?
2. Should I run Java on the JVM?

Sun/Oracle Hotspot JVM JIT
• Method inlining, loop unrolling
• On-stack replacement
• Jump from interpreted code to JIT’d equivalent whenever code becomes hot
• Escape analysis
• Object fields are replaced with scalar values, avoiding heap allocation
• Monomorphic dispatch (avoid vtable lookup)
• Intrinsics (replace method with something more native)
• Dynamic deoptimization
• As access patterns change or new classes loaded: undo and try again

• Two compilers, tiered compilation (as of Java 7)
• C1 (Client)
• Fast startup
• Emits simple native code
• Still faster than executing bytecode in an interpreter
• C2 (Server)
• Generates better native code
• Decides how best to optimize based on execution profiles
• May frequently de-optimize
• Old, complex C++ codebase (needs replacing – more on this later)

• Tiered compilation
• Level 0 – interpreted code
• Level 1 – simple C1 compiled code (with no profiling)
• Level 2 – limited C1 compiled code (with light profiling)
• Level 3 – full C1 compiled code (with full profiling)
• Level 4 – C2 compiled code (uses profiling data from previous steps)
• Usually 0 -> 3 -> 4
• More complex code warrants more profiling, compilation

Sun/Oracle Hotspot JVM GC
• G1 (Java 8)
• Specify your latency requirements (“20 ms is the longest I’d wait for GC”)
• ZGC (Java 11)
• Low (<10ms) pause times even on multi-terabyte heaps
• Future support: multi-tiered heaps (hot objects in DRAM, cold in NVMe flash)
• Heap compression
• Pointer colouring (sell more SPARC machines)
• Shenandoah (Java 12)
• Low, constant pause time
• Most work done concurrently

Dalvik
• Google’s implementation of JVM for Android
• Caused Oracle to sue Google for 9 years (so far)
• Uses registers as primarily unit of data-storage instead of stack
• Avoid instruction dispatch, unnecessary memory access
• Higher semantic density per instruction
• 30% fewer instructions, 35% fewer code units
• 35% more bytes in instruction stream (but we consume two at a time)
• Combines .class files into .dex (Dalvik Executables)
• De-dupes any repeated information, saving 50% space

OpenJDK vs Oracle JDK
• Around Java SE 7, various JVMs converged.
• Oracle provided some extra ”commercial features”
• Incident analysis
• Font rendering
• Class sharing (for faster startup, smaller footprint)
• ZGC garbage collector
• For Java 11, Oracle upstreamed these. Basically the same now.
• Oracle JDK is (now) commercial
• OpenJDK is (now) provided by Red Hat (previously Oracle)

Hipster JVMs
• Amazon Corretto
• Zero-cost LTS
• Azul Zing
• Faster startup (saves previously-used JIT profile for re-use)
• Falcon JIT (high-performance server JIT based on LLVM)
• C4 garbage collector (concurrent, compacting, no GC pause)
• TeaVM
• AoT compiles JVM bytecode to JS or WebAssembly
• GraalVM (more on this later)

Hipster JVMs
• Or use the CLR
• Not standards-compliant
• Due to native interface

JavaScript on the JVM
• Rhino; Java 1.4/1997 – part of an all-Java Netscape Navigator
• JVM JIT outperformed C++, but memory leaky and slow startup
• Interpreted mode was
• Nashorn; Java 8/2011
• “Several orders of magnitude” faster
• Deprecated in Java 11 because JavaScript was changing too fast to keep up
• GraalVM
• Suggested as a way to replace Nashorn
• More on this later

Other JVM languages
• Scala
• Has a “criticism” section on Wikipedia
• Kotlin
• Made by JetBrains (i.e. IntelliJ, Resharper)
• Coroutines, generators, safe navigation, elvis ?:, reification, data classes, FP
• Fast compilation (aiming to be as fast as Java, and not slow like Scala)
• Compiles to JS and native code
• Clojure
• Lisp, REPL
• Compiles to JS too

Other JVM languages
• Groovy
• Used for DSLs (for example data engineering)
• Used for Gradle config (now being replaced by Kotlin)
• JRuby
• Contributed invokedynamic instruction to JVM (not used by Java!)
• Dynamically changes classes and methods at runtime
• Outperforms real Ruby, especially in concurrent code (thanks to JVM threads)
• Jython
• Sounds like it’s for people who concede JVM has good libraries, but hate Java

GraalVM
• Oracle Labs research project based on JDK 8
• Universal Virtual Machine
• JVM-based languages
• LLVM-based languages
• Node.js, Python, Ruby, R
• JIT and AoT compiler (Graal)
• Language AST interpreter (Truffle)
• Enables language-agnostic debugger, profiler, heap viewer
• Compilation to native images, with minimal runtime (SubstrateVM)

GraalVM – JIT Compiler (Graal)
• Written in Java
• Compile Java using Java, rather than C++ (“Java-on-Java”)
• Generates native code (like LLVM/Clang does)
• Integrates into any JDK that supports JVM CI (Compiler Interface)
• JVM CI lets a JVM use as its dynamic compiler: any compiler written in Java
• Oracle Labs has backported JVM CI to JDK 8
• JVM CI ships with JDK 11 proper
• Replace Hotspot JIT’s C2 compiler
• Optimized performance for Truffle-based languages running on JVM

GraalVM – Ahead-of-time compilation
• Uses Graal compiler too
• Includes minimal runtime, SubstrateVM
• Smaller memory footprint
• Zero-dependency native image
• Tiny filesize (Spring web application + runtime in 36MB)
• Instant startup (deploy Spring web application in about 50ms)
• Produce native libraries (for your other native code to link to)
• Optionally include Graal compiler to complement AoT with JIT
• Build image with profile-guided optimizations from previous runs

GraalVM – Truffle
• Library for building programming language implementations
• Describe language as an interpreter for a self-modifying Abstract Syntax Tree
• Low-overhead language interop
• Performance matches or exceeds other language runtimes
• General instrumentation framework
• Multi-language debugging (via Chrome DevTools!)
• Profiling
• Heap view

GraalVM – LLVM
• GraalVM implements LLVM’s LLI tool
• Directly execute programs from LLVM bitcode
• First you must compile any program (e.g. C, C++, Rust) to LLVM IR
• Note: platform-dependent
• LLI interprets the IR, then dynamically compiles hot parts using Graal
• Enables seamless interop with other dynamic languages in GraalVM

GraalVM – Database embed
• Oracle Database, MySQL
• Use GraalVM languages and modules… inside a SQL statement
• Write SELECT statements that:
• Classify whether a string is an email address
• Detect credit card brand

GraalVM – Performance
• Twitter cut their CPU usage by 13% by switching to GraalVM
• Across thousands of machines running thousands of JVMs
• See “Twitter’s Quest for a Wholly Graal Runtime”
• Better inlining, and across language boundaries
• Partial escape analysis
• Remove costly object allocations in more scenarios
• More aggressive speculative optimizations
• Full set of optimizations only available with Enterprise license!

Advantages compared to standard runtime
• Run Node.js with large-heap configuration and JVM’s GC
• V8 is tuned for browsers and small-heap scenarios
• Re-use libraries from Java, R, or Python… in Node.js
• Use Python for data science
• Use R for plotting graphs
• Use Java for Spark or Flink

A tour of Java and the JVM

Recommended

More Related Content

What's hot (19)

Similar to A tour of Java and the JVM (20)

Recently uploaded (20)

A tour of Java and the JVM

Editor's Notes