Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 8b5e6ebb64e65a4aefd8c9de48916c7da5438841
https://github.com/WebKit/WebKit/commit/8b5e6ebb64e65a4aefd8c9de48916c7da5438841
Author: Yijia Huang <[email protected]>
Date: 2026-08-11 (Tue, 11 Aug 2026)
Changed paths:
M Source/JavaScriptCore/runtime/JSONObject.cpp
Log Message:
-----------
[JSC] Reland: cache FastStringifier's buffer pointer and length across
property-name emission
https://bugs.webkit.org/show_bug.cgi?id=321518
rdar://184628273
Reviewed by Yusuke Suzuki.
Relands 318944@main (ea3fbb33caa5), reverted in 318969@main (ba1d526398de) for a
perf regression, with the property-value half dropped.
ea3fbb3 cached buffer() and m_length in two places: the property-name block and
the inlined string-value block. Dropping the value block is what recovers the
regression. That block is also the half that grew the hot lambda's frame from
0x50 to 0x60, which is the suspicious part: in DynamicBuffer mode append()
recurses once per nesting level behind a softStackLimit() check, and crossing
that
check abandons the whole fast path for the generic Stringifier instead of
degrading gradually.
This reland keeps only the property-name block, which is where the reloads are
concentrated (19 for 9 stores). The frame is back to 0x50 and stack traffic
matches baseline. The discipline is unchanged: locals are captured after
hasRemainingCapacity(), which can reallocate; m_length is published before
appendNewLineAndIndentUnchecked(), which reads and advances it, and before every
bail-out.
Hot instantiation (Latin1, DynamicBuffer, HasGap::No): 1712 -> 1660 bytes, loads
70 -> 61, member reloads 26 -> 17.
Note the reverted version was better on every one of those counters -- 1648
bytes, 56 loads, 12 reloads -- and still regressed. Reload count is a proxy, not
the objective.
Canonical link: https://commits.webkit.org/318990@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
