Bug 215153 - [JSC] Use LazyNeverDestroyed & std::call_once for complex singletons
Summary: [JSC] Use LazyNeverDestroyed & std::call_once for complex singletons
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Yusuke Suzuki
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-08-04 18:05 PDT by Yusuke Suzuki
Modified: 2021-04-20 03:15 PDT (History)
13 users (show)

See Also:


Attachments
Patch (17.32 KB, patch)
2020-08-04 18:09 PDT, Yusuke Suzuki
no flags Details | Formatted Diff | Diff
Patch (18.18 KB, patch)
2020-08-04 18:14 PDT, Yusuke Suzuki
no flags Details | Formatted Diff | Diff
Patch (18.15 KB, patch)
2020-08-04 18:24 PDT, Yusuke Suzuki
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yusuke Suzuki 2020-08-04 18:05:36 PDT
[JSC] Use LazyNeverDestroyed & std::call_once for complex singletons
Comment 1 Yusuke Suzuki 2020-08-04 18:09:18 PDT
Created attachment 405972 [details]
Patch
Comment 2 Yusuke Suzuki 2020-08-04 18:09:21 PDT
<rdar://problem/65718983>
Comment 3 Yusuke Suzuki 2020-08-04 18:14:21 PDT
Created attachment 405973 [details]
Patch
Comment 4 Yusuke Suzuki 2020-08-04 18:24:57 PDT
Created attachment 405975 [details]
Patch
Comment 5 Mark Lam 2020-08-04 18:37:12 PDT
Comment on attachment 405975 [details]
Patch

r=me
Comment 6 Yusuke Suzuki 2020-08-04 20:57:45 PDT
stress/put-by-val-direct-putprivate.js.dfg-eager is failing recently.
Comment 7 EWS 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].
Comment 8 Keith Miller 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?
Comment 9 Kimmo Kinnunen 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...
Comment 10 Yusuke Suzuki 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...