When enabled with the v8_enable_conservative_stack_scanning flag, a
snapshot of the call stack upon entry to GC is used to determine part of
the root-set. When the collector walks the stack, it looks at each value
and determines whether it could be a potential on-heap object pointer.

This is very experimental. For conservative stack scanning to work,
direct handles must be implemented.

Bug: v8:10614
Change-Id: Id4209cfbe76ef02239c903fabcb7f677b32fc977
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375201
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69644}

The fuzzer function is called multiple times with libfuzzer. Trap
handlers, however, should only be initialized once. With this CL we add
a flag to initialize trap handlers only once.

R=clemensb@chromium.org

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

Unify the encoding/decoding of values into a ranged bytecode with a
single templated class that takes the bytecode, minimum, and maximum,
and provides Encode and Decode methods.

This class also handles range checks on both the input and output,
which (along with a few other byte cases) allows us to get rid of the
PutSection method.

Change-Id: Icb2cd409607ce7b650226eb8dca80c0e363a8acc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2369172
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69642}

This fixes the Android Arm perf build after https://crrev.com/c/2365216

TBR=machenbach@chromium.org

Fix: v8:10867
Change-Id: Ic67c0d8b6334179356a6662a352039e445f92389
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387572
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69641}

Change-Id: Ica6b886ca0b16ab6eb86f3a90c598a0801230648
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2385918Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69640}

If multiple recompilations are triggered at the same time, we cannot
contribute to compilation, because this would bump the number of workers
above the maximum expected concurrency.

This is a quick fix, a better (but more involved) fix would be to make
the number of queues grow dynamically.

R=thibaudm@chromium.org

Bug: chromium:1123471

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

This reverts commit dfb3f7da.

Reason for revert: Breaks LSAN & ASAN flakily: https://bugs.chromium.org/p/v8/issues/detail?id=10861

Original change's description:
> [cpu-profiler] Ensure sampled thread has Isolate lock under Windows
> 
> While the sampler checked if the sampled thread had the Isolate locked
> (if locks are being used) under Linux, the check was not done under
> Windows (or Fuchsia) which meant that in a multi-threading application
> under Windows, thread locking was not checked making it prone to seg
> faults and the like as the profiler would be extracting info from a
> heap in motion. The fix was to move the lock check into CpuSampler
> and Ticker (--prof) so all OSes would do the correct check.
> 
> The basic concept is that on all operating systems a CpuProfiler, and
> so its corresponding CpuCampler, the profiler is tied to a thread.
> This is not based on first principles or anything, it's simply the
> way it works in V8, though it is a useful conceit as it makes
> visualization and interpretation of profile data much easier.
> 
> To collect a sample on a thread associated with a profiler the thread
> must be stopped for obvious reasons -- walking the stack of a running
> thread is a formula for disaster. The mechanism for stopping a thread
> is OS-specific and is done in sample.cc. There are currently three
> basic approaches, one for Linux/Unix variants, one for Windows and one
> for Fuchsia. The approaches vary as to which thread actually collects
> the sample -- under Linux the sample is actually collected on the
> (interrupted) sampled thread whereas under Fuchsia/Windows it's on
> a separate thread.
> 
> However, in a multi-threaded environment (where Locker is used), it's
> not sufficient for the sampled thread to be stopped. Because the stack
> walk involves looking in the Isolate heap, no other thread can be
> messing with the heap while the sample is collected. The only ways to
> ensure this would be to either stop all threads whenever collecting a
> sample, or to ensure that the thread being sampled holds the Isolate
> lock so prevents other threads from messing with the heap. While there
> might be something to be said for the "stop all threads" approach, the
> current approach in V8 is to only stop the sampled thread so, if in a
> multi-threaded environment, the profiler must check if the thread being
> sampled holds the Isolate lock.
> 
> Since this check must be done, independent of which thread the sample
> is being collected on (since it varies from OS to OS), the approach is
> to save the thread id of the thread to be profiled/sampled when the
> CpuSampler is instantiated (on all OSes it is instantiated on the
> sampled thread) and then check that thread id against the Isolate lock
> holder thread id before collecting a sample. If it matches, we know
> sample.cc has stop the sampled thread, one way or another, and we know
> that no other thread can mess with the heap (since the stopped thread
> holds the Isolate lock) so it's safe to walk the stack and collect data
> from the heap so the sample can be taken. It it doesn't match, we can't
> safely collect the sample so we don't.
> 
> Bug: v8:10850
> Change-Id: Iab2493130b9328430d7e5f5d3cf90ad6d10b1892
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377108
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69623}

