How a Two-Decade-Old Issue Still Haunts Software Scalability
summary
A JVM-level bug in the secondary super cache makes repeated interface checks catastrophically unstable: profiling found up to three billion type checks (about 800 million per interface) that serialized across cores and broke scaling on a 32‑core machine, so Drools fell behind a competitor that was ~4x faster. The fix uses a type-pollution agent (ByteBuddy) to surface hotspots, replaces costly instanceof on interfaces with checks on concrete/abstract types or virtual type methods, rewrites some hierarchies, and uncovers an assembly instruction that broke profilers; the patches improve but don’t fully eliminate the issue.
AI-written summary · about
chapters (18)
- 0:00Two-decade scalability issue
- 4:19Starting performance engineering
- 7:55Secondary supercache problem
- 10:00JVM type checks trigger cache instability
- 14:16Issue in Drools rule engine
- 15:57Type pollution agent to diagnose
- 17:46Fix: interface to concrete types
- 20:17Hibernate-inspired alternative fix
- 21:20Fixing generics-related type checks
- 23:06Simplify type hierarchies
- 24:30Hardware roots of supercache
- 27:21CPU cache lines amplify issue
- 31:58Profilers break and detect problem
- 35:30True vs false sharing effects
- 37:21Impact on Java apps and frameworks
- 38:25Workarounds and JDK fixes
- 40:17Results and backporting fixes
- 41:23Q&A
related talks
01h 00mon Java - Historical Oddities & Persistent Itches
54mJava performance techniques The cost of HotSpot runtime optimizations
01h 01mAn Introduction to JVM Performance
15mWell-Typed Programs Can Go Wrong: A Study of Typing-Related Bugs in JVM Compilers
52mFuture of Java
44mJava at Speed: Building a Better JVM.
59mAn Introduction to JVM Performance
35mJava at Speed: Building a Better JVM