[WIP] Speed up the Scala compiler on the `mill-libs-javalib` codebase by ~50% by lihaoyi · Pull Request #26025 · scala/scala3

lihaoyi · 2026-05-09T08:24:35Z

This PR vibe-optimizes the Scala compiler, running codex/claude in a loop over a few weeks, resulting in a ~50% speedup over the course of ~100 commits.

10x warmup runs 10x measurement runs

	Mean	Std Dev
Before	8801 ms/op	+/- 294
After	5681 ms/op	+/- 151

Speedup: 54%:
Time reduction: 35%

These numbers are running on my 2021 M1 Macbook Pro, and while they vary across benchmark runs overall it seems about there: speedup ranges from 45-55% running the benchmark over and over.

While it is a large number of commits, they are each relatively localized changes and should be reviewable for correctness individually, so it should be possible to review and merge this PR with some work. Each one is typically a single micro-optimization: hoisting/sharing of computed values, caching, and other straightforward micro-optimizations.

This benchmark uses compilation of mill-libs-javalib (the user-facing Mill API) and its upstream dependencies (totalling 364 files 32kLOC) as the workload, rather than bootstrapping scala-compiler, as mill-libs-javalib has a very different style of Scala: lots of macros, lots of third-party libraries, etc.. The individual commits are all done by claude and contain their individual reasoning and individual (noisy) benchmarks.

All existing tests pass

Major themes

Per-runId/period scalar caches for stable predicates and per-symbol lookups (derivesFrom, isStatic, NamedType.symbol, ThisType.cls, isBottom, empty-GADT).
Identity-eq short-circuits at map/copy/traversal entry points to skip dispatch when inputs are reference-identical.
Shape-based no-op skips (frozen, empty, NonMember, NoPrefix, leaf nodes, class tycons) that bypass setup the dominant case doesn't need.
Inlining synthetic by-name thunks to retire op$proxy frames in TypeMap/TypeAccumulator/AsSeenFromMap variance handling.
Cutting redundant denotation/info/symbol forces along resolution chains via reorder, threading, and gating.
Iterative loops + Array indexing replacing mutual recursion and List.drop(n).head walks.
Sharing one substitution map / adjuster per outer call instead of allocating fresh each iteration.
Hash-table tuning (prefilter, sizing, paged growth, EqHashMap.HashedOnly) for Uniques/WeakHashSet/EqHashMap.
Period-keyed caching of expensive denotation lookups (member cache, baseType, derivedSelect, asSeenFrom).
Allocation reduction via smaller eager buffers, lazy refs, stamp-based resets, and outermost-only traversals.

For review

mill-libs-javalib is normally built as separate smaller modules, but this PR consolidates all of that into one big compile for benchmarking

The first commit in this PR contains the bench-mill-javalib/ benchmarking and optimization scripts used to perform this benchmark, which contain the majority of the lines changed (~1k lines). These scripts:
- Download the mill-libs-javalib's source jar and unpack it
- Run JFR
- Nicely visualize the JFR profile data, etc..
They are throwaway vibe coded slop and can be removed before merging, since none of it is necessary for the optimizations to take effect, but I left it in the PR in case we want to keep it or some variant of it for others to pick up in future. They're written as Scala scripts, using a local Mill bootstrap script until Add Mill build #25970 lands we cannot easily write such scripts in Scala. They were originally in Python but ported to Scala due to poor performance.
The subsequent commits each contain a single optimization with the rationale for that optimization and measured before/after using JMH or JFR that demonstrates the improvement (total ~1000 lines).
- Each one should be self contained and reviewable on its own. This PR should be rebased/merged without squashing, as each commit contains useful information without mixing them together.
- Related commits are grouped together in the commit log, to make them easier to review in one pass, but mostly maintained as separate commits with separate profiling results and separate reasoning. Only a small number of especially overlapping commits were merged together

The best way to review this is probably to go through commit by commit in order and review the code change and commit message, leaving comments on each commit. Once done I can do a single cleanup pass to fix or remove any commits as necessary, whether code changes or benchmarking harness, and we can merge this without squashing preserving the original commits and commit messages containing reasoning and benchmarks

How much have you relied on LLM-based tools in this contribution?

Entirely vibe coded in ralph loops, with some human judgement. The prompt used is provided at bench-mill-javalib/prompt.md

How was the solution tested?

This branch was developed by hooking up claude or codex in a loop with JMH and JFR (loop-claude.sh and loop-codex.sh), and asking it to find potential performance optimizations over and over by cross-referencing the JFR profile with the source code, and validating these optimizations by looking for the expected % drop in the optimized methods JFR self/total times.

Notably, Codex seems better for this usage:

It is much better at following instructions, e.g. Claude has trouble spawning the right number of subagents, passing correct and complete instructions to subagents, formatting the commit message correctly, ensuring all heavy lifting is delegated to subagents rather than the top-level agent, etc.
It has a much more generous subscription quote, e.g. Claude20x's 5hr subscription can only do one iteration of loop-*.sh, whereas Codex20x can do 6-8 iterations
It is much more stable: Claude regularly hangs without noticing that a subagent has finished and it can proceed, or kills subagents prematurely due to thinking an async-await-ing subagent is idle, and all sorts of other harness problems unrelated to the model itself.

Each iteration using Codex typically takes 5-10 hours running 4x parallel on my macbook, which I leave running during the day and overnight

Profiling

JMH profiles are typically too noisy to measure the <1% drops in the total time taken for a compilation run, whereas the JFR profiles are fine grained enough that e.g. we can clearly see a method go from e.g. 0.5% of the profile to 0.2% and have confidence that the expected improvement materialized. In particular, JFR profiles %s do not seem heavily influenced by system load: running 1x parallel (uncontented) to 4x parallel (significantly overloaded) does not seem to significantly affect the std dev of the JFR profile %s, presumably because such system load affects the entire program equally

Each commit is profiled 5 times each time running 10 iterations (~1min of runtime) and we accept any change where the optimized methods show a reduction in %self or %total times more than their standard deviation between those 5 profiles.

Rejected commits are documented here #26091 for posterity, complete with their code changes and profiling numbers and analysis. The rejected branch does see a small speedup of ~4%, but given the number of commits it is difficult to identify where that speedup comes up and whether those changes can be included in this PR. The prompt instructs the agent to review both accepted and rejected commits each iteration before coming up with proposed optimizations.

As usual, there is no easy way to regression tests performance: it can only be maintained or improved by repeated or ongoing monitoring and improvement effort going forward

Correctness is validated via existing tests Tests to make sure nothing breaks.

He-Pin · 2026-05-09T19:21:38Z

 9. **Already-present fast-paths**: terminal type fast-paths in `TypeMap.mapOver` for `NoPrefix`/`ThisType`/`BoundType`/`NoType`/`ConstantType` were there before iter1. Don't add them again.
 10. **Intermittent `InvalidScalaInstance` / `IntStream/T` errors** in `__.compile` runs: a flaky daemon-side race when many modules build in parallel — has nothing to do with classpath logic. If you only see it in *one* sample of `measure-mill.sh` while four samples are clean, re-run; do NOT chase the false signal. Both errors cleared on retry without code change.
+11. **`__.compile` measurement variance is ±2-3s warm-steady** on this hardware. A change with 97% counter-confirmed dedup rate (iter18 _seenTopLevelType) measured 78.7-84.1s post-opt vs 80.4s baseline — algorithmic correctness verified, but wall-clock impact is below the noise floor (~1-2%). For dedup-style optimizations targeting already-cheap inner loops (a `markMemberRefSeen` returning false is itself ~5ns), the cost of the dedup probe may approximately match the saved work. Don't chase wall-clock confirmation past 5 samples; if borderline, ship the algorithmic improvement and move on.



Gedochao · 2026-05-11T07:58:49Z

cc @mbovel

mbovel · 2026-05-11T09:10:49Z

Benchmarks started. Workflow run.

Gedochao · 2026-05-11T09:13:56Z

So while this is perhaps interesting as an experiment, I'd like to raise that reviewing 2k lines worth of a vibe coded contribution is entirely unreviewable.

lihaoyi · 2026-05-11T09:14:00Z

