Bug 166097
| Summary: | [JSC] JS Parser should work concurrently | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Yusuke Suzuki <ysuzuki> |
| Component: | JavaScriptCore | Assignee: | Yusuke Suzuki <ysuzuki> |
| Status: | NEW | ||
| Severity: | Normal | CC: | fpizlo, koivisto, saam |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Yusuke Suzuki
<script async>, <script defer> and ES6 modules can receive benefit from parsing JS concurrently.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Yusuke Suzuki
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.
Yusuke Suzuki
(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).
Saam Barati
Cool! I remember talking to Antti at some point where he said he wanted this.
Antti Koivisto
+1
Yusuke Suzuki
Interesting. http://dl.acm.org/citation.cfm?id=3004281
Yeah, we should consider pre-parse hash table and string table.