TBR=akodat@rocketsoftware.com,petermarshall@chromium.org,petermarshall@google.com

Change-Id: Ib6b6dc4ce109d5aa4e504fa7c9769f5cd95ddd0c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10850
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387570Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69638}

Bug: v8:10765
Change-Id: I49e425d861d900ab66b6f7801cddec8a7175ac03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2385462
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69637}

Change the serialization protocol to ensure that maps are serialized
before objects using them. This ensures that as soon as we allocate
space for an object, we can immediately write the object's map into that
allocation. In the future, this will allow us to make deserialized
object visible to the GC.

Specifically, this forces map serialization to happen after emitting
a kNewObject for an object, but before allocating the space for it. We
have to serialize the map after kNewObject because otherwise the map
itself would be written into the "current" slot, into which the object
is supposed to be deserialized.

Objects whose maps are currently being deserialized are considered
"pending" -- started, but not yet allocated. The map might point to a
pending object (e.g. if an object's constructor points to the object).
This is solved by introducing a new concept of forward references, where
the field referring to the pending object is serialized as a "pending
forward reference" which is "resolved" once the object is allocated.

It might also point to itself, in the case of the meta map -- this is
simply solved by introducing a new bytecode for the meta map; this
cannot be a pending forward reference because the meta map is not yet
allocated, so its map slot cannot be registered as pending.

Finally, we may need to go to a new chunk after serializing the map; so
after the map serialization, we peek to see if there's a next chunk
bytecode before the object allocation.

Bug: v8:10815
Change-Id: Ifa8f25bdaf3b15b5d990a1d2e7be677c2fa80013
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362953
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69636}

Rewrite the deserializer case macros to look, to formatters, more like
a single case value, and clean up some of the repetition to be more
explicit, e.g. replace

  SIXTEEN_CASES(kFoo)
    impl()

with

  case CASE_REPEAT(kFoo, 16):
    impl()

This should help with auto-formatting issues when modifying the big
deserializer switch statement.

As a drive-by, also clean up the per-space case macros to use a
function rather than a macro for specifying the bytecode, and add
helpers for encoding fixed raw data size in the bytecode (similar to
the existing helper for fixed repeat counts).

Change-Id: I885ba79afef03b95ad64cd78bdfba5dffc82be1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2367853
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69635}

Mostly a cleanup for x64.

Also enable two tests for Arm and Arm64 since they do not make use of
JSEntry frames.

Bug: v8:10833
Change-Id: Id6adadf582bdca0076460842ffe4ec856ca99393
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381455
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69634}

{std::atomic} is being used in the header without including the <atomic>
header. It was reported on the v8-users list that this causes compile
errors on Windows.

R=ulan@chromium.org

Change-Id: I1de19c301ce47787628416bf0e744d0dd7507fa3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387562Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69633}

This is a reland of c6d3516f

Original change's description:
> [Intl] Ship Intl.Segmenter
> 
> Spec: https://tc39.es/proposal-intl-segmenter/
> ECMA402 site: https://github.com/tc39/proposal-intl-segmenter
> I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/MJ1OpvkcA8s/m/mYNxpwqSCAAJ
> I2I: https://groups.google.com/a/chromium.org/g/blink-dev/c/muRQBwyzzPw/m/rB_2I9t0CQAJ
> Design Doc: https://docs.google.com/document/d/1xugLpLmgRFnNXK8ztariTAbD2IXueDw1T3VNuuZCz8k/edit
> CPS: https://www.chromestatus.com/feature/6099397733515264
> Test262 Tests: https://github.com/tc39/test262/tree/main/test/intl402/Segmenter
> v8 tests: https://source.chromium.org/chromium/chromium/src/+/master:v8/test/intl/segmenter/?q=test%2Fintl%2Fsegmenter&ss=chromium
> 
> Approved by API Owners: yoav@yoav.ws / chrishtr@chromium.org / bratell.d@gmail.com
> 
> Bug: v8:6891
> Change-Id: I64775ed63557a9e1af77560abd42349742bc4c03
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376967
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69593}

