Bug 236124

Summary: cache the result of JSString::toIdentifier
Product: WebKit Reporter: Cameron McCormack (:heycam) <heycam>
Component: JavaScriptCoreAssignee: Cameron McCormack (:heycam) <heycam>
Status: RESOLVED FIXED    
Severity: Normal CC: ews-watchlist, keith_miller, mark.lam, msaboff, saam, tzagallo, webkit-bug-importer, ysuzuki
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
patch
none
Patch
ews-feeder: commit-queue-
Patch none

Cameron McCormack (:heycam)
Reported 2022-02-03 21:05:03 PST
JSString::toIdentifier does not store the result of atomizing its string value, except when it is a rope. We can often end up atomizing the same JSString a number of times. Forthcoming patch caches the last atomized string produced from JSString::toIdentifier in a given VM. From local testing, this is a 0.5% Speedometer2 improvement on an M1 MacBook Air, although surprisingly is neutral on a recent Intel MacBook Pro.
Attachments
patch (5.81 KB, patch)
2022-02-03 21:09 PST, Cameron McCormack (:heycam)
no flags
Patch (4.42 KB, patch)
2022-02-05 20:22 PST, Cameron McCormack (:heycam)
ews-feeder: commit-queue-
Patch (4.40 KB, patch)
2022-02-05 20:51 PST, Cameron McCormack (:heycam)
no flags
Cameron McCormack (:heycam)
Comment 1 2022-02-03 21:09:37 PST
Radar WebKit Bug Importer
Comment 2 2022-02-03 21:10:06 PST
Yusuke Suzuki
Comment 3 2022-02-03 21:37:42 PST
Comment on attachment 450862 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=450862&action=review Nice, I have some questions. > Source/JavaScriptCore/runtime/JSString.h:785 > + if (vm.lastAtomizedString.ptr() != valueInternal().impl()) { > + vm.lastAtomizedString = *valueInternal().impl(); > + vm.lastAtomizedStringAtom = AtomStringImpl::add(valueInternal().impl()).releaseNonNull(); > + } Is there any reasons why we do not perform it in toAtomString? If we should do this cache only in `toIdentifier` call and we should do that only when converting existing non-atom-string to atom-string, then can we change lastAtomizedString / lastAtomizedStringAtom names to more specific ones?
Cameron McCormack (:heycam)
Comment 4 2022-02-03 21:39:00 PST
(In reply to Yusuke Suzuki from comment #3) > Is there any reasons why we do not perform it in toAtomString? No, I think I can move it down to toAtomString.
Saam Barati
Comment 5 2022-02-03 21:59:21 PST
Comment on attachment 450862 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=450862&action=review > Source/JavaScriptCore/ChangeLog:8 > + JSString::toIdentifier does not store the result of atomizing its string I wonder if this is worth doing.
Yusuke Suzuki
Comment 6 2022-02-03 22:10:39 PST
Comment on attachment 450862 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=450862&action=review >> Source/JavaScriptCore/ChangeLog:8 >> + JSString::toIdentifier does not store the result of atomizing its string > > I wonder if this is worth doing. This is because string is concurrently accessed from GC thread and concurrent compilers. If we replace it without stopping them, then these threads will touch the old String => UAF. If we would like to do that, we need some protocol to allow this.
Cameron McCormack (:heycam)
Comment 7 2022-02-05 19:42:58 PST
(In reply to Cameron McCormack (:heycam) from comment #4) > No, I think I can move it down to toAtomString. I forgot that's actually what I tried first, but didn't get good results. I will rename the variables.
Yusuke Suzuki
Comment 8 2022-02-05 20:13:40 PST
(In reply to Cameron McCormack (:heycam) from comment #7) > (In reply to Cameron McCormack (:heycam) from comment #4) > > No, I think I can move it down to toAtomString. > > I forgot that's actually what I tried first, but didn't get good results. I > will rename the variables. Sounds good to me!!
Cameron McCormack (:heycam)
Comment 9 2022-02-05 20:22:16 PST
Cameron McCormack (:heycam)
Comment 10 2022-02-05 20:51:28 PST
EWS
Comment 11 2022-02-06 12:39:10 PST
Committed r289177 (246871@main): <https://commits.webkit.org/246871@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 451023 [details].
Note You need to log in before you can comment on or make changes to this bug.