CI Perf Lint

jvm-cds-opportunity-for-repeated-startup

What It Does

Detects Java repositories where short-lived JVM startup likely dominates CI runtime and suggests evaluating CDS/AppCDS or related startup amortization techniques.

Why It Matters

Each short-lived JVM invocation spends a significant fraction of wall time on class loading, bytecode verification, and JIT warmup. When CI pipelines repeatedly launch independent JVM processes (e.g. per-test-class forks, Gradle test executors, Maven Surefire forks), this overhead adds up.

Class Data Sharing (CDS/AppCDS) lets the JVM archive resolved class metadata so subsequent launches skip much of the class-loading phase. For repeated JVM startup patterns in CI, this can meaningfully reduce total workflow duration.

Triggers

Repository evidence (any of):

Workflow evidence (2+ occurrences across workflows):

Evidence is limited to non-release JVM steps: either repeated test commands or repeated direct java -jar/java -cp launches. Ordinary builds alone do not prove repeated short-lived test JVMs. Matrix boosts come from the JVM job, and diagnostics point at a relevant JVM command. CDS flags in JAVA_TOOL_OPTIONS, JDK_JAVA_OPTIONS, GRADLE_OPTS and MAVEN_OPTS are recognized.

Nested build roots referenced by workflow working directories or inline cd participate in JVM detection.

Non-Triggers

Severity

warning — exploratory performance opportunity

Score Boosters

Higher score when any of these are detected:

Advisory

CDS/AppCDS introduces archive generation and setup cost. The benefit depends on:

Always measure before and after. Compare total workflow duration, not isolated JVM startup latency.