Bug 196384

Summary: Worklist should have a more fine grained way to just stop for some VMs
Product: WebKit Reporter: Saam Barati <saam>
Component: JavaScriptCoreAssignee: Saam Barati <saam>
Status: NEW    
Severity: Normal CC: benjamin, fpizlo, ggaren, gskachkov, guijemont, keith_miller, mark.lam, msaboff, rmorisset, ticaiolima, tzagallo, ysuzuki
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
WIP
none
WIP none

Saam Barati
Reported 2019-03-28 17:35:29 PDT
...
Attachments
WIP (8.66 KB, patch)
2019-03-28 19:02 PDT, Saam Barati 		no flags
DetailsFormatted DiffDiff
WIP (8.66 KB, patch)
2019-04-07 11:52 PDT, Saam Barati 		no flags
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Saam Barati
Comment 1 2019-03-28 17:41:21 PDT
So I have a WIP patch. I'm testing on 2-core x86-64 MBP (using instruments to bring my core count down to 2 w/ hyper threading). The patch makes us go from total CPU time spent in "Heap::suspendCompilerThreads" from 34000 ms to 400ms. However, it's not a progression on bomb-workers. And there's a slight chance it's even a regression. I wonder if it's revealing other forms of contention that per-process locking was somehow saving us from.
Saam Barati
Comment 2 2019-03-28 17:49:40 PDT
When I test in four core mode, it's also repeatably just a bit slower. However, we're also repeatably spending ~2 orders of magnitude less time in Heap::suspendCompilerThreads
Saam Barati
Comment 3 2019-03-28 19:02:23 PDT
Created attachment 366233 [details] WIP
Saam Barati
Comment 4 2019-04-07 11:52:21 PDT
Created attachment 366906 [details] WIP Stashing this WIP here.
Note You need to log in before you can comment on or make changes to this bug.