Bug 215153

Summary: [JSC] Use LazyNeverDestroyed & std::call_once for complex singletons
Product: WebKit Reporter: Yusuke Suzuki <ysuzuki>
Component: New BugsAssignee: Yusuke Suzuki <ysuzuki>
Status: RESOLVED FIXED    
Severity: Normal CC: benjamin, cdumez, cmarcelo, ews-watchlist, hi, joepeck, keith_miller, kkinnunen, mark.lam, msaboff, saam, tzagallo, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch none

Yusuke Suzuki
Reported 2020-08-04 18:05:36 PDT
[JSC] Use LazyNeverDestroyed & std::call_once for complex singletons
Attachments
Patch (17.32 KB, patch)
2020-08-04 18:09 PDT, Yusuke Suzuki 		no flags
DetailsFormatted DiffDiff
Patch (18.18 KB, patch)
2020-08-04 18:14 PDT, Yusuke Suzuki 		no flags
DetailsFormatted DiffDiff
Patch (18.15 KB, patch)
2020-08-04 18:24 PDT, Yusuke Suzuki 		no flags
DetailsFormatted DiffDiff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Yusuke Suzuki
Comment 1 2020-08-04 18:09:18 PDT
Created attachment 405972 [details] Patch
Yusuke Suzuki
Comment 2 2020-08-04 18:09:21 PDT
<rdar://problem/65718983>
Yusuke Suzuki
Comment 3 2020-08-04 18:14:21 PDT
Created attachment 405973 [details] Patch
Yusuke Suzuki
Comment 4 2020-08-04 18:24:57 PDT
Created attachment 405975 [details] Patch
Mark Lam
Comment 5 2020-08-04 18:37:12 PDT
Comment on attachment 405975 [details] Patch r=me
Yusuke Suzuki
Comment 6 2020-08-04 20:57:45 PDT
stress/put-by-val-direct-putprivate.js.dfg-eager is failing recently.
EWS
Comment 7 2020-08-04 21:19:10 PDT
Committed r265276: <https://trac.webkit.org/changeset/265276> All reviewed patches have been landed. Closing bug and clearing flags on attachment 405975 [details].
Keith Miller
Comment 8 2020-08-05 10:57:24 PDT
Should we have a class that contains the std::once and whatnot? Maybe call it ConcurrentLazyNeverDestroyed or something?
Kimmo Kinnunen
Comment 9 2021-04-20 02:35:03 PDT
What's the logic in the commit? > WebKit's static does not have thread-safety. Isn't the deduction against c++11 spec? Function local static initialization is specified to be thread-safe? Here is example: https://godbolt.org/z/jcMz9M11d Here is discussion: https://stackoverflow.com/questions/26013650/threadsafe-lazy-initialization-static-vs-stdcall-once-vs-double-checked-locki/27206650 What makes WebKit statics broken? Asking because I see plenty of static uses in WebKit that rely on this...
Yusuke Suzuki
Comment 10 2021-04-20 03:15:56 PDT
(In reply to Kimmo Kinnunen from comment #9) > What's the logic in the commit? > > > WebKit's static does not have thread-safety. > > Isn't the deduction against c++11 spec? We are explicitly disabling that in WebKit for performance reason via -fno-threadsafe-statics. Check GCC_THREADSAFE_STATICS in WebKit tree. > > Function local static initialization is specified to be thread-safe? > > Here is example: > https://godbolt.org/z/jcMz9M11d > > Here is discussion: > https://stackoverflow.com/questions/26013650/threadsafe-lazy-initialization- > static-vs-stdcall-once-vs-double-checked-locki/27206650 > > What makes WebKit statics broken? > Asking because I see plenty of static uses in WebKit that rely on this...
Note You need to log in before you can comment on or make changes to this bug.