When you evaluate a system with a garbage collector and want to understand its tail latency, you often see SPECjbb2015 or DaCapo used. While both offer corrective measures for coordinated omission, only SPECjbb2015 can run the workload generator and backend server in the same JVM, as well as separate them into different JVMs. This post is a deep dive that uses SPECjbb2015's flexibility to explore and highlight the risks of running the workload generator in the same JVM as the backend.

Imagine your company is managing a large-scale data processing system, and every second counts. You're constantly seeking ways to reduce latency and optimize performance. Now, consider the impact of speeding up thread monitoring on user CPU time by 20 times. The public standard in Linux for reading thread CPU time is the computational equivalent of printing a spreadsheet to paper, then scanning it with a camera, only to digitize it back into a spreadsheet just to read a value. It works, but it destroys throughput. I recently integrated a patch into OpenJDK that replaces this legacy logic with direct calls. The result is a 20x speedup for thread monitoring of user CPU time. Here is the story behind the optimization and why "everything is a file" isn't the right philosophy for performance.

A deep dive into JEP 500 and the Java Memory Model to understand the formal boundaries of 'final'. We examine JLS §17, unsafe publication, and why immutable fields can still appear mutable in concurrent environments.

Modern GCs often waste cycles moving objects that are reachable but effectively dead. We introduce Mark-Scavenge, a novel algorithm for ZGC that delays evacuation to let 'trash take itself out,' reducing dead object relocation by up to 91%.

In modern concurrent garbage collectors like ZGC, moving objects safely while the application is running requires significant CPU resources. But what if we could avoid moving objects that are about...

Signed integer overflow is Undefined Behavior in C. We examine how compilers like GCC leverage this specification to silently optimize away manual safety checks, potentially turning robust logic into critical security vulnerabilities.

An exploration of type system soundness. We demonstrate how TypeScript's design goal of JavaScript compatibility necessitates intentional unsoundness, allowing validly compiled code to violate its own type definitions at runtime.