1. 07 Jul, 2020 1 commit
  2. 01 Jul, 2020 1 commit
  3. 29 Jun, 2020 1 commit
  4. 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
  5. 22 Jun, 2020 1 commit
  6. 25 May, 2020 1 commit
  7. 08 May, 2020 1 commit
  8. 04 May, 2020 1 commit
  9. 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
  10. 29 Apr, 2020 2 commits
  11. 21 Apr, 2020 1 commit
  12. 03 Mar, 2020 1 commit
  13. 13 Jan, 2020 1 commit
  14. 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
  15. 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
  16. 29 Oct, 2019 1 commit
  17. 28 Oct, 2019 1 commit
  18. 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
  19. 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
  20. 15 Oct, 2019 2 commits
  21. 11 Oct, 2019 2 commits
    • Seth Brenith's avatar
      [torque] Generate instance types · 8c7ae314
      Seth Brenith authored
      Design doc:
      https://docs.google.com/document/d/1ZU6rCvF2YHBGMLujWqqaxlPsjFfjKDE9C3-EugfdlAE/edit
      
      Changes from the design doc:
      - Changed to use 'class' declarations rather than 'type' declarations
        for things that need instance types but whose layout is not known to
        Torque. These declarations end with a semicolon rather than having a
        full set of methods and fields surrounded by {}. If the class's name
        should not be treated as a class name in generated output (because
        it's actually a template, or doesn't exist at all), we use the
        standard 'generates' clause to declare the most appropriate C++ class.
      - Removed @instanceTypeName.
      - @highestInstanceType became @highestInstanceTypeWithinParentClassRange
        to indicate a semantic change: it no longer denotes the highest
        instance type globally, but only within the range of values for its
        immediate parent class. This lets us use it for Oddball, which is
        expected to be the highest primitive type.
      - Added new abstract classes JSCustomElementsObject and JSSpecialObject
        to help with some range checks.
      - Added @lowestInstanceTypeWithinParentClassRange so we can move the new
        classes JSCustomElementsObject and JSSpecialObject to the beginning of
        the JSObject range. This seems like the least-brittle way to establish
        ranges that also include JSProxy (and these ranges are verified with
        static assertions in instance-type.h).
      - Renamed @instanceTypeValue to @apiExposedInstanceTypeValue.
      - Renamed @instanceTypeFlags to @reserveBitsInInstanceType.
      
      This change introduces the new annotations and adds the ability for
      Torque to assign instance types that satisfy those annotations. Torque
      now emits two new macros:
      - TORQUE_ASSIGNED_INSTANCE_TYPES, which is used to define the
        InstanceType enumeration
      - TORQUE_ASSIGNED_INSTANCE_TYPE_LIST, which replaces the non-String
        parts of INSTANCE_TYPE_LIST
      
      The design document mentions a couple of other macro lists that could
      easily be replaced, but I'd like to defer those to a subsequent checkin
      because this one is already pretty large.
      
      Bug: v8:7793
      Change-Id: Ie71d93a9d5b610e62be0ffa3bb36180c3357a6e8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1757094
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64258}
      8c7ae314
    • Jakob Kummerow's avatar
      Update DescriptorArray and Map to use InternalIndex · d509ed53
      Jakob Kummerow authored
      This is for consistency and compiler-enforced type safety. No change
      in behavior intended.
      
      Change-Id: I31467832ba6c63fd5f97df9fee6221559b283d67
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852766
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64244}
      d509ed53
  22. 09 Oct, 2019 1 commit
  23. 01 Oct, 2019 1 commit
  24. 10 Sep, 2019 1 commit
  25. 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
  26. 09 Jul, 2019 1 commit
  27. 03 Jul, 2019 1 commit
  28. 26 Jun, 2019 3 commits