This CL adds an argument to the heap profiler that allows to control
whether global objects (e.g. 'window' in JavaScript) are treated as
roots in the heap snapshot. Doing so hides blink-internal details and
is often a good choice when user-JS leaks are investigated. Sometimes,
however, this introduces spurious retainer cycles, which are hard to
debug.

Previously, this option was exposed as a V8 flag. The blink
implications of the build-time V8 flag are now available via
the new blink flag `enable_additional_blink_object_names`.

Tbr: hpayer@chromium.org
Bug: chromium:1034504
Change-Id: Ibe9412917ae598a3ff0c3dc956ab0bc179f50a21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967387Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65491}

Read-only heap objects are immutable and immovable. It is safe to access
these objects directly from the heap. Not having to serialize them
reduces the time we spend on main thread especially for TurboProp.

Bug: v8:9684
Change-Id: Ibabb7076af50c9007d2a8ed57fe257406958fb6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955596Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65490}

Bug: v8:9972
Change-Id: Ic1d18586c92536575c9bf4e7b3d2758b44acab30
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1954389
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65489}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/2da4a4a..471c567

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/b119e4e..0124932

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/ba4699f..5e2debe

Rolling v8/third_party/fuchsia-sdk: https://chromium.googlesource.com/chromium/src/third_party/fuchsia-sdk/+log/4225f68..9a6352a

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/a9190d6..cd8fb02

TBR=machenbach@chromium.org,tmrts@chromium.org

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

This change implements support for reading and writing bitfields from
Torque code, and adds a couple of unit tests for this functionality. As
Tobias suggested, the LocationReference for a bitfield access contains
a nested LocationReference to where the bitfield struct is stored, so
that store operations can read the original value, update part of it,
and write it back.

Bug: v8:7793
Change-Id: I1004a5c7fcb6cf58df5ad50109b114bf89c80efc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1957841
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65487}

Add a --max-serializer-nesting flag which defaults to 25.

Fixed: chromium:1034768
Change-Id: Ib68f26ce4bf53db297b25d16a046d275beaec642
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969895
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65486}

Change-Id: I2de7128210313e40d3c310edd72658180f1ee110
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1968165Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#65485}

This is a reland of 83786cb4

Original change's description:
> Delay setting up deserialized JSArrayBuffer
>
> Setting up JSArrayBuffer may trigger GC. Delay this until we
> are done with deserialization.
>
> R=ulan@chromium.org
>
> Bug: chromium:1033395
> Change-Id: I6c79bc47421bc2662dc1906534fc8e820c351ced
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1965580
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65441}

Tbr: yangguo@chromium.org
Bug: chromium:1033395, chromium:1034059
Change-Id: I89d05768f52a480400d9c6f5aaaa233c5d5ba126
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969896
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65484}

This reverts commit 53308bf7.

Reason for revert: Fails on multiple arm bots, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/12441

Original change's description:
> [csa] use JSGraph to create constants in CodeAssembler
> 
> Now that CodeAssembler uses optimizing TurboFan passes, creating
> constants without using the caching implemented in JSGraph leads to
> problems, since value numbering only works properly if all constants
> in the graph were introduced through the cache.
> To mitigate this, this CL creates the JSGraph earlier so that
> CodeAssembler can already use the same JSGraph used by later TurboFan
> optimizations.
> For other uses of RawMachineAssembler, everything stays as before.
> 
> This issue is creating bot failures in
> https://chromium-review.googlesource.com/c/v8/v8/+/1958011
> 
> Change-Id: Ife017876b19cb2602694279ef1da75f23e18a031
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967329
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65477}

TBR=tebbi@chromium.org,mslekova@chromium.org

Change-Id: I6df6782adfb40632f51681942efab9b591f72cab
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969901Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65483}

MSVC wants the static cast, even if the constant fits in the narrower
type anyway.

R=ahaas@chromium.org

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

For out-of-line code, we need to generate the debug side table
information at the point where the out-of-line code is being triggered,
not when it is emitted (at the end of the function).

This CL also adds more tests to check the actual content of the debug
side table in different scenarios.

R=jkummerow@chromium.org

Bug: v8:10019
Change-Id: I7714c86ee7edc4918b5ecc97cbded84c27b00e09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967388Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65481}

This adds heuristics to perform young and full GCs on allocation
of external ArrayBuffer backing stores.

Young GCs are performed proactively based on the external backing
store bytes for the young generation. Full GCs are performed only
if the allocation fails. Subsequent CLs will add heuristics to
start incremental full GCs based on the external backing store bytes.

This will allow us to remove AdjustAmountOfExternalMemory for
ArrayBuffers.

Bug: v8:9701, chromium:1008938
Change-Id: I0e8688f582989518926c38260b5cf14e2ca93f84
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803614
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65480}

Bug: chromium:1034203
Change-Id: I225fa6416d443802b063e149da6e6fca0a176bb1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969898
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65479}

This is a reland of 5f5b4b04

