- 13 May, 2020 1 commit
-
-
Marja Hölttä authored
There's no need for them to be in NativeContext. This CL moves the only remaining Proxy-related SFI. Bug: v8:10482 Change-Id: I2f5e2d250c30f552787915d306c1be23b9d033bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2196184Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#67766}
-
- 12 May, 2020 1 commit
-
-
Marja Hölttä authored
There's no need for them to be in NativeContext. This CL moves the rest of the Promise-related SFIs. Bug: v8:10482 Change-Id: I7eb926be14bf44fb3cd01cb96b4769eff1c2911b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190752 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#67732}
-
- 08 May, 2020 2 commits
-
-
Tobias Tebbi authored
Bug: v8:7793 TBR: danno@chromium.org Change-Id: If6b1229af2b282bd24bf222b2a06a45cc640c557 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190750Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67691}
-
Marja Hölttä authored
There's no need for them to be in NativeContext. This CL moves the minimal subset of SFIs related to Promises / finally. Bug: v8:10482 Change-Id: I06a20dc927f13b7bfc8cea853a11913314ee019d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187271Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Auto-Submit: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#67674}
-
- 07 May, 2020 1 commit
-
-
Marja Hölttä authored
There's no need for them to be in NativeContext. This CL moves the minimal subset of SFIs related to async iterators. Bug: v8:10482 Change-Id: I80a34a886387398e6565afe77ab99f389d2ccabd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2184233Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#67636}
-
- 06 May, 2020 1 commit
-
-
Marja Hölttä authored
There's no need for them to be in NativeContext. This CL moves the minimal subset of SFIs related to async functions and async generators. Bug: v8:10482 Change-Id: Ic90e342ae77b406c12dedf6b8f7e3fadb661b205 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2179843 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#67590}
-
- 28 Apr, 2020 1 commit
-
-
Jakob Gruber authored
This reverts the changes made in https://chromium-review.googlesource.com/c/v8/v8/+/1695465 https://chromium-review.googlesource.com/c/v8/v8/+/1776078 We originally moved this protector to the native context to avoid cross-native-context pollution of protector state. Ideally, invalidating a protector in one NC should not affect any other NC. But as it turns out, having the protector on the NC causes more problems than it solves since all affected callers now need to find the correct native context to check. Sometimes (e.g. in CSA regexp builtins) it is possible to blindly check the current NC, but the reasoning behind this optimization is tricky to understand. Sometimes, fetching the correct NC is not possible due to access restrictions. These implementation complexities outweigh the (unknown) potential performance benefits. In the future we should attempt to move away from the protector concept for these kinds of checks. Bug: chromium:1069964,v8:9463 Change-Id: I2cbb2ec7266282165dae5e4a6c8bdbda520c50a9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157382Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67415}
-
- 20 Apr, 2020 1 commit
-
-
Sathya Gunasekaran authored
Previously, one single retained maps list was used across all contexts. When one context was disposed, this entire list of retained maps was disposed as well. This caused maps that were still alive to be disposed leading to deopts when such maps were embedded in code objects. This patch makes the list of retained maps be per context so we can dispose only the dead maps. Bug: v8:9684, v8:10431 Change-Id: I0a50f4f49c9f6d72367c62e950828a039220fdfc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122016Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#67225}
-
- 08 Apr, 2020 1 commit
-
-
Tobias Tebbi authored
The two refactorings are somewhat orthogonal, but intersect at the class and instance type list generation, which is why it's easier to put them in one CL. For the removal of HasIndexedField, the removal is motivated by the fact that is no longer necessary, and that using a flag to store this kind of information is hacky. For the class list changes, this is a cleanup in that we no longer generate third-order macros, but instead normal macro lists. There is a functional change and bug-fix in that we no longer include abstract classes in lists that refer to instance types or maps. It's still somewhat broken though, so I can't test abstract internal classes yet, though. Coming in a follow-up CL. TBR=ulan@chromium.org Bug: v8:7793 Change-Id: Ided8591370570ca3810d7991f53177ca32e03048 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108034 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#67056}
-
- 09 Mar, 2020 1 commit
-
-
Tobias Tebbi authored
In the process: * Augment C++-generated Torque classes with SizeFor methods to calculate size of instances. * Add a new "@generateBodyDescriptor" annotation that causes Torque to generate C++ BodyDescriptors code that can be used to visit objects compatible with existing V8 mechanisms, e.g. GC * Fully automate C++ macro machinery so that adding non-extern Torque class doesn't require any C++ changes, including ensuring generation of instance types and proper boilerplate for validators and printers. * Make handling of @export a true annotation, allowing the modifier to be used on class declarations. * Add functionality such that classes with the @export annotation are available to be used from C++. Field accessors for exported classes are public and factory methods are generated to create instances of the objects from C++. * Change the Torque compiler such that Non-exported classes implicitly have the @generateBodyDescriptor annotation added and causes both verifiers and printers to be generated. * Switch non-extern Torque classes from using existing Struct-based machinery to being first-class classes that support more existing Torque class features. Change-Id: Ic60e60c2c6bd7acd57f949bce086898ad14a3b03 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007490 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66621}
-
- 24 Feb, 2020 1 commit
-
-
Shu-yu Guo authored
Renaming the JS-visible identifiers and strings is left for a future CL. FinalizationGroup was renamed at Feb 2020 TC39, to better signal that if a FinalizationRegistry dies, the finalization actions registered with it may no longer be performed. Bug: v8:8179 Change-Id: I0d676a71a4a67d2b7175994a67458a6158065844 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2055381Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#66416}
-
- 18 Feb, 2020 1 commit
-
-
Seth Brenith authored
This allows CoverageInfo to be distinguished from other kinds of FixedArray at runtime. I also updated it to use untagged data since it only stores ints, since that seems like the generally right thing to do (even though I doubt anybody allocates enough of these to notice the reduced GC work). Related Torque changes: - Allow structs containing untagged data to be used as class fields. This requires classifying them into the tagged or untagged sections of the class layout, and checking that their alignment requirements are met when stored in a packed array. - Generate a struct containing struct field offsets, so we can ensure that the layouts defined in Torque and C++ code match. Of course it would be nice to generate a lot more (indexed accessors, synchronized accessors, GC visitors, etc.), but we can't do it all at once. Change-Id: I29e2a2afe37e4805cd80e3a84ef9edfe7ca7bb6b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047399Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#66318}
-
- 17 Feb, 2020 1 commit
-
-
Shu-yu Guo authored
Currently dirty FinalizationGroups are processed by the cleanup task in LIFO order. This results in starvation when FinalizationGroups are added to the dirty list faster than the cleanup task is run. R=ulan@chromium.org Bug: v8:8179 Change-Id: I6e4a5bbd490396120b07ca6053176beded7cef6e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051619Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#66296}
-
- 12 Feb, 2020 1 commit
-
-
Shu-yu Guo authored
A FinalizationGroup that needs cleanup should not artificially prolong its lifetime by being on the dirty list. R=ulan@chromium.org Bug: v8:8179 Change-Id: I19f102d154a9ac43b549b7d833d0c3ca7e61c6d0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051562Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#66251}
-
- 14 Jan, 2020 1 commit
-
-
Seth Brenith authored
There is no particular reason that PropertyDescriptorObject should be a subclass of FixedArray. By using a separate struct type, we get better generated accessor functions, automatic verification, and runtime type info, plus we save four bytes per instance. Change-Id: If076782832aa9398806794e4ee6d019aea2f92b7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1999463Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#65756}
-
- 10 Jan, 2020 1 commit
-
-
Seth Brenith authored
This change moves the definitions of the bitfield flags used by Symbol and Map to Torque. Symbol could directly follow the pattern established by SharedFunctionInfo, but Map required some other changes: - Until now, Torque bitfield definitions have required unsigned types. I thought that this would be the least-surprising behavior, since we never sign-extend when decoding bitfield values. However, I believe that the amount of churn involved in making ElementsKind be unsigned outweighs the benefit we were getting from this restriction (and similar difficulties are likely to arise in converting other bitfield structs to Torque), so this CL updates Torque to allow signed bitfield values. - If we try to make Map extend from all of the generated classes that define its flags, we end up with class sizing problems because some compilers only apply empty base class optimization to the first in a row of empty base classes. We could work around this issue by generating macros instead of classes, but I took this as an opportunity for a minor clean-up instead: rather than having bitfield definitions for several different bitfield structs all jumbled together in Map, they can be split up. I think this makes the code a little easier to follow, but if others disagree I'm happy to implement macro generation instead. Change-Id: Ibf339b0be97f72d740bf1daa8300b471912faeba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988934Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#65701}
-
- 18 Nov, 2019 1 commit
-
-
Tobias Tebbi authored
For many subclasses of JSObject, we used kSize instead of kHeaderSize even though they can contain in-object properties. In fact, kSize was very much used as the header size, as can be seen in many examples in this CL. This change is a preparation for a for a cleanup of how Torque generates field offsets. TBR=hpayer@chromium.org Change-Id: I350e996057cd66c427381334080f8ac93de88597 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917141 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#65013}
-
- 15 Nov, 2019 1 commit
-
-
Maya Lekova authored
This helps reduce the number of false positives encountered by the dead variable analysis in gcmole. TBR=jgruber@chromium.org, verwaest@chromium.org, yangguo@chromium.org Bug: v8:9810 Change-Id: I1a34ccaab340e6abc37832b4ce1a0cabc56fa438 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917146 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64981}
-
- 30 Oct, 2019 1 commit
-
-
Gus Caplan authored
Change-Id: I2a1ad1835b751237b350e56d64e3475459bfb7a6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873715 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#64636}
-
- 24 Oct, 2019 1 commit
-
-
Victor Gomes authored
The native context used an empty function scope info. This is inconsistent with the fact the native context has an extension slot, since the empty function scope info doesn't have the extension slot flag set. This CL creates a scope info dedicated for the native context with the flag set. Bug: v8:9744 Change-Id: I00459e9a0ca75dd7a0e2add5e9e61747d0635f39 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876821 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#64550}
-
- 22 Oct, 2019 1 commit
-
-
Jakob Gruber authored
The natives blob was deprecated in V8 7.8. This CL removes all related functionality, including: - Build system support, i.e.: generation of natives_blob.bin and the v8_extra_library_files gn flag. - Related scripts (js2c.py, concatenate-files.py). - Related API functions (SetNativesDataBlob, InitializeExternalStartupData). - Natives bootstrapping logic. - The InternalArray type (previously exposed through natives). - Other natives-exposed builtins. - Inlining of these builtins. - The dedicated 'uncached external one byte string' type. Step 1 landed in https://crrev.com/c/1824944. Step 2 landed in https://crrev.com/c/1835536. Step 3 (this CL) removes these all functionality related to natives support in V8. Bug: v8:7624 Change-Id: Ice6c2662781efe8417231805276476d32bc5a625 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1844771 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Tamer Tas <tmrts@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#64446}
-
- 17 Oct, 2019 1 commit
-
-
Toon Verwaest authored
This is a reland of c7c47c68. This makes TSAN happy in addition to: Previously I presumed that the context read from a frame in the profiler was a valid context. Turns out that on non-intel we're not guaranteed that the frame is properly set up. In the case we looked at, the profiler took a sample right before writing the frame marker indicating a builtin frame, causing the "context" pointer from that frame to be a bytecode array. Since we'll read random garbage on the stack as a possible context pointer, I made the code reading the native context from it a little more defensive. Bug: v8:9860 Tbr: ulan@chromium.org, neis@chromium.org, ishell@chromium.org Original change's description: > [runtime] Move Context::native_context to the map > > Remove the native context slot from contexts by making context maps > native-context-specific. Now we require 2 loads to go from a context to the > native context, but we have 1 field fewer to store when creating contexts. > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64296} Change-Id: I4d0ab4cbbb23a9ae616407f17ef8f35a0b68ddb4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864654 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64360}
-
- 16 Oct, 2019 2 commits
-
-
Sathya Gunasekaran authored
This reverts commit c7c47c68. Reason for revert: breaks TSAN https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/28738 Original change's description: > Reland "[runtime] Move Context::native_context to the map" > > This is a reland of f05bae1e > > Previously I presumed that the context read from a frame in the profiler was > a valid context. Turns out that on non-intel we're not guaranteed that the > frame is properly set up. In the case we looked at, the profiler took a > sample right before writing the frame marker indicating a builtin frame, > causing the "context" pointer from that frame to be a bytecode array. Since > we'll read random garbage on the stack as a possible context pointer, I made > the code reading the native context from it a little more defensive. > > Bug: v8:9860 > > Original change's description: > > [runtime] Move Context::native_context to the map > > > > Remove the native context slot from contexts by making context maps > > native-context-specific. Now we require 2 loads to go from a context to the > > native context, but we have 1 field fewer to store when creating contexts. > > > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Reviewed-by: Maya Lekova <mslekova@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#64296} > > Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Auto-Submit: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64314} TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com Change-Id: I4f9edc62ea6f9f5857619ff0ad1a63cab4b33cc3 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9860 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864937Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64316}
-
Toon Verwaest authored
This is a reland of f05bae1e Previously I presumed that the context read from a frame in the profiler was a valid context. Turns out that on non-intel we're not guaranteed that the frame is properly set up. In the case we looked at, the profiler took a sample right before writing the frame marker indicating a builtin frame, causing the "context" pointer from that frame to be a bytecode array. Since we'll read random garbage on the stack as a possible context pointer, I made the code reading the native context from it a little more defensive. Bug: v8:9860 Original change's description: > [runtime] Move Context::native_context to the map > > Remove the native context slot from contexts by making context maps > native-context-specific. Now we require 2 loads to go from a context to the > native context, but we have 1 field fewer to store when creating contexts. > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64296} Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64314}
-
- 15 Oct, 2019 2 commits
-
-
Sathya Gunasekaran authored
This reverts commit f05bae1e. Reason for revert: broke arm sim debug https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/17714 https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8899519852984476944/+/steps/Check_-_trusted/0/logs/FunctionDetailsInlining/0 Original change's description: > [runtime] Move Context::native_context to the map > > Remove the native context slot from contexts by making context maps > native-context-specific. Now we require 2 loads to go from a context to the > native context, but we have 1 field fewer to store when creating contexts. > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64296} TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com Change-Id: Ie7b4086c3a9ab2627ecac599da36b20cf8d1f948 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863200Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64299}
-
Toon Verwaest authored
Remove the native context slot from contexts by making context maps native-context-specific. Now we require 2 loads to go from a context to the native context, but we have 1 field fewer to store when creating contexts. Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64296}
-
- 08 Oct, 2019 1 commit
-
-
Mythri A authored
Empty slow element dictionary had the sticky bit set. This bit was used to indicate that the dictionary cannot go to the fast mode either because the dictionary had elements with attributed or elements at large indices. There is no reason for the empty dictionary to have this bit set. This causes bugs in some corner cases. Bug: chromium:1003732 Change-Id: Ib29e1cda784869b9deb9361d8e6b5539f7154a38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1833686Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#64158}
-
- 01 Oct, 2019 1 commit
-
-
Joshua Litt authored
Removes the static protector values from isolate now that they are no longer needed. This is the final cl in the migration effort. Bug: v8:9463 Change-Id: I2127ef6c8a0cdaf0ccf28aed12539335ef985704 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1827455Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#64068}
-
- 23 Sep, 2019 1 commit
-
-
Joshua Litt authored
Bug: v8:9463 Change-Id: Ie0e04e102b56ffdfb636e94ef293bb0d46e5f4a9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1808485Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#63933}
-
- 16 Sep, 2019 1 commit
-
-
Victor Gomes authored
Uses templates to dispath the allocation flag statically. Bug: v8:9714 Change-Id: I1998ae47be2f7d872d34b3bc2390d01cbfad6afa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1801848 Auto-Submit: Victor Gomes <victorgomes@google.com> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#63783}
-
- 12 Sep, 2019 1 commit
-
-
Victor Gomes authored
Bug: v8:9714 Change-Id: I70c28c3bc2aae6234e55e8a3b176da2035520a67 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800567 Commit-Queue: Victor Gomes <victorgomes@google.com> Auto-Submit: Victor Gomes <victorgomes@google.com> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#63717}
-
- 11 Sep, 2019 2 commits
-
-
Dominik Inführ authored
SharedFunctionInfos that do not belong to a script were tracked in noscript_shared_function_infos. However this was only used in object-stats. Remove this since it was actually leaking memory in some use cases. Bug: v8:9674 Change-Id: I9482f7e5dedf975666a70684b3d2ea04c9a23518 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1798423Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#63685}
-
Joshua Litt authored
Also converts ACP from a Cell to a PropertyCell. Bug: v8:9463 Change-Id: I6cd26d4e4fd8869a17bf75f83cc177524f8082d7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795742Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#63675}
-
- 09 Sep, 2019 1 commit
-
-
Ulan Degenbaev authored
This reverts commit 9da34831 Original change's description: > "Reland x4 [arraybuffer] Rearchitect backing store ownership" > > This is a reland of bc33f5ae > > Contributed by titzer@chromium.org > > Original change's description: > > [arraybuffer] Rearchitect backing store ownership > > > > This CL completely rearchitects the ownership of array buffer backing stores, > > consolidating ownership into a {BackingStore} C++ object that is tracked > > throughout V8 using unique_ptr and shared_ptr where appropriate. > > > > Overall, lifetime management is simpler and more explicit. The numerous > > ways that array buffers were initialized have been streamlined to one > > Attach() method on JSArrayBuffer. The array buffer tracker in the > > GC implementation now manages std::shared_ptr<BackingStore> pointers, > > and the construction and destruction of the BackingStore object itself > > handles the underlying page or embedder-allocated memory. > > > > The embedder API remains unchanged for now. We use the > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to > > keep the backing store alive properly, even in the case of aliases > > from live heap objects. Thus the embedder has a lower chance of making > > a mistake. Long-term, we should move the embedder to a model where they > > manage backing stores using shared_ptr to an opaque backing store object. > > TBR=yangguo@chromium.org > > BUG=v8:9380,v8:9221,chromium:986318 > > Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005 > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63041} TBR=yangguo@chromium.org Change-Id: I3cc4bb80081c662b1751234bc16a821c20e744be Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792166 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63617}
-
- 03 Sep, 2019 1 commit
-
-
Joshua Litt authored
NativeContext will soon outgrow the limits of the fixed sized map. This CL simply moves NativeContext back to the variable sized map. Bug: v8:9463 Change-Id: I477dc5f19ed22b5b2b8d3415daad9d87e785bdcb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774185Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#63524}
-
- 30 Aug, 2019 1 commit
-
-
Ulan Degenbaev authored
This reverts commit 62e16830. Reason for revert: it will be relanded after branch Original change's description: > Reland x5 [arraybuffer] Rearchitect backing store ownership > > This reverts commit 8fdb2387. > > Original change's description: > > "Reland x4 [arraybuffer] Rearchitect backing store ownership" > > > > This is a reland of bc33f5ae > > > > Contributed by titzer@chromium.org > > > > Original change's description: > > > [arraybuffer] Rearchitect backing store ownership > > > > > > This CL completely rearchitects the ownership of array buffer backing stores, > > > consolidating ownership into a {BackingStore} C++ object that is tracked > > > throughout V8 using unique_ptr and shared_ptr where appropriate. > > > > > > Overall, lifetime management is simpler and more explicit. The numerous > > > ways that array buffers were initialized have been streamlined to one > > > Attach() method on JSArrayBuffer. The array buffer tracker in the > > > GC implementation now manages std::shared_ptr<BackingStore> pointers, > > > and the construction and destruction of the BackingStore object itself > > > handles the underlying page or embedder-allocated memory. > > > > > > The embedder API remains unchanged for now. We use the > > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to > > > keep the backing store alive properly, even in the case of aliases > > > from live heap objects. Thus the embedder has a lower chance of making > > > a mistake. Long-term, we should move the embedder to a model where they > > > manage backing stores using shared_ptr to an opaque backing store object. > > > > TBR=yangguo@chromium.org > > > > BUG=v8:9380,v8:9221,chromium:986318 > > > > Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005 > > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#63041} > > TBR=yangguo@chromium.org,clemensh@chromium.org,mstarzinger@chromium.org > > Change-Id: Iba55c7ab71e5642b5cb6aeb699d6fc9cf9061486 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771795 > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63461} TBR=ulan@chromium.org,mlippautz@chromium.org Change-Id: Id8f67a68ab398032eb2975b1b24ee125394d9c4b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776095Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#63471}
-
- 29 Aug, 2019 1 commit
-
-
Ulan Degenbaev authored
This reverts commit 8fdb2387. Original change's description: > "Reland x4 [arraybuffer] Rearchitect backing store ownership" > > This is a reland of bc33f5ae > > Contributed by titzer@chromium.org > > Original change's description: > > [arraybuffer] Rearchitect backing store ownership > > > > This CL completely rearchitects the ownership of array buffer backing stores, > > consolidating ownership into a {BackingStore} C++ object that is tracked > > throughout V8 using unique_ptr and shared_ptr where appropriate. > > > > Overall, lifetime management is simpler and more explicit. The numerous > > ways that array buffers were initialized have been streamlined to one > > Attach() method on JSArrayBuffer. The array buffer tracker in the > > GC implementation now manages std::shared_ptr<BackingStore> pointers, > > and the construction and destruction of the BackingStore object itself > > handles the underlying page or embedder-allocated memory. > > > > The embedder API remains unchanged for now. We use the > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to > > keep the backing store alive properly, even in the case of aliases > > from live heap objects. Thus the embedder has a lower chance of making > > a mistake. Long-term, we should move the embedder to a model where they > > manage backing stores using shared_ptr to an opaque backing store object. > > TBR=yangguo@chromium.org > > BUG=v8:9380,v8:9221,chromium:986318 > > Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005 > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63041} TBR=yangguo@chromium.org,clemensh@chromium.org,mstarzinger@chromium.org Change-Id: Iba55c7ab71e5642b5cb6aeb699d6fc9cf9061486 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771795Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#63461}
-
- 20 Aug, 2019 1 commit
-
-
Leszek Swirski authored
Since the mutability of HeapNumbers is determined by their owning object's descriptor array, we can remove the MutableHeapNumber type entirely, at the cost of a few fewer DCHECKs and a couple of TODOs to use the descriptor array information. This is a necessary step towards a follow-up which allows in-place Double -> Tagged transitions Design doc: https://docs.google.com/document/d/1VeKIskAakxQFnUBNkhBmVswgR7Vk6T1kAyKRLhqerb4/ Bug: v8:9606 Change-Id: I13209f9c86f1f204088f6fd80089e17d956b4a50 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743972 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#63294}
-
- 12 Aug, 2019 1 commit
-
-
Ross McIlroy authored
Create canonical ScopeInfos for the global this binding and empty function in the read only space, rather than creating them during bootstrapping for each native context. This saves some memory, and also means we don't need to access the native context to get the global this binding in when deserializing a scope info, which is important since parsing should be native context independent. BUG=chromium:992063 Change-Id: I800f576e8e9b95d46e043cba0c1a03ae19a683c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748690 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63174}
-
- 05 Aug, 2019 1 commit
-
-
Ulan Degenbaev authored
This reverts commit 5611f70b. Reason for revert: flaky tests: v8:9588, v8:9587 Original change's description: > "Reland x4 [arraybuffer] Rearchitect backing store ownership" > > This is a reland of bc33f5ae > > Contributed by titzer@chromium.org > > Original change's description: > > [arraybuffer] Rearchitect backing store ownership > > > > This CL completely rearchitects the ownership of array buffer backing stores, > > consolidating ownership into a {BackingStore} C++ object that is tracked > > throughout V8 using unique_ptr and shared_ptr where appropriate. > > > > Overall, lifetime management is simpler and more explicit. The numerous > > ways that array buffers were initialized have been streamlined to one > > Attach() method on JSArrayBuffer. The array buffer tracker in the > > GC implementation now manages std::shared_ptr<BackingStore> pointers, > > and the construction and destruction of the BackingStore object itself > > handles the underlying page or embedder-allocated memory. > > > > The embedder API remains unchanged for now. We use the > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to > > keep the backing store alive properly, even in the case of aliases > > from live heap objects. Thus the embedder has a lower chance of making > > a mistake. Long-term, we should move the embedder to a model where they > > manage backing stores using shared_ptr to an opaque backing store object. > > TBR=yangguo@chromium.org > > BUG=v8:9380,v8:9221,chromium:986318 > > Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005 > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63041} TBR=ulan@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,clemensh@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:9380, v8:9221, chromium:986318 Change-Id: Ic7381239f4e90d0c437b7e47a5ac6e8bce60f882 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1736747Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#63081}
-