Skip to content

V
V8
Switch branch/tag
  1. 07 Oct, 2020 2 commits
    • Jakob Gruber's avatar
      [nci] Also spawn NCI tasks for OSR requests · ec76fb0f
      Jakob Gruber authored 
      In addition to normal optimization requests, it also makes sense to
consider OSR requests. In that case, the function is definitely hot,
and since we've seen it OSR (i.e. we spend a long time inside a loop
in the interpreted function), immediately jumping into NCI code in
future contexts would be great.

Future work: support OSR from NCI to TF.

Bug: v8:8888
Change-Id: Iaa4c60bc0c2e1bf3dc067053bb7b50e9af51c0d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448462
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70364}
      ec76fb0f
    • Michael Achenbach's avatar
      [test] Overhaul mode processing in test runner · 608b732d
      Michael Achenbach authored 
      This simplifies mode processing as follows:
- Passing the --mode parameter is deprecated.
- The build output is now only searched in the --outdir parameter
that was passed (previously some combinations of mode and outdir
were possible).
- The mode is deduced from the build artifacts based on the gn
arguments "is_debug" and "dcheck_always_on".
- Timeouts and status file entries in release mode with dchecks are
treated like in debug mode.

This change was prepared on the infrastructure side by deprecating
the --mode flag and passing --outdir=out/build:
https://crrev.com/c/2426643

Bug: chromium:1132088, v8:10893
Change-Id: I0f34ebc003b220f07df4ecdbf69ea6c06ac1f66a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2450016Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70363}
      608b732d
  3. 06 Oct, 2020 34 commits
  5. 05 Oct, 2020 4 commits
    • Adam Klein's avatar
      Revert "Reland^3 "[serializer] Allocate during deserialization"" · a10ec2be
      Adam Klein authored 
      This reverts commit 3f4e9bbe, along
with the following dependent changes (reverted to make this a clean revert):
76ad3ab5 [identity-map] Change resize heuristic
77cc96aa [identity-map] Cache the calculated Hash
bee5b996 [serializer] Remove Deserializer::Initialize
c8f73f22 [serializer] Cache instance type in PostProcessNewObject
4e7c99ab [identity-map] Remove double-lookups in IdentityMap

Reason for revert: major crash spike on Canary (https://crbug.com/1135027)

Original change's description:
> Reland^3 "[serializer] Allocate during deserialization"
>
> 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: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70288}

TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org,dinfuehr@chromium.org

Bug: chromium:1075999, chromium:1135027
Change-Id: I5d0d9e49c0302d94ff7291834f5f18e7a0839eb7
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng,v8_linux64_tsan_no_cm_rel_ng,v8_linux64_tsan_isolates_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2451030Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70328}
      a10ec2be
    • Milad Fa's avatar
      s390: [was-simd] Fix Vector pack and unpack behaviour. · f29078a8
      Milad Fa authored 
      Due to the lane numbering difference between Intel and IBM machines,
we need to switch the input registers when doing a vector pack.

Change-Id: I40e1fdae308e5dcd67aafab2abf099d4be0bb1a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2450832Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#70327}
      f29078a8
    • Shu-yu Guo's avatar
      Revert "[heap] String::MakeThin can get away without NotifyObjectLayoutChange" · 9edcb196
      Shu-yu Guo authored 
      This reverts commit 6e621f84.

Reason for revert: Suspicion of GC stress failures like https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/30260

Original change's description:
> [heap] String::MakeThin can get away without NotifyObjectLayoutChange
>
> String::MakeThin doesn't need to invoke NotifyObjectLayoutChange because
> ThinString will only introduce tagged values and hence will not
> overwrite recorded slots with untagged values.
>
> Bug: v8:10315
> Change-Id: Iaff9c06cef763462eb57bf3debc5183ae8db6fa0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448792
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70321}

TBR=ulan@chromium.org,leszeks@chromium.org,dinfuehr@chromium.org

Change-Id: I11c12e25702eb816cf616593d817a6ee3f691188
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10315
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2451029Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70326}
      9edcb196
    • Seth Brenith's avatar
      [torque] Generate shorter code for indexed field accesses · 73a8eded
      Seth Brenith authored 
      Currently, when accessing a field that doesn't have a constant offset,
Torque emits code to compute each preceding indexed field's length and
add them all together. This works, but such code can get super long if a
class has many indexed fields, and especially if the length expressions
of some indexed fields refer to other indexed fields. We'd like the
output of the new C++ backend to be short enough to go in inline headers
which will be included in many compilation units.

This change attempts to reorganize the code so that the computation of
each length expression can only be emitted exactly once. This only
shortens the generated C++ code; the resulting TurboFan output should be
identical. There are two main parts:
1. For each indexed field, we already generate a macro that can get a
   Slice referring to that field. Update these macros to not use the dot
   operator on that field. Using the dot operator on the predecessor
   field is allowed.
2. Update the dot operator for indexed fields to emit a call to the
   macro from step 1.

This sort of reverses the dependency added by the previous change
https://crrev.com/c/2429566 : rather than the slice macros depending on
the dot operator, this change makes the dot operator depend on the slice
macros.

The overall torque_generated directory shrinks by under 1% with this
change, but the runtime_macros.cc file (which should eventually become
inline headers) shrinks by 24%. More to the point, this change keeps
runtime_macros.cc from ballooning out of control when we add a
work-in-progress Torque definition for ScopeInfo
( https://crrev.com/c/2357758 ).

Bug: v8:7793
Change-Id: I989dda9c3666f1a49281fef03acb35baebb5b63a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432070Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70325}
      73a8eded