Note that the benchmarks I'm running using Mill's code are very different from scala-compiler code. As an example, in Mill the inlining phase actually takes more time than the typer`

lihaoyi · 2026-05-11T09:15:01Z

@Gedochao most of the 2k lines is the benchmarking scripts, the actual code changes are pretty small and straightforward

lihaoyi · 2026-05-11T09:15:20Z

If you would like I can delete all the benchmarking scripts and it'll be like 200 lines or something

Gedochao · 2026-05-11T09:17:47Z

@Gedochao most of the 2k lines is the benchmarking scripts, the actual code changes are pretty small and straightforward

I'd ask @mbovel whether those benchmarks are worth considering against the benchmarks we do have.

How small are we speaking here? With 34 commits, I am very lost here.

lihaoyi · 2026-05-11T09:22:20Z

The current git diff main -w --numstat -- ':!bench-mill-javalib' shows 500 lines of code change, mostly semantics-preserving micro-optimizations.

It's obviously not ready to review yet, but once I'm done cleaning it up and making it reviewable should be a tractable amount of work on my side and result in a reviewable PR on yours.

Gedochao · 2026-05-11T09:24:38Z

500 lines might still be worth splitting down, if it's vibe coded performance fixes.

lihaoyi · 2026-05-11T09:25:40Z

Yes of course, hence the Draft label. When it's ready for review I'll press Ready for review haha

Gedochao · 2026-05-11T09:48:19Z

No worries, I just took a look at what's here right now and the thought of getting this reviewed filled me with dread. 😅
Don't mind me then, do continue.

SolalPirelli · 2026-05-11T11:22:20Z

+          while rest ne Nil do
+            s = include(s, rest.head)
+            rest = rest.tail
+          s


this seems like something the compiler could do?

@SolalPirelli the while loop thing is incidental, I think the main thing is that we avoid going through the def include = x match dispatch every element of the list, when we know that once we see the List[?] we know that all .tails will also be List[?] without needing to check if they are untpd.Modifiers or Positioned or whatever

ok that makes sense, I wonder if there's a way to refactor this method to not have the : Any arg, which indeed seems like a perf anti-pattern in general

bishabosha · 2026-05-12T09:01:13Z

do you think it would also be useful to bench memory usage, GC pressure?

mbovel · 2026-05-12T09:27:47Z

Benchmarks failed. Workflow run.

lihaoyi · 2026-05-12T09:53:12Z

@mbovel the benchmarks failed with The job has exceeded the maximum execution time while awaiting a runner for 24h0m0s, probably not related to the code in this PR

…eedup) TypeComparer.isBottom(tp) is tp.widen.isRef(NothingClass), and a single recur frame probes isBottom(tp1) at four sites across firstTry, secondTry, and thirdTryNamed. Each call recomputes tp.widen and walks baseClasses even though tp1 is identical across those points. This change adds a 1-slot comparer-local cache keyed on tp1 identity (eq) and routes the four sites through it. A recursive recur passes a different tp1, identity diverges, and the slot is overwritten on the next miss — no explicit invalidation needed. isBottom(tp2) at flagNothingBound and the two glb/lub call sites stay on the direct path. Safe because tp.widen × isRef(NothingClass) depends only on tp's static dealiased structure within a frame; classfile state does not change between the four probes. Expected changes: - TypeComparer.firstTry$1 tot% should improve: the LazyRef-branch isBottom(tp1) probe becomes an eq check after any earlier site populated the slot. - TypeComparer.secondTry$1 tot% should improve: the NamedType non-alias isBottom(tp1) probe reuses the cached result instead of re-walking widen + baseClasses. - TypeComparer.thirdTryNamed$1 tot% should improve: both TypeBounds and non-TypeBounds branches collapse to an eq check on cache hit. - TypeComparer.isBottom tot% should drop modestly: cache hits skip the call entirely. - Type.widen self% and tot% should stay flat: still called once per recur frame whenever no prior probe ran. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-1/run-0 → iter-1/run-22): 1. TypeComparer.firstTry$1 tot%: 14.63 → 14.14 (-0.49, 1.7σ) 2. TypeComparer.secondTry$1 tot%: 7.80 → 7.26 (-0.54, 1.6σ) 3. TypeComparer.thirdTryNamed$1 tot%: 2.97 → 2.79 (-0.18, 1.8σ) 4. TypeComparer.isBottom tot%: 0.35 → 0.30 (-0.05, 1.7σ) 5. Type.widen tot%: 2.78 → 2.71 (-0.07, 0.5σ) (Per-side stddev not retained from the original iter-1/run-22 measurement; σ values shown.) Estimated total speedup: 0.50 ± — (from rows 1, 2, and 3 above; uncertainty is unrecoverable from the source data because per-side stddev was not retained, only the combined σ per row) Accepted. All four target cascades (firstTry$1, secondTry$1, thirdTryNamed$1, isBottom) improve with σ ≥ 1.6, and Type.widen does not regress. The cache hits on the four shared probes within a recur frame structurally explain the consistent downward movement across the cascade.

TypeComparer.typeVarInstance now memoizes the most recent (TypeVar, Constraint) pair against the resulting tvar.underlying. The hot firstTry/secondTry TypeVar cases both call typeVarInstance, which for uninstantiated variables walks into OrderingConstraint.instType → entry; OrderingConstraint.instType self/tot is 0.11 / 0.26 in the baseline summary. The cache short-circuits to the previously computed type when the same tvar is probed against the same constraint instance. Every OrderingConstraint mutation (replace/add/remove/swapKey/withHard/etc.) returns a fresh instance, so an eq test on the current constraint suffices for invalidation in the same pattern used by the existing empty-GADT and last-binder caches. A permanent instantiation goes through instantiateWith, which immediately follows setPermanentInst with constraint.replace, so the constraint-identity check also covers the inst-field transition. Expected changes: - OrderingConstraint.instType self% and tot% should drop: repeated probes of the same TypeVar against the same constraint stop re-entering entry/typeVarOfParam. - TypeComparer.firstTry$1 tot% should improve: the tp2:TypeVar case short-circuits to the cached recur(tp1, cached) value. - TypeComparer.secondTry$1 tot% should improve: the symmetric tp1:TypeVar case shares the same one-slot cache. - OrderingConstraint.entry self% should stay near flat: instType's internal entry calls drop slightly but entry is called from many other sites, so the row movement is small. - No semantic regression expected: cache is invalidated by an eq test on the OrderingConstraint instance, which is replaced on every mutation that could change tvar.underlying. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-1/run-0 → iter-1/run-24): 1. TypeComparer.secondTry$1 tot%: 7.80 ± 0.13 → 7.38 ± 0.07 (-0.42, 3.2σ) 2. TypeComparer.firstTry$1 tot%: 14.63 ± 0.13 → 14.29 ± 0.13 (-0.34, 2.6σ) 3. OrderingConstraint.instType tot%: 0.26 ± 0.02 → 0.23 ± 0.02 (-0.03, 1.5σ) 4. OrderingConstraint.instType self%: 0.11 ± 0.01 → 0.10 ± 0.01 (-0.01, 1.0σ) 5. OrderingConstraint.entry tot%: 0.36 ± 0.06 → 0.35 ± 0.03 (-0.01, 0.2σ) Estimated total speedup: 0.34 ± 0.13 (from row 2 above; rows 1 and 3 cover the same TypeVar-instance probe path through the symmetric secondTry caller and the direct instType target, and rows 4 and 5 are the local target regression checks) Accepted. Both caller-cascade rows (firstTry$1 and secondTry$1 tot%) clear the threshold, the direct OrderingConstraint.instType tot% target moves in the same direction at 1.5σ, and entry stays flat — confirming the optimization removes redundant probe work without disturbing neighboring constraint accesses. Bootstrap compile succeeds.

…S info in compareNamed (est. 2.29% speedup) TypeComparer.isSubType accounts for ~15% total time; two adjacent hot points are the eagerness of tryBaseType for direct static class TypeRefs and the eager tp2.info force in compareNamed. The first change guards tryBaseType with derivesFrom for direct static class TypeRefs: successes return before constructing a base type, and guaranteed misses skip a failed lookup. The second change recognizes RHS TypeRef class symbols before forcing tp2.info and routes them through new compareKnownClass and thirdTryKnownClass helpers split out of the info-based path; aliases, bounds, FromJavaObject, and non-class refs still force info and use the old branch. Expected changes: - TypeComparer.isSubType, recur, compareNamed$1, and secondTry$1 tot% should improve: direct static class success and miss cases avoid unnecessary base-type construction or failed lookup work, and RHS class refs skip eager tp2.info before entering the class comparison path. - TypeComparer.thirdTryNamed$1 self% should improve: class comparison work moves out of the info-based NamedType third try. - TypeComparer.compareKnownClass$1 self% and thirdTryKnownClass$1 self% should regress: the new helpers now own class-symbol comparison work formerly attributed to compareNamed$1 and thirdTryNamed$1. - ClassDenotation.baseTypeOf self% should improve or stay neutral: fewer direct static class probes need to construct a base type. - BaseClassSet.contains$extension self% and ClassDenotation.derivesFrom tot% could regress: the shortcut adds derivesFrom/base-class guard checks before deciding whether tryBaseType is needed. - NamedType.symbol tot% could regress: the fast lane reads the RHS symbol before deciding whether it can skip info. - Denotation.info tot% should stay neutral: info movement should remain within noise. - No correctness regression expected: aliases, proxies, refinements, match types, capture wrappers, and non-class refs remain on the existing base-type and info-based paths. JFR profile deltas for static class success (5 repeats × 10 runs, mean ± stddev, iter-13/run-0 → iter-13/run-19): 1. TypeComparer.isSubType tot%: 15.29 ± 0.24 → 14.47 ± 0.41 (-0.82, 2.0σ) 2. TypeComparer.compareNamed$1 tot%: 4.49 ± 0.08 → 3.98 ± 0.08 (-0.51, 6.4σ) 3. TypeComparer.secondTry$1 tot%: 8.44 ± 0.10 → 7.21 ± 0.31 (-1.23, 4.0σ) 4. ClassDenotation.baseTypeOf self%: 0.33 ± 0.09 → 0.20 ± 0.06 (-0.13, 1.4σ) 5. BaseClassSet.contains$extension self%: 0.19 ± 0.03 → 0.26 ± 0.03 (+0.07, 2.3σ) JFR profile deltas for static class misses (5 repeats × 10 runs, mean ± stddev, iter-17/run-0 → iter-17/run-8): 1. ClassDenotation.recur$4 self%: 0.69 ± 0.05 → 0.72 ± 0.10 (+0.03, 0.3σ) 2. ClassDenotation.baseTypeOf self%: 0.35 ± 0.07 → 0.32 ± 0.16 (-0.03, 0.2σ) 3. TypeComparer.isSubType tot%: 15.34 ± 0.26 → 14.85 ± 0.43 (-0.49, 1.1σ) 4. TypeComparer.recur tot%: 15.11 ± 0.26 → 14.61 ± 0.42 (-0.50, 1.2σ) 5. ClassDenotation.derivesFrom tot%: 1.05 ± 0.14 → 1.18 ± 0.13 (+0.13, 0.9σ) 6. BaseClassSet.contains$extension self%: 0.28 ± 0.12 → 0.23 ± 0.04 (-0.05, 0.4σ) JFR profile deltas for class RHS info deferral in compareNamed (5 repeats × 10 runs, mean ± stddev, iter-4/run-0 → iter-4/run-7): 1. TypeComparer.compareNamed$1 self%: 0.23 ± 0.03 → below floor 2. TypeComparer.thirdTryNamed$1 self%: 0.13 ± 0.02 → below floor 3. TypeComparer.compareKnownClass$1 self%: below floor → 0.14 ± 0.02 4. TypeComparer.thirdTryKnownClass$1 self%: below floor → 0.10 ± 0.03 5. TypeComparer.secondTry$1 tot%: 8.27 ± 0.18 → 6.91 ± 0.31 (-1.36, 4.4σ) 6. TypeComparer.recur tot%: 15.00 ± 0.26 → 14.00 ± 0.39 (-1.00, 2.6σ) 7. TypeComparer.isSubType tot%: 15.29 ± 0.26 → 14.31 ± 0.38 (-0.98, 2.6σ) 8. Denotation.info tot%: 17.89 ± 0.23 → 18.26 ± 1.23 (+0.37, 0.3σ) 9. NamedType.symbol tot%: 0.94 ± 0.06 → 1.00 ± 0.12 (+0.06, 0.5σ) Estimated total speedup: 2.29 ± 0.83 (from static-class-success table row 1, static-class-misses table row 3, and class-RHS-deferral table row 7; deltas -0.82, -0.49, -0.98 are from successive iter baselines targeting TypeComparer.isSubType tot%; σ = sqrt(0.24²+0.41²+0.26²+0.43²+0.26²+0.38²) ≈ 0.83) Accepted. TypeComparer.isSubType total drops across all three measurement windows, secondTry$1 and compareNamed$1 confirm the same subtype-path improvement, and the extra derivesFrom/base-class guard and NamedType.symbol costs do not become meaningful regressions. The old compareNamed and thirdTryNamed self rows fall below the summary floor and reappear as smaller class-specific helpers, while Denotation.info stays within noise.

TypeComparer.isSubType is 15.57% total in iter-16/run-0, and same-symbol class TypeRefs with valid prefixes were setting up local GADT bookkeeping before reaching the next useful type-argument comparison. This change calls isSubArgs first for exact class applications, avoiding that setup when aliases, failed prefixes, and GADT-bound matching are not involved. It is safe because aliases, invalid prefixes, and GADT-bound matching still use the existing path. Expected changes: - TypeComparer.isSubType tot% should improve: exact class applications avoid local GADT setup before comparing type arguments. - TypeComparer.recur, firstTry$1, secondTry$1, and compareNamed$1 tot% should improve: these nested subtype-comparison frames all include the same exact-class application path. - TypeComparer.isSubType self% should stay neutral: the change removes nested setup work rather than a large amount of local wrapper code. - Allocation bytes should stay neutral or improve slightly: avoiding local GADT setup can remove small allocations but does not change broad allocation shape. - No correctness regression expected: aliases, invalid prefixes, and GADT-bound matching still use the existing path. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-16/run-0 → iter-16/run-3): 1. TypeComparer.isSubType self%: 0.39 ± 0.03 → 0.38 ± 0.03 (-0.01, 0.3σ) 2. TypeComparer.isSubType tot%: 15.57 ± 0.30 → 14.65 ± 0.27 (-0.92, 3.1σ) 3. TypeComparer.recur tot%: 15.32 ± 0.28 → 14.42 ± 0.26 (-0.90, 3.2σ) 4. TypeComparer.firstTry$1 tot%: 15.17 ± 0.29 → 14.28 ± 0.25 (-0.89, 3.1σ) 5. TypeComparer.secondTry$1 tot%: 8.71 ± 0.27 → 7.42 ± 0.29 (-1.29, 4.4σ) 6. TypeComparer.compareNamed$1 tot%: 4.67 ± 0.21 → 3.91 ± 0.13 (-0.76, 3.6σ) 7. Total allocation bytes MiB: 302.01 ± 1.60 → 300.51 ± 2.78 (-1.50 MiB, 0.5σ) Estimated total speedup: 0.92 ± 0.40 (from row 2 above) Accepted. The subtype-checking total improves clearly, the nested TypeComparer calls confirm the same improvement, and allocation remains effectively unchanged.

…rce (est. 0.43% speedup) When tycon2.symbol.isClass, skip the tycon2.info match entirely. Class TypeRefs always have ClassInfo, never TypeBounds, so the pattern match is dead work on the class path. This avoids forcing the denotation info, which triggers the expensive goBack$1 / SingleDenotation.current chain. Expected changes: - goBack$1 self% / tot% should improve: class tycons no longer force info through the goBack$1 denotation chain. - SingleDenotation.current tot% should improve: cascade via fewer info forces. - No other regressions expected: only the class-tycon arm is changed; TypeBounds / non-class paths still take the existing match. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-11/run-0 → iter-11/run-10): 1. goBack$1 self%: 0.90 ± 0.51 → 0.47 ± 0.33 (-0.43, 0.8σ) 2. goBack$1 tot%: 1.26 ± 0.04 → 0.60 ± 0.24 (-0.66, 2.8σ) 3. SingleDenotation.current self%: 0.37 ± 0.01 → 0.34 ± 0.12 (-0.03, 0.2σ) 4. SingleDenotation.current tot%: 5.00 ± 0.06 → 4.35 ± 0.34 (-0.65, 1.9σ) Estimated total speedup: 0.43 ± 0.51 (from row 1 — the self% drop on goBack$1, the direct target of the info-force bypass) Accepted. goBack$1 tot% drops -0.66 at 2.8σ with matching SingleDenotation.current tot% -0.65 at 1.9σ, confirming the class-tycon fast-path avoids the predicted info-force chain. The high variance on goBack$1 self% (0.8σ) is consistent with the tot% signal carrying the cleaner measurement.

TypeComparer now caches the isCaptureCheckingOrSetup result when init installs a new comparer context, and the hot subtype frame reads that field instead of recomputing phaseId plus capture-checking iteration state. The cached value feeds recur's inert-frame check, capture-variable comparison, refined-function handling, singleton capture widening, and relaxed method-parameter matching. This is safe because TypeComparer.init already refreshes context-dependent comparer state before reuse, so a phase or capture-iteration change gets a fresh cached value with the same lifetime as state and mode fields. Expected changes: - TypeComparer.firstTry$1 self% should improve: refined-function and capture-sensitive branches stop recomputing the capture/setup phase predicate in the first RHS-directed subtype pass. - TypeComparer.recur self% should improve: each subtype frame uses a field load for the inert-frame and capture-variable gates instead of repeated context phase and capture-checking state checks. - TypeComparer.secondTry$1 tot% should improve: capture-variable comparisons reached through the LHS-directed pass avoid the repeated predicate work in callees. - TypeComparer.init self% could regress: every comparer initialization writes one additional cached boolean. - No correctness regressions expected: the cached value is refreshed with the comparer context in init, matching the existing lifetime of gadtConstraintInferenceMode and typer state. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-19/run-0 → iter-19/run-11): 1. TypeComparer.firstTry$1 self%: 0.52 ± 0.05 → 0.35 ± 0.08 (-0.17, 2.1σ) 2. TypeComparer.recur self%: 0.45 ± 0.05 → 0.35 ± 0.04 (-0.10, 2.0σ) 3. TypeComparer.secondTry$1 tot%: 7.06 ± 0.09 → 6.36 ± 0.13 (-0.70, 5.4σ) 4. TypeComparer.init self%: below floor → below floor Estimated total speedup: 0.27 ± 0.11 (from rows 1 and 2 above; row 3 is overlapping confirmation) Accepted. TypeComparer.firstTry$1 and TypeComparer.recur both show significant exclusive-time wins from replacing repeated capture/setup predicate evaluation with a cached mode field. TypeComparer.secondTry$1 total time confirms the improvement through the LHS-directed comparison path without being double-counted, while the extra init write remains below the profile-summary floor.

…dup) RHS TypeParamRef comparison can retry `tp1 <:< tp2` under frozen constraints before adding a lower-bound constraint, and the TypeComparer path is hot in this profile with `isSubType` at 0.54% self / 15.06% total. This change adds a comparer-local one-slot cache keyed by operand identity plus unchanged Constraint and GADT identities, so repeated frozen retries for the same state return directly. It is disabled for capture checking and monitored/pending subtype recursion, replays GADT/opaque usage flags on hits, and relies on immutable constraint/GADT replacement for invalidation. Expected changes: - TypeComparer.firstTry$1 self% should improve: firstTry cascades into the same frozen retry with fewer full subtype frames. - TypeComparer.secondTry$1 self% should improve: RHS TypeParamRef fallback avoids re-entering the frozen subtype retry when the same pair and constraint repeat. - TypeComparer.isSubType tot% and TypeComparer.recur tot% should improve: caller totals see less work under the repeated frozen subtype retry. - TypeComparer.isSubType self% could regress: cache misses add identity checks and flag replay around the old frozen wrapper. - No other regressions expected: capture checking and monitored/pending subtype recursion keep the old path, and any relevant constraint or GADT mutation changes the identity key. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-23/run-0 → iter-23/run-21): 1. TypeComparer.firstTry$1 self%: 0.46 ± 0.06 → 0.34 ± 0.05 (-0.12, 2.0σ) 2. TypeComparer.secondTry$1 self%: 0.36 ± 0.04 → 0.25 ± 0.04 (-0.11, 2.7σ) 3. TypeComparer.isSubType tot%: 15.06 ± 0.28 → 14.64 ± 0.33 (-0.42, 1.3σ) 4. TypeComparer.recur tot%: 14.75 ± 0.30 → 14.35 ± 0.32 (-0.40, 1.3σ) 5. TypeComparer.isSubType self%: 0.54 ± 0.09 → 0.51 ± 0.11 (-0.03, 0.3σ) Estimated total speedup: 0.23 ± 0.10 (from rows 1 and 2 above) Accepted. The direct self-time rows for firstTry$1 and secondTry$1 both clear the threshold, and the isSubType/recur total-time confirmation moves with them. isSubType self-time stays within noise, so the cache miss checks do not show measurable direct overhead.

TypeComparer.recur now sends frozen, non-capture frames through an inert path that does not read the current OrderingConstraint, snapshot GADT state, or sample the capture undo log. The iter-23/run-0 profile had TypeComparer.recur at 0.45% self / 14.75% total, with many recursive calls coming from frozen subtype checks where addConstraint and capture undo logging are disabled. This is safe because the optimized path is limited to frozenConstraint with no caseLambda and outside capture checking; all mutable rollback state remains saved and restored on the normal path. Expected changes: - TypeComparer.recur self% should improve: inert recursive frames skip constraint, GADT, and undo-log prologue work before entering the comparison body. - TypeComparer.secondTry$1 self% should improve: common recursive calls reached from the left-hand fallback path inherit the cheaper inert recur frame. - TypeComparer.compareNamed$1 self% should improve: named-type comparisons perform fewer inert recursive setup reads around prefix and alias checks. - TypeComparer.recur self% could regress: the prologue now has a branch and two code paths before the comparison body. - Typer.typedNamed$1 tot% could regress: broad typer attribution can move when subtype-comparer and later phase totals shift in opposite directions. - No semantic regressions expected: unfrozen, case-lambda, and capture-checking frames keep the old constraint, GADT, and undo-log rollback path, while inert frames could not mutate those structures through addConstraint or CaptureSet undo logging. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-23/run-0 → iter-23/run-51): 1. TypeComparer.recur self%: 0.45 ± 0.05 → 0.34 ± 0.03 (-0.11, 2.2σ) 2. TypeComparer.secondTry$1 self%: 0.36 ± 0.04 → 0.25 ± 0.03 (-0.11, 2.7σ) 3. TypeComparer.compareNamed$1 self%: 0.14 ± 0.01 → 0.11 ± 0.01 (-0.03, 3.0σ) 4. TypeComparer.recur tot%: 14.75 ± 0.30 → 14.47 ± 0.29 (-0.28, 0.9σ) 5. MegaPhase.transformTree tot%: 14.95 ± 0.26 → 13.96 ± 0.19 (-0.99, 3.8σ) 6. Typer.typedNamed$1 tot%: 59.03 ± 0.29 → 60.99 ± 0.55 (+1.96, 3.6σ) Estimated total speedup: 0.25 ± 0.08 (from rows 1, 2, and 3 above; rows 4, 5, and 6 are overlapping caller and phase-total confirmations) Accepted. TypeComparer.recur self-time clears the threshold, and the neighboring secondTry and compareNamed self rows move in the same direction above the threshold. The broad Typer total-time regression is overlapping phase attribution rather than direct self-time, while MegaPhase total-time moves down, so the direct subtype-comparer self-time wins justify preserving the split.

…% speedup) TypeBounds conjunction and disjunction already normalize their lower and upper bounds before using frozen subtype checks, and the TypeComparer path is hot in this profile with recur at 0.45% self / 14.75% total. This change treats identity-equal normalized bounds as the cached true result of the frozen subtype comparison, avoiding the frozen wrapper and recursive TypeComparer entry in that common equal-bound case. It is safe because it only bypasses calls whose operands are the same Type object, preserving the old ordering and results for every non-identical bound pair. Expected changes: - TypeComparer.recur self% should improve: equal normalized TypeBounds operands no longer enter the frozen subtype recursion just to return true. - TypeComparer.secondTry$1 self% and tot% should improve: fewer frozen recursive subtype checks are reached while simplifying bounds. - TypeComparer.isSubType self% could regress: TypeBounds union and intersection misses add identity checks before falling back to the old frozen subtype call. - No other regressions expected: the guard substitutes only the identity-proven true result for the same frozen_<:< predicate. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-23/run-0 → iter-23/run-32): 1. TypeComparer.recur self%: 0.45 ± 0.05 → 0.37 ± 0.04 (-0.08, 1.6σ) 2. TypeComparer.secondTry$1 self%: 0.36 ± 0.04 → 0.28 ± 0.01 (-0.08, 2.0σ) 3. TypeComparer.secondTry$1 tot%: 7.26 ± 0.26 → 6.90 ± 0.23 (-0.36, 1.4σ) 4. TypeComparer.isSubType self%: 0.54 ± 0.09 → 0.45 ± 0.12 (-0.09, 0.8σ) Estimated total speedup: 0.16 ± 0.08 (from rows 1 and 2 above) Accepted. The direct TypeComparer.recur and secondTry$1 self-time rows clear the threshold, and secondTry$1 total moves with them. isSubType self-time improves but stays within noise, so the added identity guards do not show measurable wrapper overhead.

The inliner builds paramProxy and thisProxy for each inline call, then reads them from the DeepTypeMap path under TypeMap.mapOver, which is 8.71% total in iter-19/run-0; HashMap$Node.findNode is also visible at 0.33% self. This change stores up to four proxy entries in linear arrays before falling back to mutable.HashMap, and the thisProxy value probe uses the same small path instead of allocating a values.exists iterator. It is safe because the helper preserves the Inliner map operations, keeps mutable.HashMap semantics beyond the threshold, and deliberately preserves == key/value comparison rather than switching to identity. Expected changes: - TypeMap.mapOver self% and tot% should improve: inliner proxy get/getOrElse calls avoid HashMap node traversal for the common small-map case. - TreeTypeMap.transform tot% should improve: this caller includes the mapped type work reached through TypeMap.mapOver. - HashMap$Node.findNode self% should improve: paramProxy and thisProxy no longer allocate and probe HashMap nodes while they stay at four entries or fewer. - HashMap.put0 self% could regress: proxy maps larger than the threshold pay one conversion into a mutable.HashMap. - No other regressions expected: keys and values are still compared with ==, and larger maps fall back to the previous mutable.HashMap behavior. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-19/run-0 → iter-19/run-27): 1. TypeMap.mapOver self%: 0.69 ± 0.07 → 0.59 ± 0.05 (-0.10, 1.4σ) 2. TypeMap.mapOver tot%: 8.71 ± 0.23 → 8.07 ± 0.40 (-0.64, 1.6σ) 3. TreeTypeMap.transform tot%: 7.68 ± 0.26 → 6.79 ± 0.42 (-0.89, 2.1σ) 4. HashMap$Node.findNode self%: 0.33 ± 0.06 → 0.27 ± 0.02 (-0.06, 1.0σ) Estimated total speedup: 0.16 ± 0.11 (from rows 1 and 4 above) Accepted. TypeMap.mapOver self% clears the go/no-go threshold, with TypeMap.mapOver and TreeTypeMap.transform total-time rows confirming the mapped type path improved. HashMap$Node.findNode moves in the expected direction, while the small HashMap.growTable and HashMap.put0 movements are too close to the summary floor to offset the direct self-time improvement.

dropUnusedDefs now memoizes the active term-reference symbols contributed by each tree type while counting references for inlineable bindings. The path is hot because updateTermRefCounts repeatedly walked identical typeOpt values through TypeAccumulator.foldOver at 3.57% total and ForeachAccumulator.apply at 1.34% total in iter-23/run-0, plus inactive refCount probes in EqHashMap.lookup at 0.53% self. Replaying the cached symbol list avoids repeated type traversal and lookup probes while preserving the existing +2 count inflation for every active TermRef occurrence, so one-use inline decisions and non-inlineable references keep the same behavior. Expected changes: - TypeAccumulator.foldOver self% and tot% should improve: repeated typeOpt.foreachPart traversals in updateTermRefCounts are replaced by identity-cache replay when the same Type object appears on multiple trees. - ForeachAccumulator.apply self% and tot% should improve: cached type contributions skip the ForeachAccumulator created by Type.foreachPart on repeated type identities. - EqHashMap.lookup self% should improve: inactive TermRefs are filtered once per distinct Type instead of probing refCount on every repeated type walk. - IdentityHashMap.get self% could regress: every counted RefTree, New, and TypeTree now checks the per-dropUnusedDefs type-contribution cache. - No correctness regressions expected: the cache stores duplicate active symbols per Type and replays each occurrence with the same +2 increment, while non-inlineable symbols keep the old no-op behavior. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-23/run-0 → iter-23/run-10): 1. TypeAccumulator.foldOver self%: 0.76 ± 0.01 → 0.50 ± 0.03 (-0.26, 8.7σ) 2. TypeAccumulator.foldOver tot%: 3.57 ± 0.16 → 2.86 ± 0.08 (-0.71, 4.4σ) 3. ForeachAccumulator.apply self%: 0.28 ± 0.03 → 0.10 ± 0.01 (-0.18, 6.0σ) 4. ForeachAccumulator.apply tot%: 1.34 ± 0.06 → 0.61 ± 0.05 (-0.73, 12.2σ) 5. EqHashMap.lookup self%: 0.53 ± 0.04 → 0.47 ± 0.04 (-0.06, 1.5σ) 6. IdentityHashMap.get self%: 0.22 ± 0.09 → 0.16 ± 0.05 (-0.06, 0.7σ) Estimated total speedup: 0.50 ± 0.07 (from rows 1, 3, and 5 above) Accepted. TypeAccumulator.foldOver and ForeachAccumulator.apply both move strongly in the expected direction, confirming that repeated type-part traversals were removed from the inliner reference-counting path. EqHashMap.lookup self time also improves, and the new IdentityHashMap cache lookup does not show a measurable regression.

Inliner parameter proxies now use the parameter Symbol as the primary key, while keeping a Type-keyed fallback for non-symbol designators. The hot DeepTypeMap path runs under TypeMap.mapOver at 7.69% total and TreeTypeMap.transform at 7.48% total in iter-23/run-0, and BoxesRunTime.equals2 was 0.89% total with SmallFallbackMap.indexOf contributing 0.11 in that equality subtree; symbol lookup avoids the structural Type equality that those small-map probes paid for parameter references. This is safe because nested LambdaTypeTree parameters still pass the existing paramSymss guard, and name-designator references retain the previous Type-keyed fallback behavior. Expected changes: - BoxesRunTime.equals2 self% and tot% should improve: symbol-keyed paramProxy probes avoid Type == comparisons in SmallFallbackMap.indexOf. - TypeMap.mapOver self% and tot% should improve: inliner type mapping reaches fewer structural proxy lookups while rewriting inlined-body types. - TreeTypeMap.transform tot% should improve: the enclosing inliner tree walk inherits the cheaper DeepTypeMap proxy lookup path. - NamedType.symbol self% could regress: registration and Ident lookups read symbols directly to find the symbol-keyed proxy. - No other regressions expected: non-symbol designators still use the old Type-keyed fallback, and i13460-style nested lambda type parameters remain excluded by the method-parameter membership check. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-23/run-0 → iter-23/run-9): 1. BoxesRunTime.equals2 self%: 0.78 ± 0.04 → 0.62 ± 0.04 (-0.16, 4.0σ) 2. BoxesRunTime.equals2 tot%: 0.89 ± 0.03 → 0.69 ± 0.04 (-0.20, 5.0σ) 3. TypeMap.mapOver self%: 0.70 ± 0.07 → 0.53 ± 0.04 (-0.17, 2.4σ) 4. TypeMap.mapOver tot%: 7.69 ± 0.28 → 6.92 ± 0.25 (-0.77, 2.8σ) 5. TreeTypeMap.transform tot%: 7.48 ± 0.18 → 6.18 ± 0.15 (-1.30, 7.2σ) 6. NamedType.symbol self%: 0.32 ± 0.04 → 0.39 ± 0.04 (+0.07, 1.8σ) 7. SmallFallbackMap.indexOf under BoxesRunTime.equals2 tree share: 0.11 → 0.04 Estimated total speedup: 0.26 ± 0.11 (from rows 1, 3, and 6 above; self% rows are exclusive, with row 6 netted as the measured regression) Accepted. BoxesRunTime.equals2 improves strongly in both self and total time, and the SmallFallbackMap.indexOf tree share under it drops from 0.11 to 0.04, confirming that symbol-keyed probes remove structural Type equality. TypeMap.mapOver self-time and total-time rows move down with the TreeTypeMap.transform caller, while the direct NamedType.symbol self-time regression is smaller than the summed direct self-time wins.

Inline expansion now stores each inlineable method parameter's binding and argument span in one small array-backed map instead of two mutable HashMaps keyed by the same parameter name. The iter-23/run-0 profile had HashMap.put0 at 0.12% self / 0.28% total and the inliner mapper contributes under TypeMap.mapOver at 7.69% total, so small inline calls avoid allocating and updating two hash tables while preserving the old hash-map fallback for larger arities. This is safe because Name keys keep the same identity equality, duplicate-name overwrites still update both binding and span, and missing spans still fail at the same lookup point. Expected changes: - HashMap.put0 self% and tot% should improve: common small inline calls no longer update separate paramBinding and paramSpan hash maps while matching type and value arguments. - TypeMap.mapOver self% and tot% should improve: the inliner mapping path inherits cheaper parameter-name binding/span access when rewriting parameter references. - TreeTypeMap.transform tot% should improve: transformed inline bodies inherit the cheaper parameter-data lookup path. - Inliner$$anon$8.apply self% could regress: the new small cache adds linear probes and helper calls around the inliner map path. - No other regressions expected: large parameter lists fall back to mutable HashMaps, and both binding and span lookups preserve the previous keying and overwrite semantics. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-23/run-0 → iter-23/run-25): 1. HashMap.put0 self%: 0.12 ± 0.02 → below floor 2. HashMap.put0 tot%: 0.28 ± 0.04 → below floor 3. TypeMap.mapOver self%: 0.70 ± 0.07 → 0.56 ± 0.03 (-0.14, 2.0σ) 4. TypeMap.mapOver tot%: 7.69 ± 0.28 → 7.09 ± 0.07 (-0.60, 2.1σ) 5. TreeTypeMap.transform tot%: 7.48 ± 0.18 → 6.62 ± 0.17 (-0.86, 4.8σ) 6. Inliner$$anon$8.apply self%: below floor → 0.09 ± 0.04 Estimated total speedup: at least 0.12 ± 0.09 (from rows 1, 3, and 6 above; row 1 is credited only by its minimum below-floor improvement, and row 6 is charged as a full below-floor regression) Accepted. HashMap.put0 drops below the summary floor in both self and total time, confirming that the duplicated parameter-name hash updates were removed from the inline-call setup path. TypeMap.mapOver and TreeTypeMap.transform move down as caller confirmations, while the visible Inliner$$anon$8.apply self-time cost is smaller than the measured direct and mapper wins.

dropUnusedDefs now keeps inlineable binding reference counts in the three states used by the fixpoint, 0, 1, and saturated 2, while tracking how many symbols are still below saturation. This path is hot in iter-23/run-0 through TreeAccumulator.foldOver at 1.29% self, TypeAccumulator.foldOver at 0.76% self, ForeachAccumulator.apply at 0.28% self, and EqHashMap.lookup at 0.53% self; once every inlineable binding is known to be retained, later tree and type walks no longer update the counter map. The change is safe because counts of exactly 1 remain exact for inlineBindings, type mentions still force saturation to 2, and the existing retained-binding fixpoint is unchanged. Expected changes: - TreeAccumulator.foldOver self% and tot% should improve: remaining binding trees stop walking subtrees once all tracked symbols have saturated counts. - TypeAccumulator.foldOver and ForeachAccumulator.apply self% should improve: typeOpt.foreachPart is skipped after the active counter reaches zero. - EqHashMap.lookup self% should improve: saturated symbols avoid later ref-count get/update work, and updateRefCount uses lookup directly instead of allocating Option wrappers. - Inliner.dropUnusedDefs self% could regress: small expansions pay an active-count branch around each local counting helper. - EqHashMap$HashedOnly.addOldHashed self% could regress: unrelated member-cache promotion can become a slightly larger share when generic traversal and lookup time drops. - No other regressions expected: the observable counter states consumed by retain and inlineBindings are still absent, 0, 1, and greater than 1. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-23/run-0 → iter-23/run-45): 1. TreeAccumulator.foldOver self%: 1.29 ± 0.08 → 0.94 ± 0.11 (-0.35, 3.2σ) 2. TreeAccumulator.foldOver tot%: 6.29 ± 0.13 → 4.92 ± 0.04 (-1.37, 10.5σ) 3. ForeachAccumulator.apply self%: 0.28 ± 0.03 → below floor 4. TypeAccumulator.foldOver self%: 0.76 ± 0.01 → 0.52 ± 0.05 (-0.24, 4.8σ) 5. EqHashMap.lookup self%: 0.53 ± 0.04 → 0.39 ± 0.03 (-0.14, 3.5σ) 6. EqHashMap$HashedOnly.addOldHashed self%: 0.27 ± 0.02 → 0.31 ± 0.03 (+0.04, 1.3σ) Estimated total speedup: at least 0.92 ± 0.16 (from rows 1, 3, 4, 5, and 6 above, conservatively charging the below-floor ForeachAccumulator.apply after sample at the 0.05 summary floor; row 6 is netted as the measured regression) Accepted. TreeAccumulator.foldOver gives the direct traversal win, TypeAccumulator.foldOver and ForeachAccumulator.apply confirm skipped type-part counting, and EqHashMap.lookup moves in the expected direction above the significance threshold. The small HashedOnly.addOldHashed regression is much smaller than the summed direct self-time wins and is outside the touched generic ref-count map.

Inline binding normalization now carries compact member-definition worklists for proxy bindings whose RHS has already been owner-mapped, so defTree refresh can touch those definitions directly instead of walking each binding subtree. Bindings whose RHS changes during projection normalization, opaque remapping, or unknown construction keep the old traversal fallback, and debug mode verifies carried worklists against a full subtree scan. Expected changes: - TreeMap.transform self% should improve: the generic foreachSubTree pass over normalized inline bindings is skipped for known proxy bindings. - TreeTypeMap.transform tot% should improve: the existing owner-remap pass records member definitions while it walks, so the later binding traversal drops out of the inlining path. - TreeTypeMap.transform self% could regress: member-definition collection adds a small MemberDef match and append check to the owner-remap transformer. - Inliner$$anon$8.apply tot% should stay neutral: proxy registration and final binding contents are unchanged; only defTree refresh bookkeeping differs. - No other regressions expected: changed RHSs, opaque remaps, and unknown bindings fall back to the previous subtree walk, while known worklists are checked against that walk in debug mode. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-3/run-0 → iter-3/run-14): 1. TreeMap.transform self%: 0.87 ± 0.03 → 0.80 ± 0.05 (-0.07, 1.4σ) 2. TreeTypeMap.transform tot%: 7.97 ± 0.14 → 7.39 ± 0.32 (-0.58, 1.8σ) 3. TreeTypeMap.transform self%: 0.34 ± 0.04 → 0.36 ± 0.07 (+0.02, 0.3σ) 4. Inliner$$anon$8.apply tot%: 1.76 ± 0.12 → 1.75 ± 0.09 (-0.01, 0.1σ) Estimated total speedup: 0.07 ± 0.06 (from row 1 above; row 2 is overlapping total confirmation) Accepted. TreeMap.transform self-time moves down in the directly affected traversal row, and the overlapping TreeTypeMap.transform total row confirms the inlining owner-map path shrinks overall. The small TreeTypeMap.transform self increase is noise-level, and the watched inliner total row stays flat.

Inline expansion now caches the RHS leaf type roots used to seed parameter and this proxies on the inline body tree, so the first expansion keeps the old subtree walk while later expansions replay the cached type roots before running InlinerMap. The path is hot because iter-3/run-0 had TreeAccumulator.foldOver at 0.95% self / 4.10% total, and verifier counters saw 4,287 inline expansions scanning 206,256 RHS nodes and 87,467 registerable leaves before substitution. The summary only stores existing Type roots in a non-sticky tree attachment and still invokes the same call-site registerType traversal, preserving proxy order, prefix adaptation, and parameter binding behavior. Expected changes: - TreeAccumulator.foldOver tot% should improve: cached inline bodies avoid repeated foreachSubTree folds over RHS nodes after first expansion. - TreeMap.transform self% should improve: less inlining setup work is interleaved with generic tree transformation before the RHS substitution map. - TreeTypeMap.transform tot% should improve: the RHS substitution map starts after cheaper proxy seeding and carries less surrounding inliner traversal time. - InlineRhsLeafSummary.Builder.add self% could regress: first expansion of each uncached RHS records leaf Type roots into a small array. - Attachment.LinkSource.putAttachment self% could regress: first expansion installs one non-sticky summary attachment on the inline RHS root. - No other regressions expected: summary replay uses the same Type roots and registerType traversal as the old scan, and uncached RHS trees still take the old traversal path. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-3/run-0 → iter-3/run-20): 1. TreeMap.transform self%: 0.87 ± 0.03 → 0.80 ± 0.06 (-0.07, 1.2σ) 2. TreeAccumulator.foldOver tot%: 4.10 ± 0.03 → 3.68 ± 0.26 (-0.42, 1.6σ) 3. TreeTypeMap.transform tot%: 7.97 ± 0.14 → 6.73 ± 0.35 (-1.24, 3.5σ) 4. TypeMap.mapOver tot%: 8.02 ± 0.21 → 7.30 ± 0.32 (-0.72, 2.2σ) 5. Inliner$$anon$8.apply tot%: 1.76 ± 0.12 → 1.60 ± 0.02 (-0.16, 1.3σ) Estimated total speedup: 0.07 ± 0.07 (from row 1 above; rows 2, 3, 4, and 5 are overlapping total confirmation) Accepted. TreeMap.transform self-time clears the threshold at 1.2σ, and the directly affected TreeAccumulator.foldOver total row improves by -0.42 at 1.6σ. TreeTypeMap.transform, TypeMap.mapOver, and Inliner$$anon$8.apply totals all move down significantly, while the new summary helpers stay below the profile floor, so the cached RHS leaf replay pays for itself despite noisy direct self-time.

Inliner owner changes used MemberDefCollectingTreeTypeMap to run super.transform and then test every mapped node for MemberDef; the baseline tree report put that subclass at 8.11% of TreeTypeMap.transform self. TreeTypeMap now notifies a protected hook after the ValDef, DefDef, and TypeDef arms produce their final mapped member, so the inliner builder records the same post-order member results without the per-node post-match. ValDef and TypeDef still delegate to the existing TreeMap arms, and DefDef records only after parameter, annotation, and RHS remapping, preserving the previous transformed member list. Expected changes: - MemberDefCollectingTreeTypeMap.transform self% should improve: the collecting subclass no longer wraps every TreeTypeMap node with a post-transform MemberDef match. - TreeTypeMap.transform tot% should improve: inliner owner-changing maps avoid the extra subclass frame while preserving the same member-producing child traversal. - TreeTypeMap.transform self% could regress: non-collecting maps now pass mapped member definitions through a no-op hook at member arms. - No other regressions expected: the hook observes the same ValDef, DefDef, and TypeDef results after existing copy/type/owner remapping. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-13/run-0 → iter-13/run-23): 1. TreeTypeMap.transform tot%: 8.18 ± 0.17 → 6.85 ± 0.47 (-1.33, 2.8σ) 2. TreeTypeMap.transform self%: 0.46 ± 0.08 → 0.42 ± 0.08 (-0.04, 0.5σ) 3. TypeMap.mapOver self%: 0.65 ± 0.08 → 0.56 ± 0.03 (-0.09, 1.1σ) 4. TypeMap.mapOver tot%: 7.70 ± 0.16 → 7.33 ± 0.29 (-0.37, 1.3σ) 5. TreeMap.transform tot%: 28.67 ± 0.67 → 28.37 ± 0.75 (-0.30, 0.4σ) Estimated total speedup: 1.33 ± 0.50 (from row 1 above; rows 2, 3, and 4 overlap it, and row 5 is the enclosing TreeMap guardrail) Accepted. TreeTypeMap.transform total time improves by 2.8σ and the old MemberDefCollectingTreeTypeMap.transform branch disappears from the tree report, while TreeMap.transform total remains within noise. The no-op hook does not produce a significant TreeTypeMap.transform self regression, so the member-arm collection pays for itself on the inliner owner-change path.

Splicing now lowers applied level-0 quotes by calling the shared PickleQuotes.transformQuote helper immediately after direct splices have been rewritten to holes, then clears the unit's staging-work flag so the later PickleQuotes phase skips it. This path is hot because staging units previously paid one TreeMap pass to find level-0 quotes and another whole-unit TreeMap pass to pickle the same quote roots. The change is safe because inline-method quotes remain deferred until after inlining, staging still runs before splicing, and the fused path reuses the existing hole extraction, type-tag encoding, hole-content transform, and pickle construction order. Expected changes: - TreeMap.transform self% should improve: staging units no longer run a separate PickleQuotes transformer over every tree after splicing has already found the quote roots. - TreeMap.transform tot% should improve: removing that whole-unit pass reduces the enclosing tree-transform time for quote-heavy staging units. - TreeTypeMap.transform tot% should improve: quote type-tag encoding is reached from fused quote-root lowering instead of a later PickleQuotes traversal. - TypeMap.mapOver self% should improve: fewer quote-pickling type maps run after the splicing traversal. - CrossStageSafety.transform tot% should improve: clearing the staging-work flag after fused lowering reduces later staging-marked transform work in the profile. - DirectMethodHandle.allocateInstance self% could regress: moving quote lowering into the splicing transformer can shift closure and helper-object allocation timing around hole contents. - No other regressions expected: all non-applied quotes, inline-method quotes, hole extraction, annotation mapping, type-tag encoding, and pickle construction still use the existing semantics. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-19/run-0 → iter-19/run-54): 1. TreeMap.transform self%: 0.89 ± 0.10 → 0.66 ± 0.02 (-0.23, 2.3σ) 2. TreeMap.transform tot%: 30.14 ± 0.34 → 29.23 ± 0.24 (-0.91, 2.7σ) 3. TreeTypeMap.transform tot%: 7.68 ± 0.26 → 6.57 ± 0.13 (-1.11, 4.3σ) 4. TypeMap.mapOver self%: 0.69 ± 0.07 → 0.57 ± 0.02 (-0.12, 1.7σ) 5. CrossStageSafety.transform tot%: 0.79 ± 0.03 → below floor 6. DirectMethodHandle.allocateInstance self%: 0.44 ± 0.04 → 0.57 ± 0.08 (+0.13, 1.6σ) Estimated total speedup: 0.22 ± 0.15 (from rows 1, 4, and 6 above; self% rows are exclusive, with row 6 netted as the measured regression) Accepted. TreeMap.transform self% gives the direct traversal win, TreeMap.transform and TreeTypeMap.transform totals confirm the removed PickleQuotes pass, and TypeMap.mapOver moves in the same direction for type-tag work. The DirectMethodHandle.allocateInstance regression is smaller than the summed direct self% wins, and CrossStageSafety.transform falling below the floor is consistent with less staging-marked transform work rather than a semantic change.

TreeMapWithStages now sends level-zero Block, Template, DefDef, CaseDef, and LambdaTypeTree nodes straight to the parent TreeMap traversal instead of collecting local symbols that symbolsInCurrentLevel would discard. This is safe because nonzero quote and splice levels still register local symbols through the existing path, and Import/Export nodes remain unchanged. Expected changes: - CrossStageSafety.transform tot% should improve: level-zero staging traversal avoids discarded symbol-list construction. - TreeMap.transform self% should improve: level-zero nodes reach normal traversal without the staging symbol-collection prelude. - TreeMap.transform tot% could stay neutral or regress slightly: staging nodes now take an explicit level branch before delegation. - goForward$1 and freshOver should stay neutral: denotation and context movement are not targeted by this traversal-local change. - No staging diagnostics regressions expected: quote, splice, and other nonzero-level contexts keep the existing symbol registration behavior. JFR profile deltas (iter-23/run-0 → iter-23/run-5): 1. CrossStageSafety.transform tot%: 0.94 ± 0.09 → below floor 2. TreeMap.transform self%: 0.86 ± 0.08 → 0.74 ± 0.08 (-0.12, 1.5σ) 3. TreeMap.transform tot%: 29.22 ± 0.41 → 29.45 ± 0.81 (+0.23, 0.3σ) 4. goForward$1 self%: 0.86 ± 0.03 → 0.83 ± 0.10 (-0.03, 0.3σ) 5. goForward$1 tot%: 3.61 ± 0.21 → 3.48 ± 0.27 (-0.13, 0.5σ) 6. freshOver self%: 1.04 ± 0.04 → 0.97 ± 0.09 (-0.07, 0.8σ) Estimated total speedup: at least 0.84 ± 0.09 (from row 1 above; after row is below the summary floor) Accepted. CrossStageSafety.transform total time falls below the profile summary floor from 0.94 ± 0.09, and TreeMap.transform self-time improves by 1.5×. TreeMap.transform total time, goForward$1, and freshOver all stay within noise, so no targeted regression row offsets the removed level-zero symbol collection.

LocalOpt now lets DCE report whether a method contains line numbers and limits temporary reachability marks to try-block starts, so methods with no line nodes skip the final cleanup while handler cleanup consumes only the label bits it needs. removeEmptyLineNumbers was visible at 0.19% total in iter-23/run-0; it now makes one forward pass that keeps only the latest pending line before executable code instead of recursively looking ahead from each LineNumberNode. This is safe because the same LineNumberNode.start label invariant decides which pending line survives, and try-block reachability bits are cleared by removeEmptyExceptionHandlers after the handler liveness query. Expected changes: - LocalOptImpls.removeEmptyLineNumbers self% and tot% should improve: the cleanup no longer restarts a lookahead from every line node and can skip methods DCE proved have no line numbers. - LocalOptImpls.removeUnreachableCodeImpl tot% could regress: DCE records line-node presence and checks handler-start labels when try/catch blocks exist. - IdentityHashMap.get self% could regress: handler-start reachability uses an identity map on methods with exception handlers. - No other regressions expected: only try-block start labels carry the temporary reachability bit, and removeEmptyExceptionHandlers clears those bits after its liveness query. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-23/run-0 → iter-23/run-18): 1. LocalOptImpls.removeEmptyLineNumbers self%: 0.13 ± 0.03 → 0.10 ± 0.02 (-0.03, 1.0σ) 2. LocalOptImpls.removeEmptyLineNumbers tot%: 0.19 ± 0.04 → 0.10 ± 0.02 (-0.09, 2.3σ) 3. IdentityHashMap.get self%: 0.22 ± 0.09 → 0.12 ± 0.06 (-0.10, 1.1σ) Estimated total speedup: 0.03 ± 0.04 (from row 1 above; row 2 is overlapping total confirmation) Accepted. LocalOptImpls.removeEmptyLineNumbers total time improves by 2.3σ after the cleanup becomes a single pass, and the direct self row moves down. The watched IdentityHashMap.get self row also moves down, so the handler-start reachability guard does not show a measured regression.

…ion) SourceFile.apply now routes well-formed UTF-8 source bytes through SourceFile.decodeValidUtf8, avoiding the intermediate String backing array and String.toCharArray before SourceFile construction. Non-UTF-8 and malformed input remain on the existing charset decoder path. Expected changes: - Total allocation bytes should improve: UTF-8 source loading avoids the intermediate String representation. - [B] allocation bytes should improve: compact String backing arrays disappear from the hot SourceFile.apply path. - [C] allocation bytes should improve: direct decode allocates the final source char array without String.toCharArray. - StringLatin1.replace should improve or stay neutral: less source-loading work reaches the old String path. - No correctness regression expected: fallback decoding still handles unsupported charsets and malformed input. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-19/run-0 → iter-19/run-32): 1. Total allocation bytes MiB: 90.51 ± 2.07 → 83.86 ± 1.64 (-6.65, 3.2σ) 2. [B] allocation bytes MiB: 27.86 ± 1.77 → 23.61 ± 0.53 (-4.25, 2.4σ) 3. [C] allocation bytes MiB: 13.00 ± 0.34 → 10.98 ± 1.20 (-2.02, 1.7σ) 4. StringLatin1.replace self%: 0.27 ± 0.02 → 0.21 ± 0.03 (-0.06, 2.0σ) Estimated allocation reduction: 6.65 ± 2.64 MiB (from row 1 above) Accepted. Total allocation bytes drop -6.65 MiB at 3.2σ, with the expected [B] and [C] allocation classes both moving down. SourceFile.decodeValidUtf8 stays below the timing summary floor, but this is acceptable for an allocation-driven change because the total allocation movement is significant and StringLatin1.replace also improves.

…loc reduction) TASTy source-change contexts now install a cached SourceFile seeded from the pickled line-size table instead of forcing ctx.getSource to read and decode the referenced source. The path is hot because sourceChangeContext is reached from TASTy completion and lazy annotation body reading, where positions need source identity and line/column mapping while source text is rarely inspected. If content is later demanded, the source still goes through the normal SourceFile loader, so diagnostics and script handling keep the existing behavior. Expected changes: - Total allocation bytes should improve: TASTy source changes no longer decode library source contents just to build line indices. - [C] allocation bytes should improve: the large SourceFile.decodeValidUtf8 char-array subtree under sourceChangeContext should mostly disappear. - PositionUnpickler.ensureDefined tot% should improve or stay below the summary floor: line-size metadata is still read once, but source changes avoid the eager source-loading work attached to it. - SymDenotation.completeFrom tot% should stay neutral: completion still unpickles the same TASTy and only changes the SourceFile representation used by positions. - No correctness regression expected: position-only sources keep TASTy line indices immediately and delegate to normal SourceFile loading if diagnostics or APIs request content. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-2/run-0 → iter-2/run-16): 1. Total allocation bytes MiB: 83.14 ± 2.20 → 78.97 ± 2.52 (-4.17, 1.7σ) 2. [C] allocation bytes MiB: 11.66 ± 0.99 → 8.18 ± 0.51 (-3.48, 3.5σ) 3. PositionUnpickler.ensureDefined tot%: 0.38 ± 0.05 → below floor 4. SymDenotation.completeFrom tot%: 19.59 ± 0.21 → 19.76 ± 0.38 (+0.17, 0.4σ) Estimated allocation reduction: 4.17 ± 3.34 MiB (from row 1 above) Accepted. Total allocation drops -4.17 MiB at 1.7σ, and the directly targeted [C] allocation class drops -3.48 MiB at 3.5σ. SymDenotation.completeFrom remains within noise, so the measured win is the intended source-decoding allocation reduction without a significant TASTy-completion regression.

…edup) Audited tree-copy paths for Apply, TypeApply, Block, Inlined, Quote, and Splice can now construct nodes with the source span already installed, using the InitialSpan constructor protocol on Positioned (defined by this commit) instead of building an envelope and immediately overwriting it with TreeCopier.finalize. The direct path is hot because iter-7/run-0 had Positioned.include$1 at 1.34% self / 1.44% total, and it is only used when immediate same-source children already carry spans; otherwise the old constructor and withSpan backfilling path remains in force. Expected changes: - Positioned.include$1 self% and tot% should improve: audited known-span copy construction skips the constructor-time child envelope scan. - Positioned.envelope tot% should improve: fewer copied Apply, TypeApply, Block, Inlined, Quote, and Splice nodes enter envelope during construction. - TreeCopier.finalize self% should improve: direct-span copies no longer call copied.withSpan(tree.span) on the accepted path. - TreeCopier.childHasSpanOrForeignSource self% should regress: the audited paths check immediate children before skipping span backfilling. - No other regressions expected: same-source children without spans fall back to the old envelope/backfill path, and unsupported tree shapes keep the existing constructor protocol. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-7/run-0 → iter-7/run-8): 1. Positioned.include$1 self%: 1.34 ± 0.04 → 0.98 ± 0.12 (-0.36, 3.0σ) 2. Positioned.include$1 tot%: 1.44 ± 0.04 → 1.05 ± 0.11 (-0.39, 3.5σ) 3. Positioned.envelope tot%: 1.82 ± 0.05 → 1.48 ± 0.12 (-0.34, 2.8σ) 4. TreeCopier.finalize self%: 0.21 ± 0.04 → 0.12 ± 0.03 (-0.09, 2.3σ) 5. TreeCopier.childHasSpanOrForeignSource self%: below floor → 0.15 ± 0.02 Estimated total speedup: 0.30 ± 0.14 (from rows 1, 4, and 5 above; rows 2 and 3 are overlapping constructor/envelope confirmation) Accepted. Positioned.include$1 self-time drops by 3.0σ and total time drops by 3.5σ, with Positioned.envelope total time and TreeCopier.finalize self-time also moving down significantly. The new child-span guard is visible at 0.15% self, but the direct self-time wins remain larger and position backfilling is preserved for children that still need it. Note: the InitialSpan constructor protocol on Positioned was originally added by the "direct-span synthetic definitions" commit; that commit was dropped as unsound (it mis-positioned synthetic definitions, corrupting line tables and TASTy round-trips), so its sound Positioned infrastructure is folded into this commit, which is the only remaining user of the protocol.

…4.26 MiB alloc reduction) TASTy string constants now reserve per-pickler UTF8 name entries keyed by the raw String, and TreePickler writes those refs directly, so StringTag payloads no longer allocate global TermNames only to serialize a TASTy name. The baseline allocation tree had 4.00 MiB of char arrays under Decorators.toTermName -> TreePickler.pickleConstant while annotation pickling string constants; the new lane still emits ordinary UTF8 name-table entries, leaves real Name refs and source-path utf8Index on the existing path, and lets duplicate raw-string and real-name entries unpickle to the same text. Expected changes: - Total allocation should improve: string constants serialized into TASTy bypass global TermName interning and its char-slab growth. - [C] allocation should improve: the Decorators.toTermName -> TreePickler.pickleConstant branch should disappear from the char-array allocation tree. - String.hashCode self% could regress: the per-pickler string table still hashes raw strings, though it replaces the global name-table lookup for this payload-only lane. - No other regressions expected: string constants are still encoded as normal UTF8 TASTy name entries, non-string NameBuffer dependencies are unchanged, and source-position paths continue to use utf8Index/nameIndex. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-3/run-0 → iter-3/run-15): 1. Total allocation bytes MiB: 79.96 ± 2.40 → 75.69 ± 3.25 (-4.26, 1.3σ) 2. [C] allocation bytes MiB: 8.26 ± 0.40 → 4.07 ± 0.47 (-4.19, 8.9σ) 3. NameTable.enterIfNewAscii self%: 0.12 ± 0.02 → below floor 4. String.hashCode self%: 0.27 ± 0.20 → 0.18 ± 0.17 (-0.09, 0.5σ) Estimated allocation reduction: 4.26 ± 4.04 MiB (from row 1 above) Accepted. Total allocation drops by 4.26 MiB at 1.3σ, and the directly targeted [C] class drops by 4.19 MiB at 8.9σ. The watched name-table row falls below the summary floor and String.hashCode remains within noise, so this is the intended TASTy string-payload allocation reduction without a global Names representation change.

TypeApply assignment used to run ExistsAccumulator(_ eq pt) across every explicit type argument before LambdaType.instantiate, even though simple TypeRef, ThisType, AppliedType, TypeBounds, wildcard, and array shapes cannot contain the current TypeLambda binder. The baseline TypeApply path had 528 main-thread samples and 101 with ExistsAccumulator, with ExistsAccumulator.apply at 0.63% total; this change uses a conservative binder-free shape predicate and only constructs the accumulator for uncertain arguments. The predicate falls back for TypeVar, ParamRef, generic TypeProxy, refinement, match, annotated, capture, term-prefix, and other unknown shapes, preserving the old i6682 fresh-copy path whenever an argument could contain the polytype. Expected changes: - VariantTraversal.stopBecauseStaticOrLocal self% should improve: binder-free TypeApply arguments avoid the ExistsAccumulator TypeAccumulator traversal over named-type prefixes. - ExistsAccumulator.apply tot% should improve: common class and applied type arguments skip the defensive self-reference scan entirely. - TypeAssigner.assignType self% should regress: the shape predicate adds branch work before instantiation, especially when it must fall back to the old scan. - No other regressions expected: uncertain argument shapes keep the existing accumulator scan and self-reference copy behavior. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-3/run-0 → iter-3/run-16): 1. VariantTraversal.stopBecauseStaticOrLocal self%: 0.68 ± 0.05 → 0.58 ± 0.06 (-0.10, 1.7σ) 2. ExistsAccumulator.apply tot%: 0.63 ± 0.06 → 0.55 ± 0.04 (-0.08, 1.3σ) 3. TypeAssigner.assignType tot%: 5.86 ± 0.26 → 5.68 ± 0.06 (-0.18, 0.7σ) 4. TypeAssigner.assignType self%: 0.11 ± 0.02 → 0.12 ± 0.03 (+0.01, 0.3σ) Estimated total speedup: 0.09 ± 0.09 (from rows 1 and 4 above; row 2 overlaps the skipped accumulator traversal and row 3 is caller confirmation) Accepted. The direct TypeAccumulator prefix-traversal row improves by 1.7σ, and ExistsAccumulator.apply total time moves down by 1.3σ, confirming that binder-free TypeApply arguments avoid the defensive scan. TypeAssigner.assignType self-time stays within noise, so the new shape predicate does not show a measurable local overhead.

… speedup) Dependent Apply typing now uses a conservative MethodType result-parameter mask to substitute only arguments that can occur in the raw result type. Imprecise cases such as provisional type variables, incomplete lazy refs, annotations, capture refs, and arities outside the compact mask keep the old all-parameter substitution path, so skipped parameters are known absent from the result and cannot affect skolemization or dependent result semantics. Expected changes: - Substituters.substParams self% and tot% should improve: skipped result-independent arguments remove no-op safeSubstParam iterations in dependent application result typing. - TypeMap.mapOver tot% should improve: fewer substitutions construct TypeMaps and traverse result-type structure. - TypeAssigner.assignType self% should regress: mask lookup and per-argument bit tests add local work before substitution. - No other regressions expected: unknown result shapes and mask-imprecise cases fall back to the old all-parameter substitution path. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-3/run-0 → iter-3/run-30): 1. Substituters.substParams self%: 0.27 ± 0.03 → 0.22 ± 0.03 (-0.05, 1.7σ) 2. Substituters.substParams tot%: 2.80 ± 0.18 → 2.53 ± 0.20 (-0.27, 1.4σ) 3. Substituters.subst self%: 0.11 ± 0.08 → below floor 4. Substituters.subst tot%: 0.53 ± 0.06 → below floor 5. TypeMap.mapOver tot%: 8.02 ± 0.21 → 7.47 ± 0.22 (-0.55, 2.5σ) 6. TypeAccumulator.foldOver tot%: 2.65 ± 0.06 → 2.64 ± 0.06 (-0.01, 0.2σ) 7. TypeAssigner.assignType self%: 0.11 ± 0.02 → 0.11 ± 0.02 (+0.00, 0.0σ) 8. TypeAssigner.assignType tot%: 5.86 ± 0.26 → 5.63 ± 0.23 (-0.23, 0.9σ) Estimated total speedup: 0.05 ± 0.04 (from row 1 above; rows 2, 3, 4, and 5 are overlapping substitution/map confirmation, rows 6, 7, and 8 are overhead and caller guardrails) Accepted. Substituters.substParams self-time improves by 1.7σ and total time by 1.4σ, with Substituters.subst dropping below the reporting floor and TypeMap.mapOver total time improving by 2.5σ. The added mask work does not show up in TypeAssigner.assignType self-time or TypeAccumulator.foldOver total time, and the caller total moves down within noise.

…edup) adaptNoArgs now computes the normalized expected type only when a branch actually needs function-expected information, using a manual NoType sentinel rather than an eager value. The hot path is Typer.adapt1 at 31.56 total, and the delayed demand skips underlyingApplied/defn.isFunctionNType dealias work for ExprType, successful implicit-method result matches, and ordinary non-companion fallback cases. Branches that need the predicate still evaluate the same check before using it, and the case-companion warning remains guarded by the same full condition. Expected changes: - Types.Type.dealias self% and tot% should improve: no-args adaptation paths that never compare against a function prototype avoid the expected-type dealiasing used by function classification. - Typer.adapt1 self% should improve: eager normalization and function checks are removed from branches that return before eta-expansion or inserted-apply decisions. - Typer.adapt1 and Typer.typedNamed$1 tot% could regress: the manual cache and delayed case-companion predicate add small branches on the enclosing typer path. - No other regressions expected: all branches that depend on functionExpected still demand the same predicate before making adaptation, eta-expansion, or inserted-apply decisions. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-13/run-0 → iter-13/run-10): 1. Types.Type.dealias self%: 0.82 ± 0.08 → 0.72 ± 0.00 (-0.10, 1.2σ) 2. Types.Type.dealias tot%: 1.28 ± 0.08 → 1.13 ± 0.07 (-0.15, 1.9σ) 3. Definitions.asContextFunctionType self%: 0.19 ± 0.04 → 0.18 ± 0.05 (-0.01, 0.2σ) 4. Typer.adapt1 self%: 0.21 ± 0.04 → 0.17 ± 0.02 (-0.04, 1.0σ) 5. Typer.adapt1 tot%: 31.56 ± 0.53 → 32.00 ± 0.40 (+0.44, 0.8σ) 6. Typer.typedNamed$1 tot%: 60.57 ± 0.38 → 60.84 ± 0.63 (+0.27, 0.4σ) Estimated total speedup: 0.10 ± 0.08 (from row 1 above; row 2 overlaps it, rows 3 and 4 are direct confirmation, and rows 5 and 6 are enclosing guardrails) Accepted. Types.Type.dealias self-time improves by 1.2σ and total time by 1.9σ, while Definitions.asContextFunctionType, Typer.adapt1 total, and Typer.typedNamed$1 total remain within noise. The direct dealias savings pay for the delayed-demand branches without a significant enclosing typer regression.

Concrete-class member type checking now reuses RefChecks-owned Name and Symbol scratch sets instead of allocating fresh util.HashSet tables for every class. The path is hot because baseline allocation profiling showed 2.22 MiB of object arrays under RefChecks.checkMemberTypesOK, and replacing per-class table allocation with occupied-slot clearing cuts the repeated setup work visible in Arrays.fill. The scratch sets keep the same hash/equality behavior, bound retained capacity, and use a busy guard with nested fallbacks so stale entries and reentrant checkAllOverrides frames preserve the previous behavior. Expected changes: - Arrays.fill self% and tot% should improve: reused member-type sets clear only occupied slots instead of repeatedly allocating and clearing fresh hash-table arrays. - MegaPhase.transformTree tot% should improve: RefChecks runs inside the broad phase traversal, so less member-type set setup should reduce the enclosing transform total. - HashSet.isEqual self% could regress: global equality/hash-set traffic can move slightly as the old util.HashSet membership checks disappear from this path and other hash-set work becomes more visible. - Symbol.isTerm self% could regress: the member declaration scan still tests every candidate symbol, so this unchanged predicate can move up when nearby set-management time is removed. - No other regressions expected: equality/hash behavior matches util.HashSet, occupied slots are nulled after every class, reentrant calls get separate scratch sets, and unusually large tables are reset above the retained-capacity bound. JFR profile deltas (5 repeats × 10 runs, mean ± stddev, iter-7/run-0 → iter-7/run-15): 1. Arrays.fill self%: 0.26 ± 0.05 → 0.16 ± 0.03 (-0.10, 2.0σ) 2. Arrays.fill tot%: 0.26 ± 0.05 → 0.17 ± 0.03 (-0.09, 1.8σ) 3. MegaPhase.transformTree tot%: 15.19 ± 0.13 → 14.07 ± 0.85 (-1.12, 1.3σ) 4. HashSet.isEqual self%: 0.19 ± 0.01 → 0.22 ± 0.02 (+0.03, 1.5σ) 5. Symbol.isTerm self%: 0.36 ± 0.04 → 0.40 ± 0.04 (+0.04, 1.0σ) Estimated total speedup: 0.07 ± 0.06 (from rows 1 and 4 above; rows 2 and 3 are overlapping confirmation, row 5 is a scan guardrail) Accepted. Arrays.fill self-time improves by 2.0σ and total time by 1.8σ, while the enclosing MegaPhase.transformTree total moves down. HashSet.isEqual has a small global self regression and Symbol.isTerm is at threshold, but the removed allocation path plus net direct self-time win make the scratch reuse worth carrying.

lihaoyi changed the title ~~Performance Improvements~~ [WIP] Performance Improvements May 9, 2026

He-Pin reviewed May 9, 2026

View reviewed changes

lihaoyi closed this May 10, 2026

lihaoyi force-pushed the perf branch from 509ff0c to eb2e041 Compare May 10, 2026 03:09

hamzaremmal temporarily deployed to release-nightly May 10, 2026 05:12 — with GitHub Actions Inactive

hamzaremmal temporarily deployed to release-nightly May 10, 2026 05:27 — with GitHub Actions Inactive

lihaoyi reopened this May 11, 2026

SolalPirelli reviewed May 11, 2026

View reviewed changes

lihaoyi force-pushed the perf branch from c4c43ab to a05a708 Compare May 12, 2026 01:27

lihaoyi changed the title ~~[WIP] Performance Improvements~~ Speed up the Scala compiler by 43% (or ~29% latency reduction) on the mill-libs-javalib codebase May 12, 2026

lihaoyi changed the title ~~Speed up the Scala compiler by 43% (or ~29% latency reduction) on the mill-libs-javalib codebase~~ [WIP] Speed up the Scala compiler on the mill-libs-javalib codebase May 12, 2026

lihaoyi force-pushed the perf branch from a05a708 to e124e43 Compare May 12, 2026 03:14

lihaoyi changed the title ~~[WIP] Speed up the Scala compiler on the mill-libs-javalib codebase~~ [WIP] Speed up the Scala compiler on the mill-libs codebase May 12, 2026

lihaoyi changed the title ~~[WIP] Speed up the Scala compiler on the mill-libs codebase~~ [WIP] Speed up the Scala compiler on the mill-runner-daemon codebase May 12, 2026

lihaoyi changed the title ~~[WIP] Speed up the Scala compiler on the mill-runner-daemon codebase~~ [WIP] Speed up the Scala compiler on the mill-libs-javalib codebase May 12, 2026

lihaoyi added 22 commits May 27, 2026 22:14

lihaoyi force-pushed the perf branch from 45dbc0f to 153e6ef Compare May 27, 2026 14:16

lihaoyi added 6 commits May 27, 2026 23:52

lihaoyi force-pushed the perf branch from 153e6ef to 6906ac8 Compare May 27, 2026 15:57

Conversation

lihaoyi commented May 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Major themes

For review

How much have you relied on LLM-based tools in this contribution?

How was the solution tested?

Profiling

Uh oh!

He-Pin May 9, 2026

Choose a reason for hiding this comment

Uh oh!

Gedochao commented May 11, 2026

Uh oh!

mbovel commented May 11, 2026

Uh oh!

Gedochao commented May 11, 2026

Uh oh!

lihaoyi commented May 11, 2026

Uh oh!

lihaoyi commented May 11, 2026

Uh oh!

lihaoyi commented May 11, 2026

Uh oh!

Gedochao commented May 11, 2026

Uh oh!

lihaoyi commented May 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Gedochao commented May 11, 2026

Uh oh!

lihaoyi commented May 11, 2026

Uh oh!

Gedochao commented May 11, 2026

Uh oh!

SolalPirelli May 11, 2026

Choose a reason for hiding this comment

Uh oh!

lihaoyi May 11, 2026

Choose a reason for hiding this comment

Uh oh!

SolalPirelli May 11, 2026

Choose a reason for hiding this comment

Uh oh!

bishabosha commented May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mbovel commented May 12, 2026

Uh oh!

lihaoyi commented May 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

lihaoyi commented May 9, 2026 •

edited

Loading

lihaoyi commented May 11, 2026 •

edited

Loading

bishabosha commented May 12, 2026 •

edited

Loading