The handle was always created empty which resulted in a DCHECK crash
in debug builds and in never-cancelled tasks in release builds.

Bug: chromium:1056170
Change-Id: I798ce65c37738bbe9c60b44b692ff04536f6d830
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2388101Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69653}

Fuzzers use a slight variant of the sse4_1 flag, see
https://source.chromium.org/chromium/chromium/src/+/master:v8/tools/testrunner/testproc/fuzzer.py;l=26;drc=9491d5eaa4e764721b5269e75af68f181bef09cf.

Bug: v8:10863
Change-Id: Ifc467644f00a4f10776794c12a227f13774f48ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387555Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69652}

There were some +/- infs hidden in that list of NaNs (and those were
repeated too). Add a NaN with top bit of payload unset. This will help
catch cases where we did not canonicalize results properly.

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

Marked GetStackFrameId V8_DEPRECATED

Bug: v8:10566
Change-Id: I2e225eae7d0375cff7b9f79e4c38802265940219
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352475
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69650}

Allows reflection of v8::Data types, such as being able to check if a
value is a v8::Module. This is useful for libraries which wrap the V8
API, such as rusty_v8.

Change-Id: I4841c5f7f60885b20e1504c8562e278844ff7ec3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2382719Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Gus Caplan <snek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69649}

With a recent change, we require WebAssembly code to be tiered up to
serialize it, see https://crrev.com/c/2349290. In that CL tests were
adjusted to set the --wasm-tier-up flag when serialization was involved.
However, the test adjusted in this CL was missing, because this test
used the kExprRefNull instruction, which caused a bailout to TurboFan
anyways. With recent changes, Liftoff can compile kExprRefNull now,
and therefore causes problems.

R=thibaudm@chromium.org

Bug: v8:10852
Change-Id: I9b89f37c22f17cbf046110f3ee1c98bfea73e009
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387574Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69648}

This adds a global counter for the various reasons we might fail to
attribute a tick.

The counters are cleared and printed when Profile::Print() is called,
which we call in our tests, so flaky test output will now contain these
stats along with the printed profile tree.

Drive-by cleanup some print functions and make them const.

Change-Id: Ia3a27405f5b5346adfdbb32afc7e414857969cc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1550406
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69647}

I previously wrote a comment that said "We haven't seen any indication
of performance improvements from seeking optimal spilling positions
except on loop-top phi values". That statement is no longer true, now
that I've looked a little harder. In the latest version of the Mono
interpreter, we can improve performance by 2.5% by enabling SpillPlacer
for any value defined within a loop.

Bug: v8:10606
Change-Id: I25e06458c87ad4ffcefe52be3042032e05a47b35
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381557Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#69646}

The generic wrapper can be used for Wasm functions with int32 parameters
and no return values.

Changed the GC scanning for the generic wrapper.

Added tests for cases when all the parameters of the Wasm function fit
into registers and when some of the parameters are on the top of the
stack.

Change-Id: I511fd04d2a4a2bdc4a6f72d72e2867a03b256f6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381459Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Eva Herencsárová <evih@google.com>
Cr-Commit-Position: refs/heads/master@{#69645}

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}