Associate DeoptLogEntry with both, the function's source position and
the deopt location's source position.

Also fixes the list-panel click handler to support all clickable entry
types.

Bug: v8:10644, v8:10754
Change-Id: If10272a926d5dad10b29322e237610900715b9dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584955
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71732}

- Show selection tab-bar
- Hide panels on empty timeline
- Fix legend position in ic list-panel

Bug: v8:10644
Change-Id: I4ef09627ed4de8682adb60f88be38867bc91640d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584953Reviewed-by: Sathya Gunasekaran  <gsathya@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71731}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/62841ca..b0341eb

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

Change-Id: I819de0f3557de321ad8426eb7205bce56f4b4196
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2588956Reviewed-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@{#71730}

Drive-by cleanup: IWYU for macro-assembler-ia32.cc.

IWYU added src/heap/basic-memory-chunk.h which failed a presubmit, so I
updated src/DEPS to allow for including it.

Bug: v8:11217,v8:7490
Change-Id: I63662bfb2b34e354e94f6052edfcb92f1341da58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2583675Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71729}

Drive-by cleanup: IWYU for macro-assembler-ia32.h and
instruction-selector-ia32.cc

Ran using `iwyu_tool.py -p out/ia32.debug <filename>`, with a local
build of llvm and iwyu.

Bug: v8:11217,v8:7490
Change-Id: I4f8e95fa9be2f51f6764c994bb4da9ae86854c4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2583671Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71728}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/11901ee..62841ca

Rolling v8/third_party/aemu-linux-x64: VSu8Vtf9AtE1W0EtQ4GMhLufzBudMRrz3_8vRSuj0O4C..ijHjc7kfgeuh7rvjQtk93a5SuvO23dABp_CeotpPcMAC

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

Change-Id: I9ab3d4ef52ac1a8edcf8f18b7fc6786de0da66bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2588394Reviewed-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@{#71727}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/026aa68..11901ee

Rolling v8/third_party/aemu-linux-x64: 5qqsaI1HWopoPDYdsXSJnZ-4w5bARXjJgFX_oohbDqIC..VSu8Vtf9AtE1W0EtQ4GMhLufzBudMRrz3_8vRSuj0O4C

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/d5e2194..0991ca1

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/c94b21d..99399ca

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

Change-Id: Iff37157907d9d7a0fc8c28fbd839ffc9695da4f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2587792Reviewed-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@{#71726}

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

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

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

PPC has a set of 64 Vector Registers called VSX.
The lower 32 of them are shared with Floating Point register (only
64 bit of the registers are used for FP operations).

The upper 32 registers are VR registers which are only used for
VMX Vector operations.

VSX Vector operations have the option to use the lower 32 or upper
32 registers using the TX bit set on the instructions. VMX operations
only use the upper 32 registers.

In V8 we always set the VSX TX bit to "1" to make sure all the vector
operations take place on the upper 32 registers.

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

This flag disables the implicit fallback to Turbofan when
Liftoff bails out due to an unsupported instruction/type.
Instead, Liftoff bailouts are treated as fatal errors.

This is meant for testing; it is not (yet?) a configuration
we support in production.

Change-Id: I04e2045f1976e202e65da0ba8e8d660c47859bf4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584949Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71721}

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

The rest of the code base was already migrated last year in
https://crrev.com/c/1631409. In the API we have to be more careful to
not break embedders. According to the standard there is no semantic
difference between typedef and using ([decl.typedef#2]):
  A typedef-name can also be introduced by an alias-declaration. The
  identifier following the using keyword becomes a typedef-name and the
  optional attribute-specifier-seq following the identifier appertains
  to that typedef-name. Such a typedef-name has the same semantics as if
  it were introduced by the typedef specifier.

Thus this CL replaces all typedefs in include/v8.h by the equivalent
using declaration. This improves readability, especially for function
pointer types.

R=ulan@chromium.org
CC=leszeks@chromium.org

Bug: v8:11074
Change-Id: Id917b6aa5c8cd289c60bda5da1e3667e747936e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563880
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71719}

The name has very few uses. I found at least one where the current
value does not make sense (on js-to-wasm wrappers in profiling), but I
found zero uses that were actually useful.

Hence this CL removes the name, i.e. just sets none on wasm scripts.

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

Bug: chromium:1125986
Change-Id: I2f793986a3da905980132cd09349dd6a1d787957
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584245
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71718}

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

This CL moves SharedFunctionInfo and BytecodeArray to the
kNeverSerialized classes, making them directly accessible from the
background thread.

To resolve the dependence on HeapNumber and BigInt objects stored in
the BytecodeArray's constant pool, this CL introduces a new
ObjectDataKind::kPossiblyBackgroundSerializedHeapObject, which allows
for objects to be serialized lazily from the background thread where
we know that this is safe (e.g. because they are constant). BigInt and
HeapNumber are the first members of this new group of objects.

Bug: v8:7790
Change-Id: I1d962d1cb7c36cc3f5baeb9603d5298f32af3363
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567705Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71716}

