This is a reland of ff0c5cfa

TSAN issue fixed in https://crrev.com/c/2410057

Original change's description:
> [offthread] Enable off-thread finalization in --future
>
> Enable the new LocalHeap-based off-thread finalization behind --future.
>
> Bug: chromium:1011762
> Change-Id: I4b33fc300a34530d75aa1a3e197e0d1326994efa
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2403252
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69813}

Bug: chromium:1011762
Change-Id: I89013a4f6437f062194e7abdaa68c17f0b285edf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412169Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69940}

Liftoff code is never relocated and never serialized, thus relocation
information is not needed.

This results in slightly less information being printed when
disassembling code, because the disassembler sometimes uses relocation
information to show the kind of a call (e.g. internal wasm call vs.
builtin call). This is an acceptable regression IMO.

R=thibaudm@chromium.org

Bug: v8:10777
Change-Id: I019913a41b47466fba7b7f216ab51b91475cd984
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412186Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69939}

Bug: v8:10315
Change-Id: If64ff0bcd441ecce4113f70ba72373949f076efe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2409276Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69938}

With the --always_promote_young_mc flag the mark-compact collector
cannot gracefully handle allocation failures when evacuating the young
generation. In some scenarios this causes OOM crashes without invoking
NearHeapLimitCallback.

This CL ensures that the young generation is evacuated before the old
generation because old generation evacuation can be aborted if needed.
Additionally, the CL cleans up usages of CanExpandOldGeneration.

Bug: v8:10843
Change-Id: I50d83912137afa3d3dac797dd4c6bddb51612334
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404829
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69937}

This CL deletes the image on the timeline overview which
only reflects the last uploaded timeline-track data
and updates the timelineOverviewIndicator on mousemove and
chunk zoom events.

Bug: v8:10644

Change-Id: Ib0a43083d2461cc343a0c946cfddaf4fdc514687
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2413257Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Cr-Commit-Position: refs/heads/master@{#69936}

Bug: chromium:1056170
Change-Id: I4f935e1e653b2b713e690d9cd7d8a624d7bf1536
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2413259
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69935}

For "else" and "catch" statements, the Ref to the end label should only
be added if the current block is unreachable, not the parent block.

In the added regression test, the "true" block ends in an unreachable
state with a stack height less than the target height of the end label.
This is valid due to the semantics of unreachable code, but we should
not add the Ref in this case because its stack height is invalid.

R=clemensb@chromium.org

Fixed: chromium:1092130
Change-Id: Iebaf5e7d6516278ccd3c8268ac331069e109d882
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412181
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69934}

Methods are now fully replaced with SafepointScope and are not supposed
to be used anymore.

Bug: v8:10315
Change-Id: I16f9c37b1849590d74fa55c92b8ea5cc83cd7cce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2413256Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69933}

Since the string-table's data pointer is written inside a mutex, but
read outside of it, we need to acq/rel access to it.

There's no support in C++ for an std::atomic<std::unique_ptr>, so this
patch changes the std::unique_ptr<Data> into a std::atomic<Data*>, and
handles the deletion manually. StringTable::Data still uses

std::unique_ptr as the general pointer-passing contract, we just
carefully set and release the unique_ptrs when accessing and setting
the StringTable's atomic Data pointer.

Change-Id: I711a56825e2f5f9b2db63d1874e09c2627af54b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2410057
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69932}

Introduced in a8a1776e. The chromium build checks against an explicit
list of compilation units with static initializers, thus it's easier
to use

 static Constant() { ... }

than

 static const kConstant;

Bug: v8:8888
Change-Id: I2625130dd3d92607b46c0cc615623907149f800e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2413255
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69931}

This is needed for preserving test coverage for the mode that runs
without local heaps. Flags that depend on --local-heaps are also
disabled in this variant.

Bug: v8:10828
Change-Id: I4a3b219e5235945278d8356f4efd886a97ffa16a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404456
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69930}

This commit adds support for capture groups (as in e.g. /x(123|abc)y/)
in the experimental regexp engine.  Now every InterpreterThread owns a
register array containing (sub)match boundaries. There is a new
instruction to record the current input index in some register.

Submatches in quantifier bodies should be reported only if they occur
during the last repetition.  Thus we reset those registers before
attempting to match the body of a quantifier.  This is implemented with
another new instruction.

Because of concerns for the growing sizeof the NfaInterpreter object
(which is allocated on the stack), this commit replaces the
`SmallVector` members of the NfaInterpreter with zone-allocated arrays.
Register arrays, which for a fixed regexp are all the same size, are
allocated with a RecyclingZoneAllocator for cheap memory reclamation via
a linked list of equally-sized free blocks.

Possible optimizations for management of register array memory:
1. If there are few register per thread, then it is likely faster to
   store them inline in the InterpreterThread struct.
