166097 2016-12-20 09:54:53 -0800 [JSC] JS Parser should work concurrently 2017-06-14 23:01:57 -0700 1 1 1 Unclassified WebKit JavaScriptCore WebKit Nightly Build Unspecified Unspecified NEW P2 Normal --- 1 ysuzuki ysuzuki fpizlo koivisto saam oldest_to_newest 1261454 0 ysuzuki 2016-12-20 09:54:53 -0800 <script async>, <script defer> and ES6 modules can receive benefit from parsing JS concurrently. 1314590 1 ysuzuki 2017-06-01 06:10:13 -0700 The largest problem is Identifier's AtomicStringTable. We never want to access to one AtomicStringTable concurrently. Fortunately, our parser infrastructure has ParserArena. And we access to Identifier through const Identifier*. So, my current plan is 1. Decouple VM from ParserArena. This also decouples VM from Parser largely. 2. ParserArena should have AtomicStringTable like things. And Parser arena generates Identifier. 3. Finally, we will merge AtomicStrings in non-UI thread into main thread's table. The great thing is that ParserArena holds Identifiers. Thus, after merging AtomicStrings, we will replace Identifier's impl with main-thread AtomicStringImpls. 1314591 2 ysuzuki 2017-06-01 06:11:24 -0700 (In reply to Yusuke Suzuki from comment #0) > <script async>, <script defer> and ES6 modules can receive benefit from > parsing JS concurrently. Since JSC's module mechanism is largely confined in JSC side, we can easily use concurrent JS parser in JSC. (I mean that it is not good design that WebCore touches concurrent JSC JS parsers). 1314644 3 saam 2017-06-01 09:27:12 -0700 Cool! I remember talking to Antti at some point where he said he wanted this. 1315101 4 koivisto 2017-06-02 10:33:37 -0700 +1 1319463 5 ysuzuki 2017-06-14 23:01:57 -0700 Interesting. http://dl.acm.org/citation.cfm?id=3004281 Yeah, we should consider pre-parse hash table and string table.