Bug: v8:6891
Change-Id: I0908c859ce4c7875860f5839a2548b55daea3c89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380440
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69632}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/2dbf41f..482dd77

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/77fb6d1..1eb42f5

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/c73782c..ed15af5

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/89d15db..fcef86e

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

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

Heap growing estimates when to start  incremental gc such that it
will finish when we are expecting to finalize (i.e. when an atomic
gc would be triggered).
There is also a minimum ratio between limit for atomic gc and limit
for incremental gc, to guarantee that incremental gc get's some time to
run even with the application rarely allocates.

This is a continuation of:
https://chromium-review.googlesource.com/c/v8/v8/+/2377691

Bug: chromium:1056170
Change-Id: I8c87e98d60b6f8b5748558771a236f15385f7858
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381454Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69630}

Port 524fa743

Original Commit Message:

    This regression test does not work on MIPS without SIMD since the scalar
    lowering is not complete yet. Skip it for now.

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

Change-Id: I0338593de3160dc0864c066e607b6030956e3efa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2386141Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#69629}

Incrementing coverage counter was triggering EvalError for
evaluateOnCallFrame when throwOnSideEffect is true.

R=jgruber@chromium.org, sigurds@chromium.org, yangguo@chromium.org

Bug: v8:10856
Change-Id: I0552e19a3a14ff61a9cb626494fb4a21979d535e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384011
Commit-Queue: Benjamin Coe <bencoe@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69628}

When running 64-bit Windows binaries on macOS using Wine, there is a
conflict between macOS's use of GS to point to pthread thread-specific
data, and Windows' use of GS to point to the TEB.

Apple has reserved some TSD slots for use by Wine to store commonly-used
TEB members (such as 0x30, the 'Self' pointer to the TEB).
But, other direct GS accesses by Windows programs (such as to
'StackBase') will return macOS pthread data rather than the TEB member.
This was causing a V8 unit test to crash on macOS under Wine.

Using NtCurrentTeb() gets the 'Self' pointer first, then dereferences
it to access the correct 'StackBase', fixing the crash.
This turns GetStackStart() from one instruction into two.

Chrome (http://crrev.com/c/2380425) and Crashpad also use
NtCurrentTeb().

The 32-bit change isn't needed, but is just for consistency.

Bug: chromium:1121842
Change-Id: I824f893aa451d8570142226be91840c964426f38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381941Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69627}

This regression test does not work on MIPS without SIMD since the scalar
lowering is not complete yet. Skip it for now.

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

v8/test/cctest/interpreter/test-bytecode-generator.cc contains lots of string arrays with intentional concatenation.

Bug: chromium:1114873
Change-Id: Ie9d35c3849b5b0a6d1d01b6ce21fb80a320d8736
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2366829
Commit-Queue: Arthur Eubanks <aeubanks@google.com>
Reviewed-by: Sathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69625}

By eager compile all functions in the startup snapshot, the startup
snapshot can contain all function codes without warm-up.

BUG=v8:4836
R=yangguo@chromium.org

Change-Id: I07e86b6940c2fe75816df8ae429d110272216d0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379535Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69624}

While the sampler checked if the sampled thread had the Isolate locked
(if locks are being used) under Linux, the check was not done under
Windows (or Fuchsia) which meant that in a multi-threading application
under Windows, thread locking was not checked making it prone to seg
faults and the like as the profiler would be extracting info from a
heap in motion. The fix was to move the lock check into CpuSampler
and Ticker (--prof) so all OSes would do the correct check.

The basic concept is that on all operating systems a CpuProfiler, and
so its corresponding CpuCampler, the profiler is tied to a thread.
This is not based on first principles or anything, it's simply the
way it works in V8, though it is a useful conceit as it makes
visualization and interpretation of profile data much easier.