2. re2 implements copy-on-write:  InterpreterThreads can share the same
   register array. If a thread attempts to write to shared register
   array, the register array is cloned first.
3. The register at index 1 contains the end of the match; this is only
   written to right before an ACCEPT statement.  We could make ACCEPT
   equivalent to what's currently CAPTURE 1 followed by ACCEPT.  We
   could then save the memory for register 1 for threads that haven't
   finished yet.  This is particularly interesting if now optimization 1
   kicks in.

Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Bug: v8:10765
Change-Id: I2c0503206ce331e13ac9912945bb66736d740197
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390770
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69929}

Making test failures more convenient to debug than simply failing
a .ToHandleChecked() call.

Change-Id: Ieb4553bec8886d1a4eb0dbf0c7bc53ac6435a82c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412528
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69928}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/62cb86f..be363dc

Rolling v8/third_party/aemu-linux-x64: cG1zzefbD24rFmPDujqP0rrEG0uXUhH8axBOrD619hoC..8YjsZy1I3YIJIOUKErXW54SHjiEX62hd9SqYjmop19oC

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/534924e..0063ad8

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/b71187b..52fdd1f

TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com

Change-Id: I02d2cd22c57d032d8b7b8cf810c78b90b3897edd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2413268Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#69927}

Bug: v8:10201
Change-Id: I313405983696546b817c96a820343e6cb9e3fdd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2408977Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Yu Yin <xwafish@gmail.com>
Cr-Commit-Position: refs/heads/master@{#69926}

Port 068cf20e

Original Commit Message:

    Implement f32x4 and f64x2 nearest, trunc, ceil, and floor.

    These instructions were accepted into the proposal [0], this change
    removes all the ifdefs and todo guarding the prototypes, and moves these
    instructions out of the post-mvp flag.

    [0] https://github.com/WebAssembly/simd/pull/232

R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: I02086255f635f1d47586fc74dd754426f6beccb0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411675Reviewed-by: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#69925}

Bug: v8:10180
Bug: v8:10906
Change-Id: Ieb11edfef24902a3ffb1eae87730ca7b60b59a47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411772Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69924}

Implement f32x4 and f64x2 nearest, trunc, ceil, and floor.

These instructions were accepted into the proposal [0], this change
removes all the ifdefs and todo guarding the prototypes, and moves these
instructions out of the post-mvp flag.

[0] https://github.com/WebAssembly/simd/pull/232

Bug: v8:10906
Change-Id: I44ec21dd09f3bf7cf3cae5d35f70f9d2c178c4e4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2406547
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69923}

Those functions will return a BigInt, which we need to convert to int to
match the value returned by the interpreter.

R=ahaas@chromium.org

Bug: chromium:1127717
Change-Id: I328660ab73776de2bd90b19d18e46663efe6b6cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412177Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69922}

The API in the wasm module builder changed recently
(https://crrev.com/c/2390144). The fuzzer was still emitting code for
the old API.
This CL fixes this for primitive types, and adds a TODO to implement
heap types when needed.

R=ahaas@chromium.org
CC=manoskouk@chromium.org

Bug: chromium:1127717
Change-Id: I514b6e53d0492e5706a5b06d24026da13c3a2165
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412176Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69921}

Currently, the generic wrapper is used for i32 and i64 params and 0 or 1
i32 and i64 return value.

Bug: v8:10701
Change-Id: I4b592d7e0e4ebcb3455520c094c92bf4177c5a5a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412179Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Eva Herencsárová <evih@google.com>
Cr-Commit-Position: refs/heads/master@{#69920}

Check that a v128 imported global in a Wasm module is initialized with a
WebAssembly.Global object.

This is technically impossible, because creating WebAssembly.Global of
type v128 is an error, and creating one of any other type is a type
mismatch. However, we still need this check to avoid hitting an
unreachable case when setting the value of the global later on.

Also, this is not a validation error, since the v128 restriction is only
a Web/JS limitation. Other embedders can choose to do something
different with this module with an imported v128 global.

Bug: chromium:1127740
Change-Id: I6d444578c082b6b1c353cfa2fd82bb42eb14fc3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2410659Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69919}

Assigning to reference to std::unordered_set doesn't change the
reference. It merely replaces the content of rhs with that of lhs.
We should use pointers instead.

Bug: chromium:1056170
Change-Id: I496544ca4b16ce8ae8a9aff57cb05a07cad984c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412184Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69918}

R=ulan@chromium.org, thibaudm@chromium.org

Bug: v8:7581
Change-Id: I9b8f2d3967821a2edd577b13951d9b845ae2868e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404828
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69917}

Bug: v8:10884
Change-Id: I961033da39fea6e2e165aabb978208b581cfeaf0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412170Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69916}

