- 05 Apr, 2017 1 commit
-
-
Marja Hölttä authored
There's no need to set it so early - it's only needed when the function has really been parsed. This way we don't need to produce and store it for skipped inner functions. BUG=v8:5516 Change-Id: Ibf59a8acb886ea3de9be140431a334a03b408f5b Reviewed-on: https://chromium-review.googlesource.com/461827 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#44410}
-
- 29 Mar, 2017 1 commit
-
-
Marja Hölttä authored
There's no need to set it so early - it's only needed when the function has really been parsed. This way we don't need to produce and store it for skipped inner functions. BUG=v8:5516 Change-Id: Ida2abd44b494030771b5663a8eb326edb0a53b72 Reviewed-on: https://chromium-review.googlesource.com/461160Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44235}
-
- 28 Mar, 2017 3 commits
-
-
Ross McIlroy authored
Don't put internalized parser handles in a DeferredHandleScope if we aren't going to compile concurrently since this has a performance cost. BUG=chromium:686658 Change-Id: Id89d197b863569346895583e6df79134e79a5d4b Reviewed-on: https://chromium-review.googlesource.com/461879Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#44196}
-
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: I0a3546618d01b9232014da94cf8d0f72427a0d1d Reviewed-on: https://chromium-review.googlesource.com/458006 Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44176}
-
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: Ief4eb3c9873026a93338d5556985f31c9abe17e6 Reviewed-on: https://chromium-review.googlesource.com/458005 Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#44173}
-
- 27 Mar, 2017 3 commits
-
-
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: I977eec8faecc8a112506f219994b4e4ec388b180 Reviewed-on: https://chromium-review.googlesource.com/458004 Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44160}
-
Ross McIlroy authored
Since we no longer support the ignition-staging configuration any longer, we can retire the three tier pipeline and the CompileBaseline functionallity. We still need support for JSFunction self healing due to liveedit (which for --no-turbo might end up replacing a forced Ignition function with a FCG function) - we can remove this once we remove --no-turbo support. BUG=v8:4280 Change-Id: I5482abd17785324654e022affd6bdb555b19b181 Reviewed-on: https://chromium-review.googlesource.com/452620 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#44141}
-
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: I25b23b3bf64502f84c28ce688ad2997c9665a069 Reviewed-on: https://chromium-review.googlesource.com/458003Reviewed-by: Daniel Clifford <danno@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@{#44140}
-
- 24 Mar, 2017 3 commits
-
-
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: I2a3a8a02d791d7ae6acc2243e2f430defc3be5ea Reviewed-on: https://chromium-review.googlesource.com/458002 Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44097}
-
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}
-
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: If5e7ba2f76f9f8422c26f47c9f0eb5b197114b25 Reviewed-on: https://chromium-review.googlesource.com/458000Reviewed-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@{#44089}
-
- 23 Mar, 2017 1 commit
-
-
Michael Starzinger authored
This adds a --stress-validate-asm flag intended to stress test the validator by running against every single function, independent of whether a "use asm" directive is present. It mainly tests negative cases because barely any function in our test corpus will be a valid module according to the asm.js spec. R=bradnelson@chromium.org BUG=v8:6127 Change-Id: Id04b0440628134d4e81c9bb4d71039f940fc9a83 Reviewed-on: https://chromium-review.googlesource.com/457039Reviewed-by: Brad Nelson <bradnelson@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#44055}
-
- 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}
-
- 16 Mar, 2017 6 commits
-
-
franzih authored
Extract script->type() == TYPE_NORMAL into a function. BUG= Review-Url: https://codereview.chromium.org/2744613006 Cr-Commit-Position: refs/heads/master@{#43868}
-
franzih authored
Collect type information for JavaScript variables and display it in Chrome DevTools. Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing When debugging JavaScript, it’s helpful to know the type of a variable, parameter, and return values. JavaScript is dynamically typed, and for complex source code it’s often hard to infer types. With type profiling, we can provide type information to JavaScript developers. This CL is a proof of concept. It collects type profile for assignments and simply prints the types to stdout. The output looks something like this: #my_var1 #Object #number #string #number #undefined #string #Object #Object We use an extra slot in the feedback vector of assignments to carry the list of types for that assignment. The extra slot is only added when the flag --type-profile is given. Missing work: * Collect data for parameters and return values (currently only assignments). * Remove duplicates from the list of collected types and use a common base class. * Add line numbers or source position instead of the variable name. For now, has a test that compares the stdout of --type-profile in test/message. We will remove this test when --type-profile is fully integrated in the debugger protocol. Adding the test in test/inspector does not work, because the inspector test itself consists of JavaScript code that would convolute the output and be non-deterministic under stress. BUG=v8:5935 Review-Url: https://codereview.chromium.org/2707873002 Cr-Commit-Position: refs/heads/master@{#43866}
-
franzih authored
Revert of Collect type profile for DevTools. (patchset #41 id:770001 of https://codereview.chromium.org/2707873002/ ) Reason for revert: Still flaky Original issue's description: > Collect type profile for DevTools > > Collect type information for JavaScript variables and display it > in Chrome DevTools. > Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing > > When debugging JavaScript, it’s helpful to know the type of > a variable, parameter, and return values. JavaScript is > dynamically typed, and for complex > source code it’s often hard to infer types. With type profiling, we > can provide type information to JavaScript developers. > > This CL is a proof of concept. It collects type profile for > assignments and simply prints the types to stdout. > > The output looks something like this: > > #my_var1 > #Object > #number > #string > #number > #undefined > #string > #Object > #Object > > > We use an extra slot in the feedback vector of assignments to > carry the list of types for that assignment. The extra slot is > only added when the flag --type-profile is given. > > > Missing work: > * Collect data for parameters and return values (currently only assignments). > * Remove duplicates from the list of collected types and use a common base class. > * Add line numbers or source position instead of the variable name. > > > > BUG=v8:5935 > > Review-Url: https://codereview.chromium.org/2707873002 > Cr-Original-Original-Original-Commit-Position: refs/heads/master@{#43791} > Committed: https://chromium.googlesource.com/v8/v8/+/0332bebde99d0f9a5a8326382f5f37cc26224ae0 > Review-Url: https://codereview.chromium.org/2707873002 > Cr-Original-Original-Commit-Position: refs/heads/master@{#43804} > Committed: https://chromium.googlesource.com/v8/v8/+/6cf880f4b84c533d4bb139d33c1369e309d1c579 > Review-Url: https://codereview.chromium.org/2707873002 > Cr-Original-Commit-Position: refs/heads/master@{#43846} > Committed: https://chromium.googlesource.com/v8/v8/+/5c322873908a5b5c04552fc47d8d81f7603b5d11 > Review-Url: https://codereview.chromium.org/2707873002 > Cr-Commit-Position: refs/heads/master@{#43849} > Committed: https://chromium.googlesource.com/v8/v8/+/18c35e4958be6a70acc923bf10363eb9aaee5ce4 TBR=yangguo@chromium.org,mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5935 Review-Url: https://codereview.chromium.org/2745413006 Cr-Commit-Position: refs/heads/master@{#43852}
-
franzih authored
Collect type information for JavaScript variables and display it in Chrome DevTools. Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing When debugging JavaScript, it’s helpful to know the type of a variable, parameter, and return values. JavaScript is dynamically typed, and for complex source code it’s often hard to infer types. With type profiling, we can provide type information to JavaScript developers. This CL is a proof of concept. It collects type profile for assignments and simply prints the types to stdout. The output looks something like this: #my_var1 #Object #number #string #number #undefined #string #Object #Object We use an extra slot in the feedback vector of assignments to carry the list of types for that assignment. The extra slot is only added when the flag --type-profile is given. Missing work: * Collect data for parameters and return values (currently only assignments). * Remove duplicates from the list of collected types and use a common base class. * Add line numbers or source position instead of the variable name. BUG=v8:5935 Review-Url: https://codereview.chromium.org/2707873002 Cr-Original-Original-Original-Commit-Position: refs/heads/master@{#43791} Committed: https://chromium.googlesource.com/v8/v8/+/0332bebde99d0f9a5a8326382f5f37cc26224ae0 Review-Url: https://codereview.chromium.org/2707873002 Cr-Original-Original-Commit-Position: refs/heads/master@{#43804} Committed: https://chromium.googlesource.com/v8/v8/+/6cf880f4b84c533d4bb139d33c1369e309d1c579 Review-Url: https://codereview.chromium.org/2707873002 Cr-Original-Commit-Position: refs/heads/master@{#43846} Committed: https://chromium.googlesource.com/v8/v8/+/5c322873908a5b5c04552fc47d8d81f7603b5d11 Review-Url: https://codereview.chromium.org/2707873002 Cr-Commit-Position: refs/heads/master@{#43849}
-
franzih authored
Revert of Collect type profile for DevTools. (patchset #40 id:750001 of https://codereview.chromium.org/2707873002/ ) Reason for revert: Flaky under stress. Fix first. Original issue's description: > Collect type profile for DevTools > > Collect type information for JavaScript variables and display it > in Chrome DevTools. > Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing > > When debugging JavaScript, it’s helpful to know the type of > a variable, parameter, and return values. JavaScript is > dynamically typed, and for complex > source code it’s often hard to infer types. With type profiling, we > can provide type information to JavaScript developers. > > This CL is a proof of concept. It collects type profile for > assignments and simply prints the types to stdout. > > The output looks something like this: > > #my_var1 > #Object > #number > #string > #number > #undefined > #string > #Object > #Object > > > We use an extra slot in the feedback vector of assignments to > carry the list of types for that assignment. The extra slot is > only added when the flag --type-profile is given. > > > Missing work: > * Collect data for parameters and return values (currently only assignments). > * Remove duplicates from the list of collected types and use a common base class. > * Add line numbers or source position instead of the variable name. > > > > BUG=v8:5935 > > Review-Url: https://codereview.chromium.org/2707873002 > Cr-Original-Original-Commit-Position: refs/heads/master@{#43791} > Committed: https://chromium.googlesource.com/v8/v8/+/0332bebde99d0f9a5a8326382f5f37cc26224ae0 > Review-Url: https://codereview.chromium.org/2707873002 > Cr-Original-Commit-Position: refs/heads/master@{#43804} > Committed: https://chromium.googlesource.com/v8/v8/+/6cf880f4b84c533d4bb139d33c1369e309d1c579 > Review-Url: https://codereview.chromium.org/2707873002 > Cr-Commit-Position: refs/heads/master@{#43846} > Committed: https://chromium.googlesource.com/v8/v8/+/5c322873908a5b5c04552fc47d8d81f7603b5d11 TBR=yangguo@chromium.org,mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5935 Review-Url: https://codereview.chromium.org/2747383004 Cr-Commit-Position: refs/heads/master@{#43847}
-
franzih authored
Collect type information for JavaScript variables and display it in Chrome DevTools. Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing When debugging JavaScript, it’s helpful to know the type of a variable, parameter, and return values. JavaScript is dynamically typed, and for complex source code it’s often hard to infer types. With type profiling, we can provide type information to JavaScript developers. This CL is a proof of concept. It collects type profile for assignments and simply prints the types to stdout. The output looks something like this: #my_var1 #Object #number #string #number #undefined #string #Object #Object We use an extra slot in the feedback vector of assignments to carry the list of types for that assignment. The extra slot is only added when the flag --type-profile is given. Missing work: * Collect data for parameters and return values (currently only assignments). * Remove duplicates from the list of collected types and use a common base class. * Add line numbers or source position instead of the variable name. BUG=v8:5935 Review-Url: https://codereview.chromium.org/2707873002 Cr-Original-Original-Commit-Position: refs/heads/master@{#43791} Committed: https://chromium.googlesource.com/v8/v8/+/0332bebde99d0f9a5a8326382f5f37cc26224ae0 Review-Url: https://codereview.chromium.org/2707873002 Cr-Original-Commit-Position: refs/heads/master@{#43804} Committed: https://chromium.googlesource.com/v8/v8/+/6cf880f4b84c533d4bb139d33c1369e309d1c579 Review-Url: https://codereview.chromium.org/2707873002 Cr-Commit-Position: refs/heads/master@{#43846}
-
- 15 Mar, 2017 1 commit
-
-
Leszek Swirski authored
Marking shared functions for tier-up was optimizing the functions non-concurrently, to avoid the case where the same shared function is optimized concurrently by multiple JS functions. This was particularly a problem for small functions, which (if called in a loop) could get marked for optimisation quite quickly. In this CL, the shared function is instead marked as having an active optimization job running, and these do not spawn a compilation job. BUG=chromium:693590 BUG=chromium:700863 BUG=chromium:701665 Change-Id: I2b1c5af8e7aa8d779f86814c22c65c78bee0630f Reviewed-on: https://chromium-review.googlesource.com/455779Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#43833}
-
- 14 Mar, 2017 6 commits
-
-
franzih authored
Revert of Collect type profile for DevTools. (patchset #40 id:750001 of https://codereview.chromium.org/2707873002/ ) Reason for revert: gcc bot is now flaky https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/11863 Original issue's description: > Collect type profile for DevTools > > Collect type information for JavaScript variables and display it > in Chrome DevTools. > Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing > > When debugging JavaScript, it’s helpful to know the type of > a variable, parameter, and return values. JavaScript is > dynamically typed, and for complex > source code it’s often hard to infer types. With type profiling, we > can provide type information to JavaScript developers. > > This CL is a proof of concept. It collects type profile for > assignments and simply prints the types to stdout. > > The output looks something like this: > > #my_var1 > #Object > #number > #string > #number > #undefined > #string > #Object > #Object > > > We use an extra slot in the feedback vector of assignments to > carry the list of types for that assignment. The extra slot is > only added when the flag --type-profile is given. > > > Missing work: > * Collect data for parameters and return values (currently only assignments). > * Remove duplicates from the list of collected types and use a common base class. > * Add line numbers or source position instead of the variable name. > > > > BUG=v8:5935 > > Review-Url: https://codereview.chromium.org/2707873002 > Cr-Original-Commit-Position: refs/heads/master@{#43791} > Committed: https://chromium.googlesource.com/v8/v8/+/0332bebde99d0f9a5a8326382f5f37cc26224ae0 > Review-Url: https://codereview.chromium.org/2707873002 > Cr-Commit-Position: refs/heads/master@{#43804} > Committed: https://chromium.googlesource.com/v8/v8/+/6cf880f4b84c533d4bb139d33c1369e309d1c579 TBR=yangguo@chromium.org,mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5935 Review-Url: https://codereview.chromium.org/2754573002 Cr-Commit-Position: refs/heads/master@{#43805}
-
franzih authored
Collect type information for JavaScript variables and display it in Chrome DevTools. Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing When debugging JavaScript, it’s helpful to know the type of a variable, parameter, and return values. JavaScript is dynamically typed, and for complex source code it’s often hard to infer types. With type profiling, we can provide type information to JavaScript developers. This CL is a proof of concept. It collects type profile for assignments and simply prints the types to stdout. The output looks something like this: #my_var1 #Object #number #string #number #undefined #string #Object #Object We use an extra slot in the feedback vector of assignments to carry the list of types for that assignment. The extra slot is only added when the flag --type-profile is given. Missing work: * Collect data for parameters and return values (currently only assignments). * Remove duplicates from the list of collected types and use a common base class. * Add line numbers or source position instead of the variable name. BUG=v8:5935 Review-Url: https://codereview.chromium.org/2707873002 Cr-Original-Commit-Position: refs/heads/master@{#43791} Committed: https://chromium.googlesource.com/v8/v8/+/0332bebde99d0f9a5a8326382f5f37cc26224ae0 Review-Url: https://codereview.chromium.org/2707873002 Cr-Commit-Position: refs/heads/master@{#43804}
-
machenbach authored
Revert of Collect type profile for DevTools. (patchset #39 id:730001 of https://codereview.chromium.org/2707873002/ ) Reason for revert: gcc bot has problems with this: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/11858 Original issue's description: > Collect type profile for DevTools > > Collect type information for JavaScript variables and display it > in Chrome DevTools. > Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing > > When debugging JavaScript, it’s helpful to know the type of > a variable, parameter, and return values. JavaScript is > dynamically typed, and for complex > source code it’s often hard to infer types. With type profiling, we > can provide type information to JavaScript developers. > > This CL is a proof of concept. It collects type profile for > assignments and simply prints the types to stdout. > > The output looks something like this: > > #my_var1 > #Object > #number > #string > #number > #undefined > #string > #Object > #Object > > > We use an extra slot in the feedback vector of assignments to > carry the list of types for that assignment. The extra slot is > only added when the flag --type-profile is given. > > > Missing work: > * Collect data for parameters and return values (currently only assignments). > * Remove duplicates from the list of collected types and use a common base class. > * Add line numbers or source position instead of the variable name. > > > > BUG=v8:5935 > > Review-Url: https://codereview.chromium.org/2707873002 > Cr-Commit-Position: refs/heads/master@{#43791} > Committed: https://chromium.googlesource.com/v8/v8/+/0332bebde99d0f9a5a8326382f5f37cc26224ae0 TBR=yangguo@chromium.org,mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org,franzih@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5935 Review-Url: https://codereview.chromium.org/2749673003 Cr-Commit-Position: refs/heads/master@{#43798}
-
franzih authored
Collect type information for JavaScript variables and display it in Chrome DevTools. Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing When debugging JavaScript, it’s helpful to know the type of a variable, parameter, and return values. JavaScript is dynamically typed, and for complex source code it’s often hard to infer types. With type profiling, we can provide type information to JavaScript developers. This CL is a proof of concept. It collects type profile for assignments and simply prints the types to stdout. The output looks something like this: #my_var1 #Object #number #string #number #undefined #string #Object #Object We use an extra slot in the feedback vector of assignments to carry the list of types for that assignment. The extra slot is only added when the flag --type-profile is given. Missing work: * Collect data for parameters and return values (currently only assignments). * Remove duplicates from the list of collected types and use a common base class. * Add line numbers or source position instead of the variable name. BUG=v8:5935 Review-Url: https://codereview.chromium.org/2707873002 Cr-Commit-Position: refs/heads/master@{#43791}
-
Michael Achenbach authored
This reverts commit 822aef29. Reason for revert: Makes getters-on-elements flaky on many bots. E.g.: https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/16848/steps/Check%20-%20isolates%20%28flakes%29/logs/getters-on-elements Bisected locally and tested with: tools/run-tests.py --gn --variants=asm_wasm mjsunit/getters-on-elements --isolates --random-seed-stress-count=500 Original change's description: > [compiler] Mark shared functions which have an optimization job > > Marking shared functions for tier-up was optimizing the functions > non-concurrently, to avoid the case where the same shared function is > optimized concurrently by multiple JS functions. This was particularly a > problem for small functions, which (if called in a loop) could get > marked for optimisation quite quickly. > > In this CL, the shared function is instead marked as having an active > optimization job running, and these do not spawn a compilation job. > > BUG=693590 > > Change-Id: I3df93fbf9cec7eda8229fcf416d7c429c06bec86 > Reviewed-on: https://chromium-review.googlesource.com/446836 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Cr-Commit-Position: refs/heads/master@{#43778} TBR=mvstanton@chromium.org,leszeks@chromium.org,hablich@chromium.org,v8-reviews@googlegroups.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=693590 Change-Id: If7dbdf3de302ec595c44e7f4795554db7674f22f Reviewed-on: https://chromium-review.googlesource.com/454042Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#43787}
-
Leszek Swirski authored
Marking shared functions for tier-up was optimizing the functions non-concurrently, to avoid the case where the same shared function is optimized concurrently by multiple JS functions. This was particularly a problem for small functions, which (if called in a loop) could get marked for optimisation quite quickly. In this CL, the shared function is instead marked as having an active optimization job running, and these do not spawn a compilation job. BUG=693590 Change-Id: I3df93fbf9cec7eda8229fcf416d7c429c06bec86 Reviewed-on: https://chromium-review.googlesource.com/446836 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#43778}
-
- 13 Mar, 2017 1 commit
-
-
yangguo authored
Previously, we would incorrectly not assign any debug id to scripts deserialized from the code cache. R=jgruber@chromium.org BUG=v8:6072 Review-Url: https://codereview.chromium.org/2742713003 Cr-Commit-Position: refs/heads/master@{#43740}
-
- 01 Mar, 2017 1 commit
-
-
Michael Starzinger authored
This fixes a corner-case in the above predicate that was introduced to allow fully disabling optimization using %NeverOptimizeFunction. This property of a function is a transient property (i.e. changes over time), whereas {UseTurboFan} is designed to be a static property (i.e. gives same answer over time). Violating this led to cases where functions got optimization disabled for other reasons would suddenly be baselined. The correct place to check transient properties is when optimization is requested. R=jarin@chromium.org TEST=mjsunit/never-baseline Change-Id: I37eb0c70d2b39704be29fd4bda76975bfbede66b Reviewed-on: https://chromium-review.googlesource.com/447937Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43514}
-
- 23 Feb, 2017 2 commits
-
-
Ross McIlroy authored
This reverts commit 8307ab70. Reason for revert: Breaks TSAN Original change's description: > [Counters] Add HistorgramTimers for optimized compile. > > Will be used for UMA to track time spent optimizing code in the wild. > > Change-Id: Ibc01540552eac4cb9224f1cb6cc11a55aae5834d > Reviewed-on: https://chromium-review.googlesource.com/444345 > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#43374} TBR=rmcilroy@chromium.org,mvstanton@chromium.org,machenbach@chromium.org,hablich@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Change-Id: I1cfc2ee599b9ba0132e69c8a61b21ff32c74f68e Reviewed-on: https://chromium-review.googlesource.com/446360Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43396}
-
Marja Hölttä authored
BUG=v8:5294 Change-Id: If45f25aae8de526027b7851cb4efe0ccf4a7c4b1 Reviewed-on: https://chromium-review.googlesource.com/444226 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43388}
-
- 22 Feb, 2017 1 commit
-
-
Ross McIlroy authored
Will be used for UMA to track time spent optimizing code in the wild. Change-Id: Ibc01540552eac4cb9224f1cb6cc11a55aae5834d Reviewed-on: https://chromium-review.googlesource.com/444345Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43374}
-
- 16 Feb, 2017 5 commits
-
-
jwolfe authored
For functions declared in source code, the .toString() representation will be an excerpt of the source code. * For functions declared with the "function" keyword, the excerpt starts at the "function" or "async" keyword and ends at the final "}". The previous behavior would start the excerpt at the "(" of the parameter list, and prepend a canonical `"function " + name` or similar, which would discard comments and formatting surrounding the function's name. Anonymous functions declared as function expressions no longer get the name "anonymous" in their toString representation. * For methods, the excerpt starts at the "get", "set", "*" (for generator methods), or property name, whichever comes first. Previously, the toString representation for methods would use a canonical prefix before the "(" of the parameter list. Note that any "static" keyword is omitted. * For arrow functions and class declarations, the excerpt is unchanged. For functions created with the Function, GeneratorFunction, or AsyncFunction constructors: * The string separating the parameter text and body text is now "\n) {\n", where previously it was "\n/*``*/) {\n" or ") {\n". * At one point, newline normalization was required by the spec here, but that was removed from the spec, and so this CL does not do it. Included in this CL is a fix for CreateDynamicFunction parsing. ')' and '`' characters in the parameter string are no longer disallowed, and Function("a=function(", "}){") is no longer allowed. BUG=v8:4958, v8:4230 Review-Url: https://codereview.chromium.org/2156303002 Cr-Commit-Position: refs/heads/master@{#43262}
-
mvstanton authored
This is a workaround for the fact that %SetCode can "lose" the script for a js native. If the js native is re-initialized (for a Realm or something), then the source SharedFunctionInfo won't have a script anymore. Nonetheless, we may want to optimize the function. If we've compiled bytecode, then we can compile optimized code without a script. Here, we carve out a special exception for this case, so that we can turn on the --mark-shared-functions-for-tier-up. BUG=v8:5946 R=leszeks@chromium.org Review-Url: https://codereview.chromium.org/2684033007 Cr-Original-Commit-Position: refs/heads/master@{#43240} Committed: https://chromium.googlesource.com/v8/v8/+/4123a3dd790495c40cf839990318a85c146e057d Review-Url: https://codereview.chromium.org/2684033007 Cr-Commit-Position: refs/heads/master@{#43252}
-
machenbach authored
Revert of Allow a ParseInfo without a script for %SetCode users (patchset #5 id:220001 of https://codereview.chromium.org/2684033007/ ) Reason for revert: Please remove the file in status file too. Breaks presubmit: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20presubmit/builds/14754 Or lets call it post-submit :( Original issue's description: > This is a workaround for the fact that %SetCode can "lose" the script for a js native. If the js native is re-initialized (for a Realm or something), then the source SharedFunctionInfo won't have a script anymore. Nonetheless, we may want to optimize the function. If we've compiled bytecode, then we can compile optimized code without a script. > > Here, we carve out a special exception for this case, so that we can turn on the --mark-shared-functions-for-tier-up. > > BUG=v8:5946 > R=leszeks@chromium.org > > Review-Url: https://codereview.chromium.org/2684033007 > Cr-Commit-Position: refs/heads/master@{#43240} > Committed: https://chromium.googlesource.com/v8/v8/+/4123a3dd790495c40cf839990318a85c146e057d TBR=leszeks@chromium.org,mstarzinger@chromium.org,marja@chromium.org,mvstanton@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5946 Review-Url: https://codereview.chromium.org/2703553002 Cr-Commit-Position: refs/heads/master@{#43242}
-
mvstanton authored
This is a workaround for the fact that %SetCode can "lose" the script for a js native. If the js native is re-initialized (for a Realm or something), then the source SharedFunctionInfo won't have a script anymore. Nonetheless, we may want to optimize the function. If we've compiled bytecode, then we can compile optimized code without a script. Here, we carve out a special exception for this case, so that we can turn on the --mark-shared-functions-for-tier-up. BUG=v8:5946 R=leszeks@chromium.org Review-Url: https://codereview.chromium.org/2684033007 Cr-Commit-Position: refs/heads/master@{#43240}
-
Marja Hölttä authored
Patch adopted from mvstanton@ ( https://codereview.chromium.org/2657413002/ ) BUG= Change-Id: I4296b3d5694116e250a6bb88296fbed0f0c444e6 Reviewed-on: https://chromium-review.googlesource.com/443246Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#43238}
-
- 14 Feb, 2017 1 commit
-
-
Ross McIlroy authored
BUG=v8:5203 Change-Id: Ia64775756873a8abc5d5b9ee987201a16c190420 Reviewed-on: https://chromium-review.googlesource.com/441812Reviewed-by: Jochen Eisinger <jochen@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43181}
-
- 10 Feb, 2017 3 commits
-
-
rmcilroy authored
Don't block on inner function compilation before competing outer function compilation. Instead wait for the compilation to complete when the function is called. BUG=v8:5203 Review-Url: https://codereview.chromium.org/2686673002 Cr-Commit-Position: refs/heads/master@{#43116}
-
Ross McIlroy authored
The --ignition-filter hasn't worked properly for a while due to some functions only being supported by Ignition. Remove it and add a --print-bytecode-filter to allow the main use-case of limiting bytecode printing to a particular function. BUG=chromium:685476,v8:5203 Change-Id: Id41eeb3083ae9f713433d3a30227cd4c5d0d47dd Reviewed-on: https://chromium-review.googlesource.com/441047Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#43113}
-
rmcilroy authored
In order to compile eager inner functions on a background thread we need to keep the handles created during parsing and scope analysis alive until the background compilation is complete. In order to do that, we allocate the handles in a deferred handle scope and keep the deferred handles alive with a shared_ptr in the ParseInfo and CompileInfo respectively. BUG=v8:5203 Review-Url: https://codereview.chromium.org/2650883002 Cr-Commit-Position: refs/heads/master@{#43107}
-