I think this was likely fixed by one of the other bugfixes in the
meantime. It doesn't flake with 50k runs locally.

Fixed: v8:2008
Change-Id: I9e6f1e7f75cf20c52d49937d980aafacaa23b401
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584945Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71715}

The issue is with this pattern, assuming disjoint uses for all vregs:

phi: v1 = v0 ...
phi: v2 = v0 ...
phi: v3 = v0 ...
...
phi: vN = v0 ...

For every phi, BuildBundles proceeds as follows:
- Create a new bundle for the output
- Merge the input bundle into the output bundle

Since the bundle gets bigger at every iteration, the merges become more
and more expensive and consume Zone memory that is immediately thrown
away at the next iteration.

A simple fix is to check the size of the bundles before merging and
always copy the smallest one into the biggest. In the pattern above this
should always copy the single-range output bundle into the large input
bundle.

R=sigurds@chromium.org

Bug: v8:11237
Change-Id: I6ad9152035da698d94b02b5b41802545ba149307
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584879Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71714}

When Liftoff bails out, the function ExecuteLiftoffCompilation performs
an early return before updating the "counters" data structure with the
bailout reason. The early return was introduced in
https://chromium-review.googlesource.com/c/v8/v8/+/2423710.
We should just drop it again, as there is another
"if (did_bailout()) return" right after updating the counters.

Bug: v8:11259

Change-Id: Ia7f72c3a7eda4252a5a4450646427edb26130996
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584880Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71713}

The gc_in_progress flag was reset to false only after sweeping was done.
As a result, if we call CollectGarbage during an incremental GC and
after marking has finished, the we will observe that a gc is still in
progress but will not have a marker and crash.

The immediate solution is to move resetting the gc_in_progress flag such
that it indicates whether we didn't have the atomic pause yet. That
means we could have gc_in_progress==false and incremental sweeping still
running, which semantically negates the meaning of gc_in_progress.

Observing that gc_in_progress essentially becomes equivalent to having a
marker, this CL removes the gc_in_progress flag and replaces checks on
it with checks on marker.

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

Using the config of one of the builders that catched the chromium:1138115 issue; compile only.

Bug: chromium:1142484
Change-Id: I4ad19a7c32819a3a8306fa169d3c8ec0ffb47a8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584874
Commit-Queue: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71711}

Add a method that returns the microtask queue that is being used
by the `v8::Context`.

This is helpful in non-monolithic embedders like Node.js, which
accept Contexts created by its own embedders like Electron, or
for native Node.js addons. In particular, it enables:

1. Making sure that “nested” `Context`s use the correct microtask
   queue, i.e. the one from the outer Context.
2. Enqueueing microtasks into the correct microtask queue.

Previously, these things only worked when the microtask queue for
a given Context was the Isolate’s default queue.

As an alternative, I considered adding a way to make new `Context`s
inherit the queue from the `Context` that was entered at the time
of their creation, but that seemed a bit more “magic”, less flexible,
and didn’t take care of concern 2 listed above.

Change-Id: I15ed796df90f23c97a545a8e1b30a3bf4a5c4320
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2579914Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71710}

next_enumeration_index is the next free index available to store a
property. ObjectDescriptor tracks this field while instantiating the
literal and updates the next_enumeration_index when finalizing the
instantiation. When adding new properties (named / computed) we were
updating this value to the current value that is being used instead
of next free index. This cl fixes it.

Bug: chromium:1152231
Change-Id: Ica8c36dcabf035db559e29d4573ecd5e53d6062a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2577463
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71709}

movd/movq moves from/to 32/64 bit operand to xmm, the disasm was
incorrect printing both operands as xmm.

Was: "movd xmm2,xmm10"
Now: "movd xmm2,r10"
Change-Id: I4061257da763efd3493a3fd5875dc116296e1737
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2585258Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71708}

