readme/bench: re-measure everything, and move workload 2 to Java 28

The performance tables were from the pre-mimalloc build and workload 2 was the
JDK 26 image — stale on both counts. Re-ran the whole matrix in one session on
the same host (all tools on OpenJDK 27, -Xmx8g), and the script now targets the
NEWEST JDK's module image (28 EA, 27,766 entries -> 15,039 units):

  rt.jar (12,609 units)      jcdc 3.6 s / 684 MB   (single-thread 12.0 s / 458 MB)
                             Vineflower 24.7 s, CFR 51.9 s, Procyon 108.8 s,
                             fernflower 208.6 s   (2.2-8.6 GB peak)
  Java 28 image (15,039)     jcdc 6.2 s / 945 MB   (single-thread 31.6 s / 568 MB)
                             CFR 144.7 s, fernflower 497.5 s, Procyon 725.2 s,
                             Vineflower: cannot finish

jcdc is ~6.8x Vineflower, ~14x CFR, ~30x Procyon and ~57x fernflower on
rt.jar, and ~23x / ~80x / ~117x on the Java 28 image; the peak-RSS gap is
2.3x-19x. Even single-threaded it beats every JVM tool here.

The Vineflower footnote was re-probed rather than carried over: at 8 g it
catches 194 per-class `Java heap space` errors and writes nothing in 300 s; at
16 g the heap holds but it still writes nothing in 7 minutes (>= 9 GB RSS);
the 32 g / 40-minute data point is the earlier probe on a same-size image.

Verified the harness itself while doing this: the four tool jars are back in
/tmp/bench_tools (procyon 2,004,704 bytes = the same release asset as before)
and `bench.sh` points at corpus/jdks/jdk28.

Author: ejfkdev

README.md

@@ -36,56 +36,59 @@ fresh Rust implementation.
 
 Whole-SDK benchmarks on two workloads — every class in **Java 8's `rt.jar`**
 (20,413 class entries → 12,609 emitted units) and **every class of the newest
-JDK, Java 26**. (JDK 9+ has no `rt.jar`: the boot classpath became the module
-image `lib/modules`, so workload 2 is that image's complete class set — all
-68 modules, 27,855 entries → 15,231 units — extracted with `jimage`.) Host:
-Apple M5 Pro (18 cores, 48 GB), macOS. All Java tools run on the same JVM
-(OpenJDK 26) with a uniform `-Xmx8g` heap; each tool gets one
+JDK, Java 28 (early access)**. (JDK 9+ has no `rt.jar`: the boot classpath
+became the module image `lib/modules`, so workload 2 is that image's complete
+class set — all 68 modules, 27,766 entries → 15,039 units — extracted with
+`jimage`.) Host: Apple M5 Pro (18 cores, 48 GB), macOS. All Java tools run on
+the same JVM (OpenJDK 27) with a uniform `-Xmx8g` heap; each tool gets one
 `/usr/bin/time -l` run (wall time + peak RSS) after jcdc has warmed the page
 cache. Reproduce with [`scripts/bench.sh`](scripts/bench.sh).
 
 **Workload 1 — `rt.jar` (JDK 8, 12,609 units):**
 
 | Tool | Wall time | Peak RSS | Units emitted |
 |---|---:|---:|---:|
-| **jcdc** (parallel — default, 1 worker/core) | **6.0 s** | **788 MB** | 12,609 |
-| jcdc (`JCDC_THREADS=1`, single-threaded) | 24.1 s | 493 MB | 12,609 |
-| Vineflower 1.11.1 | 38.5 s | 8,765 MB | 12,609 |
-| CFR 0.152 | 87.3 s | 4,242 MB | 12,609 |
-| Procyon 0.6.0 | 172.8 s | 2,282 MB | 12,586 |
-| fernflower (JetBrains) | 297.2 s | 2,438 MB | 12,609 |
+| **jcdc** (parallel — default, 1 worker/core) | **3.6 s** | **684 MB** | 12,609 |
+| jcdc (`JCDC_THREADS=1`, single-threaded) | 12.0 s | 458 MB | 12,609 |
+| Vineflower 1.11.1 | 24.7 s | 8,633 MB | 12,609 |
+| CFR 0.152 | 51.9 s | 4,516 MB | 12,609 |
+| Procyon 0.6.0 | 108.8 s | 2,218 MB | 12,586 |
+| fernflower (JetBrains) | 208.6 s | 2,639 MB | 12,609 |
 