To collect a sample on a thread associated with a profiler the thread
must be stopped for obvious reasons -- walking the stack of a running
thread is a formula for disaster. The mechanism for stopping a thread
is OS-specific and is done in sample.cc. There are currently three
basic approaches, one for Linux/Unix variants, one for Windows and one
for Fuchsia. The approaches vary as to which thread actually collects
the sample -- under Linux the sample is actually collected on the
(interrupted) sampled thread whereas under Fuchsia/Windows it's on
a separate thread.

However, in a multi-threaded environment (where Locker is used), it's
not sufficient for the sampled thread to be stopped. Because the stack
walk involves looking in the Isolate heap, no other thread can be
messing with the heap while the sample is collected. The only ways to
ensure this would be to either stop all threads whenever collecting a
sample, or to ensure that the thread being sampled holds the Isolate
lock so prevents other threads from messing with the heap. While there
might be something to be said for the "stop all threads" approach, the
current approach in V8 is to only stop the sampled thread so, if in a
multi-threaded environment, the profiler must check if the thread being
sampled holds the Isolate lock.

Since this check must be done, independent of which thread the sample
is being collected on (since it varies from OS to OS), the approach is
to save the thread id of the thread to be profiled/sampled when the
CpuSampler is instantiated (on all OSes it is instantiated on the
sampled thread) and then check that thread id against the Isolate lock
holder thread id before collecting a sample. If it matches, we know
sample.cc has stop the sampled thread, one way or another, and we know
that no other thread can mess with the heap (since the stopped thread
holds the Isolate lock) so it's safe to walk the stack and collect data
from the heap so the sample can be taken. It it doesn't match, we can't
safely collect the sample so we don't.

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

PerformCheckCast<Data>() itself should not invoke Data::Cast(), since
there is no such method and every publicly available value can be
casted to it anyway. This is an issue in e.g.
GetDataFromSnapshotOnce<Data>().

Change-Id: I5d9ee89657c31bc0ca1fb16e704df58911c85f6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2383030
Commit-Queue: Gus Caplan <snek@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69622}

This CL adds support for disjunctions and some quantification in
EXPERIMENTAL regexp patterns. It is implemented using a new bytecode
format and an NFA-based breadth-first interpreter.

R=jgruber@chromium.org

Bug: v8:10765
Change-Id: Idd49a3bbc9a9fcc2be80d822c9d84a638e53e777
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2370634
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69621}

Bug: chromium:1120729
Change-Id: I27533a2426a63ec6b67d34d94f3cae554fc95d91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379852
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69620}

The graph assembler calls MergeControlToEnd as part of Unreachable
node creation; this causes issues when used inside the GraphReducer
framework, since the reducer is not notified by gasm that the end node
should be revisited.

The (hacky) fix in this CL is to always mark the end node for
revisitation after a gasm reduction has taken place.

Bug: v8:8888,chromium:1123379
Change-Id: I350bb7144add04a0c3fd7f3d88c07fcfe1cd42e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384772
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69619}

The goal is to have one graph per test case, and inside the graph,
4 different lines:
- baseline
- baseline noopt
- super-ic
- super-ic noopt

Bug: v8:9237
Change-Id: I511b5555487a3d96698a3fb648abf76a13f76858
No-Try: True
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384770Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69618}

A recent unrelated change caused these tests to get unlucky in
GC stress mode. Their "assertOptimized" expectations rely on
certain type feedback data not getting flushed at the wrong time.

Bug: v8:10846
Change-Id: I86d0b0c049539e4a69aa764cc6ec92465ca12beb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381458Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69617}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/0efd610..2dbf41f

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/6c48487..c73782c

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

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

With conservative stack scanning enabled, a snapshot of the call stack
upon entry to GC will be used to determine part of the root-set. When
the collector walks the stack, it looks at each value and determines
whether it could be a potential on-heap object pointer. However, unlike
with Handles, these on-stack pointers aren't guaranteed to point to the
start of the object: the compiler may decide hide these pointers, and
create interior pointers in C++ frames which the GC doesn't know about.

The solution to this is to include an object start bitmap in the header
of each page. Each bit in the bitmap represents a word in the page
payload which is set when an object is allocated. This means that when
the collector finds an arbitrary potential pointer into the page, it can
walk backwards through the bitmap until it finds the relevant object's
base pointer. To prevent the bitmap becoming stale after compaction, it
is rebuilt during object sweeping.

