This CL adds a mechanism that prevents the RuntimeProfiler from
triggering optimization of a function after
%PrepareFunctionForOptimization has been called. This is useful to
prevent flakiness in tests, as sometimes a function that already
got deoptimized would receive a new code object from a concurrent
compile that was triggered by a heuristic just in the right moment
for the assertUnoptimized test to fail. For example, the following
was happening:
PrepareFunctionForOptimization
[marking `testAdd` for optimized recompilation, reason: small function]
[concurrently compiling method `testAdd` using TurboFan]
[manually marking `testAdd` for non-concurrent optimization]
[synchonously compiling method `testAdd` using TurboFan]
[synchonously optimizing `testAdd` produced code object 0xAAAA - took 1.638 ms]
Runtime_GetOptimizationStatus OPTIMIZED `testAdd` (code object 0xAAAA)
DeoptimizeFunction `testAdd` with Code Object 0xAAAA
[concurrently optimizing `testAdd` produced code object 0xBBBB - took 3.377 ms]
Runtime_GetOptimizationStatus OPTIMIZED `testAdd` (code object 0xBBBB)
Bug: v8:9563
Change-Id: Ia4c846aba95281589317d43b82383e70fe0a35f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763546
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63343}
This reverts commit aba185a713.
Reason for revert: We want to keep this API.
Original change's description:
> [heap] Remove slots when shrinking objects
>
> Immediately remove recorded old-to-new slots when shrinking objects.
> This operation needs to drain the store buffer, however the store buffer
> is supposed to be removed anyway.
>
> Also do not remove slots when left-trimming since this isn't needed for
> correctness.
>
> Bug: v8:9454
> Change-Id: I751baf2dcd03c87aee9cb1ebd168e05bf373a738
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762012
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63271}
TBR=ulan@chromium.org,dinfuehr@chromium.org
Bug: v8:9454
Change-Id: I9524a7448cc49948915fdccc5a6b1aa22e4de4a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762524
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63342}
This reverts commit e66cee7e9e.
Reason for revert: Speculative revert for https://ci.chromium.org/p/chromium/builders/try/linux-rel/173349
Original change's description:
> [debug] only break on entry when immediately called from JS
>
> When we break on function entry, check whether the target function is being
> called from JS after entering V8 through V8's API. We implement this by
> keeping track of the stack height when we enter V8 through the API, and compare
> the caller JS frame's stack height with that.
>
> R=szuend@chromium.org
>
> Bug: chromium:991217, chromium:992406
> Change-Id: I258ad9cef11fe0ef48de6fd5055790792fd0ec0c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762298
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63331}
TBR=yangguo@chromium.org,szuend@chromium.org
Change-Id: I4bfb42f7ce1484807696048a09609f14113d10f4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:991217, chromium:992406
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762525
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63341}
This was deleted in 5b2ab2f6f7, it seems only
the first part of the condition should have been deleted.
This changes (from the embedded builtins):
movz x9, #0x2
cmp x9, x8
Back to:
cmp x8, #0x2
This saves 0.29% in the embedded builtins size for a pointer-compression enabled arm64 build.
Also a minor cleanup by removing the commutative boolean parameter and always commuting the
FlagsContinuation. For a commutative operation the FlagsContinuation will stay the same.
Change-Id: I5bba84a07bb32284b4756bc6293560ee106745f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762522
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/master@{#63337}
Also: add hint for "prototype" property. This makes us not miss
the ObjectCreate map in any of our tests.
Bug: v8:7790
Change-Id: Icc9f91ebaf466a1cdfba27526335b930c744b9c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762519
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63336}
Automated cleanup which finds patterns of `Node* a = foo` where `foo` is
a TNode expression, and replaces Node* with the appropriate TNode.
Bug: v8:9396
Change-Id: I8b0cd9baf10e74d6e2e336eae62eca6cfe6a9c11
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762515
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63335}
Forge (Google3) can only run 64-bit executables. As Torque runs as part
of the build process, we need a 32-bit "cross-compile" mode when
we target 32-bit architectures. Note that this flag won't be needed
in Chromium/V8 land, since we build V8 with the same bit width as
the target architecture.
This CL adds a new runtime flag to torque "-m32". When enabled, the
flag forces 32-bit word sizes for various pointer/word sizes. By
default, the host system sizes from {src/commons/globals.h}
are used.
R=tebbi@chromium.org
Bug: v8:9641
Change-Id: I8701eec45e3fb59dc65049b0a679d34589c4127f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763540
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63334}
This fixes a serious performance regression in Octane2 future variant.
Bug: v8:7790
Change-Id: Ie72d7b8ecf8af12e06a0ecae216cfb456908fe5d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763542
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63333}
Previously, the handler would load the constant field from the holder
everytime by using the descriptor index. Instead, this patch inlines
the constant field directly into the handler.
Change-Id: Ia731811b135897033f4c5dc973031a30f25a64ed
Bug: v8:9616
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1688829
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63332}
When we break on function entry, check whether the target function is being
called from JS after entering V8 through V8's API. We implement this by
keeping track of the stack height when we enter V8 through the API, and compare
the caller JS frame's stack height with that.
R=szuend@chromium.org
Bug: chromium:991217, chromium:992406
Change-Id: I258ad9cef11fe0ef48de6fd5055790792fd0ec0c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762298
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63331}
This is another step towards considering the unoptimized frame size in
stack checks within optimized code.
With the changes in this CL, we now keep track of the maximal
unoptimized frame size of the function that is currently being
compiled. An optimized function may inline multiple unoptimized
functions, so a single optimized frame can deopt to multiple
frames. The real frame size thus differs in different parts of the
optimized function.
We only care about the maximal frame size, which we calculate
conservatively as an over-approximation, and track in
InstructionSelector::max_unoptimized_frame_height_ for now. In future
work, this value will be passed on to codegen, where it will be
applied as an offset to the stack pointer during the stack check.
(The motivation behind this is to avoid stack overflows through deopts,
caused by size differences between optimized and unoptimized frames.)
Note that this offset only ensure that the topmost optimized frame can
deopt without overflowing the stack limit. That's fine, because we only
deopt optimized frames one at a time. Other (non-topmost) frames are
only deoptimized once they are returned to.
Drive-by: Print variable and total frame height in --trace-deopt.
Bug: v8:9534
Change-Id: I821684a9da93bff59c20c8ab226105e7e12d93eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762024
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63330}
We have internal::TickSample which inherits from this, but we never
use the public version in the API despite defining it there.
Change-Id: I6f0ce7ee663ef821be57cfbad540c1660484a525
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745472
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63329}
Implement move ctor and assignment for both, the version that matches T
and the version where T and S are related in the type hierarchy.
Bug: chromium:995684
Change-Id: I21a747d706b224117c398e6feff42cc4ffc4cae8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762296
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63325}
Bug: v8:7790
Change-Id: I02de7cb5b89a20a4eb10407cb1ff56ed3ece098f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762520
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63322}
This CL was reviewed originally in https://crrev.com/c/1518181.
Bug: v8:7741
Change-Id: Iddb139a24c4b9aee6694e20cb5d04e9f9887160c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752859
Auto-Submit: Sven Sauleau <sven@cloudflare.com>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63321}
The LinkageLocation currently consists of two fields, a bit_field and a
machine_type. The existing equality check only checked the equality of
the bit_field, which meant that a FP register location and a GP register
location could alias. I added a static {IsSameLocation} function which
checks that not just the bit_field but also if one of the two locations
at least has a subtype of the other. Note that we do not check for
type-equality because {CanTailCall} checks, which are the main user of
the LinkageLocation equality check, should pass even if the result types
are in a sub-typing relationship.
R=mstarzinger@chromium.org
Bug: v8:9396
Change-Id: Iaa2d11311d0c18e8ffc1dd934e369106ab2456a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763533
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63319}
This CL implements the nullish operator in bytecode as defined by:
https://github.com/tc39/proposal-nullish-coalescing. It can be
enabled by passing '--harmony-nullish'.
Nullish is similar to logical operators, but instead of truthy/falsey
values, it short circuits when it evaluates a null or undefined value.
Bug: v8:9547
Change-Id: Ia0f55877fc2714482b5547942baef9733537d1b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738568
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63317}
This CL consists of several preparatory steps for slices in Torque. Above all, it introduces a user-defined struct, torque_internal::Slice<T>, that performs bounds checking and returns references to elements in arrays. To enable this, several smaller changes were also made:
- Constructors of internal classes such as torque_internal::Reference<T> now require a special 'Unsafe' argument, making it clear that there be dragons.
- Struct methods are now declared during finalization. This allows instances of generic structs to have methods referring to the same struct. Previously, methods would be declared before the instance had been fully registered, leading to errors during type resolution. Furthermore, such methods were declared in a temporary namespace, that would then erroneously escape and lead to use-after-free issues.
- Instances of TypeArgumentInference were not running in the correct (Torque) scopes, leading to type resolution errors.
- The chain of ContextualVariable::Scope for any given ContextualVariable (such as CurrentScope) can now be walked, simplifying debugging.
R=jgruber@chromium.org, tebbi@chromium.org
Bug: v8:7793
Change-Id: I36f808f63cc3ce441062dfc56f511f24f1e3121e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758322
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63314}
The linkage should not have any knowledge about the existance of nodes.
R=mstarzinger@chromium.org
Bug: v8:9396
Change-Id: If10bf113c6ec19c434573a8d9bb7b736caef5dee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763532
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63313}
This adds type reflection support to the {WebAssembly.Module.exports} as
well as {WebAssembly.Module.imports} method. It also refactors existing
reflective code to use the internal instead of the public embedder API,
which is slightly more efficient anyways.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I88a6c7e9236a549808707c72e40a63302b7747a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763527
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63312}
This just adds a test case checking against the current behavior, but
expectations might change once the proposal is clarified. For details
see: https://github.com/WebAssembly/js-types/issues/11R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I2fc502460c0a8094a414d138703b75497b2d1c6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762517
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63311}
With the added parenthesis from a previous CL, clang-format does a
decent job of formatting the nested ternary operator statement.
R=leszeks@chromium.org
Change-Id: If2f5db766b6234a44f771c167f9831adda5dbd43
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762301
Auto-Submit: Simon Zünd <szuend@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63308}
This CL fixes a bug where function proxies were reported as functions
instead as proxies to devtools, which caused dev-tools to call methods
on the function, possibly triggering side-effects.
Change-Id: I1d5d234b784601bd4b7ec91107e4b0cf0d877d07
Bug: chromium:995753
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762303
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63307}
The tests were assuming that the destructor leaves behind memory in a
defined state when the object was allocated with placement new. Turns
out gcc with no component builds optimizes away the resetting of the
memory.
There's a simpler way to test the functionality by inspecting global
handle counts.
Bug: v8:9639, chromium:995684
Change-Id: I253d84910414c62ca314507b20d2c819f925ea6e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762512
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63303}
When regexp match indices are enabled, we stash required data in the JSRegExpResult object,
and then build a JSRegExpResultIndices object lazily when the 'indices' property is
accessed.
This cl simply checks that fast and slow paths produce the same values for
result.indices and result.indices.groups.
Change-Id: I6322d8eaef4c6e5a0ed3a5aef8b2ff05ac2b2c7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763249
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63301}
This set of macros was only used for one test, while another versions
exists in the header file that's used in the rest of the tests. Clean up
the duplication.
R=ahaas@chromium.org, titzer@chromium.org
Change-Id: I851c47a0748b5c78d9a966dfb59b95a3381e7cf7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1747179
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63300}
This adds type reflection support to the {WebAssembly.Module.exports} as
well as {WebAssembly.Module.imports} method. It also refactors existing
reflective code to use the internal instead of the public embedder API,
which is slightly more efficient anyways.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: Ic51b7b4744f7b3ad056a778aecfc4614ca8d6e75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762019
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63299}
Some scopes that were subtracted were not part of the outer scopes and
thus can result in negative values.
Change-Id: I2264b27c4b7a48075fed4e3afaa6b6dd27d8daa4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762299
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63298}
Before this cl, we always added slack to JSRegExpResult's initial_map.
However, this is incorrect. Now we only add slack to JSRegExpResult's initial map
if we intend to actually append the indices descriptor.
Bug: chromium:996099
Change-Id: Iac23e92415a9b60409915ff1de9634326ed109c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763064
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63297}
private name was not found in the current scope. Outer private names
were sometimes coincidentally correctly resolved if the innermost
ClassScope does not need to allocate a context and does not have a
ScopeInfo.
ClassScope: :LookupPrivateName was not walking the scope chain when a
Change-Id: I18937e6cdf2ad4ae15825b11762fbec7a1358145
Bug: v8:9635
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1761547
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63295}
Since the mutability of HeapNumbers is determined by their owning
object's descriptor array, we can remove the MutableHeapNumber type
entirely, at the cost of a few fewer DCHECKs and a couple of TODOs
to use the descriptor array information.
This is a necessary step towards a follow-up which allows in-place
Double -> Tagged transitions
Design doc: https://docs.google.com/document/d/1VeKIskAakxQFnUBNkhBmVswgR7Vk6T1kAyKRLhqerb4/
Bug: v8:9606
Change-Id: I13209f9c86f1f204088f6fd80089e17d956b4a50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743972
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63294}
