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/+/2381557
Reviewed-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/+/2381459
Reviewed-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}
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/+/2387561
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69639}
This reverts commit dfb3f7daa5.
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/+/2387570
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69638}
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/+/2387562
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69633}
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/+/2381454
Reviewed-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}
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/+/2381941
Reviewed-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/+/2385855
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69626}
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/+/2379535
Reviewed-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/+/2377108
Reviewed-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}
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/+/2384770
Reviewed-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/+/2381458
Reviewed-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}
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}
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/+/2380710
Reviewed-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/+/2376810
Reviewed-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/+/2379861
Reviewed-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/+/2376811
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69608}
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}
This is the first step in a series of CLs. The goal is to make
super property access faster.
Design doc: https://docs.google.com/document/d/1b_wgtExmJDLb8206jpJol-g4vJAxPs1XjEx95hwRboI/edit?usp=sharing
This CL:
- Add bytecode LdaNamedPropertyFromSuper
- IGNITION_HANDLER just calls Runtime::LoadFromSuper
- JSGenericLowering::LowerJSLoadNamedFromSuper just replaces the node
with a runtime call to Runtime::LoadFromSuper
Bug: v8:9237
Change-Id: Id28e935294c5068dd6c54e6b860a77d61517fff5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2327912
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69604}
Explicit nullification aims to simplify migration to Oilpan, in the
case when unique_ptrs are converted to Member and user code relies on
source pointers to be in "empty" state.
Change-Id: Ia54137d53ca03f93932b3c1f2eaba439a416a06e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379857
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69603}
Schedule is simpler compared to the schedule in blink since it now
returns deadlines based on marked bytes instead of time.
If marking is ahead of schedule, return the minimum step size.
Otherwise, set step size to catch up to schedule (ignoring the time
passed while performing the step).
No more default initial step size (needed in blink since marking speed
was unknown).
If estimated schedule is exceeded (marking takes longer than 500ms), the
steps will try to mark all remaining objects but would still be capped
by the maximum step duration of 2ms.
Bug: chromium:1056170
Change-Id: I09857db161c621a12d064f9c8c21b646c34f9d71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375200
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69602}
Starting marking required Creating a Marker and calling StartMarking.
StartMarking should always have been called immediately after creating
the marker.
Since markers are not persisted between GC (a marker exists only while
marking is in progress), it makes sense to start marking implicitly when
a marker is created.
Calling StartMarking in MarkerBase ctor is inadvisable since subclasses
might still to initialize fields.
Using MarkerFactory instead guarantees that StartMarking is always
called immediately after creating a Marker.
Bug: chromium:1056170
Change-Id: Icbf11afd848e1618c204ca6bf951600b3ae9fef2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375199
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69601}
Changes:
* Transition edges on timeline-track with the same color of the map type.
* Log file reader loading background adapted to light theme.
* Support additional IC log event colors.
* Move theme switch button to top of the app.
Bug: v8:10644, v8:10673
Change-Id: Ib086b6f4a8bc5f86a4925b251112c640e37278ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379869
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Cr-Commit-Position: refs/heads/master@{#69600}
Bug fixes:
* Wrong time range selection of timeline chunks handled by mouse events.
* Consecutive file uploads does not create a new Model object causing
bugs on timeline-track start and end times.
Bug: v8:10644
Change-Id: I3d31ddda1ffca70c18c87dd103f2b788713c2911
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379863
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Cr-Commit-Position: refs/heads/master@{#69598}
This reverts commit 9eb090d261.
Reason for revert: breaks trybot android-pie-arm64-dbg, repro steps: build cctest with target_cpu="arm64" in the args.
See thread:
https://chromium.slack.com/archives/CGJ5WKRUH/p1598563610118900
Original change's description:
> [heap] Add concurrent typed slot recording
>
> Since the typed slot set is not thread-safe, each concurrent marking
> barrier collects typed slots locally and publishes them to the main
> typed slot set in safepoints.
> Bug: v8:10315
>
> Change-Id: If1f5c5df786df88aac7bc27088afe91a4173c826
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2370302
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69576}
TBR=ulan@chromium.org,dinfuehr@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:10315
Change-Id: Iade0443e5eccef06e3ea77913e18fd1f563995f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380613
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69597}