Original change's description:
> Support Intel VTune ITT API
> 
> Add VTune domain support extension to use VTune Domain/Task API and
> tagging trace data for particular JS code block.
> 
> How to use:
> 1. Set `"checkout_ittapi" = True` in the custom_vars section of .gclient
> file to download intel/ittapi by 'gclient sync'
> 2. Build d8 with gn build flag 'v8_enable_vtunetracemark = true'
> 3. Run d8 with flag '--enable-vtune-domain-support'
> 
> The Vtune Domain/Task API can be invoked from JS to mark JS code block.
> You can mark the start of a JS task by
>     vtunedomainmark(domain_name, task_name, "start")
> and the end of a task by
>     vtunedomainmark(domain_name, task_name, "end")
> Tasks can nest.
> 
> The VTune API (ittapi) is integrated as an external third party library
> while the v8_vtune_jit also relies on the VTune ittapi. We have another
> patch almost ready which refactors the v8_vtune_jit related code to
> depend on the third_party/ittapi. We will submit the refactored v8_vtune_jit
> code after this patch stabilized and landed.
> 
> 
> Contributed by fanchen.kong@intel.com
> 
> Change-Id: I0ecc9dd4e1ea52545f1b6932fcdadfa7c1a6d2b2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938490
> Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65409}

Change-Id: I563aa70fa2b8abe34c981af47aa7220cfc2a7edb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1963511
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65478}

Now that CodeAssembler uses optimizing TurboFan passes, creating
constants without using the caching implemented in JSGraph leads to
problems, since value numbering only works properly if all constants
in the graph were introduced through the cache.
To mitigate this, this CL creates the JSGraph earlier so that
CodeAssembler can already use the same JSGraph used by later TurboFan
optimizations.
For other uses of RawMachineAssembler, everything stays as before.

This issue is creating bot failures in
https://chromium-review.googlesource.com/c/v8/v8/+/1958011

Change-Id: Ife017876b19cb2602694279ef1da75f23e18a031
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967329Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65477}

If --perf-prof is specified, we commit the whole code range at once, and
never update the {total_committed_code_space_} counter (see
{WasmCodeManager::Commit} and {WasmCodeManager::Decommit}). Hence we
should also not decrement that counter when the native module dies.

R=jkummerow@chromium.org

Bug: chromium:1032753
Change-Id: I9a40f1a1322485d7142ed56f5c9365305aa0e056
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969790Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65476}

Since RecordStats during GC, (when it fails to recover enough memory),
it unsafe for it to allocate any memory. Thus it cannot call PrintStack
which can call SharedFunctionInfo::EnsureSourcePositionsAvailable and
which may allocate, so this removes the call to PrintStack which is
apparently not useful for debugging anyway.

Bug: chromium:1032087
Change-Id: I94feeaab1445f7fd4f770a20197546fc40c77390
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967377Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65475}

Objects in arrays take the shape of the object right before as feedback to
speed up object creation. If a subsequent object with the same shape has a
member that also has the same shape, that member can cause the feedback map to
be deprecated. To avoid confusion, we now update (dedeprecate) the feedback map
before use.

Thanks a bunch Seth Brenith for figuring out the issue!

Bug: chromium:1029077
Change-Id: I047b1acfd4906616a2302f253ab9cd29272bdc79
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1970211
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65474}

port 0f8769df https://crrev.com/c/1967379

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

In this test we expect that the feedback vector is not flushed
so we retain what we have learnt from the earlier executions. If we
flush the earlier feedback the code might deoptimize again and the test
fails. Hence adding --no-stress-flush-bytecode and --no-flush-bytecode
flags.

Bug: v8:10035
Change-Id: Ia71748e83d64a731f595fed7f5b85a8dafa2b31a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969850
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65472}

Add pointer-sized field extension to the JSArrayBuffer class. Only
reserve space for this field when feature is enabled for now.

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

MapRef::GetStrongValue now returns an Optional to account for the case
where we can't figure out the name of the bound function during
serialization. We could reach out to the heap in the future in this
case.

Fixed: chromium:1034203
Change-Id: I9fa81921b5dbd8bc9f68aa3c10921bc01b695a6b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967386Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65470}

Add an API on Isolate that returns a sorted vector of code pages allocated
within V8. The implementation is designed to be signal-safe, so that the
user (the UMA sampling profiler) can access this information from a signal
handler, where allocation and taking locks is prohibited.

This CL adds the machinery for maintaining the list of allocated code
pages. Further CLs will modify the Unwinder API itself to accept the code
pages provided by this API.

The unwinder API currently uses the reserved virtual-memory range called
the CodeRange to identify where all V8 code objects live, but this doesn't
exist on arm32 or any 32-bit platform, so this approach adds a way to
expose the location of all valid V8 code objects in a signal-safe way for
use by the UMA sampling profiler.

On 64-bit, this API always gives the code_range and embedded_code_range, and
does not maintain a vector of code pages. This is so that we have a unified
API on 32 and 64-bit that can be used in exactly the same way by embedders.

