WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
175013
Merge ThreadHolder to WTF::Thread itself
https://bugs.webkit.org/show_bug.cgi?id=175013
Summary
Merge ThreadHolder to WTF::Thread itself
Yusuke Suzuki
Reported
2017-08-01 01:53:34 PDT
By doing so, we can put WTF::Thread* directly to TLS (instead of putting ThreadHolder*, which holds Ref<Thread>). It reduces one level indirection. Yeah, ThreadHolder design is clean and great, but if this is important part, we should take more efficient design. Actually, we use fast TLS in some platforms (which is pre-allocated TLS by the system, and we can access it with super fast operation, like using segment registers). If we can drop one level indirection here, it would be awesome. TLS -> ThreadHolder* -> Thread* TLS -> Thread*
Attachments
Patch
(39.91 KB, patch)
2017-08-03 00:46 PDT
,
Yusuke Suzuki
no flags
Details
Formatted Diff
Diff
Patch
(40.13 KB, patch)
2017-08-03 04:23 PDT
,
Yusuke Suzuki
mark.lam
: review+
mark.lam
: commit-queue-
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Yusuke Suzuki
Comment 1
2017-08-03 00:46:18 PDT
Created
attachment 317098
[details]
Patch
Build Bot
Comment 2
2017-08-03 00:49:23 PDT
Attachment 317098
[details]
did not pass style-queue: ERROR: Source/WTF/wtf/ThreadingWin.cpp:353: This { should be at the end of the previous line [whitespace/braces] [4] Total errors found: 1 in 5 files If any of these errors are false positives, please file a bug against check-webkit-style.
Yusuke Suzuki
Comment 3
2017-08-03 04:23:04 PDT
Created
attachment 317110
[details]
Patch
Build Bot
Comment 4
2017-08-03 04:24:27 PDT
Attachment 317110
[details]
did not pass style-queue: ERROR: Source/WTF/wtf/ThreadingWin.cpp:350: This { should be at the end of the previous line [whitespace/braces] [4] Total errors found: 1 in 5 files If any of these errors are false positives, please file a bug against check-webkit-style.
Mark Lam
Comment 5
2017-08-03 08:30:44 PDT
Comment on
attachment 317110
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=317110&action=review
r=me with issues resolved (including broken windows build) and EWS bots are green.
> Source/WTF/wtf/Threading.h:69 > class Thread : public ThreadSafeRefCounted<Thread> {
I didn't think of this before but we need to double check something here: ThreadHolder is not allocated with bmalloc, but ThreadSafeRefCounted is. Therefore, Thread is also allocated with bmalloc. We need to make sure that there's no unsafe interaction between bmalloc and TLS (basically, does bmalloc also depend on TLS ... if so, we need to make sure thread TLS clean up happens before bmalloc TLS clean up). Otherwise, we need to use a non-bmalloc ThreadSafeRefCounted. But since this is not an issue introduced in this patch, we can consider fixing it in a subsequent patch (if needed).
> Source/WTF/wtf/Threading.h:240 > + // Holds Thread in the thread-specific storage. The destructor of current thread TLS reliably destroy Thread.
I would rephrase this as: The Thread instance is ref'ed and held in thread-specific storage. It will be deref'ed by destructTLS at thread destruction time.
> Source/WTF/wtf/ThreadingPthreads.cpp:477 > + auto& threadInTLS = thread.leakRef();
I suggest adding a comment before this to say something like: We leak the ref to keep the Thread alive while it is held in TLS. destructTLS will deref it later at thread destruction time.
> Source/WTF/wtf/ThreadingWin.cpp:314 > + auto& threadInTLS = thread.leakRef();
Please add the comment here as suggested in ThreadingPthreads about why we leakRef.
Yusuke Suzuki
Comment 6
2017-08-03 11:16:53 PDT
Comment on
attachment 317110
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=317110&action=review
>> Source/WTF/wtf/Threading.h:69 >> class Thread : public ThreadSafeRefCounted<Thread> { > > I didn't think of this before but we need to double check something here: ThreadHolder is not allocated with bmalloc, but ThreadSafeRefCounted is. Therefore, Thread is also allocated with bmalloc. We need to make sure that there's no unsafe interaction between bmalloc and TLS (basically, does bmalloc also depend on TLS ... if so, we need to make sure thread TLS clean up happens before bmalloc TLS clean up). Otherwise, we need to use a non-bmalloc ThreadSafeRefCounted. > > But since this is not an issue introduced in this patch, we can consider fixing it in a subsequent patch (if needed).
Sounds reasonable. I think bmalloc should do well even in the face of TLS. Otherwise, we cannnot use any values allocated in bmalloc in TLS. And I think this issue remains even before introducing WTF::Thread. Before that, we used HashMap to manage thread handle and id. If we remove id from the hash map, the hash map could call delete to the bucket. And since the hash map and its buckets are allocated in bmalloc, yeah, it causes issues. I've checked it in the current macOS. And it turns out that macOS FastTLS is ok because bmalloc's FastTLS number is smaller than this TLS. (I've tested it in my macOS laptop). But anyway, it's safer to use non bmalloc things in TLS destroyed related things. I'll file it separately.
>> Source/WTF/wtf/Threading.h:240 >> + // Holds Thread in the thread-specific storage. The destructor of current thread TLS reliably destroy Thread. > > I would rephrase this as: > The Thread instance is ref'ed and held in thread-specific storage. It will be deref'ed by destructTLS at thread destruction time.
OK, fixed.
>> Source/WTF/wtf/ThreadingPthreads.cpp:477 >> + auto& threadInTLS = thread.leakRef(); > > I suggest adding a comment before this to say something like: > We leak the ref to keep the Thread alive while it is held in TLS. destructTLS will deref it later at thread destruction time.
Sounds fine. Fixed.
>> Source/WTF/wtf/ThreadingWin.cpp:314 >> + auto& threadInTLS = thread.leakRef(); > > Please add the comment here as suggested in ThreadingPthreads about why we leakRef.
OK, fixed.
Yusuke Suzuki
Comment 7
2017-08-03 11:29:21 PDT
Committed
r220214
: <
http://trac.webkit.org/changeset/220214
>
Radar WebKit Bug Importer
Comment 8
2017-08-03 11:30:59 PDT
<
rdar://problem/33704658
>
Yusuke Suzuki
Comment 9
2017-08-03 11:40:46 PDT
Comment on
attachment 317110
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=317110&action=review
>>> Source/WTF/wtf/Threading.h:69 >>> class Thread : public ThreadSafeRefCounted<Thread> { >> >> I didn't think of this before but we need to double check something here: ThreadHolder is not allocated with bmalloc, but ThreadSafeRefCounted is. Therefore, Thread is also allocated with bmalloc. We need to make sure that there's no unsafe interaction between bmalloc and TLS (basically, does bmalloc also depend on TLS ... if so, we need to make sure thread TLS clean up happens before bmalloc TLS clean up). Otherwise, we need to use a non-bmalloc ThreadSafeRefCounted. >> >> But since this is not an issue introduced in this patch, we can consider fixing it in a subsequent patch (if needed). > > Sounds reasonable. I think bmalloc should do well even in the face of TLS. Otherwise, we cannnot use any values allocated in bmalloc in TLS. > And I think this issue remains even before introducing WTF::Thread. Before that, we used HashMap to manage thread handle and id. > If we remove id from the hash map, the hash map could call delete to the bucket. And since the hash map and its buckets are allocated in bmalloc, yeah, it causes issues. > > I've checked it in the current macOS. And it turns out that macOS FastTLS is ok because bmalloc's FastTLS number is smaller than this TLS. (I've tested it in my macOS laptop). > But anyway, it's safer to use non bmalloc things in TLS destroyed related things. I'll file it separately.
It seems that the current bmalloc is OK with this. Even if bmalloc Cache in TLS is destroyed, it will be re-generated if it becomes necessary (when destroying bmalloc things). And it will be re-destroyed after that. In the case of macOS, currently, bmalloc TLS is destroyed after the other TLS things are destroyed. I'm not sure it is ensured. But even if it is not ensured, the above mechanism makes it safe. But this design potentially has several issues. 1. In Windows, TLS revival is not supported. Thus, when porting bmalloc to Windows, we need to do it extra-carefully. 2. If bmalloc Cache is constantly revived, it is simply not efficient. We need to investigate what actually happens especially in Linux platforms. (since macOS uses fast TLS and I ensured it works fine).
Yusuke Suzuki
Comment 10
2017-08-03 11:59:50 PDT
Committed
r220217
: <
http://trac.webkit.org/changeset/220217
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug