Skip to content

[JSC] Predict the empty value for an unprofiled load of this of a derived constructor from its scope - #1017

Draft
robobun wants to merge 1 commit into
mainfrom
robobun/e0501bca/dfg-empty-this-of-derived-constructor
Draft

robobun wants to merge 1 commit into
mainfrom
robobun/e0501bca/dfg-empty-this-of-derived-constructor

Conversation

@robobun

@robobun robobun commented Nov 9, 2026 •

Copy link
Copy Markdown
Collaborator

Draft on purpose: for WebKit/WebKit first. See Route in Notes.

Problem

  • An arrow function that calls super() leaves optimized code again and again. The DFG compiles esbuild's __super helper 8 times in 60,000 constructions, with 25,508 exits (bc#8, InadequateCoverage).
  • It first reads this from the scope, to throw if a super() came before. The value is empty each time, and a value profile does not record that. So op_get_from_scope (DFGByteCodeParser.cpp:10930) has no prediction and plants ForceOSRExit.

Fix

  • op_get_from_scope predicts SpecEmpty for the name of this in a scope when the profile says SpecNone, as it does for ResolvedClosureVar.
  • The DFG then compiles the helper once, with no exit. A construction goes from 1072 to 80 instructions (release jsc, instructions:u).
  • Verified: JSTests/stress/dfg-arrow-function-with-super-call-is-compiled-once.js (new, fails on the base: "the DFG compiled initialize 6 times"). Self-reviewed: 2 concerns raised, 2 addressed (Notes).

Background

  • this of a derived constructor has no value before super() returns: its scope slot holds the empty value.
  • The DFG takes a bytecode with an empty value profile for code that did not run yet. It compiles an exit there, and recompiles after enough exits.
  • Considered a value profile that records the empty value: it changes every profile for one name.

Downsides

  • None found. Checked a read of this that first runs after the DFG compile: 178.7 against 179.1 instructions per construction in the DFG, 72.4 against 73.3 in all tiers. Release jsc has the same size.
Notes

Route. This PR does not ask for a merge into the fork as it stands.

Numbers. Release jsc of 5a61071 and of this branch, --useConcurrentJIT=0.

base this PR
const __super = (...args) => { super(...args); this.field = 2; return this; }, 60,000 constructions: DFG compiles of __super 8 1
the same: OSR exits in __super (--printEachOSRExit=1) 25,508 0
the same: instructions per construction, all tiers 1072 80
the same: instructions per construction, --useFTLJIT=0 1103 437
12 arrow functions that call super() in different forms and then use this, 12,000 constructions each: DFG compiles 6 each 1 each
the same with --useBytecodeOptimizer=1 1 each 1 each
  • With the bytecode optimizer the load is a ResolvedClosureVar, so the existing rule applies. That is why a bytecode image does not have the loop.
  • The instruction counts are the difference between runs of 3,000,000 and 1,000,000 constructions, median of 3.

The rule for ResolvedClosureVar. Its comment says that the empty value is a legitimate result there, and that a value profile cannot say so. Both hold for this of a derived constructor in a scope: the load in front of the check for a second super() gives the empty value on every path that does not throw.

What the prediction changes. A prediction is a hint. GetClosureVar can still give any value, and the check_tdz and is_empty that follow the load are compiled as before. The test runs the check for a second super() in optimized code.

Self-review. The review of #1018 asked for this line as a change of its own, with 1 DFG compile and no exit as the bar, and for a PR of its own. Both are done.

Test runs. The new test runs with --useConcurrentJIT=0. It fails on debug and release builds of the base and passes on both builds of this branch. A debug build with ASAN that has this PR, #1016 and #1018 passes the three new tests in every mode of run-jsc-stress-tests. 5,501 runs of other stress tests on that build, most of them in the two dfg-eager modes: 7 failures, stack overflows and a memory limit, which the base has too.

…ctor from its scope for a load of the empty value

An arrow function that calls super() first reads `this` of its derived constructor from the scope, to throw if
a super() came before. On each valid path that value is empty, and a value profile does not record the empty
value. So the DFG finds a load with no prediction, takes what follows for code that did not run yet, and plants
ForceOSRExit there. Each call of the arrow function then leaves the optimized code at that load.

    class Derived extends Base {
        constructor()
        {
            const __super = (...args) => { super(...args); this.field = 2; return this; };
            __super();
        }
    }

esbuild makes such a helper for a class whose fields it lowers. In 60,000 constructions the DFG compiles
__super 8 times and its code exits 25,508 times. A construction takes 1072 instructions (release jsc,
--useConcurrentJIT=0, instructions:u). With this change the DFG compiles it once, there is no exit in it, and a
construction takes 80 instructions.

op_get_from_scope has the answer for ResolvedClosureVar already: the prediction is SpecEmpty where the profile
says SpecNone. The same now holds for the name of `this` in a scope (thisPrivateName).

Test: JSTests/stress/dfg-arrow-function-with-super-call-is-compiled-once.js
@github-actions

github-actions Bot commented Nov 9, 2026

Copy link
Copy Markdown

Preview build of 89d38c4: autobuild-preview-pr-1017-89d38c4b

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant