- 21 Nov, 2018 1 commit
-
-
Ross McIlroy authored
Moves allocation of the WasmModuleObject for asm.js code out of SyncCompileTranslatedAsmJS since that is called when we are compiling the native context independent SharedFunctionInfo and the WasmModuleObject requires a native context. Instead save the members required to create the object in the AsmWasmData and create it during module instantiation. Note: since the Wasm module is an implementation detail for asm_wasm code and isn't exposed, this doeesn't have semantic change for asm.js code. As part of this change, the AsmWasmData is changed from a FixedArray to a dedicated struct. Some logic is also moved from module-compiler to wasm-engine to make the seperation between Wasm SyncCompile and AsmJS SyncCompile more clear. BUG=chromium:900535,v8:8395 Change-Id: Ia48469c095b0688f210aa86e7430c9ab4ea4b26b Reviewed-on: https://chromium-review.googlesource.com/c/1345509 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#57704}
-
- 24 Oct, 2018 1 commit
-
-
Ross McIlroy authored
BuildClassBoilerplate accessed the native context to get the class_function_descriptors. Baseline compilation should be native context independent, so we shouldn't access the native context at all. As it happens, class_function_descriptors wasn't used so can just be removed. BUG=chromium:898076, v8:8041 Change-Id: If9c0edf3dfde68c76ea87820f9d4b080aac6d60e Reviewed-on: https://chromium-review.googlesource.com/c/1298033Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56958}
-
- 12 Oct, 2018 1 commit
-
-
Ross McIlroy authored
Adds support for enqueuing parallel parse / compile tasks for eagerly compiled IIFEs during parsing. If the --parallel-compile-tasks flag is enabled, the parser will pre-parse eager top-level IIFEs and enqueue a task on the compiler dispatcher to do the actual parsing / compilation on a worker thread. Currently we always enqueue the task, but we likely want to only enqueue parallel tasks where the script has multiple IIFEs or a substantial amount of top-level script code before the IIFE to avoid the main thread having to immediately block on the parallel task. This work will be done as a follow-up. BUG=v8:8041 Change-Id: If68d7c374548cabd4ec32f1fb6752da7d6aaae6b Reviewed-on: https://chromium-review.googlesource.com/c/1275354Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56593}
-