1. 28 May, 2020 1 commit
  2. 04 May, 2020 1 commit
  3. 01 May, 2020 1 commit
  4. 28 Feb, 2020 1 commit
    • Seth Brenith's avatar
      Complete Torque definition of JSArrayBuffer · da900ffe
      Seth Brenith authored
      Previously, our Torque definition of JSArrayBuffer included only the
      first two fields. This allowed access to those two fields, but was
      somewhat confusing and obviously didn't let Torque code access the
      other fields. This change:
      
      - Completes the JSArrayBuffer layout definition;
      - Moves the associated bitfield struct definition to Torque;
      - Moves a couple of JSArrayBuffer macros to Torque;
      - Adds a reducer case so that the code generated using these new macros
        is not worse than what was generated previously.
      
      Change-Id: Ib19c3ba789a33801fa9d0d064cd21d62a1e03e30
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2053769
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66503}
      da900ffe
  5. 17 Feb, 2020 2 commits
  6. 13 Jan, 2020 2 commits
  7. 06 Nov, 2019 1 commit
  8. 05 Nov, 2019 1 commit
  9. 04 Nov, 2019 1 commit
  10. 31 Oct, 2019 1 commit
  11. 30 Oct, 2019 1 commit
  12. 22 Oct, 2019 1 commit
  13. 17 Oct, 2019 1 commit
  14. 10 Oct, 2019 1 commit
  15. 01 Oct, 2019 1 commit
  16. 23 Sep, 2019 1 commit
  17. 19 Sep, 2019 2 commits
    • Igor Sheludko's avatar
      Reland "[ptr-compr] Make on-heap JSTypedArrays smi-corrupting friendly" · dc1a93b8
      Igor Sheludko authored
      This is a reland of 6f9b2bd4
      
      We must load JSTypedArray::base_pointer in TurboFan as tagged value otherwise
      this value may become stale pointer after GC.
      
      Original change's description:
      > [ptr-compr] Make on-heap JSTypedArrays smi-corrupting friendly
      >
      > On-heap typed arrays contain HeapObject value in |base_pointer| field
      > and an offset in |external_pointer| field. When pointer compression is
      > enabled we want to combine decompression with the offset addition.
      > In order to do that we add an isolate root to the external_pointer value
      > and therefore the data pointer computation can is a simple addition of
      > a (potentially sign-extended) |base_pointer| loaded as Tagged_t value
      > and an |external_pointer| value.
      >
      > Bug: v8:9706
      > Change-Id: Id5c546c353c81fb25e3598921bc78165d10a9c44
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807369
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63874}
      
      Bug: v8:9706, chromium:1005599
      Cq-Include-Trybots: luci.chromium.try:gpu-fyi-try-win10-nvidia-rel-64
      Change-Id: I7bbd2a439306cdd11f2bb0dab5863498624d9740
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813744Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63898}
      dc1a93b8
    • Clemens Hammacher's avatar
      Revert "[ptr-compr] Make on-heap JSTypedArrays smi-corrupting friendly" · 815df7d2
      Clemens Hammacher authored
      This reverts commit 6f9b2bd4.
      
      Reason for revert: Fails on nvidia bots, blocking LKGR: https://ci.chromium.org/p/v8/builders/ci/Win%20V8%20FYI%20Release%20(NVIDIA)/5005
      
      Original change's description:
      > [ptr-compr] Make on-heap JSTypedArrays smi-corrupting friendly
      > 
      > On-heap typed arrays contain HeapObject value in |base_pointer| field
      > and an offset in |external_pointer| field. When pointer compression is
      > enabled we want to combine decompression with the offset addition.
      > In order to do that we add an isolate root to the external_pointer value
      > and therefore the data pointer computation can is a simple addition of
      > a (potentially sign-extended) |base_pointer| loaded as Tagged_t value
      > and an |external_pointer| value.
      > 
      > Bug: v8:9706
      > Change-Id: Id5c546c353c81fb25e3598921bc78165d10a9c44
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807369
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63874}
      
      TBR=ulan@chromium.org,neis@chromium.org,jgruber@chromium.org,ishell@chromium.org,verwaest@chromium.org
      
      Change-Id: I901280dd191e78d02969600f775c4f0da796921f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9706
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813027Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63886}
      815df7d2
  18. 18 Sep, 2019 1 commit
  19. 16 Sep, 2019 1 commit
  20. 13 Sep, 2019 1 commit
  21. 12 Sep, 2019 2 commits
  22. 04 Sep, 2019 1 commit
  23. 27 Aug, 2019 1 commit
  24. 26 Aug, 2019 1 commit
  25. 23 Aug, 2019 1 commit
  26. 19 Jun, 2019 1 commit
  27. 18 Jun, 2019 1 commit
  28. 12 Jun, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Stricter object field verification, part 1 · 3834c637
      Seth Brenith authored
      This change adjusts object initialization order for a few classes so
      that the GC can never see those objects in an invalid, partially-
      initialized state.
      
      AccessorInfo: Just zeros out a few fields upon construction. This is the
      simplest case.
      
      FunctionTemplateInfo: Slightly changes the order in which fields are
      set, so that the Smi field is set ahead of the call to SetCallHandler,
      which can GC. Also a pretty simple case.
      
      JSListFormat, JSPluralRules, JSRelativeTimeFormat, JSSegmenter: The spec
      requires that we start with OrdinaryCreateFromConstructor, which has
      observable side effects (it fetches the prototype from the new.target).
      So we split JSObject::New in half: the first half does all of the user-
      visible things and returns a Map, which we can pass to the second half
      when we're ready to actually allocate the object.
      
      JSTypedArray: Extends the pattern from JSListFormat into Torque code:
      start with a Map and don't allocate the object until we're ready to set
      all of its properties.
      
      Bug: v8:9311
      Change-Id: Id7703e8a0727ec756c774cfbb56af787658a111a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1646844
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62123}
      3834c637
  29. 27 May, 2019 4 commits
    • Tobias Tebbi's avatar
      [torque] no longer generate assemblers per namespace · 19d8bfa5
      Tobias Tebbi authored
      Instead of generating one CodeStubAssembler-like class per namespace,
      Torque-generated macros are now free-standing functions not included
      from CSA code, and explicitly exported macros become part of the new
      TorqueGeneratedExportedMacrosAssembler, which CodeStubAssembler
      inherits from, thus making them available to all CSA code.
      
      Structs are now defined in a new header csa-types-tq.h as free-standing
      types with the prefix "TorqueStruct".
      
      This is a preparation for generating per Torque-file instead of per
      namespace.
      
      Change-Id: I60fadc493a63f85d1d340768ec6f11ae47be0cb8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628787
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61865}
      19d8bfa5
    • Benedikt Meurer's avatar
      Reland "[typedarray] Move external/data pointer to JSTypedArray." · 70bd7cf0
      Benedikt Meurer authored
      This is a reland of 4b86fea5 with
      copy&paste typo in CodeStubAssembler::AllocateByteArray() fixed
      (bug led to holes in new space, which was crashing reproducibly
      on the ia32 bot).
      
      Original change's description:
      > [typedarray] Move external/data pointer to JSTypedArray.
      >
      > As the next step in supporting huge typed arrays in V8, this moves the
      > external/data pointer from the FixedTypedArrayBase backing store to the
      > JSTypedArray instance itself, and replaces the special backing stores
      > with a plain ByteArray (removing all the code for the FixedTypedArrayBase
      > class hierarchy). By doing so, we can drastically simplify the system
      > around typed arrays.
      >
      > Note: Several places in the code base used to check the instance type
      > of the elements backing store of a JSTypedArray instead of checking the
      > elements kind on the JSTypedArray map directly. Those had to be fixed,
      > since the backing store is now always a ByteArray.
      >
      > Drive-by-fix: Move all the typed elements access related code into the
      > elements.cc file to properly encapsulate the accesses.
      >
      > Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
      > Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      > Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
      > Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61855}
      
      Tbr: petermarshall@chromium.org
      Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      Change-Id: I87fcdb28532c5f08cc227332a4d59546cb423810
      Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel
      Cq-Include-Trybots: luci.v8.try:v8_linux_shared_compile_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631592Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61864}
      70bd7cf0
    • Clemens Hammacher's avatar
      Revert "[typedarray] Move external/data pointer to JSTypedArray." · e4db146a
      Clemens Hammacher authored
      This reverts commit 4b86fea5.
      
      Reason for revert: Fails on linux shared: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/31045
      
      Original change's description:
      > [typedarray] Move external/data pointer to JSTypedArray.
      > 
      > As the next step in supporting huge typed arrays in V8, this moves the
      > external/data pointer from the FixedTypedArrayBase backing store to the
      > JSTypedArray instance itself, and replaces the special backing stores
      > with a plain ByteArray (removing all the code for the FixedTypedArrayBase
      > class hierarchy). By doing so, we can drastically simplify the system
      > around typed arrays.
      > 
      > Note: Several places in the code base used to check the instance type
      > of the elements backing store of a JSTypedArray instead of checking the
      > elements kind on the JSTypedArray map directly. Those had to be fixed,
      > since the backing store is now always a ByteArray.
      > 
      > Drive-by-fix: Move all the typed elements access related code into the
      > elements.cc file to properly encapsulate the accesses.
      > 
      > Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
      > Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      > Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
      > Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61855}
      
      TBR=ulan@chromium.org,yangguo@chromium.org,titzer@chromium.org,sigurds@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org,szuend@chromium.org
      
      Change-Id: I0bc1f935de6063acf75a0f4bb8c0ba67428603fd
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631427Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61856}
      e4db146a
    • Benedikt Meurer's avatar
      [typedarray] Move external/data pointer to JSTypedArray. · 4b86fea5
      Benedikt Meurer authored
      As the next step in supporting huge typed arrays in V8, this moves the
      external/data pointer from the FixedTypedArrayBase backing store to the
      JSTypedArray instance itself, and replaces the special backing stores
      with a plain ByteArray (removing all the code for the FixedTypedArrayBase
      class hierarchy). By doing so, we can drastically simplify the system
      around typed arrays.
      
      Note: Several places in the code base used to check the instance type
      of the elements backing store of a JSTypedArray instead of checking the
      elements kind on the JSTypedArray map directly. Those had to be fixed,
      since the backing store is now always a ByteArray.
      
      Drive-by-fix: Move all the typed elements access related code into the
      elements.cc file to properly encapsulate the accesses.
      
      Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
      Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
      Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
      Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61855}
      4b86fea5
  30. 23 May, 2019 1 commit
  31. 15 May, 2019 1 commit
    • Tobias Tebbi's avatar
      Reland: [csa] verify skipped write-barriers in MemoryOptimizer · a19c3ffb
      Tobias Tebbi authored
      With very few exceptions, this verifies all skipped write-barriers in
      CSA and Torque, showing that the MemoryOptimizer together with some
      type information on the stored value are enough to avoid unsafe skipped
      write-barriers.
      
      Changes to CSA:
      SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
      MemoryOptimizer by default.
      Type information about the stored values (TNode<Smi>) is exploited to
      safely skip write barriers for stored Smi values.
      In some cases, the code is re-structured to make it easier to consume
      for the MemoryOptimizer (manual branch and load elimination).
      
      Changes to the MemoryOptimizer:
      Improve the MemoryOptimizer to remove write barriers:
      - When the store happens to a CSA-generated InnerAllocate, by ignoring
        Bitcasts and additions.
      - When the stored value is the HeapConstant of an immortal immovable root.
      - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
      - Fast C-calls are treated as non-allocating.
      - Runtime calls can be white-listed as non-allocating.
      
      Remaining missing cases:
      - C++-style iterator loops with inner pointers.
      - Inner allocates that are reloaded from a field where they were just stored
        (for example an elements backing store). Load elimination would fix that.
      - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
        We could handle that in Torque.
      - Double-aligned allocations, which are not lowered in the MemoryOptimizer
        but in CSA.
      
      Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
      can be handled by overload resolution (in Torque and C++).
      
      Reland Change: Support pointer compression operands.
      
      R=jarin@chromium.org
      TBR=mvstanton@chromium.org
      
      Bug: v8:7793
      Change-Id: I84e1831eb6bf9be14f36db3f8b485ee4fab6b22e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1612904
      Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61522}
      a19c3ffb
  32. 14 May, 2019 2 commits