This is experimental, and currently only works with inline allocation
disabled, and single generational collection.

Bug: v8:10614
Change-Id: I28ebd9562f58f335f8b3c2d1189cdf39feaa1f52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375195
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69615}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/f9767b5..0efd610

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/ffb1227..6c48487

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/b64a74c..89d15db

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

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

For SIMD instructions that use aligned moves (like movaps or movapd), we
don't have correct memory alignment for SIMD moves yet. Switch to to
movupd.

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

This allows tests to be skipped on nosse41 builds. For SIMD, nosse41 means
that we need to scalar lower all SIMD instructions, which is not fully
implemented yet.

Bug: v8:10831
Change-Id: I27dd2840b376da672237fed764cbd2491c244627
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380710Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69612}

Even though we provide a --wasm-max-code-space flag (defaulting to
{kMaxWasmCodeMB}, we still had checks in place that the actual committed
code space is not bigger than that constant.
This CL fixes that by always comparing against the value of the flag.
This will allow us to specify a code space limit which is larger than
the default. This is useful when debugging larger Wasm apps which exceed
the limit, but are not meant to be shipped that way.

Drive-by: Remove a dead use of the {kMaxWasmCodeMemory} constant.

R=ecmziegler@chromium.org

Bug: chromium:1117033, chromium:1114093, chromium:1107649, chromium:1111266
Change-Id: I2684446230a8a6f0a27ad963dd6f36e5764b25e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376810Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69611}

This CL adds a source code panel to display source code positions of
Map/IC log events.

* Clicking file positions on the Ic Panel emits FocusEvent with
SourcePositionLogEvent as entry to highlight code related with the
selected icLogEvent.

* Clicking map details on the Map Panel emits FocusEvent with
SourcePositionLogEvent as entry to highlight code related with the
selected mapLogEvent.

Bug: v8:10644
Change-Id: Icaf3e9e3f7fae485c50ad685f9ec5dc8ac28b3dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2358734
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Reviewed-by: Sathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69610}

Those globals must have type float instead of int to preserve the sign
bit.

R=ahaas@chromium.org

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

These trace events can be used for triaging profiling issues.
We already have one event if code logging is triggered via an interrupt.
The new events will be emitted if called via the foreground task, or
just directly (e.g. after deserialization).

R=ecmziegler@chromium.org

Change-Id: I67ad9568f38d9a6eb98abf53ce5542ed56170c60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376811Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69608}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/2841b25..f9767b5

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/f9ede33..77fb6d1

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/7d98e22..ffb1227

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

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

LoadICParameters already has separate fields for receiver and holder,
though, in practice, they were always equal. Moreover, the holder didn't
mean holder, but the lookup start object.

This CL makes parts of the IC layer reusable for cases where they are
not equal, by clarifying whether we're accessing the receiver, the
lookup_start_object, or the holder.

List of changes:

StoreICParameters:
- Detached from LoadICParameters, now they are independent classes.

LoadICParameters:
- Renamed holder to lookup_start_object.

TryProbeStubCache:
- Renamed receiver to lookup_start_object.

LoadIC:
LoadIC_BytecodeHandler:
LoadIC_NoFeedback:
KeyedLoadIC:
KeyedLoadICGeneric:
KeyedLoadICPolymorphicName:
- These won't be reused in the receiver != lookup_start_object case,
so added asserts that receiver == lookup_start_object.

TryMonomorphicCase:
HandlePolymorphicCase:
LoadIC_Noninlined:
GenericElementLoad:
- Renamed receiver_map param to lookup_start_object_map. The callers
either assert receiver == lookup_start_object, or read the map from the
lookup start object.

GenericPropertyLoad:
- Renamed receiver param to lookup_start_object.
- Renamed receiver_map param to lookup_start_object_map. The callers
either assert receiver == lookup_start_object, or read the map from the
lookup start object.

CallGetterIfAccessor:
- Added the holder parameter and used it accordingly.


Bug: v8:9237
Change-Id: I27aca08f58bd66cc9bd1b1baf9f1ff5565d795eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362918
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69606}

Bug: v8:10848
Change-Id: Icf014ecd5b0014be258d05aa0f958001f838286b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381450
Auto-Submit: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69605}