Make reifyRouteTree object literals match the canonical RouteTree key order#96162
Merged
Conversation
acdlite
force-pushed
the
deopt-explorer-tooling
branch
2 times, most recently
from
July 24, 2026 19:40
f1aa52a to
dcb9d1e
Compare
acdlite
force-pushed
the
deopt-fix-reify-key-order
branch
from
July 24, 2026 19:47
fd46f90 to
cadc853
Compare
Contributor
Stats from current PR🟢 2 improvements
📊 All Metrics📖 Metrics GlossaryDev Server Metrics:
Build Metrics:
Change Thresholds:
⚡ Dev Server
📦 Dev Server (Webpack) (Legacy)📦 Dev Server (Webpack)
⚡ Production Builds
📦 Production Builds (Webpack) (Legacy)📦 Production Builds (Webpack)
📦 Bundle SizesBundle Sizes⚡ TurbopackClient Main Bundles
Server Middleware
Build DetailsBuild Manifests
📦 WebpackClient Main Bundles
Polyfills
Pages
Server Edge SSR
Middleware
Build DetailsBuild Manifests
Build Cache
🔄 Shared (bundler-independent)Runtimes
📝 Changed Files (10 files)Files with changes:
View diffsapp-page-exp..ntime.dev.jsfailed to diffapp-page-exp..time.prod.jsDiff too large to display app-page-tur..ntime.dev.jsfailed to diffapp-page-tur..time.prod.jsDiff too large to display app-page-tur..ntime.dev.jsfailed to diffapp-page-tur..time.prod.jsDiff too large to display app-page.runtime.dev.jsfailed to diffapp-page.runtime.prod.jsDiff too large to display pages-api-tu..ntime.dev.jsDiff too large to display pages-turbo...ntime.dev.jsDiff too large to display 📎 Tarball URLCommit: 9d3b6b6 |
Contributor
Tests PassedCommit: 9d3b6b6 |
acdlite
force-pushed
the
deopt-fix-reify-key-order
branch
from
July 24, 2026 19:57
cadc853 to
9d3b6b6
Compare
acdlite
marked this pull request as ready for review
July 24, 2026 20:14
samselikoff
approved these changes
Jul 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The segment cache's
RouteTreeobjects were being created with two different hidden-class families: the two object literals returned byreifyRouteTreeinoptimistic-routes.tslisted their keys in a different order (slots,prefetchHints,isPage,varyPathlast) than every otherRouteTreeconstructor site incache.ts(varyPath,isPage,slots,prefetchHintslast). In V8, object literals with different key orders get different hidden classes (maps), so every code path that touches both optimistically-reified trees and server-derived trees saw polymorphic shapes. Found withpnpm bench:deopt --scenario segment-cache(the V8 deopt detection tooling from the base branch).This change is behavior-neutral: it only reorders the keys in the two
reifyRouteTreeobject literals to match the canonical order used bycache.ts. No values, types, or logic change.With all
RouteTreeliterals collapsed to one hidden class, the fix eliminates the polymorphicRouteTree-field inline caches: 22 findings removed acrossoptimistic-routes.ts,scheduler.ts,cache.ts, andvary-path.tsin the before/after diff below (keysrequestKey/segment/refreshState/prefetchHints/slots/isPage/varyPath). Note: the two remainingwrong mapdeopts atoptimistic-routes.ts:904andscheduler.ts:1058are different object families — resolved-param values (string vs string[] atnewValue.join) andFlightRouterStatetuples (oldTree[1]) respectively — and are tracked separately. This PR does not claim to fix them.Before/after
findings.txtdiff (bench:deopt --scenario segment-cache, after run with--force-build):