Design doc:
https://docs.google.com/document/d/1VGwUult5AHLRk658VetwEHMOmDDxA2eDQs9lDFMZTE0

Bug: v8:8116
Change-Id: I732509a45121fc54853182481c24d1083275afce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564068
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65469}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/03d0c36..2da4a4a

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/69337c3..b119e4e

TBR=machenbach@chromium.org,tmrts@chromium.org

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

Liftoff supports unfixed stack slot sizes now, so we can have
SlotSizeForType return different values based on the value type it is
spilling. We make the change for architectures that support unaligned
access, x64, ia32, arm64.

Note for ppc/s390/mips/mips64 ports: SlotSizeForType remains as 8 byte
(old behavior), but can be changed.

This patch also makes adjustments to PatchPrepareStackFrame to align sp
to appropriate values (pointer size).

Bug: v8:9909
Change-Id: Iddd2dcd652b162a04a02ed704c5b06f6af8a186d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1956165
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65467}

Port 0f8769df

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

Change-Id: Ica16f208f429d637faef14942d31ed66527b3dab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969064Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#65466}

Bug: v8:9838
Change-Id: I9cfa7af623af3b387962ea4fa90cfc599612f976
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958961Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65465}

Change-Id: I0657847fd58d9dc08e5bbdc37c6c0dcc9527e5eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967378
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65464}

The {cmp} instruction might add an entry to the constant pool at a time
where we didn't expect any entries to be added.
This can be fixed by moving the {CheckConstPool} call *after* the {cmp}.

R=mslekova@chromium.org

Bug: chromium:1034394
Change-Id: If075ad0b02e2973a734d70d9e58c205bd14e6a33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967380Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65463}

This is in preparation to hold on to unregister tokens weakly. The key
map will be changed to be keyed off the tokens' identity hash instead of
the token objects themselves. Once changed, a WeakCell's key (its
token's hash) will be different from its unregister token. In
particular, in case of collision, WeakCells with different unregister
tokens may have the same key.

Bug: v8:8179
Change-Id: Ifa18ace915265340db7f01431161a6e0425f2927
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1968958
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65462}

Bug: v8:9838
Change-Id: I4111e17515d5f2b440e30d08582174047be4b92b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1957761Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65461}

Some test cases stress all global functions and hang when calling
readline.

No-Try: true
Bug: chromium:1034285
Change-Id: I0eaf64437c0806cf3df0a5306aecea4367763cad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967381
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65460}

R=ecmziegler@chromium.org

Bug: v8:10063
Change-Id: I2c962e4c91578dd82ff40df1b2b69aeee7dbbf18
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967379Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65459}

Add a lock to prevent races between {WasmImportWrapperCache::Get} and
the cache modification scope.

R=clemensb@chromium.org

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

If you are not using them too often, their relationship and meaning is
not totally obvious. Especially that {kTaggedSigned} means "uncompressed
Smi" cannot be inferred from the name.

R=neis@chromium.org

Bug: v8:10021
Change-Id: If684b87ba24da0bbce846d4e35a790c2ee96116b
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967374Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65457}

PrototypeUsers::Add now iterates the WeakArrayList to find empty slots
before growing the array. Not reusing empty slots caused a memory leak.

It might also be desirable to shrink the WeakArrayList in the future.
Right now it is only compacted when invoking CreateBlob.

Also removed unused PrototypeUsers::IsEmptySlot declaration.

Bug: v8:10031
Change-Id: I570ec78fca37e8f0c794f1f40846a4daab47c225
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967317Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65456}

This makes it obvious that methods are actually macros.
Also, in the future, we might allow methods that are actually builtins.

Bug: v8:7793
Change-Id: Ib641c4b5a222b27c67aa0c31fd3611ed4a11842c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967330Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65455}

This is a reland of c924f54e

Reason: Added back a bitcast that was supposed to be redundant (but it
wasn't)

Changes can be seen from patchets 1..3.

Original change's description:
> [turbofan][ptr-compr] Remove redundant ChangeTaggedToCompressed
>
> The final goal is to eliminate it altogether. This CL just
> eliminate the redundant ones.
>
> Bug: v8:7703
> Change-Id: If6e718c373fca7c65ce46c347533ec4550fbc444
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1950968
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65398}

Bug: v8:7703
Change-Id: I099e67d0255d4ad5529a73b272df893069374136
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1965582Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65454}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/9caeb8b..03d0c36

TBR=machenbach@chromium.org,tmrts@chromium.org

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/1c5a738..9caeb8b

Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/6b3e658..fa02977

Rolling v8/buildtools/linux64: git_revision:ad9e442d92dcd9ee73a557428cfc336b55cbd533..git_revision:6feb55993083dfd27b93da195c8a82a3a9529848

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/b34e896..69337c3

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/f1ad6e4..ba4699f

TBR=machenbach@chromium.org,tmrts@chromium.org

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