Skip to content

V
V8
Switch branch/tag
  1. 01 Oct, 2020 28 commits
    • Frank Tang's avatar
      Roll test262 · 82061a66
      Frank Tang authored 
      https://chromium.googlesource.com/external/github.com/tc39/test262/+log/639760203..ad8a5e9940

Bug: v8:7834
Change-Id: Ifb5c6601b8c0b8fb2fc60144c8f77abf0a12782d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440722Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70269}
      82061a66
    • Zhi An Ng's avatar
      Revert "Reland "[serializer] Allocate during deserialization"" · c7c0e790
      Zhi An Ng authored 
      This reverts commit 28a30c57.

Reason for revert: Broke Test262 https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/38638?

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=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org

Change-Id: Ieed68332ef6a7ad36db061e3f48be0f28673d7a2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1075999
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2441608Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70268}
      c7c0e790
    • Leszek Swirski's avatar
      Reland "[serializer] Allocate during deserialization" · 28a30c57
      Leszek Swirski authored 
      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: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70267}
      28a30c57
    • Andrey Kosyakov's avatar
      DevTools: add support for injecting bindings by context name · abacd4c1
      Andrey Kosyakov authored 
      This adds support for injecting binding into contexts other than
main based on the context name (AKA isolated world name in Blink
terms). This would simplify a common use case for addBinding in
Puppeteer and other automation tools that use addBinding to expose
a back-channel for extension code running in an isolated world by
making bindings available to such code at an early stage and in a
race-free manner (currently, we can only inject a binding into
specific context after the creation of the context has been reported
to the client, which typically introduces a race with other evals
the client may be running in the context).

Change-Id: I66454954491a47a0c9aa4864f0aace4da2e67d3a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440984Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarPavel Feldman <pfeldman@chromium.org>
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70266}
      abacd4c1
    • Clemens Backes's avatar
      [wasm] Refactor generation of atomic instructions · 179f7f43
      Clemens Backes authored 
      This refactors the logic for generating atomic instructions in TurboFan.
Instead of duplicating code via macros, we look up all information we
need from a table (via switch), and generate the respective graph from
that information.
This will allow to factor in changes for memory64 more easily.

R=ahaas@chromium.org

Bug: v8:10949
Change-Id: Ic2c78588f8ce555667f7e0220b1cc50c7074ded4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440831
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70265}
      179f7f43
    • Dan Elphick's avatar
      [CSA] Tnodify CodeAssembler::Parameter · 74a9b9c4
      Dan Elphick authored 
      CodeAssembler::Parameter now takes a Type template parameter and
performs a checked cast to it. There is also UncheckedParameter which
returns a TNode but doesn't check the cast. The original Parameter
method is still there as UntypedParameter.

Parameter<T>(x) in many cases replaces CAST(Parameter(x)), where the
cast is performed inside Parameter. Since Parameter is not a macro,
this means it cannot see the original expression or its file name and
line number. So the error messages are vaguely useful, Parameter<T>()
takes a SourceLocation parameter which with a default value of
SourceLocation::Current(), which at least gives us the file name and
line number for the error message.

Bug: v8:6949, v8:10933
Change-Id: I27157bec7dc7462210c1eb9c430c0180217d25c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435106Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70264}
      74a9b9c4
    • Etienne Pierre-doray's avatar
      [Heap]: PointersUpdating uses Jobs · 95ca946c
      Etienne Pierre-doray authored 
      Replaces ItemParallelJob by std::vector to hold work items.
IndexGenerator is used to iterate over evacuation items.

Change-Id: Id687f6696e74998c9d23ee2a2ee97c7687d13815
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2438631
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70263}
      95ca946c
    • Leszek Swirski's avatar
      [ptr-cmpr] Remove runtime Isolate allocation flag · 6ca8453c
      Leszek Swirski authored 
      Remove the runtime functionality allowing the Isolate to be allocated
4GB aligned in non-pointer-compressed builds. This was barely used in
tests, so we can remove it to give slightly stronger compile-time
guarantees about pointer-compression-only methods being used only under
pointer-compression.

Change-Id: I8eb990faa8f8499ecdcb70ca104ffad4be1437b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442790Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70262}
      6ca8453c
    • Andrey Kosyakov's avatar
      DevTools: ensure binding is only exposed into the specified context · a65c5fb7
      Andrey Kosyakov authored 
      ... when addBinding is called with contextId. Previously, due to
a subtle type, we exposed bidings added with executionContextId to
all contexts created after the binding was added.

Also, do not persist context-specific bindings to agent state,
as context ids don't make sense across the process.

This also adds a test instrastructure to create additional context in
given context group.

Change-Id: I1b3e96cb65b756424bc7872d200bbbf41e4c30b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440982Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70261}
      a65c5fb7
    • Clemens Backes's avatar
      [wasm] Only store PCs for full validation · 54f852d1
      Clemens Backes authored 
      The PC stored in each entry on the value stack and control stack is only
needed for error reporting, hence avoid storing it for the
{kNoValidation} and {kBooleanValidation} modes.

R=thibaudm@chromium.org

