RESOLVED FIXED 128291
GC blocks on FTL and then badness
https://bugs.webkit.org/show_bug.cgi?id=128291
Summary GC blocks on FTL and then badness
Filip Pizlo
Reported 2014-02-05 19:07:20 PST
This is the primary reason for the FTL appearing to be a regression on Octane/typescript. It's probably also the reason for the Octane/gbemu regression. And it's the reason why we need so many compiler threads. We should totally fix this. I suspect that we might be able to make LLVM compilation concurrent with the GC. But it seems hard-ish. And if we make it work then we might as well make concurrent compilation work concurrently with GC full stop. I have a hard time imagining why this wouldn't work, if we just marked everything event slightly reachable (weakly, strongly, or anythingly) from the to-be-compiled code block so long as it was part of a DFG::Plan that is on any worklist.
Attachments
work in progress (53.17 KB, patch)
2014-02-07 22:10 PST, Filip Pizlo
no flags
the patch (59.44 KB, patch)
2014-02-09 11:32 PST, Filip Pizlo
no flags
the patch (73.09 KB, patch)
2014-02-09 12:11 PST, Filip Pizlo
no flags
the patch (73.56 KB, patch)
2014-02-09 12:22 PST, Filip Pizlo
no flags
the patch (74.90 KB, patch)
2014-02-09 12:32 PST, Filip Pizlo
no flags
the patch (76.13 KB, patch)
2014-02-09 12:39 PST, Filip Pizlo
no flags
the patch (76.95 KB, patch)
2014-02-09 12:47 PST, Filip Pizlo
no flags
the patch (78.16 KB, patch)
2014-02-09 12:53 PST, Filip Pizlo
no flags
the patch (78.96 KB, patch)
2014-02-09 13:00 PST, Filip Pizlo
no flags
the ptch (79.80 KB, patch)
2014-02-09 13:08 PST, Filip Pizlo
no flags
the patch (80.51 KB, patch)
2014-02-09 13:13 PST, Filip Pizlo
no flags
the patch (52.13 KB, patch)
2014-02-09 18:58 PST, Filip Pizlo
no flags
the patch (52.21 KB, patch)
2014-02-09 19:01 PST, Filip Pizlo
oliver: review+
Mark Hahnenberg
Comment 1 2014-02-05 19:10:09 PST
*** Bug 125518 has been marked as a duplicate of this bug. ***
Filip Pizlo
Comment 2 2014-02-05 22:22:23 PST
Here's my new strawman proposal, consisting of two standalone bugs: 1) When GC starts, don't wait for the worklist to become empty like we do now. Instead, ask for the current compilations to finish and ask the JIT threads not to dequeue any more work, and then strongly visit all references from all DFG::Plan's still on the worklist. A DFG::Plan is a CodeBlock plus a few other things. => A close alternative would be to just remove any Plans from the worklist that had CodeBlocks that died during GC. This is doable but seems trickier. This would be a standalone patch and it would be a speed-up. It's embarrassing, but in trunk we really do have GC wait for *all* outstanding compilations to finish. This is a big part of our problems. 2) When the GC asks for the current compilations to finish, make it treat JIT threads that are currently blocked on LLVM as "safe" threads and let them proceed concurrently. In proper safepointing fashion, this means each thread effectively will have a "right-to-run" mutex. The thread will acquire this mutex precisely when it is about to do DFG work. It will release it just before waiting for more work from the worklist, and also just before calling into LLVM. If the thread every releases the right-to-run mutex while holding onto a DFG::Graph, it will make sure that the DFG::Graph is available to the GC for scanning. The workflow of an FTL thread will thus be: Mutex rightToRun; // Per-thread variable visible to the GC Graph* graph = 0; // Per-thread variable visible to the GC for (;;) { RefPtr<Plan> plan = worklist.pop(); { Locker locker(rightToRun); DFG::parse(plan); DFG::optimize(plan); FTL::lowerDFGToLLVM(plan); graph = &plan.graph; } LLVM::doThings(plan); { Locker locker(rightToRun); graph = 0; FTL::link(plan); plan.complete(); } } The DFG workflow will be simpler: Mutex rightToRun; // Per-thread variable visible to the GC for (;;) { RefPtr<Plan> plan = worklist.pop(); { Locker locker(rightToRun); DFG::parse(plan); DFG::optimize(plan); DFG::generate(plan); plan.complete(); } } The GC will acquire the rightToRun of each JIT thread before GC starts, and will release the rightToRun of each JIT thread after GC ends. While the GC is running, it will inspect each JIT thread's graph - if it's non-null, then it will strongly scan it.
Filip Pizlo
Comment 3 2014-02-07 22:10:45 PST
Created attachment 223548 [details] work in progress
Filip Pizlo
Comment 4 2014-02-09 11:32:51 PST
Created attachment 223635 [details] the patch I think it's ready, but I'm not setting r? because I have no tests to do.
Filip Pizlo
Comment 5 2014-02-09 12:11:13 PST
Created attachment 223637 [details] the patch
WebKit Commit Bot
Comment 6 2014-02-09 12:13:48 PST
Attachment 223637 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/dfg/DFGJITCompiler.cpp:44: Alphabetical sorting problem. [build/include_order] [4] Total errors found: 1 in 42 files If any of these errors are false positives, please file a bug against check-webkit-style.
Filip Pizlo
Comment 7 2014-02-09 12:22:29 PST
Created attachment 223638 [details] the patch
WebKit Commit Bot
Comment 8 2014-02-09 12:25:02 PST
Attachment 223638 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/dfg/DFGJITCompiler.cpp:45: Alphabetical sorting problem. [build/include_order] [4] Total errors found: 1 in 43 files If any of these errors are false positives, please file a bug against check-webkit-style.
Filip Pizlo
Comment 9 2014-02-09 12:32:25 PST
Created attachment 223639 [details] the patch
Filip Pizlo
Comment 10 2014-02-09 12:39:41 PST
Created attachment 223640 [details] the patch
Filip Pizlo
Comment 11 2014-02-09 12:47:01 PST
Created attachment 223642 [details] the patch
Filip Pizlo
Comment 12 2014-02-09 12:53:49 PST
Created attachment 223643 [details] the patch
WebKit Commit Bot
Comment 13 2014-02-09 12:55:38 PST
Attachment 223643 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/bytecode/SamplingTool.cpp:34: Alphabetical sorting problem. [build/include_order] [4] Total errors found: 1 in 54 files If any of these errors are false positives, please file a bug against check-webkit-style.
Filip Pizlo
Comment 14 2014-02-09 13:00:40 PST
Created attachment 223644 [details] the patch
Filip Pizlo
Comment 15 2014-02-09 13:08:49 PST
Created attachment 223645 [details] the ptch
Filip Pizlo
Comment 16 2014-02-09 13:13:14 PST
Created attachment 223646 [details] the patch
Filip Pizlo
Comment 17 2014-02-09 18:58:37 PST
Created attachment 223663 [details] the patch
Filip Pizlo
Comment 18 2014-02-09 19:01:22 PST
Created attachment 223664 [details] the patch
WebKit Commit Bot
Comment 19 2014-02-09 19:03:27 PST
Attachment 223664 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/dfg/DFGThreadData.cpp:30: You should not add a blank line before implementation file's own header. [build/include_order] [4] ERROR: Source/JavaScriptCore/dfg/DFGSafepoint.cpp:30: You should not add a blank line before implementation file's own header. [build/include_order] [4] ERROR: Source/JavaScriptCore/dfg/DFGGraphSafepoint.cpp:30: You should not add a blank line before implementation file's own header. [build/include_order] [4] Total errors found: 3 in 23 files If any of these errors are false positives, please file a bug against check-webkit-style.
Filip Pizlo
Comment 20 2014-02-09 23:16:50 PST
Mark Hahnenberg
Comment 21 2014-02-20 12:21:48 PST
*** Bug 125518 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.