- 13 Mar, 2017 3 commits
-
-
eholk authored
This is basically the minimum viable signal handler for Wasm bounds checks. It includes the TLS check and the fine grained instructions checks. These two checks provide most of the safety for the signal handler. Future CLs will add code range and data range checks for more robustness. The trap handling code and data structures are all in src/trap-handler, with the code that actually runs in the signal handler confined to src/trap-handler/signal-handler.cc. This changes adds a new V8 API that the embedder should call from a signal handler that will give V8 the chance to handle the fault first. For hosts that do not want to implement their own signal handler, we include the option to install a simple one. This simple handler is also used for the tests. When a Wasm module is instantiated, information about each function is passed to the trap handler, which is used to classify faults. These are removed during the instance finalizer. Several future enhancements are planned before turning this on by default. Obviously, the additional checks will be added to MaybeHandleFault. We are also planning to add a two-level CodeObjectData table that is grouped by isolates to make cleanup easier and also reduce potential for contending on a single data structure. BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 Review-Url: https://codereview.chromium.org/2371833007 Cr-Original-Original-Commit-Position: refs/heads/master@{#43523} Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a Review-Url: https://codereview.chromium.org/2371833007 Cr-Original-Commit-Position: refs/heads/master@{#43755} Committed: https://chromium.googlesource.com/v8/v8/+/338622d7cae787a63cece1f2e79a8b030023940b Review-Url: https://codereview.chromium.org/2371833007 Cr-Commit-Position: refs/heads/master@{#43759}
-
eholk authored
Revert of [wasm] Initial signal handler (patchset #60 id:1170001 of https://codereview.chromium.org/2371833007/ ) Reason for revert: ASAN breakage, such as https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/19111/steps/Check/logs/grow-memory Original issue's description: > [wasm] Initial signal handler > > This is basically the minimum viable signal handler for Wasm bounds checks. > It includes the TLS check and the fine grained instructions checks. These > two checks provide most of the safety for the signal handler. Future CLs will > add code range and data range checks for more robustness. > > The trap handling code and data structures are all in src/trap-handler, with > the code that actually runs in the signal handler confined to > src/trap-handler/signal-handler.cc. > > This changes adds a new V8 API that the embedder should call from a signal > handler that will give V8 the chance to handle the fault first. For hosts that > do not want to implement their own signal handler, we include the option to > install a simple one. This simple handler is also used for the tests. > > When a Wasm module is instantiated, information about each function is passed > to the trap handler, which is used to classify faults. These are removed during > the instance finalizer. > > Several future enhancements are planned before turning this on by default. > Obviously, the additional checks will be added to MaybeHandleFault. We are > also planning to add a two-level CodeObjectData table that is grouped by > isolates to make cleanup easier and also reduce potential for contending on > a single data structure. > > BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 > > Review-Url: https://codereview.chromium.org/2371833007 > Cr-Original-Commit-Position: refs/heads/master@{#43523} > Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a > Review-Url: https://codereview.chromium.org/2371833007 > Cr-Commit-Position: refs/heads/master@{#43755} > Committed: https://chromium.googlesource.com/v8/v8/+/338622d7cae787a63cece1f2e79a8b030023940b TBR=ahaas@chromium.org,bradnelson@google.com,hpayer@chromium.org,jochen@chromium.org,mark@chromium.org,mseaborn@chromium.org,titzer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 Review-Url: https://codereview.chromium.org/2744383002 Cr-Commit-Position: refs/heads/master@{#43757}
-
eholk authored
This is basically the minimum viable signal handler for Wasm bounds checks. It includes the TLS check and the fine grained instructions checks. These two checks provide most of the safety for the signal handler. Future CLs will add code range and data range checks for more robustness. The trap handling code and data structures are all in src/trap-handler, with the code that actually runs in the signal handler confined to src/trap-handler/signal-handler.cc. This changes adds a new V8 API that the embedder should call from a signal handler that will give V8 the chance to handle the fault first. For hosts that do not want to implement their own signal handler, we include the option to install a simple one. This simple handler is also used for the tests. When a Wasm module is instantiated, information about each function is passed to the trap handler, which is used to classify faults. These are removed during the instance finalizer. Several future enhancements are planned before turning this on by default. Obviously, the additional checks will be added to MaybeHandleFault. We are also planning to add a two-level CodeObjectData table that is grouped by isolates to make cleanup easier and also reduce potential for contending on a single data structure. BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 Review-Url: https://codereview.chromium.org/2371833007 Cr-Original-Commit-Position: refs/heads/master@{#43523} Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a Review-Url: https://codereview.chromium.org/2371833007 Cr-Commit-Position: refs/heads/master@{#43755}
-
- 09 Mar, 2017 1 commit
-
-
jgruber authored
This fixes an incorrect usage of String::Flatten in EscapeRegExpSource. It also adds %ConstructConsString (to easily and reliably construct cons strings in tests) and Factory::NewConsString (to enable guaranteed cons string construction without preemptive flattening attempts). BUG=chromium:698790 Review-Url: https://codereview.chromium.org/2736383003 Cr-Commit-Position: refs/heads/master@{#43686}
-
- 02 Mar, 2017 1 commit
-
-
Peter Marshall authored
Turbofan is a lot slower than Crankshaft at constructing TypedArrays, because we always go to the C++ builtin. Port the builtin to CSA to improve performance, and to clean up the implementation, which is split across multiple files and pieces at the moment. This CL increases the performance with --future to roughly the same as with crankshaft. BUG=v8:5977 Change-Id: Id0d91a4592de41a3a308846d79bd44a608931762 Reviewed-on: https://chromium-review.googlesource.com/448537Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#43548}
-
- 01 Mar, 2017 4 commits
-
-
bmeurer authored
Revert of [wasm] Initial signal handler (patchset #56 id:1090001 of https://codereview.chromium.org/2371833007/ ) Reason for revert: Breaks tree, i.e. https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/18928/steps/Check/logs/grow-memory Original issue's description: > [wasm] Initial signal handler > > This is basically the minimum viable signal handler for Wasm bounds checks. > It includes the TLS check and the fine grained instructions checks. These > two checks provide most of the safety for the signal handler. Future CLs will > add code range and data range checks for more robustness. > > The trap handling code and data structures are all in src/trap-handler, with > the code that actually runs in the signal handler confined to > src/trap-handler/signal-handler.cc. > > This changes adds a new V8 API that the embedder should call from a signal > handler that will give V8 the chance to handle the fault first. For hosts that > do not want to implement their own signal handler, we include the option to > install a simple one. This simple handler is also used for the tests. > > When a Wasm module is instantiated, information about each function is passed > to the trap handler, which is used to classify faults. These are removed during > the instance finalizer. > > Several future enhancements are planned before turning this on by default. > Obviously, the additional checks will be added to MaybeHandleFault. We are > also planning to add a two-level CodeObjectData table that is grouped by > isolates to make cleanup easier and also reduce potential for contending on > a single data structure. > > BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 > > Review-Url: https://codereview.chromium.org/2371833007 > Cr-Commit-Position: refs/heads/master@{#43523} > Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a TBR=ahaas@chromium.org,bradnelson@google.com,hpayer@chromium.org,jochen@chromium.org,mark@chromium.org,mseaborn@chromium.org,titzer@chromium.org,eholk@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 Review-Url: https://codereview.chromium.org/2723133003 Cr-Commit-Position: refs/heads/master@{#43525}
-
eholk authored
This is basically the minimum viable signal handler for Wasm bounds checks. It includes the TLS check and the fine grained instructions checks. These two checks provide most of the safety for the signal handler. Future CLs will add code range and data range checks for more robustness. The trap handling code and data structures are all in src/trap-handler, with the code that actually runs in the signal handler confined to src/trap-handler/signal-handler.cc. This changes adds a new V8 API that the embedder should call from a signal handler that will give V8 the chance to handle the fault first. For hosts that do not want to implement their own signal handler, we include the option to install a simple one. This simple handler is also used for the tests. When a Wasm module is instantiated, information about each function is passed to the trap handler, which is used to classify faults. These are removed during the instance finalizer. Several future enhancements are planned before turning this on by default. Obviously, the additional checks will be added to MaybeHandleFault. We are also planning to add a two-level CodeObjectData table that is grouped by isolates to make cleanup easier and also reduce potential for contending on a single data structure. BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 Review-Url: https://codereview.chromium.org/2371833007 Cr-Commit-Position: refs/heads/master@{#43523}
-
Peter Marshall authored
This reverts commit b23b2c10. Reason for revert: Makes Linux debug bot sad Original change's description: > [builtins] Port TypedArrayInitialize to CodeStubAssembler. > > Turbofan is a lot slower than Crankshaft at constructing TypedArrays, > because we always go to the C++ builtin. Port the builtin to CSA > to improve performance, and to clean up the implementation, which is > split across multiple files and pieces at the moment. > > This CL increases the performance with --future to roughly the same > as with crankshaft. > > BUG=v8:5977 > > Change-Id: I5a4c4b544a735a56290b85bf33c2f3718df7e2b8 > Reviewed-on: https://chromium-review.googlesource.com/445717 > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Cr-Commit-Position: refs/heads/master@{#43518} TBR=cbruni@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org,v8-reviews@googlegroups.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5977 Change-Id: I5d5bc8b4677a405c716d78e688af80ae9c737b4a Reviewed-on: https://chromium-review.googlesource.com/448558Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#43520}
-
Peter Marshall authored
Turbofan is a lot slower than Crankshaft at constructing TypedArrays, because we always go to the C++ builtin. Port the builtin to CSA to improve performance, and to clean up the implementation, which is split across multiple files and pieces at the moment. This CL increases the performance with --future to roughly the same as with crankshaft. BUG=v8:5977 Change-Id: I5a4c4b544a735a56290b85bf33c2f3718df7e2b8 Reviewed-on: https://chromium-review.googlesource.com/445717 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#43518}
-
- 28 Feb, 2017 2 commits
-
-
Georg Neis authored
The order in which things were done wasn't quite correct and lead to wrong behaviour for certain circular module graphs. BUG=v8:1569,chromium:694566 Change-Id: I291186e261268c853a30ad891ff362904e0b28ef Reviewed-on: https://chromium-review.googlesource.com/447399Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#43497}
-
Igor Sheludko authored
This CL also introduces Realm.navigate(i). BUG=chromium:683667 Change-Id: I9227292ea3a575f34367e82fc6297d234d3eecae Reviewed-on: https://chromium-review.googlesource.com/447638 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#43494}
-
- 24 Feb, 2017 1 commit
-
-
caitp authored
Introduce a new Object to allow GetIterator("async") to function when the iterable does not have a Symbol.asyncIterator method. This patch has been split out from https://codereview.chromium.org/2622833002/ and incorporates test cases. BUG=v8:5855, v8:4483 R=jgruber@chromium.org, rmcilroy@chromium.org, neis@chromium.org TBR=hpayer@chromium.org, bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2645313003 Cr-Commit-Position: refs/heads/master@{#43419}
-
- 17 Feb, 2017 1 commit
-
-
Toon Verwaest authored
BUG= Change-Id: Ie7a8327fac62a0608b60cf9f0f072f979ac4fd76 Reviewed-on: https://chromium-review.googlesource.com/443528Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Toon Verwaest <verwaest@google.com> Cr-Commit-Position: refs/heads/master@{#43269}
-
- 16 Feb, 2017 1 commit
-
-
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
-
-
bbudge authored
LOG=Y BUG=v8:4124,v8:5948 R=bradnelson@chromium.org,bmeurer@chromium.org,jochen@chromium.org,hpayer@chromium.org,danno@chromium.org Review-Url: https://codereview.chromium.org/2684313003 Cr-Original-Original-Commit-Position: refs/heads/master@{#43162} Committed: https://chromium.googlesource.com/v8/v8/+/d170c57ab996d00c4665a9d865bd5754a1806c6c Review-Url: https://codereview.chromium.org/2684313003 Cr-Original-Commit-Position: refs/heads/master@{#43169} Committed: https://chromium.googlesource.com/v8/v8/+/a9b59a11f1bfe069afabe5567f919727456f1f12 Review-Url: https://codereview.chromium.org/2684313003 Cr-Commit-Position: refs/heads/master@{#43176}
-
- 13 Feb, 2017 4 commits
-
-
franzih authored
Revert of Remove SIMD.js from V8. (patchset #7 id:120001 of https://codereview.chromium.org/2684313003/ ) Reason for revert: Breaks Node integration build. Original issue's description: > Remove SIMD.js from V8. > > LOG=Y > BUG=v8:4124,v8:5948 > R=bradnelson@chromium.org,bmeurer@chromium.org,jochen@chromium.org,hpayer@chromium.org,danno@chromium.org > > Review-Url: https://codereview.chromium.org/2684313003 > Cr-Original-Commit-Position: refs/heads/master@{#43162} > Committed: https://chromium.googlesource.com/v8/v8/+/d170c57ab996d00c4665a9d865bd5754a1806c6c > Review-Url: https://codereview.chromium.org/2684313003 > Cr-Commit-Position: refs/heads/master@{#43169} > Committed: https://chromium.googlesource.com/v8/v8/+/a9b59a11f1bfe069afabe5567f919727456f1f12 TBR=bradnelson@chromium.org,bmeurer@chromium.org,jochen@chromium.org,hpayer@chromium.org,danno@chromium.org,bradnelson@google.com,machenbach@chromium.org,bbudge@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4124,v8:5948 Review-Url: https://codereview.chromium.org/2695653005 Cr-Commit-Position: refs/heads/master@{#43170}
-
bbudge authored
LOG=Y BUG=v8:4124,v8:5948 R=bradnelson@chromium.org,bmeurer@chromium.org,jochen@chromium.org,hpayer@chromium.org,danno@chromium.org Review-Url: https://codereview.chromium.org/2684313003 Cr-Original-Commit-Position: refs/heads/master@{#43162} Committed: https://chromium.googlesource.com/v8/v8/+/d170c57ab996d00c4665a9d865bd5754a1806c6c Review-Url: https://codereview.chromium.org/2684313003 Cr-Commit-Position: refs/heads/master@{#43169}
-
bradnelson authored
Revert of Remove SIMD.js from V8. (patchset #7 id:120001 of https://codereview.chromium.org/2684313003/ ) Reason for revert: red Original issue's description: > Remove SIMD.js from V8. > > LOG=Y > BUG=v8:4124,5948 > R=bradnelson@chromium.org,bmeurer@chromium.org,jochen@chromium.org,hpayer@chromium.org,danno@chromium.org > (notry since trybots can't patch directory deletes) > NOTRY=true > > Review-Url: https://codereview.chromium.org/2684313003 > Cr-Commit-Position: refs/heads/master@{#43162} > Committed: https://chromium.googlesource.com/v8/v8/+/d170c57ab996d00c4665a9d865bd5754a1806c6c TBR=bmeurer@chromium.org,jochen@chromium.org,hpayer@chromium.org,danno@chromium.org,bradnelson@google.com,bbudge@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4124,5948 Review-Url: https://codereview.chromium.org/2692933002 Cr-Commit-Position: refs/heads/master@{#43164}
-
bbudge authored
LOG=Y BUG=v8:4124,5948 R=bradnelson@chromium.org,bmeurer@chromium.org,jochen@chromium.org,hpayer@chromium.org,danno@chromium.org (notry since trybots can't patch directory deletes) NOTRY=true Review-Url: https://codereview.chromium.org/2684313003 Cr-Commit-Position: refs/heads/master@{#43162}
-
- 10 Feb, 2017 1 commit
-
-
jarin authored
This introduces new maps to track whether we have created at most one closure. If we have created just one closure, Turbofan will specialize the code to its context. Review-Url: https://codereview.chromium.org/2680313002 Cr-Commit-Position: refs/heads/master@{#43108}
-
- 08 Feb, 2017 1 commit
-
-
jkummerow authored
Review-Url: https://codereview.chromium.org/2683903002 Cr-Commit-Position: refs/heads/master@{#43047}
-
- 07 Feb, 2017 1 commit
-
-
ishell@chromium.org authored
... and TypeFeedbackMetadata to FeedbackMetadata. BUG= Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c Reviewed-on: https://chromium-review.googlesource.com/439244 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#42999}
-
- 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}
-
- 31 Jan, 2017 1 commit
-
-
eholk authored
Previously this information was encoded in a FixedArray dangling off the Code object. This extra field seems to be responsible for increased memory usage, as seen in the linked bugs. In this change, we instead encode this in the RelocInfo and remove the field from the Code object. BUG= https://bugs.chromium.org/p/chromium/issues/detail?id=678583 BUG= https://bugs.chromium.org/p/chromium/issues/detail?id=671180 BUG= https://bugs.chromium.org/p/chromium/issues/detail?id=670733 Review-Url: https://codereview.chromium.org/2651833003 Cr-Commit-Position: refs/heads/master@{#42802}
-
- 30 Jan, 2017 2 commits
-
-
jkummerow authored
BUG=chromium:685504 Review-Url: https://codereview.chromium.org/2660823002 Cr-Commit-Position: refs/heads/master@{#42783}
-
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}
-
- 24 Jan, 2017 2 commits
-
-
franzih authored
The property backing store size depends on the number of index keys. Pass index keys to the factory function instead calculating the size outside. R=verwaest@chromium.org BUG=v8:5625 Review-Url: https://codereview.chromium.org/2651533002 Cr-Commit-Position: refs/heads/master@{#42637}
-
mtrofin authored
BUG=v8:5885 Review-Url: https://codereview.chromium.org/2649163004 Cr-Commit-Position: refs/heads/master@{#42636}
-
- 23 Jan, 2017 3 commits
-
-
ishell authored
Manipulating the signaling NaN used for the hole and uninitialized double field sentinel in C++, e.g. with bit_cast or HeapNumber::value()/set_value(), will change its value on ia32 (the x87 stack is used to return values and stores to the stack silently clear the signalling bit). BUG=v8:5495 Review-Url: https://codereview.chromium.org/2652553003 Cr-Commit-Position: refs/heads/master@{#42609}
-
franzih authored
We do not want to reserve space in the backing store for index keys. Count index keys during creation of the BoilerplateDescription, and substract them for the backing store size. Correctly count index keys after encountering a property with a computed name during object literal creation. R=verwaest@chromium.org BUG=v8:5625 Review-Url: https://codereview.chromium.org/2651523002 Cr-Commit-Position: refs/heads/master@{#42598}
-
yangguo authored
We are planning to add a few more debugger related bits, and are running out of compiler hints bits. The new bit field is going to be part of the debug info struct. If the debug info is not available, we store the bit field in its place on the shared function info. Review-Url: https://codereview.chromium.org/2649873002 Cr-Commit-Position: refs/heads/master@{#42594}
-
- 20 Jan, 2017 1 commit
-
-
franzih authored
Allocate space in the backing store for computed property names. The property backing store was pre-allocated for the constant properties up to the first non-constant (computed name) property. To use lowering for storing data properties in literals with computed property names effectively, a fast store is needed, i.e., available space in the property backing store for properties with computed names. backing_store_size is the number of all properties (including computed names, but without __proto__) that is calculated in the ast and passed to the runtime function that allocates the property backing store. backing_store_size and constant_properties constitute a BoilerplateDescription. backing_store_size might be slightly too high because computed names can evaluate to the same name, but that should be a rare case so over-allocating is OK. If a property is __proto__, we don't store it as a regular property, because the map changes. Keep track of has_seen_proto in the parser to calculate the backing store size correctly. BUG=v8:5625 Review-Url: https://codereview.chromium.org/2632503003 Cr-Commit-Position: refs/heads/master@{#42576}
-
- 19 Jan, 2017 1 commit
-
-
jkummerow authored
using newly introduced ThinStrings, which store a pointer to the actual, internalized string they represent. BUG=v8:4520 (Previously landed as #42168 / af51befe) (Previously landed as #42193 / 4c699e34) (Previously landed as #42235 / ec45e6ed) Review-Url: https://codereview.chromium.org/2549773002 Cr-Commit-Position: refs/heads/master@{#42503}
-
- 18 Jan, 2017 2 commits
-
-
mattloring authored
FFI Compiler outline based on code stub assembler. We are looking to land this frame to allow specific type translation implementations to proceed in parallel. BUG=v8:4456 Review-Url: https://codereview.chromium.org/2607993003 Cr-Commit-Position: refs/heads/master@{#42475}
-
clemensh authored
Store breakpoint positions in the WasmSharedModuleData in order to set them on new instantiations. Also redirect them to all live instances at the time the breakpoint is set. Inside the WasmDebugInfo, we store the BreakPointInfo objects to find hit breakpoints. R=titzer@chromium.org, yangguo@chromium.org BUG=v8:5822 Review-Url: https://codereview.chromium.org/2626253002 Cr-Commit-Position: refs/heads/master@{#42443}
-
- 17 Jan, 2017 2 commits
-
-
gsathya authored
BUG=v8:5343 Review-Url: https://codereview.chromium.org/2637523002 Cr-Commit-Position: refs/heads/master@{#42423}
-
rmcilroy authored
A GC could happen when creating the Module string, which would cause the JSModuleNamespace to be seen in an incomplete state. Instead make this string a root object so that we don't need to allocate it during NewJSModuleNamespace construction. BUG=v8:1569 Review-Url: https://codereview.chromium.org/2631223002 Cr-Commit-Position: refs/heads/master@{#42393}
-
- 13 Jan, 2017 3 commits
-
-
kozyatinskiy authored
Inspector uses event name only for enqueue* events and doesn't really need name for other events. BUG=v8:5738 R=jgruber@chromium.org,gsathya@chromium.org TBR=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2628173005 Cr-Commit-Position: refs/heads/master@{#42339}
-
ishell authored
BUG=v8:5495 Review-Url: https://codereview.chromium.org/2633553002 Cr-Commit-Position: refs/heads/master@{#42329}
-
ishell authored
BUG=v8:5495 Review-Url: https://codereview.chromium.org/2622413004 Cr-Commit-Position: refs/heads/master@{#42328}
-