Change-Id: Ibaea56e50635dac7fe43bd7599ebcf92692fbfec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584870Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71707}

Change-Id: If3c7e11516c72091b280dbeced3df0d37c5aaa2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584869Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71706}

Implementation is almost identical to x64, except that in the
instruction-selector, for AVX, we allow the second operand to
be a slot, and so we use InputOperand in the codegen.

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/68a1580..026aa68

Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/86a7f72..ea9f1f7

Rolling v8/third_party/aemu-linux-x64: FZmiNfUmb6lJR28DxZkS03xoY4oJh4177LjCbVwbpCMC..5qqsaI1HWopoPDYdsXSJnZ-4w5bARXjJgFX_oohbDqIC

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/4565794..d5e2194

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/99b0e4a..c94b21d

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

Change-Id: I9dc4a6bf1a806397c96d22b8125c79bccd066b4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2586011Reviewed-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@{#71704}

This reverts commit cddaf66c.

Reason for revert: Multiple fuzzer failures

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

Original change's description:
> [compiler][wasm] Align Frame slots to value size
>
> - Adds an AlignedSlotAllocator class and tests, to unify slot
>   allocation. This attempts to use alignment holes for smaller
>   values.
> - Reworks Frame to use the new allocator for stack slots.
> - Reworks LinkageAllocator to use the new allocator for stack
>   slots and for ARMv7 FP register aliasing.
> - Fixes the RegisterAllocator to align spill slots.
> - Fixes InstructionSelector to align spill slots.
>
> Bug: v8:9198
>
> Change-Id: Ida148db428be89ef95de748ec5fc0e7b0358f523
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2512840
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71644}

TBR=bbudge@chromium.org,neis@chromium.org,ahaas@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:9198
Change-Id: Ib26d016df6f30f333d30b5ac14eed9630bba8252
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584200
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71703}

cl for chrome/src/DEPS in https://chromium-review.googlesource.com/c/chromium/src/+/2582536

Bug: v8:10447
Change-Id: I28452cab64f000aa8cc466290ffcc97aa0b41f78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2583189
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Auto-Submit: Frank Tang <ftang@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71702}

a few unused functions

Drive-By: Also clean up LoadSimd128 as LoadV128 and remove
Change-Id: I4cdee0fcb1e153309492026b4334af27afba7ec1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584442
Commit-Queue: Junliang Yan <junyan@redhat.com>
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71701}

Follow up on https://chromium-review.googlesource.com/c/v8/v8/+/2510969
Now that gin implements the new version:
https://chromium-review.googlesource.com/c/chromium/src/+/2566052
These can be deprecated.

Change-Id: Ie1e5448655e40eb3c11089f59510f269a9873e66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2566430Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71700}

This commit updates the gen-postmortem-metadaa.py script to
incorporate changes in V8 8.5. This removes the need to float a
patch to the script in Node.js.

Change-Id: I6532495bee906f51eb2b773ec38ff0a6e404dafe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2582705Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#71699}

Add fields to HeapOptions to denote on heap creation that the heap does
not support incremental/concurrent marking/sweeping.
This only applies to standalone heaps.
When triggering a GC (either explicitly or by the heap growing
heuristics), the given config is limited to not trigger unsupported
marking/sweeping types.

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

R=ecmziegler@chromium.org

Change-Id: I35b87585a1fab35fd2e0265d0cf74a092521a872
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584244Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71697}

The NativeModule should not die before the WasmEngine, since state owned
by the engine will still be accessed in the destructor of the
NativeModule.
This CL ensures that by moving the OperationsBarrier from the
CompilationStateImpl to the NativeModule.

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

Bug: v8:11250, v8:11243
Change-Id: Ic4d69222e9e6076578c35986b0051817dbd8dbef
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2581959
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71696}

So far we reported the script ID, but DevTools ignores that and uses the
source url instead. That url was just set to "wasm ", which the frontend
couldn't make any sense of.
This CL fixes this by passing the source URL to the code create event,
and also setting the position of the code inside the script (i.e.
wasm module).

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

Bug: chromium:1125986
Change-Id: Ic41dcd2768c60fd6748468d3a89fc4ffccb35932
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2581543
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71695}

NOTRY=true
R=thibaudm@chromium.org
CC=clemensb@chromium.org

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

NOTRY=true
R=manoskouk@chromium.org

Bug: v8:9495
Change-Id: I72142c4992e969852341b49a8e5628b53ec1d5b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2581965Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71693}