This is a manual revert of 67cdacd9. Experiments have shown that inline
headers do bring real benefits and we won't be proceeding with inline
header removal.

Bug: v8:10749
Change-Id: Icd3d0b3926d0b7a24edb19d9f177e9c8818abe09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412174
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69915}

We have to make sure that 32 bit negative values are zero extended.
Related testcase: https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8869450761469925696/+/steps/Check_-_extra/0/logs/memory_trap/0

Bug: v8:10701
Change-Id: I69ae4189d37e5d31a81254ec72dd6e02fb442b4e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412168Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Eva Herencsárová <evih@google.com>
Cr-Commit-Position: refs/heads/master@{#69914}

Bug: v8:10701
Change-Id: Ibb4879accb0e991ddb4434d878bd8ef779b70034
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2412171Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Eva Herencsárová <evih@google.com>
Cr-Commit-Position: refs/heads/master@{#69913}

Global.set requires a write barrier. This write barrier was missing in
the original CL. The reland only adds the write barrier for ia32, and
bails out on the other platforms.

Original message:

With this CL we add support for all externref globals except for
imported mutable globals.

R=thibaudm@chromium.org, ulan@chromium.org

Bug: v8:7581
Change-Id: I86328a17200d1edc505f4c4357bdf795d95cf0c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404777Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69912}

This reverts commit b5f37051.

Reason for revert: Breaking the fuzzer https://bugs.chromium.org/p/v8/issues/detail?id=10918

Original change's description:
> [compiler] Replace JSDataView with direct reads
>
> Bug: v8:7790
> Change-Id: Id01c2e4359aa4294816ffe14c08a586a9b9b10c2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404768
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69904}

Change-Id: I9a470708f06328061d5d4ecf21fa38bc0e49ff45
Bug: v8:7790, v8:10918
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2410196Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69911}

Feedback collection is currently implemented only for JS operators in
generic lowering. Missing feedback collection results in soft-deopts
immediately after tiering up to TF from NCI code.

In this CL we disable two large classes of such problematic lowerings
for NCI code, type hint lowering and typed lowering.

Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Bug: v8:8888
Change-Id: Ia8452775616074b7ad6dfe930f305449db3f5682
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2410180
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69910}

Port 863c2cb4
https://chromium-review.googlesource.com/c/v8/v8/+/2406593

Implement f32x4.pmin, f32x4.pmax, f64x2.pmin, and f64x2.pmax.

Change-Id: I102f8d80e72494f9dc48ae726a3eb272bcbe1661
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411806Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#69909}

The rename makes it clear that the atomic counter is an approximation
only. Explanation is added about the update of the counter (increased
when units are added, and reduced to zero if a worker finds no more
units). The comment also sais why it's safe to use relaxed memory
ordering in this case.

R=thibaudm@chromium.org, ahaas@chromium.org

Bug: chromium:1101340
Change-Id: I307d646189bc5732d50c92a94b2a654fa6a7f763
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2410185
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69908}

This is an attempt to fix a gcmole failure in
https://chromium-review.googlesource.com/c/v8/v8/+/2362960

Change-Id: Idff72ff3ae63863fb73f11231481469c700891c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2410193Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69907}

The signature of {GetMaxConcurrency} was recently extended to pass the
{worker_count}, i.e. the number of workers that are currently running.
This number allows us to return a more precise number for the current
maximum concurrency.
In the case of background function compilation, we were sometimes
returning a slightly too small number, resulting in too few workers to
be spawned, resulting in slightly longer compilation.
For wrapper compilation on the other hand, the returned number is
already correct, and this CL adds a comment explaining why.

R=thibaudm@chromium.org

Bug: chromium:1101340
Change-Id: I0e3122c8b99ba1cdf97616de922d4f07874b0aeb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2410383Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69906}

Bug: v8:7790
Change-Id: I5391c6688dfad81e37d260fbfef22c3dbdce0dce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404769
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69905}

Bug: v8:7790
Change-Id: Id01c2e4359aa4294816ffe14c08a586a9b9b10c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404768
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69904}

Bug: v8:10917, v8:7790
No-Try: true
Change-Id: I11dfd404e619dd547923421ff7aef3428c746243
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2410190
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69903}

Bug: v8:7790
Change-Id: I27a13c213c33e742cd66ed85e9c10c71b78a9384
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2410182
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69902}

If code is deoptimized while CPU profiling, a deoptimization event
record is sent to the profiler. But if the profiler could not find
the associated CodeMap entry in CodeDeoptEventRecord::UpdateCodeMap
it would simply return without freeing the deopt_frames array.
This change frees the deopt_frames array no matter what in
CodeDeoptEventRecord::UpdateCodeMap, eliminating a storage leak.

Bug: v8:10861
Change-Id: I4e68566bb91dff13b38e255ddfed24b85b7a1d57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2386332Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69901}