- 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}
-
- 05 Sep, 2017 1 commit
-
-
Juliana Franco authored
This CL removes the weak-list of JS functions from the context and all the code that iterares over it. This list was being used mainly during deoptimization (for code unlinking) and during garbage collection. Removing it will improve performance of programs that create many closures and trigger many scavenge GC cycles. No extra work is required during garbage collection. However, given that we no longer unlink code from JS functions during deoptimization, we leave it as it is, and on its next activation we check whether the mark_for_deoptimization bit of that code is set, and if it is, than we unlink it and jump to lazy compiled code. This check happens in the prologue of every code object. We needed to change/remove the cctests that used to check something on this list. Working in x64, ia32, arm64, arm, mips64 and mips. Bug: v8:6637 Change-Id: Ica99a12fd0351ae985e9a287918bf28caf6d2e24 TBR: mstarzinger@chromium.org Reviewed-on: https://chromium-review.googlesource.com/647596 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47808}
-
- 04 Sep, 2017 2 commits
-
-
Michael Achenbach authored
This reverts commit 84c2dfce. Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14876 Original change's description: > Remove weak-list of optimized JS functions. > > This CL removes the weak-list of JS functions from the context > and all the code that iterares over it. This list was being used > mainly during deoptimization (for code unlinking) and during > garbage collection. Removing it will improve performance of > programs that create many closures and trigger many scavenge GC > cycles. > > No extra work is required during garbage collection. However, > given that we no longer unlink code from JS functions during > deoptimization, we leave it as it is, and on its next activation > we check whether the mark_for_deoptimization bit of that code is > set, and if it is, than we unlink it and jump to lazy compiled > code. This check happens in the prologue of every code object. > > We needed to change/remove the cctests that used to check > something on this list. > > Working in x64, ia32, arm64, arm, mips64 and mips. > > Bug: v8:6637 > Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3 > Reviewed-on: https://chromium-review.googlesource.com/600427 > Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47790} TBR=mstarzinger@chromium.org,jarin@chromium.org,leszeks@chromium.org,bmeurer@chromium.org,jupvfranco@google.com Change-Id: Ia4f1a8acf6ca5cd5c74266437a03d854b3739af2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6637 Reviewed-on: https://chromium-review.googlesource.com/647540Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#47792}
-
Juliana Franco authored
This CL removes the weak-list of JS functions from the context and all the code that iterares over it. This list was being used mainly during deoptimization (for code unlinking) and during garbage collection. Removing it will improve performance of programs that create many closures and trigger many scavenge GC cycles. No extra work is required during garbage collection. However, given that we no longer unlink code from JS functions during deoptimization, we leave it as it is, and on its next activation we check whether the mark_for_deoptimization bit of that code is set, and if it is, than we unlink it and jump to lazy compiled code. This check happens in the prologue of every code object. We needed to change/remove the cctests that used to check something on this list. Working in x64, ia32, arm64, arm, mips64 and mips. Bug: v8:6637 Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3 Reviewed-on: https://chromium-review.googlesource.com/600427 Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47790}
-
- 08 Aug, 2017 1 commit
-
-
Adam Klein authored
This code appears to have been wrong forever, as it only threw in strict mode (presumably predating ES2015 const). In order to get exactly the right behavior, special handling of sloppy named function expressions is required. Rather than polluting PropertyAttributes with another dummy value, this CL simply adds a bool output argument to Context::Lookup to indicate that case. Bug: v8:6677 Change-Id: I34daa5080d291808f10cbaefc91d716f0b22963b Reviewed-on: https://chromium-review.googlesource.com/602690Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#47207}
-
- 29 Jun, 2017 1 commit
-
-
Leszek Swirski authored
There are very few cases where OSR code can be re-used, and where the function won't be non-concurrently optimized after OSR has happened. Maintaining the OSR code cache is unnecessary complexity, and caching OSR prevents us from e.g. seeding the optimizer with the actual OSR values. So, this patch removes it. Change-Id: Ib9223de590f35ffc1dc2ab593b7cc9fe97dde4a6 Reviewed-on: https://chromium-review.googlesource.com/552637 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#46306}
-
- 14 Jun, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
Context::Lookup method should support Module variables. Bug: chromium:717670 Change-Id: I58d3448b9048c7f9dd7ab8b720803b3503cf91ae Reviewed-on: https://chromium-review.googlesource.com/519389 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#45950}
-
- 22 May, 2017 1 commit
-
-
Ross McIlroy authored
Only FullCodegen code ever gets flushed by code flushing. Since we are deprecating the old pipeline, the added complexity introduced by code flushing is no longer worth it. This CL removes it (but keeps code aging, which is used to unlink SFIs from the compilation cache). BUG=v8:6389,v8:6379,v8:6409 Change-Id: I90de113a101f86dbeaaf0511c61a090ef12aa365 Reviewed-on: https://chromium-review.googlesource.com/507388 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45446}
-
- 10 May, 2017 1 commit
-
-
Ross McIlroy authored
Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246,chromium:718891 TBR=yangguo@chromium.org,ulan@chromium.org Change-Id: I3bb9ec0cfff32e667cca0e1403f964f33a6958a6 Reviewed-on: https://chromium-review.googlesource.com/500134Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45234}
-
- 08 May, 2017 1 commit
-
-
Ross McIlroy authored
This reverts commit 662aa425. Reason for revert: Crashing on Canary BUG=chromium:718891 Original change's description: > Reland: [TypeFeedbackVector] Store optimized code in the vector > > Since the feedback vector is itself a native context structure, why > not store optimized code for a function in there rather than in > a map from native context to code? This allows us to get rid of > the optimized code map in the SharedFunctionInfo, saving a pointer, > and making lookup of any optimized code quicker. > > Original patch by Michael Stanton <mvstanton@chromium.org> > > BUG=v8:6246 > TBR=yangguo@chromium.org,ulan@chromium.org > > Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327 > Reviewed-on: https://chromium-review.googlesource.com/494487 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45084} TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. BUG=v8:6246 Change-Id: Idab648d6fe260862c2a0e35366df19dcecf13a82 Reviewed-on: https://chromium-review.googlesource.com/498633Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45174}
-
- 04 May, 2017 1 commit
-
-
Ross McIlroy authored
Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246 TBR=yangguo@chromium.org,ulan@chromium.org Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327 Reviewed-on: https://chromium-review.googlesource.com/494487Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45084}
-
- 02 May, 2017 2 commits
-
-
Michael Achenbach authored
This reverts commit c5ad9c6d. Reason for revert: Fails on gc stress: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/12661 Original change's description: > [TypeFeedbackVector] Store optimized code in the vector > > Since the feedback vector is itself a native context structure, why > not store optimized code for a function in there rather than in > a map from native context to code? This allows us to get rid of > the optimized code map in the SharedFunctionInfo, saving a pointer, > and making lookup of any optimized code quicker. > > Original patch by Michael Stanton <mvstanton@chromium.org> > > BUG=v8:6246 > > Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5 > Reviewed-on: https://chromium-review.googlesource.com/476891 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45022} TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,mvstanton@chromium.org,jarin@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:6246 Change-Id: I9cd5735b03898cae6ae7adea0f19d32fceb31619 Reviewed-on: https://chromium-review.googlesource.com/493287Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#45027}
-
Ross McIlroy authored
Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246 Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5 Reviewed-on: https://chromium-review.googlesource.com/476891 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45022}
-
- 06 Feb, 2017 1 commit
-
-
mvstanton authored
TypeFeedbackVectors are strongly rooted by a closure. However, in modern JavaScript closures are created and abandoned more freely. An important closure may not be present in the root-set at time of garbage collection, even though we've cached optimized code and use it regularly. For example, consider leaf functions in an event dispatching system. They may well be "hot," but tragically non-present when we collect the heap. Until now, we've relied on a weak root to cache the feedback vector in this case. Since there is no way to signal intent or relative importance, this weak root is as susceptible to clearing as any other weak root at garbage collection time. Meanwhile, the feedback vector has become more important. All of our ICs store their data there. Literal and regex boilerplates are stored there. If we lose the vector, then we not only lose optimized code built from it, we also lose the very feedback which allowed us to create that optimized code. Therefore it's vital to express that dependency through the root set. This CL does this by creating a strong link to a feedback vector at the instantiation site of the function closure. This instantiation site is in the code and feedback vector of the outer closure. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2674593003 Cr-Commit-Position: refs/heads/master@{#42953}
-
- 30 Jan, 2017 1 commit
-
-
mvstanton authored
They have the same lifetime. It's a match! Both structures are native context dependent and dealt with (creation, clearing, gathering feedback) at the same time. By treating the spaces used for literal boilerplates as feedback vector slots, we no longer have to keep track of the materialized literal count elsewhere. A follow-on CL removes even more parser infrastructure related to this count. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2655853010 Cr-Commit-Position: refs/heads/master@{#42771}
-
- 19 Jan, 2017 3 commits
-
-
mvstanton authored
GC performance issues need to be addressed first. TBR=bmeurer@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:5456 Review-Url: https://codereview.chromium.org/2642743002 Cr-Original-Commit-Position: refs/heads/master@{#42495} Committed: https://chromium.googlesource.com/v8/v8/+/7803aa1ffb2f835c5f317ed2a097390d53e52567 Review-Url: https://codereview.chromium.org/2642743002 Cr-Commit-Position: refs/heads/master@{#42517}
-
machenbach authored
Revert of Revert [TypeFeedbackVector] Root literal arrays in function literal slots (patchset #2 id:20001 of https://codereview.chromium.org/2642743002/ ) Reason for revert: Breaks nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/13802 Original issue's description: > Revert [TypeFeedbackVector] Root literal arrays in function literal slots > > GC performance issues need to be addressed first. > > TBR=bmeurer@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org > BUG=v8:5456 > > Review-Url: https://codereview.chromium.org/2642743002 > Cr-Commit-Position: refs/heads/master@{#42495} > Committed: https://chromium.googlesource.com/v8/v8/+/7803aa1ffb2f835c5f317ed2a097390d53e52567 TBR=mvstanton@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5456 Review-Url: https://codereview.chromium.org/2642933003 Cr-Commit-Position: refs/heads/master@{#42496}
-
mvstanton authored
GC performance issues need to be addressed first. TBR=bmeurer@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org BUG=v8:5456 Review-Url: https://codereview.chromium.org/2642743002 Cr-Commit-Position: refs/heads/master@{#42495}
-
- 12 Jan, 2017 3 commits
-
-
mvstanton authored
Literal arrays and feedback vectors for a function can be garbage collected if we don't have a rooted closure for the function, which happens often. It's expensive to come back from this (recreating boilerplates and gathering feedback again), and the cost is disproportionate if the function was inlined into optimized code. To guard against losing these arrays when we need them, we'll now create literal arrays when creating the feedback vector for the outer closure, and root them strongly in that vector. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2620753003 Cr-Original-Commit-Position: refs/heads/master@{#42258} Committed: https://chromium.googlesource.com/v8/v8/+/31887804107bf5c103d915f5c601cfaaf1cd7cb6 Review-Url: https://codereview.chromium.org/2620753003 Cr-Commit-Position: refs/heads/master@{#42264}
-
machenbach authored
Revert of [TypeFeedbackVector] Root literal arrays in function literals slots (patchset #7 id:120001 of https://codereview.chromium.org/2620753003/ ) Reason for revert: gc stress: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/8105 also on mac Original issue's description: > [TypeFeedbackVector] Root literal arrays in function literals slots > > Literal arrays and feedback vectors for a function can be garbage > collected if we don't have a rooted closure for the function, which > happens often. It's expensive to come back from this (recreating > boilerplates and gathering feedback again), and the cost is > disproportionate if the function was inlined into optimized code. > > To guard against losing these arrays when we need them, we'll now > create literal arrays when creating the feedback vector for the outer > closure, and root them strongly in that vector. > > BUG=v8:5456 > > Review-Url: https://codereview.chromium.org/2620753003 > Cr-Commit-Position: refs/heads/master@{#42258} > Committed: https://chromium.googlesource.com/v8/v8/+/31887804107bf5c103d915f5c601cfaaf1cd7cb6 TBR=bmeurer@chromium.org,mstarzinger@chromium.org,yangguo@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:5456 Review-Url: https://codereview.chromium.org/2626863004 Cr-Commit-Position: refs/heads/master@{#42260}
-
mvstanton authored
Literal arrays and feedback vectors for a function can be garbage collected if we don't have a rooted closure for the function, which happens often. It's expensive to come back from this (recreating boilerplates and gathering feedback again), and the cost is disproportionate if the function was inlined into optimized code. To guard against losing these arrays when we need them, we'll now create literal arrays when creating the feedback vector for the outer closure, and root them strongly in that vector. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2620753003 Cr-Commit-Position: refs/heads/master@{#42258}
-
- 22 Dec, 2016 1 commit
-
-
hablich authored
Revert of [TypeFeedbackVector] Root literal arrays in function literals slots (patchset #11 id:370001 of https://codereview.chromium.org/2504153002/ ) Reason for revert: Speculative revert because of blocked roll: https://codereview.chromium.org/2596013002/ Original issue's description: > [TypeFeedbackVector] Root literal arrays in function literals slots > > Literal arrays and feedback vectors for a function can be garbage > collected if we don't have a rooted closure for the function, which > happens often. It's expensive to come back from this (recreating > boilerplates and gathering feedback again), and the cost is > disproportionate if the function was inlined into optimized code. > > To guard against losing these arrays when we need them, we'll now > create literal arrays when creating the feedback vector for the outer > closure, and root them strongly in that vector. > > BUG=v8:5456 > > Review-Url: https://codereview.chromium.org/2504153002 > Cr-Commit-Position: refs/heads/master@{#41893} > Committed: https://chromium.googlesource.com/v8/v8/+/93df094081f04c629c3df2e40318de90ce5e0fb9 TBR=bmeurer@chromium.org,mlippautz@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:5456 Review-Url: https://codereview.chromium.org/2597163002 Cr-Commit-Position: refs/heads/master@{#41917}
-
- 21 Dec, 2016 1 commit
-
-
mvstanton authored
Literal arrays and feedback vectors for a function can be garbage collected if we don't have a rooted closure for the function, which happens often. It's expensive to come back from this (recreating boilerplates and gathering feedback again), and the cost is disproportionate if the function was inlined into optimized code. To guard against losing these arrays when we need them, we'll now create literal arrays when creating the feedback vector for the outer closure, and root them strongly in that vector. BUG=v8:5456 Review-Url: https://codereview.chromium.org/2504153002 Cr-Commit-Position: refs/heads/master@{#41893}
-
- 20 Dec, 2016 1 commit
-
-
littledan authored
eval() may introduce a scope which needs to be represented as a context at runtime, e.g., eval('var x; let y; ()=>y') introduces a variable y which needs to have a context allocated for it. However, when traversing upwards to find the declaration context for a variable which leaks, as the declaration of x does above, this context has to be understood to not be a declaration context in sloppy mode. This patch makes that distinction by introducing a different map for eval-introduced contexts. A dynamic search for the appropriate context will continue past an eval context to find the appropriate context. Marking contexts as eval contexts rather than function contexts required updates in each compiler backend. BUG=v8:5295, chromium:648719 Review-Url: https://codereview.chromium.org/2435023002 Cr-Commit-Position: refs/heads/master@{#41869}
-
- 08 Dec, 2016 3 commits
-
-
yangguo authored
Aside from the default snapshot, there is no need for additional context snapshots to have the ability to replace the global proxy and global object after deserialization. Changes include: - Changes to the API to better distinguish default context snapshot from additional context snapshots. - Disallow global handles when creating snapshots. - Allow extensions when creating snapshots. This solves the issue of not being able to having accessors and interceptors on the global object of contexts to be serialized. R=jochen@chromium.org, peria@chromium.org BUG=chromium:617892 Review-Url: https://codereview.chromium.org/2557743003 Cr-Commit-Position: refs/heads/master@{#41588}
-
mvstanton authored
The patch was reverted due to a bug - we failed to evict OSR-optimized code in the case where the SharedFunctionInfo OptimizedCodeMap was empty/cleared. Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo. This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point. Review-Url: https://codereview.chromium.org/2561083002 Cr-Commit-Position: refs/heads/master@{#41584}
-
bmeurer authored
Revert of Store OSR'd optimized code on the native context. (patchset #8 id:140001 of https://codereview.chromium.org/2549753002/ ) Reason for revert: Speculative revert WebGL breakage reported in https://bugs.chromium.org/p/chromium/issues/detail?id=672367 Original issue's description: > Store OSR'd optimized code on the native context. > > Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo. This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point. > > BUG= > > Committed: https://crrev.com/378b6b22fb7925ac5b672335a54599f5739e7758 > Cr-Commit-Position: refs/heads/master@{#41554} TBR=mstarzinger@chromium.org, mvstanton@chromium.org, ulan@chromium.org BUG= Review-Url: https://codereview.chromium.org/2562623003 Cr-Commit-Position: refs/heads/master@{#41571}
-
- 07 Dec, 2016 1 commit
-
-
mvstanton authored
Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo. This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point. BUG= Review-Url: https://codereview.chromium.org/2549753002 Cr-Commit-Position: refs/heads/master@{#41554}
-
- 25 Oct, 2016 3 commits
-
-
neis authored
Setting variables is not yet implemented. R=adamk@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2445683002 Cr-Commit-Position: refs/heads/master@{#40566}
-
machenbach authored
Revert of [modules] Add partial support for debug-scopes. (patchset #1 id:1 of https://codereview.chromium.org/2445683002/ ) Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/9349 Original issue's description: > [modules] Add partial support for debug-scopes. > > Setting variables is not yet implemented.. > > R=adamk@chromium.org > BUG=v8:1569 TBR=adamk@chromium.org,yangguo@chromium.org,neis@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:1569 Review-Url: https://codereview.chromium.org/2449883002 Cr-Commit-Position: refs/heads/master@{#40564}
-
neis authored
Setting variables is not yet implemented.. R=adamk@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2445683002 Cr-Commit-Position: refs/heads/master@{#40559}
-
- 20 Sep, 2016 1 commit
-
-
littledan authored
This patch ensures that variables like .new_target aren't overwritable using with scopes. It does this by ensuring that scope analysis does not consider with scopes (or eval scopes) for such 'synthetic variables', similarly to how the 'this' variable was already handled. The patch also adds a DCHECK for the dynamic parallel to this case, replacing a previous unreachable path for a particular instance. BUG=v8:5405 Review-Url: https://codereview.chromium.org/2353623002 Cr-Commit-Position: refs/heads/master@{#39567}
-
- 16 Sep, 2016 1 commit
-
-
neis authored
Rename JSModule to Module and make it a Struct rather than a JSObject. We will later add a separate JSModuleNamespace object to implement the 'import * as foo' syntax. BUG=v8:1569 Review-Url: https://codereview.chromium.org/2345823002 Cr-Commit-Position: refs/heads/master@{#39477}
-
- 12 Sep, 2016 4 commits
-
-
neis authored
This adds partial support of exports to the runtime system and to the interpreter. It introduces a new HeapObject JSModule that maps each of the module's export names to a Cell containing the exported value. Several aspects of this implementation are subject to change in follow-up CLs. BUG=v8:1569 Committed: https://crrev.com/241a0412eed919395a2e163b30b9b66071ce5c17 Review-Url: https://codereview.chromium.org/2302783002 Cr-Original-Commit-Position: refs/heads/master@{#39341} Cr-Commit-Position: refs/heads/master@{#39352}
-
rmcilroy authored
Rework Runtime::FunctionForName to take a c-string instead of a v8::String so that the parser can parse native syntax runtime calls without doing on-the-fly internalization. Also adds a c-string variant of IntrinsicIndexForName for the same reasons. BUG=v8:5215,chromium:634953 Review-Url: https://codereview.chromium.org/2324803002 Cr-Commit-Position: refs/heads/master@{#39346}
-
neis authored
Revert of [modules] Basic support of exports (patchset #10 id:180001 of https://codereview.chromium.org/2302783002/ ) Reason for revert: Failures related to deopt. Original issue's description: > [modules] Basic support of exports > > This adds partial support of exports to the runtime system and > to the interpreter. It introduces a new HeapObject JSModule that > maps each of the module's export names to a Cell containing the > exported value. > > Several aspects of this implementation are subject to change in > follow-up CLs. > > BUG=v8:1569 > > Committed: https://crrev.com/241a0412eed919395a2e163b30b9b66071ce5c17 > Cr-Commit-Position: refs/heads/master@{#39341} TBR=adamk@chromium.org,rmcilroy@chromium.org,ulan@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:1569 Review-Url: https://codereview.chromium.org/2328283002 Cr-Commit-Position: refs/heads/master@{#39345}
-
neis authored
This adds partial support of exports to the runtime system and to the interpreter. It introduces a new HeapObject JSModule that maps each of the module's export names to a Cell containing the exported value. Several aspects of this implementation are subject to change in follow-up CLs. BUG=v8:1569 Review-Url: https://codereview.chromium.org/2302783002 Cr-Commit-Position: refs/heads/master@{#39341}
-
- 07 Sep, 2016 1 commit
-
-
jochen authored
This will allow getting the entire scope chain from a SharedFunctionInfo which in turn will allow for generating bytecode when we just have the SFI R=verwaest@chromium.org,marja@chromium.org BUG=v8:5215 Review-Url: https://codereview.chromium.org/2271993002 Cr-Commit-Position: refs/heads/master@{#39243}
-
- 06 Sep, 2016 1 commit
-
-
jochen authored
This will allow for chaining ScopeInfos together to form the same chains as contexts chains currently do. BUG=v8:5215 R=mstarzinger@chromium.org,marja@chromium.org,bmeurer@chromium.org,rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2314483002 Cr-Commit-Position: refs/heads/master@{#39192}
-
- 05 Sep, 2016 1 commit
-
-
jochen authored
Since the extension field is already used for the catch name, store a ContextExtension there instead. In the future, this will allow for chaining ScopeInfos together, so we no longer need a context chain for lazy parsing / compilation. BUG=v8:5215 R=bmeurer@chromium.org,neis@chromium.org,marja@chromium.org Review-Url: https://codereview.chromium.org/2302013002 Cr-Commit-Position: refs/heads/master@{#39164}
-