-**Workload 2 — JDK 26 runtime image (`lib/modules`, 15,231 units):**
+**Workload 2 — Java 28 runtime image (`lib/modules`, 15,039 units):**
 
 | Tool | Wall time | Peak RSS | Units emitted |
 |---|---:|---:|---:|
-| **jcdc** (parallel — default) | **17.9 s** | **1,052 MB** | 15,231 |
-| jcdc (`JCDC_THREADS=1`, single-threaded) | 68.0 s | 672 MB | 15,231 |
-| CFR 0.152 | 120.8 s | 8,171 MB | 15,235 |
-| fernflower (JetBrains) | 409.5 s | 6,082 MB | 15,231 |
-| Procyon 0.6.0 | 623.2 s | 4,538 MB | 15,233 |
-| Vineflower 1.11.1 † | capped at 300 s | 8,821 MB | 0 |
-
-† Vineflower **cannot finish this workload**: `scripts/bench.sh` climbs a heap
-ladder (8 g → 16 g → 32 g) precisely because this image defeats it — at 8 g and
-16 g it catches hundreds of per-class `Java heap space` errors and writes
-nothing, and at 32 g it was still running at a 40-minute cap (16.9 GB peak RSS,
-zero files). It does finish the core module alone (`java.base`, 7,422 entries)
-with a 16 g heap in 41.5 s — still slower than jcdc's whole-image run.
+| **jcdc** (parallel — default) | **6.2 s** | **945 MB** | 15,039 |
+| jcdc (`JCDC_THREADS=1`, single-threaded) | 31.6 s | 568 MB | 15,039 |
+| CFR 0.152 | 144.7 s | 8,245 MB | 15,012 |
+| fernflower (JetBrains) | 497.5 s | 5,108 MB | 15,039 |
+| Procyon 0.6.0 | 725.2 s | 6,232 MB | 15,011 |
+| Vineflower 1.11.1 † | capped at 300 s | 8,707 MB | 0 |
+
+† Vineflower **cannot finish this workload**, which is why `scripts/bench.sh`
+climbs a heap ladder (8 g → 16 g → 32 g): at **8 g** it catches 194 per-class
+`Java heap space` errors and writes no file in 300 s; at **16 g** the heap
+holds but it still writes nothing in 7 minutes (≥ 9 GB RSS); a previous **32 g**
+probe on a same-size image was still running at the 40-minute cap (16.9 GB
+peak, zero files). It does finish the core module alone (`java.base`, 7,422
+entries) with a 16 g heap in 41.5 s — still slower than jcdc's whole-image
+run.
 
 Even **single-threaded**, jcdc finishes both workloads faster than every JVM
