Java

The JVM, JIT compilation, and GC

The JVM (Java Virtual Machine) is a stack-based virtual machine that executes Java bytecode. It provides: automatic memory management (garbage collection), JIT compilation (HotSpot compiles hot bytecode to native machine code), platform independence, and runtime security. The HotSpot JIT uses tiered compilation: first interpret bytecode (Tier 0), then compile with the C1 (client) compiler (fast, Tier 1-3), then the C2 (server) compiler with aggressive optimisations for hot methods (Tier 4). This gives fast startup and high peak performance.

Generics: type erasure

Java generics use type erasure: generic type parameters are checked at compile time but removed at runtime. At runtime, List<String> and List<Integer> are both just List. This means: you cannot do new T() or instanceof List<String> at runtime. The erasure decision was made for backward compatibility with pre-generics Java (Java 5 introduced generics in 2004). Kotlin and C# chose reified generics (kept at runtime) — a cleaner model.

// Generic method
public static <T extends Comparable<T>> T max(T a, T b) {
    return a.compareTo(b) > 0 ? a : b;
}

// Bounded wildcards
public static double sum(List<? extends Number> list) {
    return list.stream().mapToDouble(Number::doubleValue).sum();
}
// Accepts List<Integer>, List<Double>, etc.

// Type erasure — both are the same class at runtime
List<String> strings = new ArrayList<>();
List<Integer> ints = new ArrayList<>();
System.out.println(strings.getClass() == ints.getClass()); // true

Concurrency: threads and the java.util.concurrent package

Java has true multi-threading — threads run in parallel on multiple CPU cores, unlike Python's GIL. The java.util.concurrent package (added in Java 5) provides high-level concurrency utilities: ExecutorService (thread pools), Future<V>/CompletableFuture<V> (async computation), Lock/ReentrantLock (finer-grained than synchronized), ConcurrentHashMap, BlockingQueue.

Java 21 introduced virtual threads (Project Loom, JEP 444): lightweight JVM-managed threads that don't map 1:1 to OS threads. Virtual threads enable millions of concurrent I/O operations without the memory cost of OS threads (~1MB each). Platform threads are mapped to OS threads; virtual threads are multiplexed on a pool of carrier (platform) threads.

import java.util.concurrent.*;

// Thread pool
ExecutorService pool = Executors.newFixedThreadPool(4);
Future<Integer> future = pool.submit(() -> {
    // computation on background thread
    return 42;
});
int result = future.get(); // blocks until complete

// CompletableFuture — composable async
CompletableFuture.supplyAsync(() -> fetchUser(1))
    .thenApply(user -> user.getName())
    .thenAccept(name -> System.out.println("User: " + name));

// Virtual threads (Java 21+)
Thread.ofVirtual().start(() -> System.out.println("Virtual thread!"));
// Can create millions — each uses only ~KB of heap

Modern Java: records, sealed classes, pattern matching

JVM bytecode and the class file format

A Java .class file contains: a magic number (0xCAFEBABE), major/minor version numbers, a constant pool (strings, class references, method signatures), access flags, field/method descriptors, and the bytecode instructions for each method. The bytecode instruction set has ~200 opcodes: iload/istore (load/store int from stack frame), invokevirtual (virtual method dispatch), invokestatic (static method call), new/dup/invokespecial (object creation). The javap -c ClassName command disassembles bytecode.

Java Memory Model

The Java Memory Model (JLS §17) defines the happens-before relationship: actions in thread A happen-before all actions in thread B that observe their effects. Key rules: (1) program order — each action in a thread happens-before all subsequent actions in that thread; (2) monitor lock — an unlock happens-before every subsequent lock of the same monitor; (3) volatile — a write to a volatile variable happens-before every subsequent read of that variable. Without a happens-before relationship, there is no guarantee a thread sees another thread's writes — even on a modern CPU with cache coherency protocols. The JMM is formally defined in JLS §17.4.

Project Loom: virtual thread implementation

Virtual threads (JEP 444, Java 21) are implemented as continuations — resumable computations. When a virtual thread blocks on I/O, the JVM parks the continuation (saves its stack to heap memory) and frees the carrier thread for other virtual threads. When the I/O completes, the continuation is resumed on any available carrier thread. The carrier thread pool defaults to the number of CPU cores. This allows millions of virtual threads to coexist with only a small fixed number of OS threads — solving the C10k problem at the JVM level without async/await syntax changes.