Bug: v8:10969
Change-Id: I14c6a6b1857545099e4a90d77d13107013f01565
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436540
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70260}
      54f852d1
    • Michael Lippautz's avatar
      cppgc: Move ProcessWeakness into FinishMarking · 20e1ba28
      Michael Lippautz authored 
      For cross-thread handling we require the atomic marking pause to
provide an atomically consistent view of markbits and weak references.
This is ensured by locking the whole atomic pause from entering to
weak processing.

This CL move ProcessWeakness() into FinishMarking() which allows to
nicely scope the upcomming lock from EnterAtomicPause() to
LeaveAtomicPause(). The alternative is requiring the caller to ensure
proper locking which is harder than ensuring that the Marker is
consistent.

Bug: chromium:1056170
Change-Id: Ib6028a0d76fcf9422c4a0d422fec3d568f106bf2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442620
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70259}
      20e1ba28
    • Michael Hablich's avatar
      Update V8 version after branch cut · 4e7621fc
      Michael Hablich authored 
      TBR=machenbach@chromium.org

Change-Id: I3ea2bb7431ee9c5834e9ca58cf88511fb719a0cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442623Reviewed-by: 's avatarMichael Hablich <hablich@chromium.org>
Commit-Queue: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70258}
      4e7621fc
    • Richard Townsend's avatar
      fix: correct calling convention for Windows on Arm · 7b3a27b7
      Richard Townsend authored 
      Corrects a "Check failed: kFPParamRegisterCount == kParamRegisterCount"
message when compiling v8_snapshot for Windows on Arm.

Unlike x64, Windows on Arm's calling convention does not alternate
between integer and float registers.

Bug: chromium:1052746
Change-Id: I4c9cdafcd6e43742b94613f85b2983761cc0891a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440717
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70257}
      7b3a27b7
    • Dominik Inführ's avatar
      [heap] Use regular FreeList for MapSpace · 487d512e
      Dominik Inführ authored 
      MapSpace was using a separate FreeList implementation since all maps
have the save exact same size. Remove FreeListMap and use the regular
free list which is also used for the old space. This will allow to use
LABs in the map space.

Bug: v8:10315
Change-Id: I00cfcb260edb20f044ad74a24772f810e1f93afd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442789Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70256}
      487d512e
    • Kong, Fanchen's avatar
      [turbofan] Enable complex memory operands for floating-point binop on x64 · abcd1835
      Kong, Fanchen authored 
      With this change, a load from memory into a register can be replaced by a memory operand for floating point binops if possible.

This eliminates one instruction for following pattern:
	vmovss xmm0, m32
	vmulss xmm1, xmm1, xmm0
===>
	vmulss xmm1, xmm1, m32

Change-Id: I6944287fae3b7756621fb6b3d0b3db9e0beaf080
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411696
Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70255}
      abcd1835
    • Yang Guo's avatar
      [debug] consider Object.keys free of side effects · 371b1a61
      Yang Guo authored 
      R=szuend@chromium.org

Fixed: v8:10910
Change-Id: I8706026db5dfa815ae5c1580a6ebbeb11adeb23e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442615
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Yang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70254}
      371b1a61
    • Frank Tang's avatar
      Fix "japanese" and "chinese" calendar · be3550bf
      Frank Tang authored 
      Roll the icu to include the fix. The roll include previously
mistakenly filter out required resources.
Fix "japanese" under "ja" and calendar: "chinese" under "zh"
Depends on https://chromium-review.googlesource.com/c/chromium/deps/icu/+/2433166

This CL prepare for such landing:
1. Add test to show the correct result.
2. Wrap the number format static cast to DecimalFormat only if
   the concrete class is DecimalFormat. This is needed after the landing
   because the new resource enable other subclass of NumberFormat.
3. Change test to allow the additional numberingSystems.

Roll the the DEPS of chromium in
https://chromium-review.googlesource.com/c/chromium/src/+/2437820

Bug: v8:10960
Change-Id: Ib10b11862a093d1d487070f79556505bfc10bcc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432801Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70253}
      be3550bf
    • Dominik Inführ's avatar
      [heap] Update path of xml file in chromium for GarbageCollectionReason · 0e127b12
      Dominik Inführ authored 
      Change-Id: Ib9956fb8ad6a129bf0df0775bc1e691a059cbd27
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2442614
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70252}
      0e127b12
    • Leszek Swirski's avatar
      [heap] Lazily sort CodeObjectRegistry pointers · c5c67ce7
      Leszek Swirski authored 
      Rather than keeping a known-sorted list of existing Code objects, and an
eagerly sorted set of new Code objects, instead store a single vector
which is lazily sorted when needed.

We keep the distinciton between adding an existing or a new Code object,
so that we only have to clear the "sorted" bit when adding the latter;
plus we check if adding the new Code object would serendipitously keep
the vector sorted, just in case the new Code object is allocated after
all previous Code objects on that page (not unlikely given linear
allocation areas),

