Stack limits were additionally maintained in pseudo-smi roots.
"Pseudo", because we stored the raw limit pointers there, just making
sure their values looked like smis by masking the least significant
bits.
This mechanism is no longer needed now that we can access the stack
limit external references as efficiently as the smi roots.
Bug: v8:9534
Change-Id: I37e78851c97aebc1012ea0e95075e56366a40a73
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745339
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63183}
Previously these were called (real) stack limit on one end, (real)
jslimit on the other. With this CL we consistently use jslimit
everywhere.
Tbr: tebbi@chromium.org
Bug: v8:9534
Change-Id: I9f86ac113bb9682544c365d54f666c1312a073a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748738
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63179}
This allows us to keep v8 free of the dependency on the crash/base components.
Second half of the change: https://chromium-review.googlesource.com/c/chromium/src/+/1690003.
Bug: v8:9323
Change-Id: If35288e3916df951ae6e2ae39e1cb06fab5fbf8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1699102
Commit-Queue: Irina Yatsenko <irinayat@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63177}
Also adds a NullContextScope for code which wants to ensure it is context
independent. Removes a workaround in V8ProfilerAgentImpl::startProfiling
which created a context due to CollectSourcePositions not being context
indpendent.
BUG=chromium:992063
Change-Id: I94c7eea6416dc64bc61fb8ff9cd945449a791a77
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748693
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63176}
This requires a native context which might not be available when
collecting source positions, and errors are cleared in any case.
BUG=chromium:992063
Change-Id: Ie0b81f60debaaf9a7810a42f56de0c005a7fbe18
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745338
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63175}
Create canonical ScopeInfos for the global this binding and empty function in
the read only space, rather than creating them during bootstrapping for each
native context. This saves some memory, and also means we don't need to access
the native context to get the global this binding in when deserializing a
scope info, which is important since parsing should be native context independent.
BUG=chromium:992063
Change-Id: I800f576e8e9b95d46e043cba0c1a03ae19a683c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748690
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63174}
The BytecodeGraphBuilder still looks at the heap. This CL mostly
eliminates heap lookups for:
* CreateArrayLiteral
* CreateObjectLiteral
* CreateRegExpLiteral
What remains is the lookup embedded in the creation of a VectorSlotPair,
which will be addressed in a subsequent change.
Bug: v8:7790
Change-Id: I5e4167f5542b84ed3684ad61f3dd1ef8ad84c96b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745482
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63173}
This CL eliminates managed heap reads from the ByteCodeGraphBuilder
from constants. These reads and serializations are made at serialization
time.
Bug: v8:7790
Change-Id: I5c59ea1f097d11f48994f41ac296cfc64121db25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1746477
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63169}
We were only considering eliminating Stores of size Tagged. There doesn't
appear to be a reason why. This CL enables store store elimination for all
sizes.
For example, in pointer compression, it means that Compressed values can
be targeted. In 32 bit versions, it means that doubles can now be targeted.
This is safe under the assumption that every byte of a JS object is only
ever accessed through one offset. For instance, byte 15 of a given object
may be accessed using a two-byte read at offset 14, or a four-byte read at
offset 12, but never both in the same program.
Change-Id: I865d412ed5b4db53a0154cf4da6303c407fdbda7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1746469
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63168}
Port 0aa204febf
Original Commit Message:
This CL unifies how stack checks are handled in the Turbofan pipeline
across architectures, in preparation for properly handling stack
overflows caused by deoptimization in follow-up work. It will also
open up possibilities to simplify related logic.
How this used to work: JSStackCheck was lowered to a UintLessThan
with the stack pointer (sp) and stack limit as inputs. On x64 and ia32,
this node pattern was later recognized during instruction selection
and rewritten to dedicated operators. On other platforms, including
arm and arm64, special logic exists to avoid useless
register-to-register moves when accessing the sp.
This CL introduces a new StackPointerGreaterThan operator, which takes
the stack limit as its sole input. This is what JSStackCheck now lowers
to. This is threaded through to code generation, where we emit the
appropriate code (in the future, we will apply an additional offset to
the sp here).
In follow-up CLs, we can remove or replace remaining uses of
LoadStackPointer in CSA, Wasm, and the interpreter; and then remove
the LoadStackPointer operator, related node matchers, related register
constraints, and the pseudo-smi stack limit roots.
R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I175c110d30190bb543001b6fa77cd65cf22e5874
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748002
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#63167}
Now that all uses of LoadStackPointer have been removed, this CL cleans
up related code:
- Removed LoadStackPointer.
- Removed ArchStackPointer.
- Removed IA32StackCheck.
- Removed X64StackCheck.
- Removed StackCheckMatcher.
All stack checks now follow a simple path without matchers or special
register constraints: they load the limit and pass it to
StackPointerGreaterThan, which is finally handled by code generation.
Bug: v8:9534
Change-Id: Ib1d7be1502a471541d6441f3261aac0c949525fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748737
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63166}
The matcher used to be needed to avoid first moving rsp to an
allocated register for LoadStackPointer. This is no longer the case
with the new stack check structure based on StackPointerGreaterThan.
This CL updates the wasm stack check and removes now-unneeded
matchers.
The generated stack check code remains unchanged from before:
// Load the stack limit through the instance then compare against rsp.
REX.W movq rcx,[rbp-0x10]
REX.W movq rcx,[rcx+0x2f]
REX.W cmpq rsp,[rcx]
// And on ia32:
mov ecx,[ebp-0x8]
mov ecx,[ecx+0x17]
cmp esp,[ecx]
Bug: v8:9534
Change-Id: I9240ad922d19d498a2661c143b12d629ac14d093
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748733
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63165}
This removes LoadStackPointer and its last remaining use in the
interpreter assembler.
Bug: v8:9534
Change-Id: I19aafb12c5fd50248841a3d92448e64243c723ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748729
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63164}
CSA's stack checks (in CodeStubAssembler::PerformStackCheck) were
previously carefully crafted to hit the stack check node pattern
matchers later on during instruction selection (see StackCheckMatcher).
This brittle mechanism is no longer needed now that stack checks use the
new StackPointerGreaterThan machine operator.
Bug: v8:9534
Change-Id: Idca169df1cadc6db237a8d36883ec1a79418f288
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748728
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63163}
We assume that during bootstrapping, we won't create script contexts.
This is wrong, since JavaScript code in extensions may introduce
let/const variables.
R=jgruber@chromium.org
Change-Id: I02595abdbb65f41faffc90bde142849bbde6b554
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1666994
Auto-Submit: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63161}
IsolateData guarantees a fixed root-relative offset for its contents,
thus allowing more efficient code generation for accesses to these
addresses. The stack limit, located within the StackGuard, is used by
all stack checks in CSA.
This CL moves the StackGuard inside IsolateData to make such efficient
loads of the limit possible.
Bug: v8:9595,v8:9534
Change-Id: I9abe26b88952709c88bf625cc6c028497815a58c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741648
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63160}
Turbofan applies the following optimization to external reference
loads on arm64 and x64: if the root-relative offset to an external
reference's address is known to be constant (and the root register has
been initialized), calculate the external reference as |kRootRegister
+ <offset>| instead of loading it from the external reference table.
There are two main cases to consider:
1. External references to arbitrary addresses in the native address
space, e.g. libc_memcpy. These kinds of external references have a
fixed address within the same running process, but may (and likely
will) change between processes (e.g.: mksnapshot and later chromium),
and the root-relative offset is different for each Isolate within the
same process.
These kinds of external references can be optimized as above when
*not* generating code which will later be serialized, and *not*
generating isolate-independent code.
2. External references to addresses within the fixed-size region of
the Isolate (essentially: within IsolateData). Since these move with
the Isolate, their root-relative offset is guaranteed to be constant
at all times.
The optimization can always be applied to these cases as long as the
root register has been initialized.
Prior to this CL, we only recognized and optimized for case 1. This CL
additionally adds support for 2.
An example of improved code generated due to this CL:
Before:
// r13 is the kRootRegister on x64.
// 0x3010 is the root-relative offset to Isolate::context_address.
leaq rdx, [r13+0x3010]
movq r8, [rdx]
After:
movq rdx, [r13+0x3010]
Bug: v8:9534
Change-Id: Idfcca751e98a56c0e5ead2c701c12a677df75399
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748727
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@{#63158}
This adds two helper functions in code-generator-{ia32,x64}:
- HasAddressingMode: is the addressing mode not equal to kNone?
- HasRegisterInput: is the specified input in a register?
Bug: v8:9534
Change-Id: I690ee52e247b347a7ef5ba0c98bba47c321ca6b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748726
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63157}
This CL unifies how stack checks are handled in the Turbofan pipeline
across architectures, in preparation for properly handling stack
overflows caused by deoptimization in follow-up work. It will also
open up possibilities to simplify related logic.
How this used to work: JSStackCheck was lowered to a UintLessThan
with the stack pointer (sp) and stack limit as inputs. On x64 and ia32,
this node pattern was later recognized during instruction selection
and rewritten to dedicated operators. On other platforms, including
arm and arm64, special logic exists to avoid useless
register-to-register moves when accessing the sp.
This CL introduces a new StackPointerGreaterThan operator, which takes
the stack limit as its sole input. This is what JSStackCheck now lowers
to. This is threaded through to code generation, where we emit the
appropriate code (in the future, we will apply an additional offset to
the sp here).
In follow-up CLs, we can remove or replace remaining uses of
LoadStackPointer in CSA, Wasm, and the interpreter; and then remove
the LoadStackPointer operator, related node matchers, related register
constraints, and the pseudo-smi stack limit roots.
Bug: v8:9534
Change-Id: I0e3f1beeed65b163c4ee5787600bed8c3cc671e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738863
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63156}
We weren't fully using InsertChangeCompressedToTagged and similar, which
in turn made it so that we were using more NewNode. This CL unifies the
way that we generate the insertion of Change nodes regarding decompressions.
Dribe-by fix: make InsertChangeCompressedPointerToTaggedPointer actually
use Pointer.
Bug: v8:7703
Change-Id: I1d8835a54914cdab93f652ff17e39e8271a585df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741661
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63154}
The Osr context is a pointer, and we can make it clear in the Typer.
Known pitfall: If we have a context within a context, the innner context
pointer is typed as Any.
Change-Id: Ia4d7e43ef42ef03f835e4b71d32d117ae835feee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741659
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63153}
We have already parsed a function when we call CollectSourcePositions, so we
shouldn't update the parsing statistics again otherwise we will double-count.
Also, CollectSourcePositions needs to be made native-context independent, and
Blink's CountUsage counter requires a context to have been entered when it is
called and so isn't context independent.
BUG=chromium:992063
Change-Id: Idda50b98a8308f022cb90e1a18afb43982e95298
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1746472
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63151}
This CL implements a naive tiering-up strategy where the interpreter
is used for the first execution for every regex, and the compiler is
used for every execution after that. The only exception is if a
global replace is being executed on a regex, we eagerly tier-up to
native code right away.
To use the tier-up logic --regexp-tier-up needs to be set. It is
currently disabled by default.
Bug v8:9566
Change-Id: Ib64ed77cbfcde10411161c0541dfa2501a0a93bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710661
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ana Pesko <anapesko@google.com>
Cr-Commit-Position: refs/heads/master@{#63150}
We might have to collect source positions for existing functions when we
start profiling, and doing so requires a context to be entered in V8. Ensure
we always enter a context by creating a temporary context and entering it before
starting profiling.
BUG=chromium:992063
Change-Id: I72b259a3ad31b712b0475f7729fb4ffdab5cdd96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745481
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63149}
This contains the following upstream commits:
486d3fe: Rename DEBUG to WASM_API_DEBUG
8d8e37d: Explicitly number wasm_valkind_t
299ebe0: Fix underlying types for enums
70be7c6: Fix test
Change-Id: I692fb6c909e5211920438740d2c57ea7ee74ab12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745483
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63147}
The BytecodeGraphBuilder still looks at the heap. This CL completely
eliminates heap lookups for:
* CreateBlockContext
* CreateFunctionContext
* CreateEvalContext
* CreateCatchContext
* CreateWithContext
Bug: v8:7790
Change-Id: I8b88215ba14a11955729b33bd0ee57219719666d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745484
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63146}
The operator== in RegisterBase only compares the reg_code. On arm64 we have
another 'base', CPURegister. Before this change, registers from different
classes but with the same register number would compare as equal.
For example, x30 == d30 would be true, which is incorrect.
Change-Id: I8f19139df3f041b07bfa0883ec5ca768ef540802
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745475
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Rodolph Perfetta <rodolph.perfetta@arm.com>
Cr-Commit-Position: refs/heads/master@{#63145}
Some of the Float(32|64) to CompressedSigned cases had their functions
defined already so they are virtually free to implement.
We are still missing the unsigned case so I am keeping the TODO.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:7703
Change-Id: Ibf40d5948226fd48aebe7f8e257c117d6a5ad478
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708483
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63143}
- Adds regular native heap entries to the HeapObjectsMap.
- Adds a side map for keeping a mapping of native objects to their canonical
heap entry that they have been merged into.
Change-Id: Ida00628126ded1948ceb2a0cbe14da817af7f361
Bug: chromium:988350
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720810
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63140}
This is the first in a series of changes to reduce the number of
bytecodes generated for the iteration protocol based operations.
The GetIterator bytecode introduced in this change currently loads the
@@iterator symbol from an object that was previously done using the
LdaNamedProperty bytecode. This change uses builtin-based mechanism
that would be extended to perform additional operations in the future
on absorbing the bytecodes associated with the GetIterator operation
from the iteration protocol.
Bug: v8:9489
Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63139}
This adds some documentation why concurrently emitting code, patching
the jump table, and executing the jump table is safe.
R=ahaas@chromium.org
CC=mstarzinger@chromium.org, joey.gouly@arm.com
Bug: v8:9477
Change-Id: Ibe295d538a1a330c6b1d94eb1f514d1078020754
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738856
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63137}
Since the same value is also returned in 'result' field it is still populated in accord with 'returnByValue' parameter. This behavior is consistent with 'evaluate'.
R=dgozman@chromium.org, lushnikov@chromium.org
Bug: v8:9509
Change-Id: I9f72682f87492ce5cd0759dce75ab3d75a5fe31c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1707331
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Yury Semikhatsky <yurys@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63134}
This reverts commit e2f98ec22c.
Reason for revert: Caused performance regression in ArrayLiteralInitialSpreadSmallHoley.
Original change's description:
> Use list of invalidated objects for old-to-new refs
>
> Instead of inserting "deletion" entries into the store buffer, keep
> a list of invalidated objects to filter out invalid old-to-new slots.
>
> The first CL https://crrev.com/c/1704109 got reverted because both the sweeper and the main task were modifying the invalidated slots data structure concurrently. This CL changes this, such that the sweeper only modifies the invalidated slots during the final atomic pause when the main thread is not running. The sweeper does not need to clean this data structure after the pause, since the "update pointers" phase already removed all invalidated slots.
>
> Bug: v8:9454
> Change-Id: Iffb5bf96de2c89eee1ee1231a3414a0f2a155cbc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733081
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63087}
TBR=ulan@chromium.org,petermarshall@chromium.org,dinfuehr@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9454
Change-Id: I328b9f72df45fc9570d4a4d1b5389eac010638c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743970
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63131}
Cleans up a plethora of JumpIfUndefined().JumpIfNull()
occurances by introducing a new JumpIfUndefinedOrNull
bytecode.
Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63130}
If the function has been uncompiled (bytecode flushed) it will have lost any preparsed data.
When we recompile the outer function we will regenerate this PreParseData but it wasn't
being reattached to the inner function. This CL fixes this by checking for this case in
Compiler::GetSharedFunctionInfo and creating a new NewUncompiledDataWithPreparseData to
attach to the inner function.
BUG=v8:9479
Change-Id: I5c0fc8251006f8f5c7c7f5f9dd17b2ecc671b672
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741655
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63128}
The spec says we have to insert some wrapper code with extra line breaks
in it, but this confuses users when they see stack traces as the line
numbers come from the code with the wrapper, instead of the original.
This CL sets line_offset on the script to indicate that line numbers
should be offset by the 2 extra line breaks when reading them out e.g.
for the purpose of stack traces.
Bug: chromium:109362
Change-Id: Ib608e1043c38b595b1466766f7592e993ee3b996
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741660
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63127}
This CL changes the dispatch technique in the regex interpreter to
token-threaded dispatch, if computed gotos are supported by the
compiler. Otherwise old switch-based dispatch is still used
(e.g. for MSVC).
With computed gotos, less jumps will be emitted (no extra jump to
single branch point/begin of switch) and branch prediction will
be better because of no single branch point.
This CL improves performance on the RexBench Benchmark suite by ~10%.
Bug: v8:9575
Change-Id: I585ad824ff1cc595a5dfa8831ad66d6810d0119b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733073
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Patrick Thier <pthier@google.com>
Cr-Commit-Position: refs/heads/master@{#63126}
With lazy feedback allocation, we don't have feedback vectors when function
starts executing. If we mark the function on the first execution we would
be missing feedback for the initial part of the function and hence the
optimized code will not be useful.
This cl resets the optimization markers on OSR if the invocation count of
the function is less than 1. We may still do wasted optimizations if the
function is hot enough for optimizing but not for OSRing. In the long term
we may want to fix it differently. This fix covers the most common cases
in benchmarks.
Bug: chromium:987523
Change-Id: I1cfe82e6b9f95278b77c99b77d4b981828b5c0ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1739373
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63124}
This CL adds an access check for the arguments to all calls to
{console} like {console.log}. This is needed since the DevTools
protocol notificiation event does not contain the context in which
the {console.log} call occurred. Only the context of the argument.
When DevTools then reads properties for the preview of the argument,
it uses arguments context, instead of the calling context, potentially
leaking objects/exceptions into the calling context.
Bug: chromium:987502, chromium:986393
Change-Id: I6f7682f7bee94a28ac61994bad259bd003511c39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741664
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63122}
Each LHS expression that contains an optional chain of some form is
wrapped in an OptionalChain node. This root node allows us to use a
single jump location for every individual item in the chain,
improving the performance and simplifying the implementation.
Bug: v8:9553
Change-Id: I678563928b2dbfd6200bff55801919d4fd816962
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1723359
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63120}
In instruction selector we were tagging as Compressed or Tagged Any when
we could have been more specific. Also, we were marking as Word32 or Word64
when we should have been using CompressedSigned or TaggedSigned, respectively.
Drive-by cleanup: Rename MarkAsReference to MarkAsTagged.
Bug: v8:7703
Change-Id: I4df7a17e25cfa51a1e11eac0af40be21efb50990
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1739367
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63119}
The previous ordering caused a SCOPED event to end after its parent
event, which isn't really supported in the trace format.
Change-Id: I2ddaa12596604499366854231506c889d910f951
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741926
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Eric Seckler <eseckler@chromium.org>
Auto-Submit: Eric Seckler <eseckler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63118}
Previous differences in eager and lazy parsing meant that it was possible
that feedback vectors could be different for the same function depending on
how it was compiled. These issues have now been fixed, so remove the workaround
and add an explicit CHECK that the feedback vectors are the same.
BUG=chromium:984344,v8:9511
Change-Id: I0edfa350b1a2f236db1ee2f86bc46690da926af1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741650
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63116}
This reverts commit 79b00555ea.
Reason for revert: needs more discussion
Original change's description:
> [torque] introduce JSAny type for user-accessible JavaScript values
>
> This CL introduces a JSAny type for user-exposed JavaScript values and
> a few new types to define it. Especially, it splits Symbol into
> PrivateSymbol (not exposed) and PublicSymbol (JavaScript exposed
> symbols).
>
> The change is mostly mechanical, but a few things are interesting:
> - PropertyKey and JSPrimitive were designed to coincide with the spec
> notions of IsPropertyKey() and primitive value, respectively.
> - Since Name is an open type, we define AnyName to be the known
> subtypes of Name. This is not too elegant, but by using AnyName
> instead of Name, typeswitch can properly conclude something if a
> subtype of Name is excluded.
>
> Small drive-by changes, which were necessary:
> - Allow subtyping on label parameters.
> - Fix the formatting of typeswitch, it was broken with union types
> in case types.
>
> Bug: v8:7793
> Change-Id: I14b10507f8cf316ad85e048fe8d53d1df5e0bb13
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735322
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63114}
TBR=neis@chromium.org,jgruber@chromium.org,tebbi@chromium.org
Change-Id: Ifde7881d74afe407628f40047997339d54cb2424
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741652
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63115}
This CL introduces a JSAny type for user-exposed JavaScript values and
a few new types to define it. Especially, it splits Symbol into
PrivateSymbol (not exposed) and PublicSymbol (JavaScript exposed
symbols).
The change is mostly mechanical, but a few things are interesting:
- PropertyKey and JSPrimitive were designed to coincide with the spec
notions of IsPropertyKey() and primitive value, respectively.
- Since Name is an open type, we define AnyName to be the known
subtypes of Name. This is not too elegant, but by using AnyName
instead of Name, typeswitch can properly conclude something if a
subtype of Name is excluded.
Small drive-by changes, which were necessary:
- Allow subtyping on label parameters.
- Fix the formatting of typeswitch, it was broken with union types
in case types.
Bug: v8:7793
Change-Id: I14b10507f8cf316ad85e048fe8d53d1df5e0bb13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735322
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63114}
This patch stores the home objects in private methods that
access super properties.
Bug: v8:8330
Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#63113}
Currently, the private name symbols are displayed in the block
scopes in DevTools, though these are just implementation details
of private fields. This patch hides them from the block scope
by marking variables with names starting with `#` as synthetic.
The private fields are still going to show up in the previews
of objects, only the key symbols themselves are going to be hidden.
Bug: v8:8773, chromium:982267
Change-Id: I059472d05c26a1f035ab92718a1b7e5ecafa8dc4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741846
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#63112}
This CL changes {descriptionForError} to not immediately return when a {stack}
is not found, but instead try to lookup and append the {message} as well.
The existing logic to build a description in a specific way when the class
of the exception does not match, is retained for backwards compatibility.
Bug: chromium:954017
Change-Id: I9fa1d2807e2877bd988f82b4b57cf329bcd9f61b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738862
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63111}
We didn't track transitions from non-smi elements kind in builtins but we
did track them in the runtime. We should track these transitions in
builtins as well. Not tracking them uniformly causes deopts in unexpected
places which are hard to reason about.
Bug: chromium:987522
Change-Id: I09403c7365d4d2474bca3ab601887abec19aef27
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1736748
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63109}
Also roll 0705a10: Comments
Change-Id: I9802283fa68093839286779503b6073122cbc8d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1739369
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63108}
The current V8HugeMaxOldGenerationSize feature increases the JS heap size for
systems with larger than 16 GB physical memory. This cl adds support for 16 GB
configuration.
Because a small portion of memory is reserved by hardware, the physical memory
calculation here is rounded up to GB so the actual installed memory is checked.
Bug:chromium:958974
Change-Id: Idaf2e03a43ba6c3c40bb771296d06b87032c2725
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1734038
Commit-Queue: Maggie Chen <magchen@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63104}
The HandleScope lets objects allocated within the slow loop be collected
prior to loop termination.
Drive-by: Use the appropriate kMaxElementCount constant.
Drive-by: Switch to less-or-equal comparison against it.
Bug: chromium:948810
Change-Id: I2449408b87e7e82dead5ee76d8c92129fa3243fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1736749
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63103}
Ongoing cleanup to use the same term everywhere.
Bug: chromium:913887
Change-Id: Ifc4d4de0c2dfd9f1150e61d64cf7f91cf923aa24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738865
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63101}
This cl makes IsLockFree return true for 8 bytes on x64 platforms.
The standard is unfortunately a bit vague on what exactly 'lock free' means.
As a result, we err on the side of caution. We can revisit this, but first
we need the specification to nail down exactly what 'lock free' in this
context.
Bug: v8:8100
Change-Id: I0a6099c6cb95a5581f3e71d0267857b88b4a2f0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735592
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63099}
There were some accesses that could be specialized to Pointer
instead of Any.
Also updated the WriteBarrierKind to match. Any -> full barrier,
Pointer -> Pointer barrier, Signed -> no barrier.
There were some accesses that were not used, and therefore got deleted.
Bug: v8:9396
Change-Id: Ie249e6571080fa6e24d9022344775de679966144
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733070
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63096}
This CL removes the SEPERATOR from the FOREACH_WASM_FEATURE_FLAG macro,
which was ugly, and fortunately also unnecessary.
R=jkummerow@chromium.org
Bug: v8:9396
Change-Id: I455589331f84a011a231d6897d03e8ab0b492b45
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738847
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63095}
The is_public name is misleading now that we have private
symbols. It's only used to know if the symbol is stored in the global
symbol registry.
This patch renames it to a more suitable name.
Change-Id: I78f31cb5438416d07b78a9038c3526c9dfb96c6e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738849
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63092}
Sorting the pages by least free bytes should reduce fragmentation:
since map space is never compacted, it makes sense to first fill
pages that are the most full already rather than to start with the
most empty pages (which is what was more or less going on until this
CL).
Bug: v8:9329
Change-Id: I2157e3b4706c53da80220da5e4a26c00ee4c592f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735325
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@google.com>
Cr-Commit-Position: refs/heads/master@{#63090}
This is a reland of a3218aa744.
Unmodified reland, thus TBR.
Original change's description:
> [wasm] Add support to allocate in a specific code region
>
> For multiple code spaces with multiple jump tables, we need to allocate
> the space for the jump tables within specific regions (the new code
> spaces) so they are within reachable distance.
> This CL adds support for that, and uses it for the first jump table.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:9477
> Change-Id: Ibdf05c9500c2dfdb2c5f5f920b4422339aaab810
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733069
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63074}
TBR=mstarzinger@chromium.org
Bug: v8:9477
Change-Id: Ic110705fa13edeb103c06ad579a61cba78b6890c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738848
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63089}
This is a reland of 779bdef36e
Original change's description:
> [wasm] Prepare for multiple jump tables
>
> This CL prepares {NativeModule} and {WasmCodeAllocator} for multiple
> code spaces with separate jump tables. {WasmCodeAllocator} calls back
> to the {NativeModule} for each code space it allocates, and
> {NativeModule} stores data (especially the jump table) for each code
> space.
> A jump table is currently only created for the first code space added,
> so nothing changes there yet.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:9477
> Change-Id: I3ddeb8e251648b07ba8b7b4638abafe2364b47ff
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730996
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63069}
Bug: v8:9477
Change-Id: I9e25d59029cb6ce4869cf53a868afc59bc20b72f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735324
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63088}
Instead of inserting "deletion" entries into the store buffer, keep
a list of invalidated objects to filter out invalid old-to-new slots.
The first CL https://crrev.com/c/1704109 got reverted because both the sweeper and the main task were modifying the invalidated slots data structure concurrently. This CL changes this, such that the sweeper only modifies the invalidated slots during the final atomic pause when the main thread is not running. The sweeper does not need to clean this data structure after the pause, since the "update pointers" phase already removed all invalidated slots.
Bug: v8:9454
Change-Id: Iffb5bf96de2c89eee1ee1231a3414a0f2a155cbc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733081
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63087}
Sorting is done in order to make compaction more efficient: by
sweeping pages with the most free bytes first, we make it more likely
that when evacuating a page, already swept pages will have enough free
bytes to hold the objects to move (and therefore, we won't need to
wait for more pages to be swept in order to move those objects).
Since maps don't move, there is no need to sort the pages from
MAP_SPACE before sweeping them.
Bug: v8:9093
Bug: v8:9329
Change-Id: I63964364d3cd0b64faf8570e87b5f75de6443902
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1736746
Commit-Queue: Darius Mercadier <dmercadier@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63086}
When serializing frame states into translations (later used by
deopts), we pass certain values, depending on the frame kind, to be
serialized as the frame height.
This CL moves the calculation of this height value into the
FrameStateDescriptor. In a follow-up, we may want to simplify the way
these height values are passed and processed by deopts.
The motivation behind this is to simplify calculation of unoptimized
stack frame sizes during compilation.
Bug: v8:9534
Change-Id: I20d2b57a42cea0c238b9c887dba0280f6aad76de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728609
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63085}
Update the TracingCpuProfiler test to work properly with perfetto.
Roll perfetto to get fixes for bugs encountered with starting/stopping
tracing rapidly, which happens in the test for the tracing profiler.
Add a check that the DataSource::Register call was successful to flush
out any errors there (although they are fixed by the perfetto roll).
Emit a fake trace event when stopping tracing in order to avoid
losing the final trace event that the user provided. Remove the ad-hoc
fake final trace events that the cctests for perfetto added.
Add a test StartAndStopRepeated which flushes out the issues fixed by
the perfetto roll.
TBR=yangguo@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux64_perfetto_dbg_ng
Bug: v8:8339
Change-Id: I042d7385486bf42c86f1631406974693868a477f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731006
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63083}
This is a reland of 159df2488c
Original change's description:
> [ic] Don't transition to premonomorphic state
>
> We used to use premonomorphic state to delay initializing the ICs.
> This optimization was to avoid the cost of setting up handlers if the
> code executed only once. With lazy feedback allocation we no longer
> need this.
>
> This cl also renames LoadIC_Uninitialized to LoadIC_Nofeedback and
> StoreIC_Uninitialized to StoreIC_Nofeedback since we now miss to
> runtime in the uninitialized state and use the builtin when there
> is no feedback.
>
>
> Change-Id: I1633e61ea74664da51348e362c34c47a017a264a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683525
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63020}
Change-Id: Ica7eb65649615c2f8410d5b815a98b55cb1cfc4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731000
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63082}
This reverts commit 5611f70b3d.
Reason for revert: flaky tests: v8:9588, v8:9587
Original change's description:
> "Reland x4 [arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of bc33f5aeba
>
> Contributed by titzer@chromium.org
>
> Original change's description:
> > [arraybuffer] Rearchitect backing store ownership
> >
> > This CL completely rearchitects the ownership of array buffer backing stores,
> > consolidating ownership into a {BackingStore} C++ object that is tracked
> > throughout V8 using unique_ptr and shared_ptr where appropriate.
> >
> > Overall, lifetime management is simpler and more explicit. The numerous
> > ways that array buffers were initialized have been streamlined to one
> > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > and the construction and destruction of the BackingStore object itself
> > handles the underlying page or embedder-allocated memory.
> >
> > The embedder API remains unchanged for now. We use the
> > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > keep the backing store alive properly, even in the case of aliases
> > from live heap objects. Thus the embedder has a lower chance of making
> > a mistake. Long-term, we should move the embedder to a model where they
> > manage backing stores using shared_ptr to an opaque backing store object.
>
> TBR=yangguo@chromium.org
>
> BUG=v8:9380,v8:9221,chromium:986318
>
> Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63041}
TBR=ulan@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,clemensh@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9380, v8:9221, chromium:986318
Change-Id: Ic7381239f4e90d0c437b7e47a5ac6e8bce60f882
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1736747
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63081}
Now that we can short-circuit control flow in the optimizing compiler,
there is no more need for BranchIf... macros in CSA/Torque.
Thus removing support for them in Torque and rewriting Torque macros to
use bool return values instead.
Bug: v8:7793
Change-Id: Ie4b7522aa5558be038fe821d8b5d02859d522ed1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724211
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63079}
This CL changes the signature of AccessorPair::GetComponent to take
an additional parameter {native_context}. The current native_context
does not always match the native context of the holder, resulting in
JSFunctions that have the wrong native context for lazy instantiated
AccessorPairs.
Bug: chromium:989909, v8:6495
Change-Id: I45bfcb27ac367858dd6788736eba1a2e1302e802
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735311
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63078}
This reverts commit 779bdef36e.
Reason for revert: Speculative revert for win breakage (https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8905967677942963904/+/steps/Check/0/logs/Fixed/0)
Original change's description:
> [wasm] Prepare for multiple jump tables
>
> This CL prepares {NativeModule} and {WasmCodeAllocator} for multiple
> code spaces with separate jump tables. {WasmCodeAllocator} calls back
> to the {NativeModule} for each code space it allocates, and
> {NativeModule} stores data (especially the jump table) for each code
> space.
> A jump table is currently only created for the first code space added,
> so nothing changes there yet.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:9477
> Change-Id: I3ddeb8e251648b07ba8b7b4638abafe2364b47ff
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730996
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63069}
TBR=mstarzinger@chromium.org,clemensh@chromium.org
Change-Id: I57af88872c1335d547f83e524c8f06938b5c817b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9477
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735320
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63076}
This reverts commit a3218aa744.
Reason for revert: Needed for another revert (https://chromium-review.googlesource.com/c/v8/v8/+/1735320)
Original change's description:
> [wasm] Add support to allocate in a specific code region
>
> For multiple code spaces with multiple jump tables, we need to allocate
> the space for the jump tables within specific regions (the new code
> spaces) so they are within reachable distance.
> This CL adds support for that, and uses it for the first jump table.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:9477
> Change-Id: Ibdf05c9500c2dfdb2c5f5f920b4422339aaab810
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733069
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63074}
TBR=mstarzinger@chromium.org,clemensh@chromium.org
Change-Id: I4b1d1e670d5b25fa40205754d9572b2b809c93ea
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9477
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735321
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63075}
For multiple code spaces with multiple jump tables, we need to allocate
the space for the jump tables within specific regions (the new code
spaces) so they are within reachable distance.
This CL adds support for that, and uses it for the first jump table.
R=mstarzinger@chromium.org
Bug: v8:9477
Change-Id: Ibdf05c9500c2dfdb2c5f5f920b4422339aaab810
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733069
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63074}
This reverts commit 9499ec0d43.
Reason for revert: Breaks lots of stuff, e.g.
https://ci.chromium.org/p/v8/builders/ci/V8-Blink%20Linux%2064%20-%20future/9401
Original change's description:
> [TurboFan] Brokerize remaining feedback vector slots
>
> This CL adds new ProcessedFeedback subclasses, corresponding to various IC
> types:
>
> * ForIn
> * Comparison ops
> * Binary/Unary ops
> * InstanceOf
> * Calls
>
> The feedback is gathered at serialization time and used in several places,
> namely:
>
> * Bytecode graph building,
> * and its helper class JSTypeHintLowering (with its "early lowering")
> * Native context specialization
> * JSCallReducer
>
> Design doc: https://docs.google.com/document/d/1JLG0VFV8xmsAIJexU19xzlbNyP51ONqfo_Gf_2DcPC8/edit?usp=sharing
>
> Bug: v8:7790
> Change-Id: I53c3d7a17f844384f38c4ee0f0b082c114217a02
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710663
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63028}
TBR=mvstanton@chromium.org,neis@chromium.org,mslekova@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7790
Change-Id: Id0c4d6651611fc3964010f7615d0ad0485169ebc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735315
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63073}
This CL changes the way AccessorPairs are collected for instantiation
when debug break trampolines are installed.
Instead of walking the heap and looking at AccessorPairs directly, we
look at all JSObjects and collect AccessorPairs via each objects
descriptor array. This way, we can associate the correct native
context with each collected AccessorPair.
The current native context is not always the correct context to instantiate
the getter and setter JSFunctions for an AccessorPair.
Bug: chromium:986063
Change-Id: I124a0802f4938b95f1ad75efc65eb05b66bcfc67
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735310
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63071}
When a fast path was added for Math.hypot, the algorithm was also
simplified. This simplification turns out to be incorrect in some rare
edge cases. This cl reverts back to the original algorithm and converts it to torque.
Original cl: https://chromium-review.googlesource.com/c/v8/v8/+/1684178
Bug: v8:9546
Change-Id: If4e21504732f46081a8de823f50f499917f1a20c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725200
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63070}
This CL prepares {NativeModule} and {WasmCodeAllocator} for multiple
code spaces with separate jump tables. {WasmCodeAllocator} calls back
to the {NativeModule} for each code space it allocates, and
{NativeModule} stores data (especially the jump table) for each code
space.
A jump table is currently only created for the first code space added,
so nothing changes there yet.
R=mstarzinger@chromium.org
Bug: v8:9477
Change-Id: I3ddeb8e251648b07ba8b7b4638abafe2364b47ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730996
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63069}
Instead of exposing a {kNext} constant to be used to construct the next
bitfield, expose a templatized {Next} type alias. This ensures that the
storage type is the same for all bitfields created this way. It's also
shorter.
Apart from the expected changes in the code base, the AST node classes
are changed to expose a {NextBitField} templated type alias instead of
a {kNextBitFieldIndex} constant. They thus follow the same pattern as
{BitField} itself.
R=jkummerow@chromium.org, mstarzinger@chromium.org, verwaest@chromium.org
Bug: v8:9396
Change-Id: I70a1b0bd71cde694ec53444de0ca55e4cf0a3836
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728615
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63068}
This CL changes {CreateApiFunction} to take an explicit native context
to set on the newly created JSFunction. The CL also adds a new variant
of {ApiNatives::InstatiateFunction}, that takes a native context and passes
it through to {CreateApiFunction}.
This is a refactoring in preparation for a bugfix.
AccessorPairs can be instantiated lazily. At the time of
lazy instantiation, the current context does not necessarily match
the creation context of the holder of an AccessorPair.
Bug: chromium:986063, chromium:989909
Change-Id: Idea4b5052f2baff5c3d916f5ab8ed5017b60699b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735308
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63063}
Building cctest has linking error when gn's args has "is_component_build = true".
This CL make the visibility of "MemOperand" and "UseScratchRegisterScope" from
"hidden" to "default" to solve this problem.
Change-Id: I3ebfaa25d598b4f2d626861b947c93d111d95456
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731213
Auto-Submit: Mu Tao <pamilty@gmail.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63062}
Increasing the number of scavenging tasks in the previous CL
https://chromium-review.googlesource.com/c/v8/v8/+/1697245
has helped with GC performance but increased memory usage.
This CL ensures that there are at least two scavenging tasks if the
new space size is larger than one MB.
Bug: chromium:982663,chromium:985731
Change-Id: I6edff8b90beb2740a5b75a51cf25f48aa5442482
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733074
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63060}
When the --initial-heap-size flag is set V8's heap will grow to that
value without full GCs. Additionally, full GCs will be skipped
if the heap size drops below that value.
This patch also adds a comment for the initial_heap_size_in_bytes
parameter of ResourceConstraints:ConfigureDefaultsFromHeapSize
Change-Id: I85fda14bc6422af7bf2193d530efbc9b0bd0553d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728622
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63054}
Also add a IsExtreme(double) overload.
This wasn't causing issues because there was no codepath
which exercised it (only approx operations did).
Change-Id: If7583fb567137c428d16c0d2cdfc37e086f7f3fd
Bug: v8:8460
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726675
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63053}
For variable proxies in a function inside an eval scope that point to
a dynamic variable in the eval scope, the current scope resolution will
find this variable only when the function is eagerly compiled, as the
eval scope only exists during top-level eval compilation. This causes
a mismatch between lazy- and eager- compiled functions.
With this patch, we skip these dynamic variables during lookup, so that
the lookup for the variable proxy always finds a kDynamicLocal or
kDynamicGlobal, both when compiled lazily and eagerly. This is a minor
pessimisation of performance (as we know that the lookup has to be
dynamic), but unblocks other improvements which require idempotent
bytecode generation (such as lazy source positions).
Note that the alternative, of simply not tracking dynamic variables on
the eval scope at all, is not viable due to needing this information
during conflict detection.
Bug: v8:8510
Bug: v8:9511
Change-Id: Ifa72ec05e9a97b7be418912340081b9656765fd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733077
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63051}
MIPS64 has a user space of 2^40 bytes on most processors, address
space limits needs to be smaller. 256G is ok, but it will cause
many wasm tests get a OOM error.
This patch also skip some tests which need correct IEEE-745 2008
NaN bit patterns on mips.
Change-Id: I52968df3934e8748b2c42a0abf19db1540441d2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1712929
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Yu Yin <xwafish@gmail.com>
Cr-Commit-Position: refs/heads/master@{#63050}
This makes sure the "parameters" and "results" properties of the passed
FunctionType object can be arbitrary iterable objects, not just plain
JavaScript arrays.
R=clemensh@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: Icba18c418e549deba9fff1855be4956813b1a953
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733071
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63049}
JSBoundFunctionRef::serialized() and JSFunctionRef::serialized() should
tolerate being called when the heap broker is disabled, because these
methods are now called in the JSCallReducer (in order to log whether
information was missing at serialization time).
Bug: v8:7790
Change-Id: Iac8e68178422bd9bb4ebe2acb412ff42ac87cf4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733075
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63045}
Previously we were also taking into account the machine type
Change-Id: Ic76aad578f00ef24cf17b349d94cdade8f9ee29d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733072
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63044}
Trying to use double_registers for fetching single precision fp values creates
four different implementations of this method depending on the architecture, hence
separating them out into their respective folder.
Change-Id: Ide61fe2e7a95bd8427b377959b262633d8c57e61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730663
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#63042}
This is a reland of bc33f5aeba
Contributed by titzer@chromium.org
Original change's description:
> [arraybuffer] Rearchitect backing store ownership
>
> This CL completely rearchitects the ownership of array buffer backing stores,
> consolidating ownership into a {BackingStore} C++ object that is tracked
> throughout V8 using unique_ptr and shared_ptr where appropriate.
>
> Overall, lifetime management is simpler and more explicit. The numerous
> ways that array buffers were initialized have been streamlined to one
> Attach() method on JSArrayBuffer. The array buffer tracker in the
> GC implementation now manages std::shared_ptr<BackingStore> pointers,
> and the construction and destruction of the BackingStore object itself
> handles the underlying page or embedder-allocated memory.
>
> The embedder API remains unchanged for now. We use the
> v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> keep the backing store alive properly, even in the case of aliases
> from live heap objects. Thus the embedder has a lower chance of making
> a mistake. Long-term, we should move the embedder to a model where they
> manage backing stores using shared_ptr to an opaque backing store object.
TBR=yangguo@chromium.org
BUG=v8:9380,v8:9221,chromium:986318
Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63041}
During date parsing, a FixedArray is allocated to store intermediate values,
which is slow. This CL holds the values on stack instead to save time.
This increases the score of JetStream2 Date-format-tofte-SP case by ~2%
on WhiskeyLake Chromebook.
Contributed by hao.a.xu@intel.com
Change-Id: I0d7a20a3ad9c57e3a225fff03efc2e434b20fbbc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726744
Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63039}
Before this change, the tagged pointer that was loaded was not decompressed.
This makes LoadTaggedPointerFromInstance match the x64 implementation.
Bug: v8:9568
Change-Id: I8fd6d3e8dd13514ae3ef423d1c417f72e1396e4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730993
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63038}
Previously when creating a new generic struct, one had to explicitly provide all type arguments, e.g., for the generic struct
struct Box<T: type> {
const value: T;
}
one would initialize a new box using
const aSmi: Smi = ...;
const box = Box<Smi> { value: aSmi };
With the additions in this CL the explicit type argument can be omitted. Type inference proceeds analogously to specialization of generic callables.
Additionally, this CL slightly refactors class and struct initialization, and make type inference more permissive in the presence of unsupported type constructors (concretely, union types and function types).
R=jgruber@chromium.org, tebbi@chromium.org
Change-Id: I529be5831a85d317d8caa6cb3a0ce398ad578c86
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728617
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63036}
The mode without write barriers works only if incremental marking
is disabled and the single generation mode is enabled.
Bug: v8:9533
Change-Id: Iecf83b0810f757c9b50e7fb338a2905af938f1d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1716471
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63033}
When the flag is on and some of the functions don't have bytecode,
we should gracefully print "no bytecode" instead of crashing.
Bug: chromium:983267
Change-Id: Id4e3385cd871a2dd5bead38c29a41b38319cc8d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731003
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63031}
On Linux, both APIs uses {madvise} (and {SetPermissions} additionally
does an {mprotect}), on windows they use different APIs. It turns out that
{SetPermissions} with {kNoAccess} uses {VirtualFree} with
{MEM_DECOMMIT}, so the pages will only be "reserved" afterwards.
{DiscardSystemPages} on the other hand uses the {DiscardVirtualMemory}
which tells the OS that the content of that memory can be discarded,
but the pages stay "committed".
Thus {SetPermissions} with {kNoAccess} frees significantly more memory
than using {DiscardSystemPages}.
R=mstarzinger@chromium.org
Bug: v8:8217
Change-Id: I3555462a9c692f15ecb3eca7834eb181617d9ef9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730992
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63029}
This CL adds new ProcessedFeedback subclasses, corresponding to various IC
types:
* ForIn
* Comparison ops
* Binary/Unary ops
* InstanceOf
* Calls
The feedback is gathered at serialization time and used in several places,
namely:
* Bytecode graph building,
* and its helper class JSTypeHintLowering (with its "early lowering")
* Native context specialization
* JSCallReducer
Design doc: https://docs.google.com/document/d/1JLG0VFV8xmsAIJexU19xzlbNyP51ONqfo_Gf_2DcPC8/edit?usp=sharing
Bug: v8:7790
Change-Id: I53c3d7a17f844384f38c4ee0f0b082c114217a02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710663
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63028}
From JSNativeContextSpecialization::ReduceKeyedLoadFromHeapConstant
to JSNativeContextSpecialization::ReduceElementLoadFromHeapConstant.
Change-Id: Ib07a6a4bd599dc71a9a100b2f1f6baef68acbe0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728618
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63027}
now that we are shipping this by default, we can remove the flag.
Change-Id: I298691df3eec934a5add1aa2a2748a0f3a884ab6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726452
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63026}
The unittest for {WasmCodeManager} currently disables implicit
allocations for win64 unwind info, but still deals with the implicitly
allocated jump table. With the addition of a far jump table, this logic
would get even more complex.
Thus this CL introduces a testing flag on the {WasmCodeManager} to
disable all implicit allocations, and uses that instead in the
{WasmCodeManagerTest}.
R=mstarzinger@chromium.org
Bug: v8:9477
Change-Id: I45e4bc6b9fec6d7286bf6b45f778681ae0dba746
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725622
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63025}
This reverts commit 159df2488c.
Reason for revert: Breaks large-classes-properties test (https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906338563361079200/+/steps/Bisect_159df248/0/steps/Retry_-_isolates/0/logs/large-classes-properties/0)
Original change's description:
> [ic] Don't transition to premonomorphic state
>
> We used to use premonomorphic state to delay initializing the ICs.
> This optimization was to avoid the cost of setting up handlers if the
> code executed only once. With lazy feedback allocation we no longer
> need this.
>
> This cl also renames LoadIC_Uninitialized to LoadIC_Nofeedback and
> StoreIC_Uninitialized to StoreIC_Nofeedback since we now miss to
> runtime in the uninitialized state and use the builtin when there
> is no feedback.
>
>
> Change-Id: I1633e61ea74664da51348e362c34c47a017a264a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683525
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63020}
TBR=mythria@chromium.org,verwaest@chromium.org
Change-Id: I4fad4e8b881d4a3f8d12149e1797b217a317eaee
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730995
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63023}
This removes the explicit {kCallWithCallerSavedRegisters} opcode which
is just a regular call node with special handling for saving/restoring
caller saved registers before/after the call. This is now handled via
the {CallDescriptor::kCallerSavedRegisters} flag.
R=neis@chromium.org
BUG=v8:9396
Change-Id: Ie6421085eb2be8a067040222cd5215a9b1013048
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728611
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63021}
We used to use premonomorphic state to delay initializing the ICs.
This optimization was to avoid the cost of setting up handlers if the
code executed only once. With lazy feedback allocation we no longer
need this.
This cl also renames LoadIC_Uninitialized to LoadIC_Nofeedback and
StoreIC_Uninitialized to StoreIC_Nofeedback since we now miss to
runtime in the uninitialized state and use the builtin when there
is no feedback.
Change-Id: I1633e61ea74664da51348e362c34c47a017a264a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683525
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63020}
Instead of having fast path for proxy only in Reflect.deleteProperty, it
is also in delete operator.
Bug: v8:6664
Change-Id: I3db919953e31f51a5dc4a504062bd691a6e17446
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717660
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63014}
Wrapped functions don't recompile properly with lazy source positions so
just force them to always collect the source positions.
Fixes cctest/test-compiler/CompileFunctionInContext in the presence of
--enable-lazy-source-positions and --stress-lazy-source-positions.
Bug: v8:8510
Change-Id: I2402a441d4930be11dc037c6041cb577a63a3529
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709427
Commit-Queue: Dan Elphick <delphick@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63013}
This reverts commit df8e617772.
Reason for revert: Multiple flakes in apparently related areas:
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906409837768155568/+/steps/Check__flakes_/0/logs/BackingStoreTest.RacyGrowWasmMem.../0
Original change's description:
> "Reland x3 [arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of bc33f5aeba
>
> Original change's description:
> > [arraybuffer] Rearchitect backing store ownership
> >
> > This CL completely rearchitects the ownership of array buffer backing stores,
> > consolidating ownership into a {BackingStore} C++ object that is tracked
> > throughout V8 using unique_ptr and shared_ptr where appropriate.
> >
> > Overall, lifetime management is simpler and more explicit. The numerous
> > ways that array buffers were initialized have been streamlined to one
> > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > and the construction and destruction of the BackingStore object itself
> > handles the underlying page or embedder-allocated memory.
> >
> > The embedder API remains unchanged for now. We use the
> > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > keep the backing store alive properly, even in the case of aliases
> > from live heap objects. Thus the embedder has a lower chance of making
> > a mistake. Long-term, we should move the embedder to a model where they
> > manage backing stores using shared_ptr to an opaque backing store object.
>
> R=mlippautz@chromium.org
> BUG=v8:9380,v8:9221,chromium:986318
> TBR=ulan@chromium.org
>
> Change-Id: I6c49e2425029b5664ef1c68dab8b5146f4ed0ff2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719191
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63007}
TBR=mstarzinger@chromium.org,titzer@chromium.org,mlippautz@chromium.org
Change-Id: If0266e5893b1325a332d5986337fa7ece2cb6943
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9380, v8:9221, chromium:986318
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1729549
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63011}
This is a reland of 4b15b984ad
Updates since original: fix an arithmetic overflow bug, remove an invalid
DCHECK, add a unit test that would trigger that DCHECK.
Original change's description:
> [regexp] Better quick checks on loop entry nodes
>
> Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this
> change is inspired by attempting to exit earlier from generated RegExp
> code, when no further matches are possible because any match would be
> too long. The motivating example this time is the following expression,
> which tests whether a string of Unicode playing cards has five of the
> same suit in a row:
>
> /([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u
>
> A human reading this expression can readily see that any match requires
> at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for
> each repeated option reports its minimum distance to the end of a match
> as zero. This is correct, because the LoopChoiceNode's behavior depends
> on additional state (the loop counter). However, the preceding node, a
> SET_REGISTER action that initializes the loop counter, could confidently
> state that it consumes at least 10 characters. Furthermore, when we try
> to emit a quick check for that action, we could follow only paths from
> the LoopChoiceNode that are possible based on the minimum iteration
> count. This change implements both of those "could"s.
>
> I expect this improvement to apply pretty broadly to expressions that
> use minimum repetition counts and that don't meet the criteria for
> unrolling. In this particular case, I get about 12% improvement on the
> overall UniPoker test, due to reducing the execution time of this
> expression by 85% and the execution time of another similar expression
> that checks for n-of-a-kind by 20%.
>
> Bug: v8:9305
>
> Change-Id: I319e381743967bdf83324be75bae943fbb5dd496
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62963}
Bug: v8:9305
Change-Id: I992070d383009013881bf778242254c27134b650
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726674
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#63009}
This is a reland of 517ab73fd7
Updates since original: now compressed pointers passed to the function
GetObjectProperties are required to be sign-extended. Previously, the
function allowed zero-extended values, but that led to ambiguity on
pointers like 0x88044919: is it compressed or is the heap range actually
centered on 0x100000000?
Original change's description:
> Add postmortem debugging helper library
>
> This change begins to implement the functionality described in
> https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
> for investigating V8 state in crash dumps.
>
> This change adds a new library, v8_debug_helper, for providing platform-
> agnostic assistance with postmortem debugging. This library can be used
> by extensions built for debuggers such as WinDbg or lldb. Its public API
> is described by debug-helper.h; currently the only method it exposes is
> GetObjectProperties, but we'd like to add more functionality over time.
> The API surface is restricted to plain C-style structs and pointers, so
> that it's easy to link from a debugger extension built with a different
> toolchain.
>
> This change also adds a new cctest file to exercise some basic
> interaction with the new library.
>
> The API function GetObjectProperties takes an object pointer (which
> could be compressed, or weak, or a SMI), and returns a string
> description of the object and a list of properties the object contains.
> For now, the list of properties is entirely based on Torque object
> definitions, but we expect to add custom properties in future updates so
> that it can be easier to make sense of complex data structures such as
> dictionaries.
>
> GetObjectProperties does several things that are intended to generate
> somewhat useful results even in cases where memory may be corrupt or
> unavailable:
> - The caller may optionally provide a type string which will be used if
> the memory for the object's Map is inaccessible.
> - All object pointers are compared against the list of known objects
> generated by mkgrokdump. The caller may optionally provide the
> pointers for the first pages of various heap spaces, to avoid spurious
> matches. If those pointers are not provided, then any matches are
> prefixed with "maybe" in the resulting description string, such as
> "maybe UndefinedValue (0x4288000341 <Oddball>)".
>
> Bug: v8:9376
>
> Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62882}
Bug: v8:9376
Change-Id: I866a1cc9d4c34bfe10c7b98462451fe69763cf3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717090
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#63008}
This is a reland of bc33f5aeba
Original change's description:
> [arraybuffer] Rearchitect backing store ownership
>
> This CL completely rearchitects the ownership of array buffer backing stores,
> consolidating ownership into a {BackingStore} C++ object that is tracked
> throughout V8 using unique_ptr and shared_ptr where appropriate.
>
> Overall, lifetime management is simpler and more explicit. The numerous
> ways that array buffers were initialized have been streamlined to one
> Attach() method on JSArrayBuffer. The array buffer tracker in the
> GC implementation now manages std::shared_ptr<BackingStore> pointers,
> and the construction and destruction of the BackingStore object itself
> handles the underlying page or embedder-allocated memory.
>
> The embedder API remains unchanged for now. We use the
> v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> keep the backing store alive properly, even in the case of aliases
> from live heap objects. Thus the embedder has a lower chance of making
> a mistake. Long-term, we should move the embedder to a model where they
> manage backing stores using shared_ptr to an opaque backing store object.
R=mlippautz@chromium.org
BUG=v8:9380,v8:9221,chromium:986318
TBR=ulan@chromium.org
Change-Id: I6c49e2425029b5664ef1c68dab8b5146f4ed0ff2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719191
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63007}
Port 556e4859bb
Original Commit Message:
Instead of storing the values of the single precision floating point registers,
get their values from the aliased double precision registers.
This saves, on arm64, 184 bytes per deoptimisation kind function (552 in total)
and 128 bytes in the RegisterValues class.
R=joey.gouly@arm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: If38a721cfaefb7980902f4f963119cb88061e342
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726857
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#63006}
With the arrival of generic structs (https://chromium-review.googlesource.com/c/v8/v8/+/1714868) the existing type inference procedure for generic calls became incomplete, since it could not infer types that were only constrained as part of generic types. For instance, given
struct Box<T: Type> { ... }
macro unbox<T: type>(box: Box<T>): T
the type argument (Smi) at the following call site
const box: Box<Smi> = ...;
unbox(box);
could not be inferred.
This CL re-implements the inference procedure and documents the semantics of type argument inference in Torque a bit more clearly.
R=tebbi@chromium.org
Change-Id: I868f16afbd9864b9c810ac49bc1639b467df939c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720812
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63005}
Removes static modifier from global inline functions defined in
globals.h.
R=rmcilroy@chromium.org
Bug: v8:9396
Change-Id: Ieacbcbf592d219fb50ab2d23dfbaba27246fb7ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728610
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63004}
On Windows ARM64, OS stack walking does not work because the V8 ARM64 backend
doesn't emit unwinding info and also because it doesn't emit ABI compliant
stack frames. This was fixed for Windows X64 (https://crrev.com/c/1469329) and
documented below:
https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0
This problem can be fixed similarly for Windows ARM64 by observing that V8
frames usually all have the same prolog which maintains a chain via frame
pointer (fp or x29 register).
stp fp, lr, [sp, ...]
One exception is JSEntry which stops fp pointer chain and needs to be handled
specially.
So it is possible to define XDATA with UNWIND_CODE which specify how Windows
should walk through V8 dynamic frames. The same as X64, since V8 Code objects
are all allocated in the same code-range for an Isolate, it is possible to
register at most 2 XDATA and a group of PDATA entries to cover stack walking
for all the code generated inside that code-range. This is more than 1
PDATA/XDATA because according to the Windows ARM64 exeption handling document,
1 PDATA can cover less than 1MB code range (see below doc).
https://docs.microsoft.com/en-us/cpp/build/arm64-exception-handling
This PR implements stackwalk for Windows ARM64 to be on par with X64, including
embedded builtins, jitted code and wasm jitted code, but not including register
handler for handling exception only, because there is no backward compatibility
to maintain for Windows ARM64 which was released since 1709 windows build.
Bug: chromium:893460
Change-Id: Ic74cbdad8af5cf342185030a4c53796f12ea5429
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701133
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63002}
The s390 port uses the auxvector APIs to detect hardware/OS
support for various z/Architecture features. These checks
only make sense if we are running native, non-simulator mode.
Moving the include<auxv.h> under V8_HOST_ARCH_S390 enables
compilation of s390 simulation on platforms that do not have auxv.h
header available.
R=miladfar@ca.ibm.com,jyan@ca.ibm.com
Change-Id: I685681a4f8786509beb181d8ae63876b3a4235b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726844
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Joran Siu <joransiu@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#62999}
port 556e485https://crrev.com/c/1669687
Original Commit Message:
Instead of storing the values of the single precision floating point registers,
get their values from the aliased double precision registers.
This saves, on arm64, 184 bytes per deoptimisation kind function (552 in total)
and 128 bytes in the RegisterValues class.
Change-Id: Ic178de717d27a63b3f510b3a93e8f33a1730dc8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725669
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Yu Yin <xwafish@gmail.com>
Cr-Commit-Position: refs/heads/master@{#62998}
REX prefix should be after mandatory prefix and before opcode.
Change-Id: I9829384d7d617d3be203026ae84ffa30aaef6d2e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726983
Commit-Queue: Bill Budge <bbudge@chromium.org>
Auto-Submit: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62997}
Original CL:
> [wasm] Simplify module creation
>
> This includes WasmEngine::NewNativeModule() and
WasmModuleObject::New().
> The intent is to make the various ways of creating a module (sync,
> async, deserialize, import) more similar.
>
> After this change, a NativeModule will always be created before a
> WasmModuleObject. This will make it easier to look up a cached
> NativeModule given its wire bytes.
>
> The following changes are made:
>
> * Use WasmCodeManager::EstimateNativeModuleCodeSize() to find the code
> size estimate by default. A different code size estimate is only
used in
> tests.
> * Change CompileJsToWasmWrappers() to allocate a new FixedArray
instead of
> assuming the array was created with the correct size. This
simplifies
> WasmModuleObject::New(), and matches what CompileToNativeModule()
> does.
> * Remove the WasmModuleObject::New() constructor that creates a
> NativeModule. This case was only used in DeserializeNativeModule()
and
> in test code.
>
> Change-Id: I6bdfc425057f92de11abbbf702d052d40aa8267d
> Reviewed-on:
https://chromium-review.googlesource.com/c/v8/v8/+/1717497
> Commit-Queue: Ben Smith <binji@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62925}
R=ahaas@chromium.org, clemensh@chromium.orgCC=binji@chromium.org
Change-Id: I03aa901a1df65af28f864d9aabe2b134ea132e99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724213
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62996}
The DCHECK related to a time when dictionary mode prototypes were the payload
of complex data driven handlers. Now the additional data is used to hold
entirely different kinds of objects. The DCHECK made no sense anymore. Cleaning
up the names makes this clearer.
Bug: chromium:986187
Change-Id: I7173d7d2824396c04c01acb4ceb74693ee9ce6b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724215
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62993}
D8 workers were leaking all messages due to a missing HandleScope
within the message loop. Add one to fix leaks.
R=verwaest@chromium.org
BUG=v8:9524
Change-Id: I2f2f6ba0b8c58bf38bf68b7464dffdf1d826a29d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724212
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62992}
Do not pass the deoptimization index in a register, instead infer it
from the address we made the deoptimization call from. This makes the
deoptimization exit sequence one instruction long instead of two.
This requires emitting all deoptimization exits at the end of the
function in a contiguous block, making sure no constant or veneer
pools are emitted in between. This means that soft deoptimizations
require an additional branch to the end of the function, which
counteracts the removal of the move instruction, however soft
deoptimizations are rare compared to eager and lazy ones.
This reduces the code size of optimised functions for benchmarks like
Octane and ARES-6 by about 4%.
Change-Id: I771f9104a07de7931a4bb9c5836e25fb55b1a2a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714876
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62991}
This patch adds:
- VariableMode::kPrivateMethod
- VariableMode::kPrivateSetterOnly
- VariableMode::kPrivateGetterOnly
- VariableMode::kPrivateGetterAndSetter
And replace the previous RequiresBrandCheckFlag by inferring
whether the brand check is required from these VariableModes.
It is then possible to check duplicate non-complementary
accessors in the parsers and throw early errors, and allow
complementary accessors to be associated with the same
private name variable.
This patch also adds the following AssignType:
- PRIVATE_METHOD
- PRIVATE_GETTER_ONLY
- PRIVATE_SETTER_ONLY
- PRIVATE_GETTER_AND_SETTER
corresponding to the new VariableModes so that it's possible
to generate specialized code for different type of
private accessor declarations.
Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit
Bug: v8:8330
Change-Id: I0fb61b1be248630d1eadd74fb16d7d64a421f4c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695204
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62988}
On Windows, the FP stack registers are used with less precision.
This causes rounding errors in the uint64 to float32 conversion.
This CL replaces the implementation based on FP stack registers
with an implementation based on bit operations. This implementation
is 2x slower than the original implementation.
An alternative would be to change the precision of the FP stack
registers just for the uint64 to float32 conversion. However, in a
micro-benchmark this is 5-6x slower than the original implementation.
It is also not clear if changing the precision could cause side
effects.
R=clemensh@chromium.org
Change-Id: Iaab6b6f258ff01e0c6e93f3632daf516fae3e74b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708486
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62986}
Previously, this was run as a microtask and this CL changes it to run
as a separate task as mandated by the current WeakRef spec.
This CL also introduces a FinalizationGroup type to the V8 API
representing the JSFinalizationGroup. This has a `Cleanup`
function that runs the cleanup callback associated with it.
SetHostCleanupFinalizationGroupCallback is added to set
the embedder defined HostCleanupFinalizationGroupCallback.
ClearKeptObject is exposed on the v8::Isolate to reset the strongly
held set of objects.
The general workflow is the following:
(a) When the GC notices that a given finalization group has dirty
cells, it calls HostCleanupFinalizationGroupCallback with the given
finalization group.
(b) As part of HostCleanupFinalizationGroupCallback, the embedder
enqueues a task that at some point later calls
FinalizationGroup::Cleanup.
(c) At some point in the future, FinalizationGroup::Cleanup is called,
which runs the cleanup callback of the finalization group.
This patch also includes d8 changes to use these new APIs. Currently,
d8 cycles through the enqueued finalization groups after a synchronous
turn (and it's microtask checkpoint) and runs the cleanup callbacks.
Change-Id: I06eb4da2c103b2792a9c62bc4b98fd4e5c4892fc
Bug: v8:8179
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655655
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62984}
This drops possible remaining pattern errors from the access target. This is
necessary since sub patterns with default values (assignment expression) aren't
otherwise identifiable as being property accesses.
Bug: v8:9560
Change-Id: Ie6781c0d161e00790268f7d9db81377d045f93b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725624
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62982}
FLAG_max_semi_space_size could be used to allow arbitrarily huge semi
spaces. Limit semi space size to kMaxSemiSpaceSize also in the case
this flag is used.
Change-Id: Id52cea6ef73eb1957265cf38c109dd490d7feccc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725618
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62980}
This allows to return bool values from Torque macros and branch on them
without performance penalty, reconstructing good control flow.
Drive-by cleanup: Delete EnsureDeferredCodeSingleEntryPoint(), since
it's no longer needed. Constructing a graph and then re-inferring
deferred blocks based on branch hints achieves this effect
automatically.
Bug: v8:7793
Change-Id: Idb6802372b407549e4760f290933d5b8f1e9d952
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1681132
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62979}
Object::Get, Set, etc. properly invoke an interceptor
registered via SetAccessCheckCallbackAndHandler, however,
Object::GetOwnPropertyDescriptor does not invoke
an interceptor.
This patch supports access-check-interceptor for
descriptors.
Change-Id: Ie2b2f2456be95c6eef8c2cdfee2bdd651c011fa3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720969
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Yuki Shiino <yukishiino@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62978}
This reverts commit 4b15b984ad.
Reason for revert: UBSan failure (https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906578530303352544/+/steps/Check/0/logs/regress-126412/0).
Original change's description:
> [regexp] Better quick checks on loop entry nodes
>
> Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this
> change is inspired by attempting to exit earlier from generated RegExp
> code, when no further matches are possible because any match would be
> too long. The motivating example this time is the following expression,
> which tests whether a string of Unicode playing cards has five of the
> same suit in a row:
>
> /([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u
>
> A human reading this expression can readily see that any match requires
> at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for
> each repeated option reports its minimum distance to the end of a match
> as zero. This is correct, because the LoopChoiceNode's behavior depends
> on additional state (the loop counter). However, the preceding node, a
> SET_REGISTER action that initializes the loop counter, could confidently
> state that it consumes at least 10 characters. Furthermore, when we try
> to emit a quick check for that action, we could follow only paths from
> the LoopChoiceNode that are possible based on the minimum iteration
> count. This change implements both of those "could"s.
>
> I expect this improvement to apply pretty broadly to expressions that
> use minimum repetition counts and that don't meet the criteria for
> unrolling. In this particular case, I get about 12% improvement on the
> overall UniPoker test, due to reducing the execution time of this
> expression by 85% and the execution time of another similar expression
> that checks for n-of-a-kind by 20%.
>
> Bug: v8:9305
>
> Change-Id: I319e381743967bdf83324be75bae943fbb5dd496
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62963}
TBR=jgruber@chromium.org,seth.brenith@microsoft.com
Change-Id: Iac085b75e054fdf0d218987cfe449be1f1630545
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9305
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725621
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62977}
Currently, each single CSA_ASSERT invokation creates its own lambda,
which is then wrapped in a {std::function} and passed to
{CodeStubAssembler::Assert}. It takes a lot of compile time for clang
to generate all the code for that.
This CL introduces a more light-weight alternative to
{CodeStubAssembler::Assert} which just receives the node directly.
This reduces compile time of {code-stub-assembler.cc} in optdebug mode
from ~30 seconds to ~17 seconds locally.
R=tebbi@chromium.org
Bug: v8:7629
Change-Id: I4520a7b587cb96319d75048cf11c1124be583d6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724370
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62976}
This fixes a build failure for arm64 on Windows.
Bug: v8:9564
Change-Id: I845b7687379ae12c27fa2924775553c83dc5d1ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724386
Commit-Queue: Richard Townsend <richard.townsend@arm.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62975}
This is a reland of a0728e869b
Original change's description:
> [d8] Remove maximum workers limitation
>
> This CL refactors the lifetime management of the v8::Worker C++ object
> and in the process lifts the 100 maximum worker limitation. To do this,
> it uses a Managed<v8::Worker> heap object and attaches the managed to
> the API worker object.
>
> R=mstarzinger@chromium.org
> BUG=v8:9524
>
> Change-Id: I279b7aeb6645a87f9108ee6f572105739721cef4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715453
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62932}
Bug: v8:9524
Change-Id: I7d903fb12ddb00909a9429455f46c55db2fd02de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722562
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62974}
We can get repeated positions from optimized code objects in some cases
but for our purposes of looking up a line number from a PC, we can only
return one line number so just use the first one that is reported in
the source position table on the code object.
Change-Id: I4c0e866fb1948f65bf6c988d992ef55f520dd874
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724375
Reviewed-by: Alexei Filippov <alph@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62972}
-0.0 and 0.0 compare equals, so a < b ? a : b for min would pick b
incorrectly. We need to use JS semantics here, which returns -0.0.
Bug: v8:8425
Change-Id: I8ab094b566ece9c586de86aad4594dfdf8da930b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724802
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62969}
Serialize for all cases of JSNativeContextSpecialization::ReduceJSInstanceOf.
Bug: v8:7790
Change-Id: I147991353b86619808257a92961b7051105511f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722558
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62965}
Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this
change is inspired by attempting to exit earlier from generated RegExp
code, when no further matches are possible because any match would be
too long. The motivating example this time is the following expression,
which tests whether a string of Unicode playing cards has five of the
same suit in a row:
/([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u
A human reading this expression can readily see that any match requires
at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for
each repeated option reports its minimum distance to the end of a match
as zero. This is correct, because the LoopChoiceNode's behavior depends
on additional state (the loop counter). However, the preceding node, a
SET_REGISTER action that initializes the loop counter, could confidently
state that it consumes at least 10 characters. Furthermore, when we try
to emit a quick check for that action, we could follow only paths from
the LoopChoiceNode that are possible based on the minimum iteration
count. This change implements both of those "could"s.
I expect this improvement to apply pretty broadly to expressions that
use minimum repetition counts and that don't meet the criteria for
unrolling. In this particular case, I get about 12% improvement on the
overall UniPoker test, due to reducing the execution time of this
expression by 85% and the execution time of another similar expression
that checks for n-of-a-kind by 20%.
Bug: v8:9305
Change-Id: I319e381743967bdf83324be75bae943fbb5dd496
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62963}
Fixes a bytecode mismatch for arrow functions with default arguments
between eager and lazy compilation. In the former case, parameters with
default values are marked as assigned even if the value never changes
within the function because the parser does not know it's an
arrow-function at the point it sees the assignment.
So this changes ArrowHeadParsingScope::ValidateAndCreateScope to clear
the is_assigned flag on its parameter VariableProxies before it binds
them.
Bug: chromium:988304, v8:8510
Change-Id: I68bf205c73471386181e5fdcec6c8c3b2e527c8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724384
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62962}
Instead of storing the values of the single precision floating point registers,
get their values from the aliased double precision registers.
This saves, on arm64, 184 bytes per deoptimisation kind function (552 in total)
and 128 bytes in the RegisterValues class.
Change-Id: I681ad46efbb610e94d1e45871e012d2c0a3cfa3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669687
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62961}
This is a reland of 658ff20085
Original change's description:
> [utils] Make BitField final
>
> We have hundreds of classes that derive from {BitField} without adding
> any functionality. This CL switches all such occurrences to 'using'
> declarations instead.
>
> Before:
> class MyBitField : public BitField<int, 6, 4, MyEnum> {};
> After:
> using MyBitField = BitField<int, 6, 4, MyEnum>;
>
> This might reduce compilation time by reducing the number of existing
> classes.
>
> The old pattern is forbidden now by making {BitField} final.
>
> R=yangguo@chromium.org
>
> Bug: v8:9396, v8:7629
> Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62956}
Bug: v8:9396, v8:7629
Change-Id: Ic68541af9d1e8d0340691970922f282b24a9767f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724379
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62959}
This reverts commit 658ff20085.
Reason for revert: Fails no-i18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/27826
Original change's description:
> [utils] Make BitField final
>
> We have hundreds of classes that derive from {BitField} without adding
> any functionality. This CL switches all such occurrences to 'using'
> declarations instead.
>
> Before:
> class MyBitField : public BitField<int, 6, 4, MyEnum> {};
> After:
> using MyBitField = BitField<int, 6, 4, MyEnum>;
>
> This might reduce compilation time by reducing the number of existing
> classes.
>
> The old pattern is forbidden now by making {BitField} final.
>
> R=yangguo@chromium.org
>
> Bug: v8:9396, v8:7629
> Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62956}
TBR=yangguo@chromium.org,clemensh@chromium.org
Change-Id: I50234a09c77aa89fdcf1e01c2497cc08d3ac79a8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9396, v8:7629
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724377
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62958}
We have hundreds of classes that derive from {BitField} without adding
any functionality. This CL switches all such occurrences to 'using'
declarations instead.
Before:
class MyBitField : public BitField<int, 6, 4, MyEnum> {};
After:
using MyBitField = BitField<int, 6, 4, MyEnum>;
This might reduce compilation time by reducing the number of existing
classes.
The old pattern is forbidden now by making {BitField} final.
R=yangguo@chromium.org
Bug: v8:9396, v8:7629
Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62956}
Prefer using the wasm engine's allocator, as the isolate may not be
available during asynchronous compilation.
Bug: v8:9554
Change-Id: Iee3777efb62d18de6b2a64fa7a71d4ef4c6b3a92
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722559
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62955}
This makes function objects constructed via the {WebAssembly.Function}
constructor callable directly from JavaScript (not just from within
WebAssembly modules). Semantics are as if the function performed the
transition JS-to-Wasm and then Wasm-to-JS in sequence.
R=clemensh@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: Ic7dcf36ccfda1b473f2541e49419f4d2ee38bc2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720809
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62953}
The preprocessor of MSVC works differently for empty __VA_ARGS__.
Another hack is needed to make this compile in both MSVC and clang.
R=tebbi@chromium.org
Bug: v8:9555
Change-Id: Ie8f2e1ed302730419dae95e49ab0cca35a4a8131
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720669
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62952}
In export wrapper compilation, the isolate was used to get enabled
features. This prevents asynchronous compilation, so this is replaced
with an enabled_features argument passed from the main thread.
R=mstarzinger@chromium.org
Bug: v8:9554
Change-Id: Iab8a090841170dc235273dda58997cde716ee13f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722554
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62949}
Prior to this CL, the regexp fast path check is stricter than it
needs to be. For example, adding any arbitrary property on the regexp
prototype would move the execution of all regexp builtins in the same
context onto the slow path. This actually happens in the real world:
popular web frameworks commonly monkey-patch builtin prototypes to add
functionality.
The intent of this CL is to widen the fast path for regexp builtins s.t.
modifications of the prototype that do not conflict with our
requirements stay on the fast path.
This is done by extending the current fast path check with an
additional step. If checking the prototype map identity or
relevant prototype property constness fails, we now compare the actual
value of all relevant properties against the expected value. If these
match, the prototype can be considered fast.
The new step as described in the previous paragraph is part of the
permissive fast path check (BranchIfFastRegExp_Permissive). The strict
variant (BranchIfFastRegExp_Strict) is also still required by a few
spots. We should refactor these to also allow the permissive check in
follow-up work.
Bug: v8:5577,chromium:977382
Change-Id: I69b2244e68ccfbd00edf17fc326aa4b5f5d089fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706056
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62948}
In export wrappers generated code, load the undefined value from the
wasm instance rather than from the isolate. With asynchronous
compilation, the isolate may not be available.
R=mstarzinger@chromium.org
Bug: v8:9554
Change-Id: Ic448bda82c2125fc9c9f8715bce26870308715d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722556
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62946}
Implements ProfilerCodeObserver, a class to track the generation and
movement of code on the heap for the lifetime of each CpuProfiler. When
sampling is inactive, logged code is committed directly to the CodeMap.
During profiling, ProfilerCodeObserver redirects these events onto the
profiling thread for later dispatch.
Bug: v8:9151
Change-Id: Ib5b152446d2a3838e1b00a80253fc4fbd2f6e8c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1604143
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Cr-Commit-Position: refs/heads/master@{#62943}
This change updates the RegExp bytecode generator to emit checks for
larger eats_at_least values when they are available, so we can fail to
match earlier in some cases.
Bug: v8:9305
Change-Id: I96740531e142ff8dced41c49b774845b07df6ae6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709768
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62942}
In some cases, we end up with a ChangeCompressedPointerToTaggedPointer next
to a CheckedTaggedToTaggedPointer. In this case, the checked one is not
needed since we are sure we are dealing with a pointer (and not a Smi).
This doesn't get resolved in the simplfied lowering phase due to having a
Phi[Tagged] in the middle of those two nodes.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:7703
Change-Id: Ia4a44b36423c2242d5c663f9b93b09924190fe8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709426
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62941}
If we are sure that we are dealing with a Compressed value, we can check
for sminess in 32 bits.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:7703
Change-Id: Icf77d8bcd1decfd392b4887241a9b559f11814c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1718146
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62940}
This CL removes the built-in reference type in favor of a Torque-implemented generic struct, i.e., internal::Reference<T>. It also adds various infrastructure for getting and creating new generic struct instances, as well as matching against them.
R=tebbi@chromium.org
Change-Id: I1e3d6afe355a0603fa9c3ad789c6b8a97d1b3c26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1718148
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62939}
The propagation of tenuring from outer allocations to inner allocations
was blocked in pointer compression since we now had Compress nodes between
AllocateRaw and StoreField.
This was causing issues in GC. It popped up in the Octane2.1/Splay
benchmark, where we had big regressions.
This CL updates the memory optimizer so that it can use the Compress nodes
as bridges and can perform the optimization successfully. Note that the
Compress nodes only appear on the value input of the StoreField.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:7703, v8:9519
Change-Id: I6b0cc67955c6cc696e8c426b85c87a1794098ed0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714650
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62938}
This reverts commit a0728e869b.
Reason for revert: Times out on Windows & debug builds - https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20nosnap%20-%20shared/34484
Original change's description:
> [d8] Remove maximum workers limitation
>
> This CL refactors the lifetime management of the v8::Worker C++ object
> and in the process lifts the 100 maximum worker limitation. To do this,
> it uses a Managed<v8::Worker> heap object and attaches the managed to
> the API worker object.
>
> R=mstarzinger@chromium.org
> BUG=v8:9524
>
> Change-Id: I279b7aeb6645a87f9108ee6f572105739721cef4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715453
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62932}
TBR=mstarzinger@chromium.org,titzer@chromium.org,clemensh@chromium.org
Change-Id: I3a27937cba13b5413390f49268a107c184515153
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9524
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720590
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62937}
Use the position of commas in arrow expressions to mark the initializer
position of any parameters that might have been set in the preceding
parameter.
To enable this, this makes variable_list_ in ExpressionParsingScope a
ScopedList<pair<VariableProxy*, int>> and changes ScopedList::at to
return references so its elements can be modified in place.
This fixes a source of bytecode mismatches when collecting source
positions lazily and is a second attempt at fixing this after
https://chromium-review.googlesource.com/c/v8/v8/+/1683267 introduced
problems due to destructuring.
Bug: chromium:980422, chromium:981701, v8:8510
Change-Id: I948f89f34fb75d7463a13183e363f7f96ad09d13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710671
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62936}
This reverts commit 1320c917dd.
Reason for revert: The code in SFI is also flushed by the serializer with FunctionCodeHandling::kClear, so this fix does not work with --no_flush_bytecode.
Original change's description:
> [snapshot] Fix clearing of feedback vector in serializer (follow-up 2)
>
> Bug: v8:7857
> Change-Id: I3940ae2830adb6c572e079551b7bba7d84462afd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715444
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62881}
TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7857
Change-Id: If85fe29b2cdf6523ee53895628da38d942d45c2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719190
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62935}
This CL refactors the lifetime management of the v8::Worker C++ object
and in the process lifts the 100 maximum worker limitation. To do this,
it uses a Managed<v8::Worker> heap object and attaches the managed to
the API worker object.
R=mstarzinger@chromium.org
BUG=v8:9524
Change-Id: I279b7aeb6645a87f9108ee6f572105739721cef4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715453
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62932}
... mostly by turning them into pointer arguments.
After this CL, all remaining non-const reference arguments in
the compiler directory are in the backend.
Bug: v8:9429
Change-Id: I6a546da0fe93179e1a0b12296632591cbf209808
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719185
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62930}
This reverts commit 425fa3ae15.
Reason for revert: test failure https://bugs.chromium.org/p/v8/issues/detail?id=9554 reverting the root cause has merge conflicts due to changes in same file
Original change's description:
> [wasm] Simplify module creation
>
> This includes WasmEngine::NewNativeModule() and WasmModuleObject::New().
> The intent is to make the various ways of creating a module (sync,
> async, deserialize, import) more similar.
>
> After this change, a NativeModule will always be created before a
> WasmModuleObject. This will make it easier to look up a cached
> NativeModule given its wire bytes.
>
> The following changes are made:
>
> * Use WasmCodeManager::EstimateNativeModuleCodeSize() to find the code
> size estimate by default. A different code size estimate is only used in
> tests.
> * Change CompileJsToWasmWrappers() to allocate a new FixedArray instead of
> assuming the array was created with the correct size. This simplifies
> WasmModuleObject::New(), and matches what CompileToNativeModule()
> does.
> * Remove the WasmModuleObject::New() constructor that creates a
> NativeModule. This case was only used in DeserializeNativeModule() and
> in test code.
>
> Change-Id: I6bdfc425057f92de11abbbf702d052d40aa8267d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717497
> Commit-Queue: Ben Smith <binji@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62925}
TBR=binji@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: I8dcad7ddcd4601f657b6263bf22009907284fce3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719230
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62926}
This includes WasmEngine::NewNativeModule() and WasmModuleObject::New().
The intent is to make the various ways of creating a module (sync,
async, deserialize, import) more similar.
After this change, a NativeModule will always be created before a
WasmModuleObject. This will make it easier to look up a cached
NativeModule given its wire bytes.
The following changes are made:
* Use WasmCodeManager::EstimateNativeModuleCodeSize() to find the code
size estimate by default. A different code size estimate is only used in
tests.
* Change CompileJsToWasmWrappers() to allocate a new FixedArray instead of
assuming the array was created with the correct size. This simplifies
WasmModuleObject::New(), and matches what CompileToNativeModule()
does.
* Remove the WasmModuleObject::New() constructor that creates a
NativeModule. This case was only used in DeserializeNativeModule() and
in test code.
Change-Id: I6bdfc425057f92de11abbbf702d052d40aa8267d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717497
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62925}
- Move SerializePrototype out of DependOnStablePrototypes into
ComputePropertyAccessInfo.
- Brokerize JSNativeContextSpecialization::InferHasInPrototypeChain.
- Brokerize JSNativeContextSpecialization::ReduceJSOrdinaryHasInstance
(modulo the call to ReduceJSInstanceOf).
- Brokerize JSNativeContextSpecialization::ReduceJSHasInPrototypeChain.
- Serialize for JSCallReducer::ReduceObjectPrototypeIsPrototypeOf.
- Serialize for JSNativeContextSpecialization::ReduceJSInstanceOf. This
is still incomplete.
Bug: v8:7790
Change-Id: Ic56eab5ddd8d725a13d2980e5b55db53ae82e822
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709408
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62920}
The motivating example is JetStream 2's UniPoker test, which tests
whether a sorted string of Unicode playing cards contains a five-card
straight using a regular expression. In the top-level generated loop for
this RegExp, we see this loop exit condition:
00000350000C2067 27 83fffe cmpl rdi,0xfe
00000350000C206A 2a 0f8da8e40000 jge 00000350000D0518 <+0xe4d8>
Meaning if the current position is pointing at the very last (16-bit)
character, then we exit the loop. Otherwise we go on and try to find
various matches starting at the current position. However, we can see
in the original expression that any possible match is at least 10
characters (5 astral-plane Unicode values), so we're wasting a lot of
time attempting to find matches in cases where we're too close to the
end of the string for any match to succeed.
This example might be a bit contrived, but I expect that an improvement
in this bounds check would help a larger family of regular expressions,
where the minimum match length is large relative to the string being
matched and we don't meet the other necessary criteria for fast Boyer-
Moore lookahead.
To get the desired bounds check in this case, this patch does the
following:
1. Compute accurate EatsAtLeast values for every node during the
analysis phase. This could end up doing more work than the current
implementation, but analysis already has to touch every node, so it
seems like a cache-friendly time to compute these values. In some
cases, this might be less total work than the current implementation,
because the current implementation might recompute the same node
multiple times.
2. When emitting a quick check, use the EatsAtLeast value from the
predecessor ChoiceNode for the bounds check.
This improves the UniPoker score on my machine by about 4%, because it
cuts the time spent checking for straights roughly in half, and checking
for straights originally accounted for about 8% of the total time.
Bug: v8:9305
Change-Id: I110b190c2578f73b2263259d5aa5750e921b01be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1702125
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62919}
Avoids unnecessary compression and decompression nodes since we
are going to be able to check for smis without needing to decompress and
re-compress.
It was doing a CheckedInt32ToTaggedSigned ->
ChangeTaggedSignedToCompressedSigned combo, where we could just do
CheckedInt32ToCompressedSigned.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:7703
Change-Id: I0bbbbb5bd4744c49840c84b2fcb775fe6b603de0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714878
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62917}
Distinguish between generic Tagged and Smi in-object fields, and special
case (boxed) double values and string data rather than lumping those
into generic "raw data"
Change-Id: I5d635434ab94065c077a40110948424c31ead73d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1718154
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62914}
Per the July TC39 meeting consensus, we'd like to make the
upcoming String.prototype.replaceAll proposal throw for
non-global RegExp searchValues. However,
String.prototype.matchAll currently does not throw in this
case, causing consistency concerns.
This patch adds a use counter for String.prototype.matchAll
with a non-global RegExp as the searchValue. Hopefully, this
pattern isn't too common in real-world code today, in which case
we can both a) change matchAll and b) proceed with the desired
replaceAll semantics.
https://github.com/tc39/proposal-string-replaceall/issues/16
V8 CL: https://chromium-review.googlesource.com/c/v8/v8/+/1718145
Chromium CL: https://chromium-review.googlesource.com/c/chromium/src/+/1718367
BUG=v8:9551
Change-Id: Ica660a0a6189d84c3d33398c98305d0bcb9f8c23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1718145
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62913}
When iterating over fields to copy, we should copy kTagged-sized fields,
not kPointer-sized fields, to avoid overwriting something allocated after
the last slot of an object if the end of the object isn't kPointer
aligned.
Bug: v8:8948
Change-Id: Ic3d933157ca1962a779dba6ae58facb558d75ca0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1718151
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62912}
If a new code allocation request cannot be fulfilled, do not just
reserve enough to fulfill this one request, but request at least 20
percent of the total reserved code space so far. This ensures that
the reserved space grows exponentially instead of linearly.
R=mstarzinger@chromium.org
Bug: chromium:987560
Change-Id: I3fc4dd0f7acee2a380495a87c0425c58058551bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1718144
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62910}
The two inputs are a Word32And and an Int32Constant. There is no need to
do this in 64 bits.
Bug: v8:9396
Change-Id: Ie564ac2f43e98192bf9853855b6c766248264886
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715462
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62909}
Port 5564356https://crrev.com/c/1714656
Original Commit Message:
This removes a shortcut to a "CEntryStub" from the instance object and
instead loads those values via the root set which is also referenced
from the instance. It makes instance objects smaller.
Change-Id: I62d16960cb18e3cd69c2fa56da85a6bfc6064db4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1716473
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Yu Yin <xwafish@gmail.com>
Cr-Commit-Position: refs/heads/master@{#62907}
This is a reland of c2ee4a7999
Original change's description:
> Reland "[regexp] Call the regexp interpreter without CEntry overhead"
>
> This is a reland of d4d28b73cb
>
> Original change's description:
> > [regexp] Call the regexp interpreter without CEntry overhead
> >
> > Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
> >
> > This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
> >
> > Bug: v8:8954
> > Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
> > Commit-Queue: Patrick Thier <pthier@google.com>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#62753}
>
> Bug: v8:8954
> Change-Id: I1f0b6de9c6da65bcb582ddb41a37419116a5c510
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706053
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Patrick Thier <pthier@google.com>
> Cr-Commit-Position: refs/heads/master@{#62794}
Bug: v8:8954
Change-Id: Ice77c05240f1fabd36bf97b8e789dd4c25a9718f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715451
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62904}
Add 'fluid-ounce','gallon', 'liter', and 'milliliter'
Also roll ICU to 682a2309
Sync with https://github.com/tc39/proposal-unified-intl-numberformat/pull/48
Bug: v8:9475
Change-Id: If45a20f17f5973b860893b0f70e724cc93c6550a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1699759
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62903}
During Module::Reset(), the module is in an unstable state between the
change to SourceTextModule::code and Module::status. Any reentrancy
between these points is problematic because the normal invariants about
the value of SourceTextModule::code in relation to Module::status do not
hold.
An allocation of the exports hash table in the middle of Module::Reset()
was causing reentrancy during this problematic time. This change fixes
the issue by moving the allocation earlier in Reset() before any fields
are modified.
Bug: v8:9522
Change-Id: Ia941af60a0b31f05a6d8da610b9a270e7f79dac2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1712449
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#62902}
This reverts commit 517ab73fd7.
Reason for revert: Test failures https://bugs.chromium.org/p/v8/issues/detail?id=9538
Original change's description:
> Add postmortem debugging helper library
>
> This change begins to implement the functionality described in
> https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
> for investigating V8 state in crash dumps.
>
> This change adds a new library, v8_debug_helper, for providing platform-
> agnostic assistance with postmortem debugging. This library can be used
> by extensions built for debuggers such as WinDbg or lldb. Its public API
> is described by debug-helper.h; currently the only method it exposes is
> GetObjectProperties, but we'd like to add more functionality over time.
> The API surface is restricted to plain C-style structs and pointers, so
> that it's easy to link from a debugger extension built with a different
> toolchain.
>
> This change also adds a new cctest file to exercise some basic
> interaction with the new library.
>
> The API function GetObjectProperties takes an object pointer (which
> could be compressed, or weak, or a SMI), and returns a string
> description of the object and a list of properties the object contains.
> For now, the list of properties is entirely based on Torque object
> definitions, but we expect to add custom properties in future updates so
> that it can be easier to make sense of complex data structures such as
> dictionaries.
>
> GetObjectProperties does several things that are intended to generate
> somewhat useful results even in cases where memory may be corrupt or
> unavailable:
> - The caller may optionally provide a type string which will be used if
> the memory for the object's Map is inaccessible.
> - All object pointers are compared against the list of known objects
> generated by mkgrokdump. The caller may optionally provide the
> pointers for the first pages of various heap spaces, to avoid spurious
> matches. If those pointers are not provided, then any matches are
> prefixed with "maybe" in the resulting description string, such as
> "maybe UndefinedValue (0x4288000341 <Oddball>)".
>
> Bug: v8:9376
>
> Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62882}
TBR=yangguo@chromium.org,mvstanton@chromium.org,jgruber@chromium.org,tebbi@chromium.org,seth.brenith@microsoft.com
Change-Id: Ia078f2e8d101d2375b5db88021b2d65d28f1b075
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9376
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1716033
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62899}
This will allow us to use ScopedPtrList for other contents than just
pointers.
Change-Id: Ib16d388d5dd556f5e01593279f463ae25510f2be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715455
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62898}
Port 55643564a6
Original Commit Message:
This removes a shortcut to a "CEntryStub" from the instance object and
instead loads those values via the root set which is also referenced
from the instance. It makes instance objects smaller.
R=mstarzinger@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I2ad2f3479431dae71f47af7ad5c722e46fd592d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1716368
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#62897}
This is a reland of 7ba8e662cc
Fixed unresolved symbol error on CFI build.
Original change's description:
> [turbofan] Make code and comment match in FastFunctionPrototypeBind
>
> Additionally, used number of own descriptors in both CSA and the
> reduction of Function.prototype.bind.
>
> Change-Id: I7b86e059d20faa1160cdc0126932fff924226eee
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714655
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62885}
Change-Id: If4d6b4c963a089dca09dd9aa9ec94784b3a21825
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715450
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62894}
This flag ensures that all allocations are performed in the old generation. This only works when inline allocation and allocation folding are both disabled.
Bug: v8:9533
Change-Id: I9ad5e8bf492c43603ab2a4a1292198e1b9882dfe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710335
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62893}
Retrieving the source position for a JavaScript stack frame is a
costly operation (it requires decoding the source position table).
The source position is usually retrieved twice, once for the line
number, and once for the column number.
This CL caches the resolved source position the first time around,
improving relevant stack trace serialization micro benchmarks by ~6%.
R=jgruber@chromium.org
Bug: v8:8742
Change-Id: Ife9903208d2be100e272ccad805a77c33e0df93a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715447
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62891}
The if above asks for field_representation to have Compressed or Any
Machine Representation. Therefore, it can never be Signed.
The functionality doesn't change. If field_representation is Signed,
it will hit the kNoWriteBarrier at the bottom.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:9396
Change-Id: I39eff3ae082e91d0494134b053c353a2c0ff02c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1702615
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62890}
This removes dead code handling register arguments to runtime calls,
which do not exist currently.
R=mstarzinger@chromium.org
Change-Id: Ia5fdd60d0036f87a335bbe42b5790d1b86aa0add
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715448
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62889}
This removes a shortcut to a "CEntryStub" from the instance object and
instead loads those values via the root set which is also referenced
from the instance. It makes instance objects smaller.
R=clemensh@chromium.org
Change-Id: I2e77cf2cb6949873bb461fb1ed0787e4a413aa5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714656
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62888}
If we already know it has CompressedPointer representation, let's use
that information to decompress more efficiently.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:7703
Change-Id: I3591bf67a7c0369c40ca6e7af16183530f8cd269
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709049
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62887}
This reverts commit 7ba8e662cc.
Reason for revert: Breaks CFI - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20cfi/21295
Original change's description:
> [turbofan] Make code and comment match in FastFunctionPrototypeBind
>
> Additionally, used number of own descriptors in both CSA and the
> reduction of Function.prototype.bind.
>
> Change-Id: I7b86e059d20faa1160cdc0126932fff924226eee
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714655
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62885}
TBR=neis@chromium.org,jgruber@chromium.org,mslekova@chromium.org
Change-Id: I6a92741c214f8b86702445c60a311cc4800593e9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715449
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62886}
Additionally, used number of own descriptors in both CSA and the
reduction of Function.prototype.bind.
Change-Id: I7b86e059d20faa1160cdc0126932fff924226eee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714655
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62885}
In windows, even use clang build, the V8_LIBC_MSVCRT was set to indicate use MSVC runtime libraries. Change to use __clang__ to determine enable cpuid magic inline assembly or not.
Change-Id: I7372a27b311b695f019c5ff2d42b691d749eb607
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715332
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Tianyou Li <tianyou.li@intel.com>
Cr-Commit-Position: refs/heads/master@{#62884}
Even in the most basic case (the task queue only ever contains a single
element), this function triggers ~4KB in zone allocations. These
allocations are basically lost and can never be reused. Avoid this by
allocating inside a new temporary zone that is only alive during the
ComputeLoopState function call.
This reduces allocation size for the zone used during load elimination
from ~30KB to ~15KB when compiling a trivial for-loop example.
An alternative solution would be to switch to something similar to
SmallVector (which uses a statically-sized stack storage before
switching to heap allocations), but based on zones instead of malloc.
Bug: v8:9427,v8:6150
Change-Id: Ic25abe6d48ac718c9ced2f9ef581f244030980fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714869
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62883}
This change begins to implement the functionality described in
https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
for investigating V8 state in crash dumps.
This change adds a new library, v8_debug_helper, for providing platform-
agnostic assistance with postmortem debugging. This library can be used
by extensions built for debuggers such as WinDbg or lldb. Its public API
is described by debug-helper.h; currently the only method it exposes is
GetObjectProperties, but we'd like to add more functionality over time.
The API surface is restricted to plain C-style structs and pointers, so
that it's easy to link from a debugger extension built with a different
toolchain.
This change also adds a new cctest file to exercise some basic
interaction with the new library.
The API function GetObjectProperties takes an object pointer (which
could be compressed, or weak, or a SMI), and returns a string
description of the object and a list of properties the object contains.
For now, the list of properties is entirely based on Torque object
definitions, but we expect to add custom properties in future updates so
that it can be easier to make sense of complex data structures such as
dictionaries.
GetObjectProperties does several things that are intended to generate
somewhat useful results even in cases where memory may be corrupt or
unavailable:
- The caller may optionally provide a type string which will be used if
the memory for the object's Map is inaccessible.
- All object pointers are compared against the list of known objects
generated by mkgrokdump. The caller may optionally provide the
pointers for the first pages of various heap spaces, to avoid spurious
matches. If those pointers are not provided, then any matches are
prefixed with "maybe" in the resulting description string, such as
"maybe UndefinedValue (0x4288000341 <Oddball>)".
Bug: v8:9376
Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62882}
The fix in https://chromium-review.googlesource.com/c/v8/v8/+/1698383
was not complete. We can have a case when a function is neither
optmized or intepreted but still has a feedback vector. This can
happen when the code of the function was flushed.
Bug: v8:7857
Change-Id: I9cb6e474d79a5d4956301e87705af136baeaeb8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714875
Auto-Submit: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62880}
