RESOLVED FIXED 194693
[JSC] Do not even allocate JIT worklists in non-JIT mode
https://bugs.webkit.org/show_bug.cgi?id=194693
Summary [JSC] Do not even allocate JIT worklists in non-JIT mode
Yusuke Suzuki
Reported 2019-02-15 00:27:51 PST
[JSC] Do not even allocate JIT worklists in non-JIT mode
Attachments
Patch (14.72 KB, patch)
2019-02-15 00:33 PST, Yusuke Suzuki
no flags
Yusuke Suzuki
Comment 1 2019-02-15 00:33:46 PST
Mark Lam
Comment 2 2019-02-15 00:59:16 PST
Comment on attachment 362102 [details] Patch r=me
WebKit Commit Bot
Comment 3 2019-02-15 01:27:48 PST
Comment on attachment 362102 [details] Patch Clearing flags on attachment: 362102 Committed r241582: <https://trac.webkit.org/changeset/241582>
WebKit Commit Bot
Comment 4 2019-02-15 01:27:49 PST
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 5 2019-02-15 01:30:39 PST
Saam Barati
Comment 6 2019-02-15 09:35:59 PST
Comment on attachment 362102 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=362102&action=review > Source/JavaScriptCore/jit/JITWorklist.cpp:339 > + WTF::storeStoreFence(); Why? Doesn’t the once act as a barrier?
Yusuke Suzuki
Comment 7 2019-02-15 10:55:42 PST
Comment on attachment 362102 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=362102&action=review >> Source/JavaScriptCore/jit/JITWorklist.cpp:339 >> + WTF::storeStoreFence(); > > Why? Doesn’t the once act as a barrier? VM::~VM calls existingGlobalWorklistOrNull. It should not see half-baked JITWorklist. If the race happens and VM::~VM missed the worklist, it is OK since it means no plan associated to destroyed VM exists in the worklist.
Yusuke Suzuki
Comment 8 2019-02-15 11:06:25 PST
Comment on attachment 362102 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=362102&action=review >>> Source/JavaScriptCore/jit/JITWorklist.cpp:339 >>> + WTF::storeStoreFence(); >> >> Why? Doesn’t the once act as a barrier? > > VM::~VM calls existingGlobalWorklistOrNull. It should not see half-baked JITWorklist. > If the race happens and VM::~VM missed the worklist, it is OK since it means no plan associated to destroyed VM exists in the worklist. The important thing is... existingGlobalWorklistOrNull does not have barrier! I thought that DFG worklists have some mechanism guarding worklists against this race, but DFG worklist seems racy. I should put the fence to DFG/FTL worklists & Wasm worklist too.
Note You need to log in before you can comment on or make changes to this bug.