Bug 185967

Summary: Rope string sweeping should avoid touching unresolved ropes
Product: WebKit Reporter: Filip Pizlo <fpizlo>
Component: JavaScriptCoreAssignee: Filip Pizlo <fpizlo>
Status: NEW    
Severity: Normal CC: ews-watchlist, ggaren, keith_miller, mark.lam, msaboff, saam, ysuzuki
Priority: P2    
Version: WebKit Nightly Build   
Hardware: All   
OS: All   
Attachments:
Description Flags
work in progress
none
maybe it'll work
none
seems to kinda work
none
the patch ysuzuki: review+

Filip Pizlo
Reported 2018-05-24 16:45:27 PDT
Especially when ropes are being used in anger, a lot of JSRopeString objects are never resolved. Thus they don't need destruction. Since destruction is expensive, that would be useful to know. Ropes are usually unresolved because people do something like this: var result = ""; for (things) result += stuff use result In that case, we will create a JSRopeString for each iteration of the loop, but we will only resolve the last one. This comes up over and over again. For example, this: "foo" + bar + "baz" + fuzz + "buzz" + thingy + "stuff" will create three JSRopeStrings, but only the last one will get resolved.
Attachments
work in progress (40.75 KB, patch)
2018-05-24 16:47 PDT, Filip Pizlo
no flags
maybe it'll work (53.65 KB, patch)
2018-05-25 15:27 PDT, Filip Pizlo
no flags
seems to kinda work (56.45 KB, patch)
2018-05-25 17:09 PDT, Filip Pizlo
no flags
the patch (57.49 KB, patch)
2018-05-26 17:04 PDT, Filip Pizlo
ysuzuki: review+
Filip Pizlo
Comment 1 2018-05-24 16:47:21 PDT
Created attachment 341234 [details] work in progress
Filip Pizlo
Comment 2 2018-05-25 15:27:45 PDT
Created attachment 341338 [details] maybe it'll work
Filip Pizlo
Comment 3 2018-05-25 16:41:57 PDT
This patch has a crash bug, it's not any faster, and it wastes a lot of memory. I'm investigating. :-/
Filip Pizlo
Comment 4 2018-05-25 17:09:45 PDT
Created attachment 341361 [details] seems to kinda work But it's not a speed-up.
Filip Pizlo
Comment 5 2018-05-25 17:10:39 PDT
(In reply to Filip Pizlo from comment #4) > Created attachment 341361 [details] > seems to kinda work > > But it's not a speed-up. Or, rather, it's a *very small* speed-up. I'll play with it a bit more before giving up.
Filip Pizlo
Comment 6 2018-05-26 16:57:53 PDT
Seems to not be super great for perf. If anything, JetStream might be slower. I think that part of the problem is that those blocks that have unresolved rope strings tend to also not be completely empty, so we have to walk over them anyway. The high cost of creating ropes might also be so great as to dominate over the benefit of reducing sweep cost.
Filip Pizlo
Comment 7 2018-05-26 17:04:37 PDT
Created attachment 341413 [details] the patch Tiny splay speed-up. The speed-up is minuscule - around 1% - but significant. I confirmed it in run-jsc-benchmarks, in-browser JetStream, and running the benchmark manually. It could be an even bigger speed-up if I made bump'n'pop's pop path faster.
EWS Watchlist
Comment 8 2018-05-26 17:06:36 PDT
Attachment 341413 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/runtime/JSRopeStringHeapCellType.cpp:30: Alphabetical sorting problem. [build/include_order] [4] Total errors found: 1 in 21 files If any of these errors are false positives, please file a bug against check-webkit-style.
Yusuke Suzuki
Comment 9 2018-05-30 08:29:29 PDT
Comment on attachment 341413 [details] the patch View in context: https://bugs.webkit.org/attachment.cgi?id=341413&action=review r=me > Source/JavaScriptCore/heap/MarkedBlock.cpp:460 > +void MarkedBlock::Handle::sweep(FreeList* freeList) Replacing the position of `MarkedBlock::Handle::sweep` and `MarkedBlock::Handle::finishSweepWithNoDestructors` would make diff clean.
Note You need to log in before you can comment on or make changes to this bug.