1. 29 Jun, 2020 1 commit
  2. 26 Jun, 2020 2 commits
    • Shu-yu Guo's avatar
      Revert "[wasm-gc] Implement rtt.sub" · 30456566
      Shu-yu Guo authored
      This reverts commit 04ce88ea.
      
      Reason for revert: TSAN failure: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/32135
      
      Original change's description:
      > [wasm-gc] Implement rtt.sub
      > 
      > RTTs are internally represented as Maps. To store supertype information,
      > this patch introduces a WasmTypeInfo object, which is installed on Wasm
      > objects' Maps and points at both the off-heap type information and the
      > parent RTT.
      > In this patch, rtt.sub always creates a fresh RTT. The canonicalization
      > that the proposal requires will be implemented later.
      > 
      > Bug: v8:7748
      > Change-Id: I8286dd11f520966155cd95c2bd844ec34fccd131
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2260566
      > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#68564}
      
      TBR=ulan@chromium.org,jkummerow@chromium.org,tebbi@chromium.org
      
      Change-Id: I311732e1ced4de7a58b87d4a9b6056e0d62aa986
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7748
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2270734Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68567}
      30456566
    • Jakob Kummerow's avatar
      [wasm-gc] Implement rtt.sub · 04ce88ea
      Jakob Kummerow authored
      RTTs are internally represented as Maps. To store supertype information,
      this patch introduces a WasmTypeInfo object, which is installed on Wasm
      objects' Maps and points at both the off-heap type information and the
      parent RTT.
      In this patch, rtt.sub always creates a fresh RTT. The canonicalization
      that the proposal requires will be implemented later.
      
      Bug: v8:7748
      Change-Id: I8286dd11f520966155cd95c2bd844ec34fccd131
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2260566
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68564}
      04ce88ea
  3. 22 Jun, 2020 1 commit
  4. 10 Jun, 2020 1 commit
  5. 11 May, 2020 1 commit
  6. 08 May, 2020 1 commit
  7. 04 May, 2020 2 commits
    • Tobias Tebbi's avatar
      [torque] improve GC visitors · f1400e43
      Tobias Tebbi authored
      Summary of changes:
      
      - GC visitors no longer rely on superclass visitors, but instead visit
        everything themselves. This enables generating better code.
      - Try to match simple body descriptors to reduce the amount of generated
        code.
      - Turn SizeFor(instance) into an AllocatedSize() method.
      - Remove the special handling of resizable object sizes from Torque
        and instead overwrite AllocatedSize in classes that need special
        handling in C++.
      - Split the visitor id lists depending on whether the class has pointer
        fields.
      - Turn Torque-generated body descriptors into an .inc file to
        simplify includes.
      - Fix generated size functions to properly align the size.
      - Generate GC visitors (and C++ class definitions) for all string
        classes and FixedArray, WeakFixedArray, and WeakArrayList.
      - Store generated instance types in Torque class types. This is only
        used to determine if a type has a single instance type in this CL.
      
      Bug: v8:7793
      Change-Id: I4d362e96b047c305bd6d065247734957b8958c42
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110014
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67542}
      f1400e43
    • Toon Verwaest's avatar
      [runtime] Don't track transitions for certainly detached maps · 548f6c81
      Toon Verwaest authored
      Previously such maps were marked as prototype, but that has bad
      performance / memory characteristics if objects are used as
      dictionaries.
      
      Bug: b:148346655, v8:10339
      Change-Id: I287c5664c8b7799a084669aaaffe3affcf73e95f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2179322Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67537}
      548f6c81
  8. 30 Apr, 2020 6 commits
    • Deepti Gandluri's avatar
      Revert "Reland^4 "[runtime] Amortize descriptor array growing for fast-mode prototypes"" · accf95fc
      Deepti Gandluri authored
      This reverts commit fd2548f3.
      
      Reason for revert: Breaks telemetry benchmark, blocks deps roll.
      https://ci.chromium.org/p/chromium/builders/try/linux-rel/373686?
      https://chromium-swarm.appspot.com/task?id=4be57eb0279bbb10
      
      Original change's description:
      > Reland^4 "[runtime] Amortize descriptor array growing for fast-mode prototypes"
      > 
      > This CL:
      >  - stops tracking transitions for fast maps that are known to be detached
      >  - reuses descriptor arrays when transitioning detached maps to avoid O(n^2) performance and garbage creation
      > 
      > Fix2 in reland: constructor_or_backpointer can be a smi since it can also hold a user-provided function.prototype
      > Fix in reland: check whether the map of the back pointer is the metamap rather than reading the map of the constructor-or-backpointer slot. If the slot contains a constructor, it's possible that the object transitions while the concurrent marker is reading the map (from which it's reading the instance type); and it's possible that the transitioned map isn't set up yet fully when we read the instance type. An acquire load for the constructor-or-backpointer map would also fix it by serializing stores, but is more expensive. Checking the metamap is faster.
      > 
      > Original commit message:
      > > This avoids an O(n^2) algorithm that creates an equal amount of garbage.
      > > Even though the actual final descriptor array might be a little bigger,
      > > it reduces peak memory usage by allocating less.
      > 
      > Change-Id: Id99dc76a369057e5c4d76a31163605cb38a66867
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172080
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67501}
      
      TBR=ulan@chromium.org,verwaest@chromium.org
      
      Change-Id: If305b5410ca37e04e9ec0ce50e9b494f5c4cd4dc
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2174767Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67510}
      accf95fc
    • Toon Verwaest's avatar
      Reland^4 "[runtime] Amortize descriptor array growing for fast-mode prototypes" · fd2548f3
      Toon Verwaest authored
      This CL:
       - stops tracking transitions for fast maps that are known to be detached
       - reuses descriptor arrays when transitioning detached maps to avoid O(n^2) performance and garbage creation
      
      Fix2 in reland: constructor_or_backpointer can be a smi since it can also hold a user-provided function.prototype
      Fix in reland: check whether the map of the back pointer is the metamap rather than reading the map of the constructor-or-backpointer slot. If the slot contains a constructor, it's possible that the object transitions while the concurrent marker is reading the map (from which it's reading the instance type); and it's possible that the transitioned map isn't set up yet fully when we read the instance type. An acquire load for the constructor-or-backpointer map would also fix it by serializing stores, but is more expensive. Checking the metamap is faster.
      
      Original commit message:
      > This avoids an O(n^2) algorithm that creates an equal amount of garbage.
      > Even though the actual final descriptor array might be a little bigger,
      > it reduces peak memory usage by allocating less.
      
      Change-Id: Id99dc76a369057e5c4d76a31163605cb38a66867
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172080Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67501}
      fd2548f3
    • Toon Verwaest's avatar
      Revert "Reland^3 "[runtime] Amortize descriptor array growing for fast-mode prototypes"" · 4911ab95
      Toon Verwaest authored
      This reverts commit 65630850.
      
      Reason for revert: due to failures
      
      Original change's description:
      > Reland^3 "[runtime] Amortize descriptor array growing for fast-mode prototypes"
      > 
      > This CL:
      >  - stops tracking transitions for fast maps that are known to be detached
      >  - reuses descriptor arrays when transitioning detached maps to avoid O(n^2) performance and garbage creation
      > 
      > Fix in reland: check whether the map of the back pointer is the metamap rather than reading the map of the constructor-or-backpointer slot. If the slot contains a constructor, it's possible that the object transitions while the concurrent marker is reading the map (from which it's reading the instance type); and it's possible that the transitioned map isn't set up yet fully when we read the instance type. An acquire load for the constructor-or-backpointer map would also fix it by serializing stores, but is more expensive. Checking the metamap is faster.
      > 
      > Original commit message:
      > > This avoids an O(n^2) algorithm that creates an equal amount of garbage.
      > > Even though the actual final descriptor array might be a little bigger,
      > > it reduces peak memory usage by allocating less.
      > 
      > TBR=ulan@chromium.org,ishell@chromium.org
      > 
      > Change-Id: I57000949debdee2b69dd41e0c5975b3e8a34c6f4
      > No-Presubmit: true
      > No-Tree-Checks: true
      > No-Try: true
      > Bug: b:148346655, v8:10339
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2173363
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67499}
      
      TBR=ulan@chromium.org,clemensb@chromium.org,ishell@chromium.org,verwaest@chromium.org
      
      Change-Id: Ie7018912f591d397c8acede9b31fbf269d225fe4
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: b:148346655, v8:10339
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2174299Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67500}
      4911ab95
    • Toon Verwaest's avatar
      Reland^3 "[runtime] Amortize descriptor array growing for fast-mode prototypes" · 65630850
      Toon Verwaest authored
      This CL:
       - stops tracking transitions for fast maps that are known to be detached
       - reuses descriptor arrays when transitioning detached maps to avoid O(n^2) performance and garbage creation
      
      Fix in reland: check whether the map of the back pointer is the metamap rather than reading the map of the constructor-or-backpointer slot. If the slot contains a constructor, it's possible that the object transitions while the concurrent marker is reading the map (from which it's reading the instance type); and it's possible that the transitioned map isn't set up yet fully when we read the instance type. An acquire load for the constructor-or-backpointer map would also fix it by serializing stores, but is more expensive. Checking the metamap is faster.
      
      Original commit message:
      > This avoids an O(n^2) algorithm that creates an equal amount of garbage.
      > Even though the actual final descriptor array might be a little bigger,
      > it reduces peak memory usage by allocating less.
      
      TBR=ulan@chromium.org,ishell@chromium.org
      
      Change-Id: I57000949debdee2b69dd41e0c5975b3e8a34c6f4
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: b:148346655, v8:10339
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2173363
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67499}
      65630850
    • Toon Verwaest's avatar
      Revert "Reland^2 "[runtime] Amortize descriptor array growing for fast-mode prototypes"" · 3afa7cf0
      Toon Verwaest authored
      This reverts commit d29b2f81.
      
      Reason for revert: accidental reland without fix
      
      Original change's description:
      > Reland^2 "[runtime] Amortize descriptor array growing for fast-mode prototypes"
      > 
      > Fix: check whether the map of the back pointer is the metamap rather than reading the map of the constructor-or-backpointer slot. If the slot contains a constructor, it's possible that the object transitions while the concurrent marker is reading the map (from which it's reading the instance type); and it's possible that the transitioned map isn't set up yet fully when we read the instance type. An acquire load for the constructor-or-backpointer map would also fix it by serializing stores, but is more expensive. Checking the metamap is faster.
      > 
      > In case of false negatives (it is a map but we read the field before it was properly initialized) we'll simply mark too many descriptors in the worst case.
      > 
      > Original change's description:
      > > Revert "Reland "[runtime] Amortize descriptor array growing for fast-mode prototypes""
      > > 
      > > This reverts commit 71f9c117.
      > > 
      > > Reason for revert: Seems to cause several TSan flakes, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20concurrent%20marking/12926
      > > 
      > > Original change's description:
      > > > Reland "[runtime] Amortize descriptor array growing for fast-mode prototypes"
      > > > 
      > > > This is a reland of 2de2d3dc
      > > > 
      > > > Original change's description:
      > > > > [runtime] Amortize descriptor array growing for fast-mode prototypes
      > > > >
      > > > > This avoids an O(n^2) algorithm that creates an equal amount of garbage.
      > > > > Even though the actual final descriptor array might be a little bigger,
      > > > > it reduces peak memory usage by allocating less.
      > > > >
      > > > > Bug: b:148346655
      > > > > Change-Id: I984159d36e9e0b37c19bc81afc90c94c9a9d168a
      > > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135728
      > > > > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > > > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > > > Cr-Commit-Position: refs/heads/master@{#67031}
      > > > 
      > > > Bug: b:148346655, v8:10339
      > > > Change-Id: I24436d8f49dc1fe527c4f6558db1abcba323b6f8
      > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139215
      > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > > Auto-Submit: Toon Verwaest <verwaest@chromium.org>
      > > > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > > > Cr-Commit-Position: refs/heads/master@{#67475}
      > > 
      > > TBR=ulan@chromium.org,ishell@chromium.org,verwaest@chromium.org
      > > 
      > > Change-Id: I6fa02d0c89557eae33b792c1fe62c9c15eb0f7c7
      > > No-Presubmit: true
      > > No-Tree-Checks: true
      > > No-Try: true
      > > Bug: b:148346655, v8:10339
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172749
      > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#67478}
      > 
      > TBR=ulan@chromium.org,clemensb@chromium.org,ishell@chromium.org,verwaest@chromium.org
      > 
      > Change-Id: Ib86e039374e721919cd5b02495c252ee7af283bd
      > No-Presubmit: true
      > No-Tree-Checks: true
      > No-Try: true
      > Bug: b:148346655, v8:10339
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2173359
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67495}
      
      TBR=ulan@chromium.org,clemensb@chromium.org,ishell@chromium.org,verwaest@chromium.org
      
      Change-Id: Ia624ac774c021146b9b3b7e60372113c50a1ec61
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: b:148346655, v8:10339
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2173361Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67497}
      3afa7cf0
    • Toon Verwaest's avatar
      Reland^2 "[runtime] Amortize descriptor array growing for fast-mode prototypes" · d29b2f81
      Toon Verwaest authored
      Fix: check whether the map of the back pointer is the metamap rather than reading the map of the constructor-or-backpointer slot. If the slot contains a constructor, it's possible that the object transitions while the concurrent marker is reading the map (from which it's reading the instance type); and it's possible that the transitioned map isn't set up yet fully when we read the instance type. An acquire load for the constructor-or-backpointer map would also fix it by serializing stores, but is more expensive. Checking the metamap is faster.
      
      In case of false negatives (it is a map but we read the field before it was properly initialized) we'll simply mark too many descriptors in the worst case.
      
      Original change's description:
      > Revert "Reland "[runtime] Amortize descriptor array growing for fast-mode prototypes""
      > 
      > This reverts commit 71f9c117.
      > 
      > Reason for revert: Seems to cause several TSan flakes, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20concurrent%20marking/12926
      > 
      > Original change's description:
      > > Reland "[runtime] Amortize descriptor array growing for fast-mode prototypes"
      > > 
      > > This is a reland of 2de2d3dc
      > > 
      > > Original change's description:
      > > > [runtime] Amortize descriptor array growing for fast-mode prototypes
      > > >
      > > > This avoids an O(n^2) algorithm that creates an equal amount of garbage.
      > > > Even though the actual final descriptor array might be a little bigger,
      > > > it reduces peak memory usage by allocating less.
      > > >
      > > > Bug: b:148346655
      > > > Change-Id: I984159d36e9e0b37c19bc81afc90c94c9a9d168a
      > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135728
      > > > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > > Cr-Commit-Position: refs/heads/master@{#67031}
      > > 
      > > Bug: b:148346655, v8:10339
      > > Change-Id: I24436d8f49dc1fe527c4f6558db1abcba323b6f8
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139215
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > Auto-Submit: Toon Verwaest <verwaest@chromium.org>
      > > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#67475}
      > 
      > TBR=ulan@chromium.org,ishell@chromium.org,verwaest@chromium.org
      > 
      > Change-Id: I6fa02d0c89557eae33b792c1fe62c9c15eb0f7c7
      > No-Presubmit: true
      > No-Tree-Checks: true
      > No-Try: true
      > Bug: b:148346655, v8:10339
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172749
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67478}
      
      TBR=ulan@chromium.org,clemensb@chromium.org,ishell@chromium.org,verwaest@chromium.org
      
      Change-Id: Ib86e039374e721919cd5b02495c252ee7af283bd
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: b:148346655, v8:10339
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2173359Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67495}
      d29b2f81
  9. 29 Apr, 2020 2 commits
  10. 21 Apr, 2020 1 commit
  11. 09 Mar, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] Generate GC object visitors for Torque classes · 4f4d73f2
      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: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66621}
      4f4d73f2
  12. 18 Feb, 2020 1 commit
    • Seth Brenith's avatar
      Assign CoverageInfo an instance type · 6ce65b96
      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: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#66318}
      6ce65b96
  13. 12 Feb, 2020 1 commit
  14. 06 Feb, 2020 1 commit
  15. 28 Jan, 2020 1 commit
  16. 13 Jan, 2020 1 commit
  17. 10 Jan, 2020 1 commit
    • Seth Brenith's avatar
      [torque] move more bitfield definitions to Torque · 87c16da5
      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: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#65701}
      87c16da5
  18. 27 Nov, 2019 1 commit
    • Leszek Swirski's avatar
      [isolate] Make field getters use a const Isolate* · 42a56e03
      Leszek Swirski authored
      To indicate that the Isolate* in getters might not be a "real" isolate,
      but rather a calculated one from GetIsolateForPtrCompr only used for
      calculating the isolate root, make that function return a const Isolate*
      and change field getters, Object::IsFoo predicates, and related
      functions to all take a const Isolate* instead of an Isolate*
      
      With this change, we can slightly more confidently use Objects that are
      in OffThreadSpace, without having to worry too much about having an
      Isolate* floating around that could accidentally be used.
      
      This is a slight abuse of const semantics, but it allows implicit
      conversion from Isolate* arguments to the const Isolate* parameter.
      
      Bug: v8:7703
      Bug: chromium:1011762
      Change-Id: I54d4a65d2299477195f4d754cabe64ce34fdaa4c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1939455
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65199}
      42a56e03
  19. 15 Nov, 2019 1 commit
  20. 30 Oct, 2019 1 commit
  21. 17 Oct, 2019 1 commit
    • Toon Verwaest's avatar
      Reland^2 "[runtime] Move Context::native_context to the map" · 3cad6bf5
      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: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64360}
      3cad6bf5
  22. 16 Oct, 2019 2 commits
    • Sathya Gunasekaran's avatar
      Revert "Reland "[runtime] Move Context::native_context to the map"" · 38301e7b
      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: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64316}
      38301e7b
    • Toon Verwaest's avatar
      Reland "[runtime] Move Context::native_context to the map" · c7c47c68
      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: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarGeorg 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}
      c7c47c68
  23. 15 Oct, 2019 2 commits
  24. 11 Oct, 2019 1 commit
  25. 30 Sep, 2019 1 commit
  26. 28 Aug, 2019 1 commit
    • Z Nguyen-Huu's avatar
      Add new nonextensible element kinds · 1f4bec27
      Z Nguyen-Huu authored
      Currently the backing store and elements kind might not aligned aka
      backing store can be dictionary where elements kind is frozen/sealed
      element kinds or the other way around. The reason is that
      Object.preventExtensions change elements kind to DICTIONARY while
      Object.seal/freeze change elements kind to SEALED/FROZEN element kind.
      Apply both these operations can lead to that problem as in
      chromium:992914
      
      To solve this issue, we avoid Object.preventExtensions to change backing
      store to dictionary by introducing new nonextensible elements kind.
      These new nonextensible elements kind are handled similar to frozen,
      sealed element kinds. This change not only fixes the problem but also
      optimize the performance of nonextensible objects.
      
      Change-Id: Iffc7f14eb48223c11abf3c577f305d2d072eb65b
      Bug: chromium:992914, v8:6831
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760976
      Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63432}
      1f4bec27
  27. 09 Jul, 2019 1 commit
  28. 03 Jul, 2019 1 commit
  29. 02 Jul, 2019 1 commit
    • Andreas Haas's avatar
      [wasm] Introduce WasmIndirectFunctionTable · 2fe2a08b
      Andreas Haas authored
      This is the first of three CLs which refactors indirect function calls
      through tables with index > 0 to work without runtime calls.
      
      The first CL introduces the WasmIndirectFunctionTable heap object. For
      a table of type anyfunc within a WebAssembly instance,
      WasmIndirectFunctionTable stores the size, the signature id's, the
      call targets, and the reference parameters for that table. I used the
      names that are already used for the matching fields of the
      WasmInstanceObject.
      
      The second CL expands the IndirectFunctionTableEntry to work also on
      WasmIndirectFunctionTable objects. All changes to a function table go
      through this class.
      
      The third CL introduces uses of the WasmIndirectFunctionTable. In this
      CL I change the code generation in TurboFan to replace runime calls with
      direct accesses to the new WasmIndirectFunctionTable. Additionally I
      extended the initialization of WasmIndirectFunctionTable, and also
      implement Table.grow.
      
      R=jkummerow@chromium.org
      
      Bug: v8:7581
      Change-Id: I0ecfcb9565e992ddba087d46c1f0e952abfa5822
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1681134Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62492}
      2fe2a08b
  30. 27 Jun, 2019 1 commit