RESOLVED FIXED 229018
Add thread safe version of CanMakeCheckedPtr
https://bugs.webkit.org/show_bug.cgi?id=229018
Summary Add thread safe version of CanMakeCheckedPtr
Ryosuke Niwa
Reported 2021-08-11 18:59:43 PDT
Like ThreadSafeRefCounted, we should have a thread safe version of CanMakeCheckedPtr.
Attachments
Patch (6.31 KB, patch)
2021-08-12 00:29 PDT, Ryosuke Niwa
no flags
Patch for landing (6.91 KB, patch)
2021-08-16 13:12 PDT, Ryosuke Niwa
no flags
Ryosuke Niwa
Comment 1 2021-08-12 00:29:27 PDT
Ryosuke Niwa
Comment 2 2021-08-12 02:40:53 PDT
Antti suggested that maybe we can use fetch_add/fetch_sub(1, std::memory_order_relaxed) instead of operator++/--. I suspect we want memory_order_acq_rel instead because we don't want these operations to be reordered with other things happening in the thread. WDYT?
Geoffrey Garen
Comment 3 2021-08-12 16:21:17 PDT
On modern ARM64, std::memory_order_relaxed compiles to ldadd / stdadd. Those are refcount-optimized instructions that are literally free (as far as I can tell after benchmarking MallocBench, PLT, JetStream2, and Speedometer2 with atomic refcounting enabled for *all* objects). So, it's nice to use std::memory_order_relaxed, since it puts us on a path to good performance. (On Intel, std::memory_order_relaxed doesn't help. Atomics are always slow.) I can imagine some theoretical benefits to acquire / release semantics, or sequential consistency semantics, in our refcounted objects. But I believe "it's free, just use it" will be a bigger benefit in the end. So, I'd favor a switch to std::memory_order_relaxed in our thread-safe refcounts. That said, ThreadSafeRefCountedBase currently does ++/--, so maybe the best thing is to land this patch doing the same, and then switch them both. I'd prefer for our approach to be consistent throughout the code.
Geoffrey Garen
Comment 4 2021-08-12 16:22:55 PDT
Comment on attachment 435397 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=435397&action=review r=me > Source/WTF/wtf/CheckedRef.h:253 > + operator IntegralType() const { assertThread(); return m_value; } > + bool operator!() const { assertThread(); return !m_value; } > + SingleThreadIntegralWrapper& operator++() { assertThread(); m_value++; return *this; } > + SingleThreadIntegralWrapper& operator--() { assertThread(); m_value--; return *this; } We can probably afford one line per statement for readability here.
Darin Adler
Comment 5 2021-08-12 16:44:45 PDT
Comment on attachment 435397 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=435397&action=review >> Source/WTF/wtf/CheckedRef.h:253 >> + SingleThreadIntegralWrapper& operator--() { assertThread(); m_value--; return *this; } > > We can probably afford one line per statement for readability here. My preference is to move functions out of the class body when we find we need multiple lines and multiple statements, and I think that works just fine even though you do have to add the inline keyword.
Ryosuke Niwa
Comment 6 2021-08-16 11:55:37 PDT
(In reply to Darin Adler from comment #5) > Comment on attachment 435397 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=435397&action=review > > >> Source/WTF/wtf/CheckedRef.h:253 > >> + SingleThreadIntegralWrapper& operator--() { assertThread(); m_value--; return *this; } > > > > We can probably afford one line per statement for readability here. > > My preference is to move functions out of the class body when we find we > need multiple lines and multiple statements, and I think that works just > fine even though you do have to add the inline keyword. Sure, I'd do both.
Ryosuke Niwa
Comment 7 2021-08-16 13:12:13 PDT
Created attachment 435625 [details] Patch for landing
EWS
Comment 8 2021-08-16 13:42:07 PDT
Committed r281105 (240564@main): <https://commits.webkit.org/240564@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 435625 [details].
Radar WebKit Bug Importer
Comment 9 2021-08-16 13:43:19 PDT
Note You need to log in before you can comment on or make changes to this bug.