-tool here (24.1 s vs Vineflower's 38.5 s on `rt.jar`), and its whole-run peak
-RSS (**493–1,052 MB** against **2.3–8.8 GB** for the JVM tools) is 2.2×–17.8×
-smaller. With its default parallel pipeline it is ~6.4× faster than
-Vineflower, ~14× CFR, ~29× Procyon and ~49× fernflower on `rt.jar`, and ~6.7×
-(CFR) / ~23× (fernflower) / ~35× (Procyon) faster on the JDK 26 image.
-Emitted-unit counts differ slightly between tools: jcdc folds `$`-named hidden
-classes into their family file (and emits `module-info.java`), while Procyon
-skips `package-info` files (−23 on `rt.jar`). (jcdc runs with `-cp <jar>` for
-full type context; the JVM tools resolve from the input jar itself.)
+tool here (12.0 s vs Vineflower's 24.7 s on `rt.jar`), and its whole-run peak
+RSS (**458–945 MB** against **2.2–8.7 GB** for the JVM tools) is 2.3×–19×
+smaller. With its default parallel pipeline it is ~6.8× faster than
+Vineflower, ~14× CFR, ~30× Procyon and ~57× fernflower on `rt.jar`, and
+~23× (CFR) / ~80× (fernflower) / ~117× (Procyon) faster on the Java 28
+image. Emitted-unit counts differ slightly between tools: jcdc folds `$`-named
+hidden classes into their family file (and emits `module-info.java`), while
+Procyon skips `package-info` files (−23 on `rt.jar`). (jcdc runs with
+`-cp <jar>` for full type context; the JVM tools resolve from the input jar
+itself.)
 
 Times move a few tens of percent between sessions on this machine; the rows in
-each table are from one run (2026-09-15, jdc-core-based jcdc), so the ratios
+each table are from one run (2026-10-24, mimalloc-based jcdc), so the ratios
 are what matters.
 
 ## Install

README.zh.md

@@ -31,54 +31,55 @@ Java 源码。设计参考了 fernflower/Vineflower、garlic、CFR、Procyon、K
 ## 性能对比
 
 两组整包 SDK 基准——**Java 8 `rt.jar`** 全量 class（20,413 个 class 条目 →
-12,609 个编译单元）与**最新 JDK（Java 26）的全部 class**。（JDK 9 起
+12,609 个编译单元）与**最新 JDK（Java 28 早期访问版）的全部 class**。（JDK 9 起
 `rt.jar` 已不存在：boot classpath 变成了模块镜像 `lib/modules`，因此负载 2
-取该镜像的完整 class 集合——全部 68 个模块、27,855 个条目 → 15,231 个编译
+取该镜像的完整 class 集合——全部 68 个模块、27,766 个条目 → 15,039 个编译
 单元，用 `jimage` 提取。）测试机：Apple M5 Pro（18 核 / 48GB）/ macOS。
-所有 Java 工具统一跑在同一 JVM（OpenJDK 26）、统一 `-Xmx8g` 堆；jcdc 先跑
+所有 Java 工具统一跑在同一 JVM（OpenJDK 27）、统一 `-Xmx8g` 堆；jcdc 先跑
 预热页缓存，之后每个工具 `/usr/bin/time -l` 计时一次（墙钟 + 峰值 RSS）。
 复现脚本：[`scripts/bench.sh`](scripts/bench.sh)。
 
 **负载 1 —— `rt.jar`（JDK 8，12,609 个编译单元）：**
 
 | 工具 | 墙钟时间 | 峰值内存 | 产出文件 |
 |---|---:|---:|---:|
-| **jcdc**（并行——默认，每核 1 worker） | **6.0 秒** | **788 MB** | 12,609 |
-| jcdc（`JCDC_THREADS=1` 单线程） | 24.1 秒 | 493 MB | 12,609 |
-| Vineflower 1.11.1 | 38.5 秒 | 8,765 MB | 12,609 |
-| CFR 0.152 | 87.3 秒 | 4,242 MB | 12,609 |
-| Procyon 0.6.0 | 172.8 秒 | 2,282 MB | 12,586 |
-| fernflower（JetBrains） | 297.2 秒 | 2,438 MB | 12,609 |
+| **jcdc**（并行——默认，每核 1 worker） | **3.6 秒** | **684 MB** | 12,609 |
+| jcdc（`JCDC_THREADS=1` 单线程） | 12.0 秒 | 458 MB | 12,609 |
+| Vineflower 1.11.1 | 24.7 秒 | 8,633 MB | 12,609 |
+| CFR 0.152 | 51.9 秒 | 4,516 MB | 12,609 |
+| Procyon 0.6.0 | 108.8 秒 | 2,218 MB | 12,586 |
+| fernflower（JetBrains） | 208.6 秒 | 2,639 MB | 12,609 |
 
-**负载 2 —— JDK 26 运行时镜像（`lib/modules`，15,231 个编译单元）：**
+**负载 2 —— Java 28 运行时镜像（`lib/modules`，15,039 个编译单元）：**
 
 | 工具 | 墙钟时间 | 峰值内存 | 产出文件 |
 |---|---:|---:|---:|
-| **jcdc**（并行——默认） | **17.9 秒** | **1,052 MB** | 15,231 |
-| jcdc（`JCDC_THREADS=1` 单线程） | 68.0 秒 | 672 MB | 15,231 |
-| CFR 0.152 | 120.8 秒 | 8,171 MB | 15,235 |
-| fernflower（JetBrains） | 409.5 秒 | 6,082 MB | 15,231 |
-| Procyon 0.6.0 | 623.2 秒 | 4,538 MB | 15,233 |
-| Vineflower 1.11.1 † | 300 秒时封顶 | 8,821 MB | 0 |
-
-† Vineflower **跑不完这组负载**：`scripts/bench.sh` 之所以要爬堆阶梯
-（8g → 16g → 32g）就是被这组负载逼出来的——8g/16g 下逐类捕获 `Java heap
-space`、一个文件都写不出，32g 跑满 40 分钟封顶时仍在运行（峰值 16.9 GB、
-0 个文件）。它单独跑核心模块 `java.base`（7,422 个条目）可以完成：16g 堆
-41.5 秒——但仍慢于 jcdc 跑完整镜像。
+| **jcdc**（并行——默认） | **6.2 秒** | **945 MB** | 15,039 |
+| jcdc（`JCDC_THREADS=1` 单线程） | 31.6 秒 | 568 MB | 15,039 |
+| CFR 0.152 | 144.7 秒 | 8,245 MB | 15,012 |
+| fernflower（JetBrains） | 497.5 秒 | 5,108 MB | 15,039 |
+| Procyon 0.6.0 | 725.2 秒 | 6,232 MB | 15,011 |
+| Vineflower 1.11.1 † | 300 秒时封顶 | 8,707 MB | 0 |
+
+† Vineflower **跑不完这组负载**，`scripts/bench.sh` 的堆阶梯（8g → 16g →
+32g）就是为它设的：**8g** 下逐类捕获 194 次 `Java heap space`、300 秒内
+一个文件都没写出；**16g** 堆不再耗尽，但 7 分钟内依旧 0 文件（RSS ≥ 9 GB）；
+早前在同一规模的镜像上试过 **32g**，跑满 40 分钟封顶时仍在运行（峰值
+16.9 GB、0 个文件）。它单独跑核心模块 `java.base`（7,422 个条目）可以完成：
+16g 堆 41.5 秒——但仍慢于 jcdc 跑完整镜像。
 
 即便**单线程**，jcdc 跑完两组负载也比这里所有 Java 工具快（`rt.jar` 上
-24.1 秒 vs Vineflower 38.5 秒），整轮峰值内存（**493–1,052 MB**，对比
-Java 工具的 **2.3–8.8 GB**）低 2.2×–17.8×。默认并行管线下：`rt.jar` 上比
-Vineflower 快约 6.4 倍、比 CFR 快约 14 倍、比 Procyon 快约 29 倍、比
-fernflower 快约 49 倍；JDK 26 镜像上比 CFR 快约 6.7 倍、比 fernflower 快
-约 23 倍、比 Procyon 快约 35 倍。各工具产出文件数的细微差异来自归类口径：
+12.0 秒 vs Vineflower 24.7 秒），整轮峰值内存（**458–945 MB**，对比
+Java 工具的 **2.2–8.7 GB**）低 2.3×–19×。默认并行管线下：`rt.jar` 上比
+Vineflower 快约 6.8 倍、比 CFR 快约 14 倍、比 Procyon 快约 30 倍、比
+fernflower 快约 57 倍；Java 28 镜像上比 CFR 快约 23 倍、比 fernflower 快
+约 80 倍、比 Procyon 快约 117 倍。各工具产出文件数的细微差异来自归类口径：
 jcdc 把 `$` 命名的隐藏类折叠进所属族文件（并输出 `module-info.java`），
 Procyon 则跳过 `package-info` 文件（`rt.jar` 上少 23 个）。（jcdc 带
 `-cp <jar>` 提供完整类型上下文；Java 工具从输入 jar 自行解析。）
 
 同一台机器不同时段跑，绝对秒数会有几十个百分点的波动；每张表内的数据取自
-同一次运行（2026-09-15，基于 jdc-core 的 jcdc），看比值更有意义。
+同一次运行（2026-10-24，采用 mimalloc 分配器的 jcdc），看比值更有意义。
 
 ## 安装
 

scripts/bench.sh

@@ -5,12 +5,12 @@
 #
 # Workloads:
 #   1. jdk8 rt.jar       — 20,413 class entries (12,609 top-level units)
-#   2. jdk26 full image  — every class of the newest JDK, i.e. the post-JDK8
+#   2. jdk28 full image  — every class of the newest JDK, i.e. the post-JDK8
 #      successor of rt.jar (JDK 9+ has no rt.jar: the boot classpath moved
 #      into the module image lib/modules). Build it with:
-#        jdk26/bin/jimage extract --dir X jdk26/lib/modules
+#        jdk28/bin/jimage extract --dir X jdk28/lib/modules
 #        for m in X/*/; do rsync -a --exclude module-info.class "$m" Y/; done
-#        (cd Y && jar cf jdk26-full.jar .)     # 27,855 classes
+#        (cd Y && jar cf jdk28-full.jar .)     # 27,766 classes
 #      (module-info.class is dropped: 68 modules share that one path.)
 #
 # Tools (jars in /tmp/bench_tools, or set BENCH_TOOLS):
@@ -23,7 +23,7 @@
 # /usr/bin/time -l (wall + peak RSS). jcdc additionally runs with
 # JCDC_THREADS=1 for an honest single-thread comparison. fernflower emits a
 # JAR of sources for jar input — it is unpacked (untimed) for counting.
-# Vineflower exhausts an 8g heap on the jdk26 image (it catches the per-class
+# Vineflower exhausts an 8g heap on the full JDK image (it catches the per-class
 # OutOfMemoryError and writes nothing): it is retried up a heap ladder until
 # a run logs no "Java heap space", and the row is labelled with the heap that
 # finally worked. Each attempt is capped (it otherwise thrashes for tens of
@@ -32,19 +32,19 @@
 #   VINE_ATTEMPT_TIMEOUT=900    seconds per attempt (alarm(2) via perl)
 #
 # Set BENCH_WORKLOADS to run a subset, e.g.:
-#   BENCH_WORKLOADS=jdk26-all-modules zsh scripts/bench.sh
+#   BENCH_WORKLOADS=jdk28-all-modules zsh scripts/bench.sh
 
 set -u
 TOOLS=${BENCH_TOOLS:-/tmp/bench_tools}
 JAVA=/opt/homebrew/opt/openjdk/libexec/openjdk.jdk/Contents/Home/bin/java
 JCDC=/Users/e/Documents/project/jcdc/target/release/jcdc
 RT8=/Users/e/Documents/project/jcdc/corpus/jdks/jdk8/Contents/Home/jre/lib/rt.jar
-RT26=$TOOLS/jdk26-full.jar
+RT28=$TOOLS/jdk28-full.jar
 WORK=/tmp/bench_run
 XMX=-Xmx8g
 
 echo "host: $(uname -m), $(sysctl -n hw.ncpu) cores, $(($(sysctl -n hw.memsize)/1073741824))GB"
-echo "inputs: rt.jar(jdk8) $(unzip -l $RT8 | grep -c '\.class$') classes; jdk26-full.jar $(unzip -l $RT26 | grep -c '\.class$') classes"
+echo "inputs: rt.jar(jdk8) $(unzip -l $RT8 | grep -c '\.class$') classes; jdk28-full.jar $(unzip -l $RT28 | grep -c '\.class$') classes"
 echo
 
 report() { # label timefile outdir
@@ -67,7 +67,7 @@ bench_workload() { # workload-name input-jar
   /usr/bin/time -l env JCDC_THREADS=1 $JCDC -cp $IN $IN -o $WORK/$W-jcdc-seq > /dev/null 2> $WORK/$W-jcdc-seq.time
   report "jcdc (JCDC_THREADS=1)" $WORK/$W-jcdc-seq.time $WORK/$W-jcdc-seq
 
-  # Vineflower exhausts small heaps on the jdk26 image; climb the ladder
+  # Vineflower exhausts small heaps on the full JDK image; climb the ladder
   # until a run logs no "Java heap space", and label the row.
   local vf_label="vineflower 1.11.1"
   local vf_cap=${VINE_ATTEMPT_TIMEOUT:-900}
@@ -94,10 +94,10 @@ bench_workload() { # workload-name input-jar
   report "procyon 0.6.0" $WORK/$W-procyon.time $WORK/$W-procyon
 }
 
-for w in ${=BENCH_WORKLOADS:-rt-jar-jdk8 jdk26-all-modules}; do
+for w in ${=BENCH_WORKLOADS:-rt-jar-jdk8 jdk28-all-modules}; do
   case $w in
     rt-jar-jdk8) bench_workload rt-jar-jdk8 $RT8 ;;
-    jdk26-all-modules) bench_workload jdk26-all-modules $RT26 ;;
+    jdk28-all-modules) bench_workload jdk28-all-modules $RT28 ;;
     *) echo "unknown workload: $w" >&2; exit 1 ;;
   esac
 done