- 03 Feb, 2018 1 commit
-
-
Sathya Gunasekaran authored
Report an error during scope analysis if we're unable to find a variable proxy for the given private field. This can happen if we try to access a private field that was not defined or if we're outside the class scope. This doesn't correctly throw an early error when pre parsing a top level function because we don't track it's variables. Bug: v8:5368 Change-Id: I0a1193fe0ae213c0732fae5d435e150852a8d87d Reviewed-on: https://chromium-review.googlesource.com/892093Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#51082}
-
- 04 Jan, 2018 1 commit
-
-
Sathya Gunasekaran authored
Create a new function kind for initializer functions and ban arguments if used in such a function. Bug: v8:5367, v8:7183 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Id3089e587b3d6a25f27224045f250e032b831818 Reviewed-on: https://chromium-review.googlesource.com/850547 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#50369}
-
- 12 Dec, 2017 3 commits
-
-
Georg Neis authored
This is a reland of c3bd741e Original change's description: > Fix "this" value in lazily-parsed module functions. > > When preparsing top-level functions in a module, we didn't track > unresolved variables. Consequently, "this" ended up referencing > the global "this", which has the wrong value (in a module "this" > is supposed to be the undefined value). > > This patch fixes that. This also lets us stop forcing context > allocation of all variables in module scopes, which the patch > takes care of as well. > > Bug: chromium:791334 > Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf > Reviewed-on: https://chromium-review.googlesource.com/808938 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#50025} TBR=adamk@chromium.org TBR=kozyatinskiy@chromium.org Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Bug: chromium:791334 Change-Id: I57acc7b84a345565b36cbb55924fa2ff9b449eec Reviewed-on: https://chromium-review.googlesource.com/822341 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#50045}
-
Michael Achenbach authored
This reverts commit c3bd741e. Reason for revert: Breaks layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/20384 Original change's description: > Fix "this" value in lazily-parsed module functions. > > When preparsing top-level functions in a module, we didn't track > unresolved variables. Consequently, "this" ended up referencing > the global "this", which has the wrong value (in a module "this" > is supposed to be the undefined value). > > This patch fixes that. This also lets us stop forcing context > allocation of all variables in module scopes, which the patch > takes care of as well. > > Bug: chromium:791334 > Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf > Reviewed-on: https://chromium-review.googlesource.com/808938 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#50025} TBR=adamk@chromium.org,marja@chromium.org,neis@chromium.org,kozyatinskiy@chromium.org Change-Id: I81f69334ed2ce104c00e6205d50001e4bdf07d15 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:791334 Reviewed-on: https://chromium-review.googlesource.com/822258Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#50036}
-
Georg Neis authored
When preparsing top-level functions in a module, we didn't track unresolved variables. Consequently, "this" ended up referencing the global "this", which has the wrong value (in a module "this" is supposed to be the undefined value). This patch fixes that. This also lets us stop forcing context allocation of all variables in module scopes, which the patch takes care of as well. Bug: chromium:791334 Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf Reviewed-on: https://chromium-review.googlesource.com/808938Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#50025}
-
- 27 Nov, 2017 1 commit
-
-
Adam Klein authored
Besides avoiding the weird hack of inserting a statement at the 0th index of the function body, we also avoid allocating (and initializing) the variable if it's unreferenced (which I'd wager is the common case). Bug: v8:6092 Change-Id: If917d422bb4818cf21e8272aa786ca84d4472802 Reviewed-on: https://chromium-review.googlesource.com/784092Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#49646}
-
- 25 Oct, 2017 1 commit
-
-
Adam Klein authored
It's been on by default since Chrome 61. Bug: v8:4806 Change-Id: I748d9008d29997667458649d7bf4999e15ff8615 Reviewed-on: https://chromium-review.googlesource.com/737416 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#48943}
-
- 22 Oct, 2017 1 commit
-
-
Georg Neis authored
The information that such functions must be parsed in module mode didn't get properly propagated. Also refactor some related code to make it more robust. In particular, set parsing_module_ at parser construction time only. Bug: v8:1569, v8:6919 Change-Id: Id136fb15c240373cad07c82025b778d0c0c43148 Reviewed-on: https://chromium-review.googlesource.com/716478 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48811}
-
- 17 Oct, 2017 1 commit
-
-
Adam Klein authored
Inner functions which called eval, and were the kind of functions that can use `super`, were erroneously not marked as "uses_super_property", leading to downstream crashes when the runtime tried to load the [[HomeObject]] from them. This patch eliminates the public Scope::uses_super_property() API and ensures that callers always call Scope::NeedsHomeObject() instead. This is a minimal fix designed for easy merging; it's likely that in the long run we should remove most mentions of "uses super property" and replace them with "needs home object" for clarity. Bug: v8:5516, chromium:774994 Change-Id: Id269dd33e35bd40f6b59a3d3e19330687afa64f8 Reviewed-on: https://chromium-review.googlesource.com/721879Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48619}
-
- 16 Oct, 2017 1 commit
-
-
Leszek Swirski authored
Bug: v8:6921 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I3294568a550b829b0ec90147a4cdaefe169bb7cb Reviewed-on: https://chromium-review.googlesource.com/718206Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#48587}
-
- 13 Oct, 2017 1 commit
-
-
Mathias Bynens authored
New code should use nullptr instead of NULL. This patch updates existing use of NULL to nullptr where applicable, making the code base more consistent. BUG=v8:6928,v8:6921 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I4687f5b96fcfd88b41fa970a2b937b4f6538777c Reviewed-on: https://chromium-review.googlesource.com/718338 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#48557}
-
- 05 Oct, 2017 1 commit
-
-
Marja Hölttä authored
The catch variable is a special VAR-mode variable which is not in a declaration scope. Normally creating such a variable is not possible with DeclareVariable, but Parser bypasses it by calling DeclareLocal directly (which doesn't have the hoisting check). PreParser used to cut corners and declare the catch variable as a LET-mode variable to prevent hoisting. But since LET and VAR variables behave differently when deciding whether they block sloppy block function hoisting, that approach doesn't fly. BUG=v8:5516,chromium:771474 Change-Id: Ic6f5f4996416c9fa59132725c8b0b6b570c72f48 Reviewed-on: https://chromium-review.googlesource.com/700634 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48308}
-
- 22 Aug, 2017 1 commit
-
-
Ross McIlroy authored
Instead of creating a new character stream to re-parse the asm.js module, use the existing stream which was used by the parser. By doing this, we avoid accessing the heap if the original character stream is a streaming source or an external string, which will enable asm.js verification to run off-thread in those situations. BUG=v8:5203 Change-Id: I5dbf83c993512eb2f3dd709120e152e3f9900bdf Reviewed-on: https://chromium-review.googlesource.com/616723Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47500}
-
- 21 Aug, 2017 1 commit
-
-
Michael Starzinger authored
R=jarin@chromium.org BUG=v8:5653,v8:6409 Change-Id: I3a7e7173afbcba9bb0bb7b1baafe9e78e22bb696 Reviewed-on: https://chromium-review.googlesource.com/612174 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47473}
-
- 18 Aug, 2017 1 commit
-
-
Ross McIlroy authored
Parse tasks are not currently used, and will need to be changed significantly for background compilation, so we remove them for now. BUG=v8:6093,v8:5203 Change-Id: I44559a94ecca85668f0117629d35aaa5f4075745 Reviewed-on: https://chromium-review.googlesource.com/617140 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#47446}
-
- 09 Aug, 2017 2 commits
-
-
Adam Klein authored
There are two reasons for Scopes to need information about eval calls inside them: - Eval in a scope, or any of its inner scopes, turns off a bunch of scope analysis optimizations (e.g., all variables have to be treated as "used" and context-allocated). - Eval in a sloppy declaration scope means allows runtime addition of var declarations. This patch aims to make the code better-reflect this reality. It's meant as a pure cleanup, with no expected change in behavior. Change-Id: I744c5051bb7a90b11420930e9596e5d6c35eb440 Reviewed-on: https://chromium-review.googlesource.com/602848 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#47257}
-
Ross McIlroy authored
Splits out AttachOuterScopeInfo from DeclarationScope::Analyze and attaches the outer scope info after parsing has completed (when parsing on the main thread, which is the only time we have an outer scope info) instead of during Compiler::Analyse(). BUG=v8:5203 TBR=yangguo@chromium.org Change-Id: Idd8d2409fb20f09a9f6bbf5cff7e6edcf90077d7 Reviewed-on: https://chromium-review.googlesource.com/605889 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#47243}
-
- 25 Jul, 2017 1 commit
-
-
Ross McIlroy authored
Move ScopeInfo allocation out of DeclarationScope::Analyse and do it later in the compile when finalizing unoptimized code generation. This is to enable scope analysis to be done without heap allocation so it could run off-thread. BUG=v8:5203 Change-Id: I954aacd4353925bbbd5a940d979027de2c52e1fd Reviewed-on: https://chromium-review.googlesource.com/581108Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46862}
-
- 14 Jul, 2017 1 commit
-
-
Caitlin Potter authored
This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
-
- 03 Jul, 2017 1 commit
-
-
Marja Hölttä authored
(The test that catches the bug was test-bytecode-generator/LookupSlot) BUG=v8:5516 Change-Id: I00a02c5326b2a132383a9d72b5b894fade53bbf2 Reviewed-on: https://chromium-review.googlesource.com/558864 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46374}
-
- 30 Jun, 2017 1 commit
-
-
Marja Hölttä authored
This way, each lazy function needs to handle only the data relevant to itself. This reduced data handling overheads. Other changes: 1) Don't deserialize the data; once it's on the heap, it can stay there. Lazy function compilation is only done in the main thread. 2) Separate ProducedPreParsedScopeData and ConsumedPreParsedScopeData. It's clearer, because: - The data looks fundamentally different when we're producing it and when we're consuming it. - Cleanly separates the operations we can do in the "producing phase" and in the "consuming phase". Bug: v8:5516 Change-Id: I6985a6621f71b348a55155724765624b5d5f7c33 Reviewed-on: https://chromium-review.googlesource.com/528094 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46347}
-
- 27 Jun, 2017 1 commit
-
-
Adam Klein authored
Change-Id: Ie380c38a91a05b66fd25172eebbb28b4cfeb646b Reviewed-on: https://chromium-review.googlesource.com/543926Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46239}
-
- 26 Jun, 2017 1 commit
-
-
hans authored
This is towards closing the perf gap between the MSVC build (which uses link- time optimization) and Clang (where LTO isn't ready on Windows yet). We did a study (see bug) to see which non-inlined functions are hit a lot during render start-up, and which would be inlined during LTO. This should benefit performance in all builds which currently don't use LTO (Android, Linux, Mac) as well as the Win/Clang build. The binary size of chrome_child.dll increases by 2KB with this. BUG=chromium:728324 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng Review-Url: https://codereview.chromium.org/2950993002 Cr-Commit-Position: refs/heads/master@{#46229}
-
- 25 Jun, 2017 1 commit
-
-
machenbach authored
Revert of Make some functions that are hit during renderer startup available for inlining (patchset #3 id:40001 of https://codereview.chromium.org/2950993002/ ) Reason for revert: Blocks roll: https://codereview.chromium.org/2954833002/ E.g.: https://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_compile_dbg_ng/builds/449680 https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_compile_dbg_ng/builds/324953 Please include those chromium trybots on reland. Maybe missing symbol export? Original issue's description: > Make some functions that are hit during renderer startup available for inlining > > This is towards closing the perf gap between the MSVC build (which uses link- > time optimization) and Clang (where LTO isn't ready on Windows yet). We did > a study (see bug) to see which non-inlined functions are hit a lot during render > start-up, and which would be inlined during LTO. This should benefit performance > in all builds which currently don't use LTO (Android, Linux, Mac) as well as > the Win/Clang build. > > The binary size of chrome_child.dll increases by 2KB with this. > > BUG=chromium:728324 > > Review-Url: https://codereview.chromium.org/2950993002 > Cr-Commit-Position: refs/heads/master@{#46191} > Committed: https://chromium.googlesource.com/v8/v8/+/d00d52be1fce9c1bf5558c8b26bf984efd09e65b TBR=jochen@chromium.org,mstarzinger@chromium.org,rmcilroy@chromium.org,vogelheim@chromium.org,marja@chromium.org,mlippautz@chromium.org,thakis@chromium.org,hans@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=chromium:728324 NOTRY=true NOPRESUBMIT=true Review-Url: https://codereview.chromium.org/2955793002 Cr-Commit-Position: refs/heads/master@{#46195}
-
- 23 Jun, 2017 1 commit
-
-
hans authored
This is towards closing the perf gap between the MSVC build (which uses link- time optimization) and Clang (where LTO isn't ready on Windows yet). We did a study (see bug) to see which non-inlined functions are hit a lot during render start-up, and which would be inlined during LTO. This should benefit performance in all builds which currently don't use LTO (Android, Linux, Mac) as well as the Win/Clang build. The binary size of chrome_child.dll increases by 2KB with this. BUG=chromium:728324 Review-Url: https://codereview.chromium.org/2950993002 Cr-Commit-Position: refs/heads/master@{#46191}
-
- 29 May, 2017 1 commit
-
-
Marja Hölttä authored
For non-simple param lists, the parser first declares a TEMPORARY for each param, and then the named variables as locals. The TEMPORARY variables determine the parameter count. This CL makes the PreParser produce the same parameter count as the Parser. BUG=v8:5516 Change-Id: I8a794d6a8342145ab7934d922e2d69450d67b199 Reviewed-on: https://chromium-review.googlesource.com/517944 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#45566}
-
- 24 May, 2017 2 commits
-
-
Ross McIlroy authored
Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
-
jarin authored
In particular, local variables should be allocated on stack (in bytecode register), and stored/loaded to the generator object on generator suspend/resume. The CL is based on @adamk's change to scoping/parsers (https://chromium-review.googlesource.com/c/498538/), I only made the debugger cope with this change. I should note that the CL changes the scope type of suspended generators from ScopeType.Closure to ScopeType.Local. In the future we might want to introduce ScopeType.SuspendedGenerator to make the distinction explicit. Some of the changes in the tests have been made because the debugger functions do not return scopes of closed generators anymore. Generators should be allowed to throw away their internal state when they finish. BUG=v8:6368 Review-Url: https://codereview.chromium.org/2898163002 Cr-Commit-Position: refs/heads/master@{#45515}
-
- 17 May, 2017 1 commit
-
-
Marja Hölttä authored
Super calls need to refer to .this_function, .new.target and this, and super property references need to refer to .this_function and this, so that the is_used for those variables will be set and they will be allocated correctly. BUG=v8:5516 Change-Id: Idc58539fccad70c995e029051b59a67ea66bff91 Reviewed-on: https://chromium-review.googlesource.com/506094Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#45376}
-
- 02 May, 2017 1 commit
-
-
Wiktor Garbacz authored
While parsing top-level code eager functions are skipped just like lazy ones, but also a parse task is created for each. The parse tasks are run by the compiler dispatcher and can be executed either on background thread or in idle time. After parsing of top-level code finishes it waits for all unfinished parser tasks - possibly picking up and executing them on current thread. Afterwards parse task results are stitched together with top-level AST, in case of failures eager functions are treated just like lazy - parsing/compilation is retriggered for them in the runtime and proper errors are generated (performance is not optimized for error case at all). BUG=v8:6093 Change-Id: Ie6508211a04b90becfe44139cce1c8ecec386b6e Reviewed-on: https://chromium-review.googlesource.com/486725Reviewed-by:
Jochen Eisinger <jochen@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Cr-Commit-Position: refs/heads/master@{#45016}
-
- 25 Apr, 2017 2 commits
-
-
Michael Achenbach authored
This reverts commit 56a6fda3. Reason for revert: Makes tsan flaky: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/15038 Original change's description: > [parser] Inital parallel parse tasks implementation. > > While parsing top-level code eager functions are skipped just like lazy > ones, but also a parse task is created for each. > > The parse tasks are run by the compiler dispatcher and can be executed > either on background thread or in idle time. > After parsing of top-level code finishes it waits for all unfinished > parser tasks - possibly picking up and executing them on current thread. > Afterwards parse task results are stitched together with top-level AST, > in case of failures eager functions are treated just like lazy - > parsing/compilation is retriggered for them in the runtime and proper > errors are generated (performance is not optimized for error case at > all). > > BUG=v8:6093 > > Change-Id: I718dd2acc8a70ae1b09c2dea2616716605d7b05d > Reviewed-on: https://chromium-review.googlesource.com/483439 > Commit-Queue: Wiktor Garbacz <wiktorg@google.com> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Jochen Eisinger <jochen@chromium.org> > Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44849} TBR=marja@chromium.org,vogelheim@chromium.org,jochen@chromium.org,wiktorg@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:6093 Change-Id: I17e689efee7d216d28a94a5c8147022ae7e830dd Reviewed-on: https://chromium-review.googlesource.com/486883Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#44859}
-
Wiktor Garbacz authored
While parsing top-level code eager functions are skipped just like lazy ones, but also a parse task is created for each. The parse tasks are run by the compiler dispatcher and can be executed either on background thread or in idle time. After parsing of top-level code finishes it waits for all unfinished parser tasks - possibly picking up and executing them on current thread. Afterwards parse task results are stitched together with top-level AST, in case of failures eager functions are treated just like lazy - parsing/compilation is retriggered for them in the runtime and proper errors are generated (performance is not optimized for error case at all). BUG=v8:6093 Change-Id: I718dd2acc8a70ae1b09c2dea2616716605d7b05d Reviewed-on: https://chromium-review.googlesource.com/483439 Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Jochen Eisinger <jochen@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#44849}
-
- 31 Mar, 2017 1 commit
-
-
Franziska Hinkelmann authored
Add the source position to variables if they are parameters. Collect type information for parameters and return values. Index the types by their corresponding source position. For the types of return values, use the function end as source position. Sample output for a function with 2 parameters (at source position 252 and 258, and function end at 443) ************* Function: testFunction 252: Object number string number 258: undefined boolean undefined undefined 443: Object number string number ************* BUG=v8:5933 Change-Id: I3b8749afcac706c1834146abf1b5b4a3fd130fb6 Reviewed-on: https://chromium-review.googlesource.com/461919Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Cr-Commit-Position: refs/heads/master@{#44299}
-
- 24 Mar, 2017 1 commit
-
-
Wiktor Garbacz authored
A step towards removing isolate from ParseInfo. Removing isolate from ParseInfo will make it easier to create and execute parse tasks on background threads. BUG=v8:6093 Change-Id: Iefd2fd01a700509f05d6f1a272cfa39cc545d39b Reviewed-on: https://chromium-review.googlesource.com/458001Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Cr-Commit-Position: refs/heads/master@{#44096}
-
- 23 Mar, 2017 1 commit
-
-
Wiktor Garbacz authored
It was removed so that Parser::DeserializeScopeChain does not have to get it from ParseInfo. Only a small step in direction of removing isolate from ParseInfo. BUG=v8:6093 Change-Id: Iaaf92dc6eb5ec9c4efc05ac73666fbc66e0ed8c1 Reviewed-on: https://chromium-review.googlesource.com/457999 Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Jochen Eisinger <jochen@chromium.org> Cr-Commit-Position: refs/heads/master@{#44057}
-
- 22 Mar, 2017 1 commit
-
-
Caitlin Potter authored
Just the front-end side of https://chromium-review.googlesource.com/c/446961/. Adds support for parsing AsyncGeneratorExpression, AsyncGeneratorDeclaration, and AsyncGeneratorMethod, as well as parser tests. BUG=v8:5855 R=neis@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I70e1a9681f22573f29292eacb4b9f57f9a38e2b2 Reviewed-on: https://chromium-review.googlesource.com/447117Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#44040}
-
- 17 Mar, 2017 1 commit
-
-
Marja Hölttä authored
The data needed to be modified a bit to actually allow skipping over functions based on it. In particular, we need to allow skipping over an unknown inner scope structure (in the previous stage, we just had tests comparing the data against some baseline truth, so it wasn't needed). also removing the current "skip functions based on preparse data" logic, since preparser data is not used any more. At a later stage, I'll consider plugging the preparser-scope-analysis-data into that pipeline (so I don't want to remove the full code yet). Integration to the various forms of compilation is still incomplete; this CL integrates just enough to get the minimal example to pass: (function foo() { function preparsed() { var var1 = 10; function skip_me() { print(var1); } return skip_me; } return preparsed; })()()(); BUG=v8:5516 Change-Id: I0d24b4c3b338f7e6b6c3bf7cf2c1ceb29608e2f2 Reviewed-on: https://chromium-review.googlesource.com/446336 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#43908}
-
- 07 Mar, 2017 1 commit
-
-
Marja Hölttä authored
This pretty much rewrites the preparsed scope data collection. We used to store the allocation result, but it's faster to just store the raw data which is needed for deciding it later. (This way we don't need to run the allocation algorithm for just getting this data.) For each variable: is_used, maybe_assigned, has_forced_context_allocation, and for each scope: inner_scope_calls_eval_. In addition, this CL moves data handling out of Scope and into PreParsedScopeData where it belongs and simplifies the API for PreParsedScopeData. BUG=v8:5516 R=vogelheim@chromium.org Change-Id: Ia5a4fa52f585cd4f483ce9a92f2dd7d9754f34ed Reviewed-on: https://chromium-review.googlesource.com/451273 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#43641}
-
- 03 Mar, 2017 1 commit
-
-
Georg Neis authored
This is always the single variable declared in the catch scope. BUG= Change-Id: I05ccc48f57394268432c9b5b8c76f9db1b3b6312 Reviewed-on: https://chromium-review.googlesource.com/448041Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#43571}
-
- 02 Mar, 2017 1 commit
-
-
Adam Klein authored
This involved adding a count_ member to SloppyBlockFunctionMap, so to avoid making DeclarationScope larger, this patch makes the creation of the map lazy, thus reducing the size of DeclarationScope by several words in the process. BUG=chromium:688567 Change-Id: If9a9eb2ccc01690fe10edadb3aa9625454ff4a19 Reviewed-on: https://chromium-review.googlesource.com/448701 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Daniel Ehrenberg <littledan@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#43558}
-