1. 05 Oct, 2020 24 commits
  2. 04 Oct, 2020 3 commits
  3. 03 Oct, 2020 2 commits
  4. 02 Oct, 2020 11 commits
    • Milad Fa's avatar
      s390: [wasm-simd] Saturate swizzle indices to 5 bits · dd79031d
      Milad Fa authored
      `vperm` indices are taken from the five least significant bits
      of the input byte. We need to make sure bigger values
      are saturated to 31 to make vperm select 0 as the output.
      
      Change-Id: I74715e909e4a50dec23f5423e53254836fe0ff8e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2446553Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
      Commit-Queue: Milad Fa <mfarazma@redhat.com>
      Cr-Commit-Position: refs/heads/master@{#70292}
      dd79031d
    • Thibaud Michaud's avatar
      [wasm][fuzzer] Add missing signature check in interpreter runner · 1ff33c41
      Thibaud Michaud authored
      R=zhin@chromium.org
      
      Bug: chromium:1134324
      Change-Id: Ica1f8c290ba496c7c24d8ec46f963f389ad9e8fa
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445875Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70291}
      1ff33c41
    • Dan Elphick's avatar
      [heap] Re-allow RO_SPACE sharing with pointer compression · c104c4b4
      Dan Elphick authored
      Remove a spurious assert probably introduced by a bad merge that
      disallowed RO_SPACE sharing when pointer compression is enabled.
      
      Change-Id: I8a59a242667252dcbb098e5be405ac67a4e01a3d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445877
      Auto-Submit: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70290}
      c104c4b4
    • Dan Elphick's avatar
      [builtins] Remove UntypedParameter from TF_BUILTIN · 924b52f4
      Dan Elphick authored
      The TF_BUILTIN version of UntypedParameter is not used anywhere. There's
      still CodeAssembler::UntypedParameter which is still in use if a untyped
      parameter is required.
      
      Change-Id: I3580e73b781d750878d7bb1b38298d5b82d15f4c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445876
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Auto-Submit: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70289}
      924b52f4
    • Leszek Swirski's avatar
      Reland^3 "[serializer] Allocate during deserialization" · 3f4e9bbe
      Leszek Swirski authored
      This is a reland of c4a062a9
      which was a reland of 28a30c57
      which was a reland of 5d7a29c9
      
      Fixes TSAN errors from non-atomic writes in the deserializer. Now all
      writes are (relaxed) atomic.
      
      Original change's description:
      > Reland^2 "[serializer] Allocate during deserialization"
      >
      > This is a reland of 28a30c57
      > which was a reland of 5d7a29c9
      >
      > The crashes were from calling RegisterDeserializerFinished on a null
      > Isolate pointer, for a deserializer that was never initialised
      > (specifically, ReadOnlyDeserializer when ROHeap is shared).
      >
      > Original change's description:
      > > Reland "[serializer] Allocate during deserialization"
      > >
      > > This is a reland of 5d7a29c9
      > >
      > > This reland shuffles around the order of checks in Heap::AllocateRawWith
      > > to not check the new space addresses until it's known that this is a new
      > > space allocation. This fixes an UBSan failure during read-only space
      > > deserialization, which happens before the new space is initialized.
      > >
      > > It also fixes some issues discovered by --stress-snapshot, around
      > > serializing ThinStrings (which are now elided as part of serialization),
      > > handle counts (I bumped the maximum handle count in that check), and
      > > clearing map transitions (the map backpointer field needed a Smi
      > > uninitialized value check).
      > >
      > > Original change's description:
      > > > [serializer] Allocate during deserialization
      > > >
      > > > This patch removes the concept of reservations and a specialized
      > > > deserializer allocator, and instead makes the deserializer allocate
      > > > directly with the Heap's Allocate method.
      > > >
      > > > The major consequence of this is that the GC can now run during
      > > > deserialization, which means that:
      > > >
      > > >   a) Deserialized objects are visible to the GC, and
      > > >   b) Objects that the deserializer/deserialized objects point to can
      > > >      move.
      > > >
      > > > Point a) is mostly not a problem due to previous work in making
      > > > deserialized objects "GC valid", i.e. making sure that they have a valid
      > > > size before any subsequent allocation/safepoint. We now additionally
      > > > have to initialize the allocated space with a valid tagged value -- this
      > > > is a magic Smi value to keep "uninitialized" checks simple.
      > > >
      > > > Point b) is solved by Handlifying the deserializer. This involves
      > > > changing any vectors of objects into vectors of Handles, and any object
      > > > keyed map into an IdentityMap (we can't use Handles as keys because
      > > > the object's address is no longer a stable hash).
      > > >
      > > > Back-references can no longer be direct chunk offsets, so instead the
      > > > deserializer stores a Handle to each deserialized object, and the
      > > > backreference is an index into this handle array. This encoding could
      > > > be optimized in the future with e.g. a second pass over the serialized
      > > > array which emits a different bytecode for objects that are and aren't
      > > > back-referenced.
      > > >
      > > > Additionally, the slot-walk over objects to initialize them can no
      > > > longer use absolute slot offsets, as again an object may move and its
      > > > slot address would become invalid. Now, slots are walked as relative
      > > > offsets to a Handle to the object, or as absolute slots for the case of
      > > > root pointers. A concept of "slot accessor" is introduced to share the
      > > > code between these two modes, and writing the slot (including write
      > > > barriers) is abstracted into this accessor.
      > > >
      > > > Finally, the Code body walk is modified to deserialize all objects
      > > > referred to by RelocInfos before doing the RelocInfo walk itself. This
      > > > is because RelocInfoIterator uses raw pointers, so we cannot allocate
      > > > during a RelocInfo walk.
      > > >
      > > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
      > > > size rather than byte size -- the size is expected to be tagged-aligned
      > > > anyway, so now we get an extra few bits in the size encoding.
      > > >
      > > > Bug: chromium:1075999
      > > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
      > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
      > > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > > Cr-Commit-Position: refs/heads/master@{#70229}
      > >
      > > Bug: chromium:1075999
      > > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#70267}
      >
      > Tbr: jgruber@chromium.org,ulan@chromium.org
      > Bug: chromium:1075999
      > Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70279}
      
      Tbr: jgruber@chromium.org,ulan@chromium.org
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng,v8_linux64_tsan_no_cm_rel_ng,v8_linux64_tsan_isolates_rel_ng
      Bug: chromium:1075999
      Change-Id: I0b9b11644aebc4cc8b07c62a0f765b24e4d73d89
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445872
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70288}
      3f4e9bbe
    • Omer Katz's avatar
      cppgc: Various marking data races · 69d507ca
      Omer Katz authored
      This resolves several races identified by concurrent marking tests.
      These include:
      (*) Several instances of not using atomic accesses.
      (*) Synchronizing page on page creation.
      
      Bug: chromium:1056170
      Change-Id: I4a32a44b93a6995a11e3cc75c9446fb8860ae780
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423717
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70287}
      69d507ca
    • Toon Verwaest's avatar
      [char-predicates] Use OneByte flag table and add line terminator support · dae25c02
      Toon Verwaest authored
      Using a OneByte table allows branches to be removed if the function is inlined
      in a place where we statically know the character is onebyte.
      
      This adds support for line terminators. To support 2byte line terminators as
      well this adds a entries for the lower byte into the table so we can often take
      a faster path in that case as well.
      
      Change-Id: Ibd08d540e0e13047d6c1f675c187f14fda4336c5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445471Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70286}
      dae25c02
    • Jakob Kummerow's avatar
      [cleanup] Drop Runtime_IsValidSmi · 896627db
      Jakob Kummerow authored
      It only had one callsite, and that callsite was useless:
      %IsValidSmi(two_31) has never returned {true} on any
      configuration we have ever shipped.
      
      Bug: v8:10933
      Change-Id: I09cdfd7bbd7960d1ec460ad4bd9f0d21e47f7393
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2434746
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70285}
      896627db
    • Milad Fa's avatar
      [BUILD] Disable warning for using enum constant in boolean context · f3861a87
      Milad Fa authored
      Change-Id: I5e976ba8cbecaff04a0975a3de00627cabb00f3f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442432Reviewed-by: 's avatarMilad Fa <mfarazma@redhat.com>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Milad Fa <mfarazma@redhat.com>
      Cr-Commit-Position: refs/heads/master@{#70284}
      f3861a87
    • Omer Katz's avatar
      cppgc: Clear object memory on sweep · 8b1a3a73
      Omer Katz authored
      We clear during sweep so that we are guaranteed the in-construction bit
      of newly allocated objects is always 0. The lock sweeping uses for
      synchronization assures no data races between clearing and concurrent
      marking.
      
      The only exception to that is debug builds that zap on sweep and clear
      on allocation. This makes it so that dangling references will most
      likely crash in debug builds.
      
      Bug: chromium:1056170
      Change-Id: I12597ef76629ec50c6bfc39dc21b68243c4160ae
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2438530
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70283}
      8b1a3a73
    • Omer Katz's avatar
      cppgc: Mark in construction objects externally · cebd8b65
      Omer Katz authored
      In construction objects don't have anything to sync with on the
      allocation side since they weren't marked as fully constructed yet.
      This could mean the initialization of the marking bit on the mutator
      thread and setting the mark bit on a concurrent thread could race
      (potentially resulting in losing the mark bit when the gc info index
      overwrites it).
      
      This CL fixes this issue by using a set of in construction objects.
      In construction objects are no longer marked. Instead they are pushed
      to the set and the heap object header is marked when they are popped
      from the worklist. Since the set avoids duplicates, this allows us to
      both avoid worklist explosion (due to pushing the same in construction
       object multiple times) and avoid the data race on the mark bit.
      
      This CL uses an unordered_set to record objects. Synchronization uses
      a lock, which could be costly but is not expected to be obtained often.
      
      Bug: chromium:1056170
      Change-Id: I366b59f476c166ff06e15b280df9e846034cc6cf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2437388
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70282}
      cebd8b65