Exploring Time-Space trade-offs for synchronized in Lilliput

TL;DR

The paper investigates time-space trade-offs for synchronized constructs in Project Lilliput to shrink object headers while preserving synchronized semantics. It evaluates three candidate locking algorithms—HashChains, HashChains+3, and CJM—against different waiting policies and measures performance with a micro-benchmark. Key contributions include detailed designs of per-object lock records in HashChains, a header-bits variant enabling a fast uncontended path in HashChains+3, and a CJM-based approach that relocates monitor state into MCS queue elements for a compact, FIFO-locking model. Empirical results show CJM-based approaches can match or approach HotSpot's synchronized performance while offering stronger space efficiency, highlighting practical implications for JVM synchronization under Lilliput.

Abstract

In the context of Project Lilliput, which attempts to reduce the size of object header in the HotSpot Java Virtual Machine (JVM), we explore a curated set of synchronization algorithms. Each of the algorithms could serve as a potential replacement implementation for the "synchronized" construct in HotSpot. Collectively, the algorithms illuminate trade-offs in space-time properties. The key design decisions are where to locate synchronization metadata (monitor fields), how to map from an object to those fields, and the lifecycle of the monitor information. The reader is assumed to be familiar with current HotSpot implementation of "synchronized" as well as the Compact Java Monitors (CJM) design and Project Lilliput.

Figures (3)

• Figure 1: Maximum Contention
• Figure 2: Moderate Contention
• Figure 3: Light Contention