Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: aa07769ee575e94efee687135493399e29409f20
https://github.com/WebKit/WebKit/commit/aa07769ee575e94efee687135493399e29409f20
Author: Dan Hecht <[email protected]>
Date: 2026-09-02 (Wed, 02 Sep 2026)
Changed paths:
A
JSTests/stress/object-allocation-sinking-phase-must-only-move-allocations-if-stack-trace-is-still-valid-closure-rule-promoted-parent.js
A
JSTests/stress/object-allocation-sinking-phase-must-only-move-allocations-if-stack-trace-is-still-valid-closure-rules.js
M Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp
Log Message:
-----------
[JSC] Fix Object Allocation Sinking closure rule for allocations within
inlined closure-call and varargs frames
https://bugs.webkit.org/show_bug.cgi?id=315674
rdar://176555185
Reviewed by Yijia Huang.
208291@main added an InlineCallFrame check that demotes candidate
allocations whose origin is a closure-call or varargs inline frame and
whose escape site is in a different frame. The check is necessary
because such an allocation, if sunk to the escape site, would have its
Materialize* node emitted where the frame's closure-call callee
slot or varargs argc slot has been reused by intervening code, causing
subsequent stack walks to potentially dereference garbage.
However, that fix was incomplete in two ways. First, the InlineCallFrame
check ran before the closure rule's worklist ("rule #2"), so it only
inspected the initial candidates. Rule #2 then promoted additional
dependencies to satisfy the closure invariant (a sink candidate stored
into a local allocation, that allocation must also be a sink candidate"),
and any such promoted allocation that would have failed the
InlineCallFrame check slipped through. Second, even for candidates the
check correctly removed, rule #2's worklist re-promoted them in order
to maintain its invariant, undoing the InlineCallFrame check.
Fix this with two complementary changes:
1. Run the closure rule (rule #2) before the InlineCallFrame check, so
the InlineCallFrame check sees both seeded and rule-#2-promoted
candidates and is the final determination of which stay sunk.
2. Add an additional closure rule (which was already documented as a
potential rule #1): remove candidates that depend on the candidates
that were demoted (due to the InlineCallFrame mismatch). Like the
original fix, this happens rarely.
Add an ASSERT in the materialization-placement loop to verify that no
allocation reaching it would fail the InlineCallFrame check. This
catches the bug pattern in debug builds and guards against future
regressions.
Test:
JSTests/stress/object-allocation-sinking-phase-must-only-move-allocations-if-stack-trace-is-still-valid-closure-rules.js
*
JSTests/stress/object-allocation-sinking-phase-must-only-move-allocations-if-stack-trace-is-still-valid-closure-rule-promoted-parent.js:
Added.
(makeInner.return.inner):
(makeInner):
(clobber):
(sink):
(opt):
*
JSTests/stress/object-allocation-sinking-phase-must-only-move-allocations-if-stack-trace-is-still-valid-closure-rules.js:
Added.
(makeInner.return.inner):
(makeInner):
(clobber):
(sink):
(opt):
* Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp:
Originally-landed-as: [email protected] (a4e027e916f5).
rdar://185368183
Canonical link: https://commits.webkit.org/320362@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