Change-Id: I70778ba624f1b437bd992616749a8cd08ad33613
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431204
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70251}
      c5c67ce7
    • Ulan Degenbaev's avatar
      [heap] Use LiveObjectRange in MarkingVerifier · 8ee03b11
      Ulan Degenbaev authored 
      This removes custom object iteration in MarkingVerifier.

Change-Id: I2e597dab6014ff4443faa60cd3d4be20a2dc1b56
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2438067Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70250}
      8ee03b11
    • Dominik Inführ's avatar
      [heap] New mechanism for requesting GC from background threads · b187504e
      Dominik Inführ authored 
      Background threads use a new mechanism to request a GC from the main
thread. Previously they used MemoryPressureNotification to request the
collection. However this conflicts with the embedder's usage of
MemoryPressureNotification.

Bug: v8:10315
Change-Id: Ib25a13a43e1f6a8785bb0d421dd056ae06a4a350
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429270Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70249}
      b187504e
    • Peter Marshall's avatar
      [cpu-profiler] Refactor ProfileGenerator · 82efa4bd
      Peter Marshall authored 
      Rename it to Symbolizer because it does exactly that.

Change the SymbolizeTickSample method to return the symbolized state
rather than pass it on to the ProfilesCollection. This makes it easier
to test as now it only relies on the CodeMap provided to it.

Make EntryForVMState a free-floating function as it doesn't rely on
state and then we can avoid importing the StateTag definition in the
header.

Remove the UNREACHABLE from EntryForVMState as the compiler got smarter
and doesn't need it anymore.

Pass the CpuProfilesCollection to SamplingEventsProcessor instead,
as it is now responsible for putting the symbolized samples into the
collection to be sorted into the appropriate profiles.

Change-Id: I104290eff22b7d94a1bd34ba904036badccf4e13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440522
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70248}
      82efa4bd
    • Leszek Swirski's avatar
      [parser] Fix AST func reindexing for function fields · a769ea7a
      Leszek Swirski authored 
      AST reindexing has to skip visiting fields that are already in the
member initializer, as they will have already been visited when
visiting said initializer. This is the case for private fields and
fields with computed names.

However, the reindexer was incorrectly assuming that all properties
with a FunctionLiteral value are methods (and thus not fields, and
can safely be visited). This is not the case for fields with
function expression values.

Now, we correctly use the class property's "kind" when making this
visitation decision.

Fixed: chromium:1132111
Change-Id: Ia53d1fe713453e361b818dfb0b5f88a90cecdf21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440519
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70247}
      a769ea7a
    • Manos Koukoutos's avatar
      [wasm-gc][bug] Fix type checking of GC instructions in unreachable code · 98a9f051
      Manos Koukoutos authored 
      Decoding of gc/reference type instructions assumed that popping a value
from the stack would either throw an error or return a value of the
expected type. This is not true in unreachable contexts, where a
bottom-typed value can be returned.
This CL fixes this problem, adds tests which expose it, and improves
AddFunction() in the infrastructure of
function-body-decoder-unittest.cc.

Bug: v8:7748
Change-Id: I7e9d0caa9ba1687b68a5cdad7b99c054285d9f0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440577
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70246}
      98a9f051
    • Leszek Swirski's avatar
      Revert "[wasm] Update spec tests" · c7416d9e
      Leszek Swirski authored 
      This reverts commit 1110ccf6.

Reason for revert: Various failures, e.g. https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8867662180901819968/+/steps/Check_-_ODROID/0/logs/simd_f32x4_pmin_pmax/0

Original change's description:
> [wasm] Update spec tests
>
> The change is auto-generated by v8/tools/wasm/update-wasm-spec-tests.sh.
>
> R=​manoskouk@chromium.org
>
> Change-Id: I1ebe8c3e56754e1242d279124a07f74edaab89c1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436456
> Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70244}

TBR=ahaas@chromium.org,manoskouk@chromium.org

Change-Id: Ifafa7ed7e7deb7d94e12e2aee9e79b207199b618
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440594Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70245}
      c7416d9e
    • Andreas Haas's avatar
      [wasm] Update spec tests · 1110ccf6
      Andreas Haas authored 
      The change is auto-generated by v8/tools/wasm/update-wasm-spec-tests.sh.

R=manoskouk@chromium.org

Change-Id: I1ebe8c3e56754e1242d279124a07f74edaab89c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436456Reviewed-by: 's avatarManos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70244}
      1110ccf6
    • Manos Koukoutos's avatar
      [wasm][formatting] Split ValueType class into regions · 54536f4f
      Manos Koukoutos authored 
      Additional change: Add ValueType::is_bottom()

Change-Id: I8e294c6318b6e51efac0a07ac0ec059ea9dc5654
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440515
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70243}
      54536f4f
    • Etienne Pierre-doray's avatar
      [Heap]: Evacuate uses Jobs · 0763e924
      Etienne Pierre-doray authored 
      Replaces ItemParallelJob by std::vector to hold work items.
IndexGenerator is used to iterate over evacuation items.

Change-Id: I63ea246f267d8cbe140c47c022b95b3873bc957a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2425339
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70242}
      0763e924
  3. 30 Sep, 2020 12 commits