We somehow forgot to thread through the VectorSlotPair for the CALL_IC
based speculation feedback to CheckedTaggedToTaggedPointer. This was
showing for example with `String#concat()` where we ended up with an
endless deoptimization loop if the parameter was a Smi.
Bug: v8:8913
Change-Id: I84d90403f6fada9b435d4eb71c689edc3c34dc86
Reviewed-on: https://chromium-review.googlesource.com/c/1488770
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59871}
The logic for removing while iterating is non-standard and
a left over from a previous index based loop. This patch
replaces it with a standard erase based version.
This fixes a runtime crash with MSVC that invalidates the
iterator and then asserts. This also makes the code safe
in case the last move can be redundant.
Change-Id: Ie6990e0d65a3b83a4b7da3e2e89ed4e60a6cd215
Reviewed-on: https://chromium-review.googlesource.com/c/1488762
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59868}
GetSymbol previously always internalized the underlying string, even if the
preparser does not need it. The most common case where this isn't needed is
property name parsing. This seems to speed up preparsing quite a bit.
For future reference: Property names in object literals still are needed due to
various checks (e.g., get 'constructor', duplicate __proto__, ...); as well as
cover grammar parsing (property names can turn into variable references). If we
turn all strings that the preparser needs to identify back into contextual
keywords we may be able to avoid the former.
Change-Id: I549e4600053de3136ca08d4915cc04db36d66a89
Reviewed-on: https://chromium-review.googlesource.com/c/1488764
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59866}
This CL introduces a new expression that can replace "std::string"
fields in other expressions. The main goal is to get SourcePositions
for identifiers to make them available in the language server.
The CL introduces a separate symbol "name", that allows to
incrementellay replace strings with name expression where needed. As
an example, variable delcarations now use a NameExpression for the
variable name.
R=danno@chromium.org, tebbi@chromium.org
Bug: v8:7793
Change-Id: I5b88bbaeac597b8e9760d2e01880e5e599ebf802
Reviewed-on: https://chromium-review.googlesource.com/c/1488752
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59865}
When --concurrent_inlining is on, precompute (during serialization)
the list of receiver maps and the transition matrix of element
accesses.
Bug: v8:7790
Change-Id: I257eaea630f33831ab6600851ccdf297e17e35ca
Reviewed-on: https://chromium-review.googlesource.com/c/1475769
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59863}
... as suggested by the bug's reporter.
Bug: chromium:935358
Change-Id: Iab9d207e4f55a395d0496ef5d5ea0e9b6783ae66
Reviewed-on: https://chromium-review.googlesource.com/c/1488757
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59862}
By making EmptyIdentifierString (used for failure-mode parsing) point to the
empty_string() we can drop nullptr checks in the preparser. This is similar to
what the parser already does.
Change-Id: I4640f7ae6b24afc8d5275818caed0cca185ca72c
Reviewed-on: https://chromium-review.googlesource.com/c/1488759
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59860}
We'll remove the gcc version from the builder name in a follow up.
TBR=sergiyb@chromium.org
NOTRY=true
Bug: chromium:933093
Change-Id: I65359afd7245f155f7d1fd0519033ab8f8f736bb
Reviewed-on: https://chromium-review.googlesource.com/c/1488758
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Belozorov <sergiyb@chromium.org>
Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59859}
That way we can avoid allocating unreusable zone memory.
Change-Id: I0f30cbf5133026c63a9729bc45e728daa4740e9f
Reviewed-on: https://chromium-review.googlesource.com/c/1488756
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59858}
This reverts commit 32fc0acfef.
Reason for revert:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/30270
layout test breakage:
https://test-results.appspot.com/data/layout_results/V8-Blink_Linux_64/30270/webkit_layout_tests%20%28with%20patch%29/layout-test-results/results.html
There is a dead node arriving in representation selection, which might indicate that the problem is not in this CL, but that this CL stirs up the node soup in such a way that dead code elimination gets confused.
Original change's description:
> Optimize `in` operator
>
> This change implements optimizations for the `in` operator for packed array
> elements and object properties. It adds a new feedback slot kind and an IC
> path similar to KeyedLoadIC for handling the lookups. TurboFan uses the
> feedback to optimize based on the maps and keys.
>
> For more details see:
> https://docs.google.com/document/d/1tIfzywY8AeNVcy_sen-5Xev21MeZwjcU8QhSdzHvXig
>
> This can provide 10x performance improvements of on loops of the form:
>
> for (let i = 0; i < ary.length; ++i) {
> if (i in ary) {
> ...
> }
> }
>
>
> Bug: v8:8733
> Change-Id: I766bf865a547a059e5bce5399bb6112e5d9a85c8
> Reviewed-on: https://chromium-review.googlesource.com/c/1432598
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Matt Gardner <magardn@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#59843}
TBR=ulan@chromium.org,rmcilroy@chromium.org,jkummerow@chromium.org,jarin@chromium.org,ishell@chromium.org,bmeurer@chromium.org,verwaest@chromium.org,magardn@microsoft.com
Change-Id: Ib2db974e5bed4c4a2b6b450f796bdc4b0b8fd562
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8733
Reviewed-on: https://chromium-review.googlesource.com/c/1488761
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59857}
This directory is created by ccls (language server for C++ and others).
R=sigurds@chromium.org
Change-Id: I2413921ca896ad2003fcfd10fdadb739f1af18c8
Reviewed-on: https://chromium-review.googlesource.com/c/1487151
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59855}
This CL contains a basic Json parser used to read and write the
Json-RPC messages of the language server protocol.
This CL is part of the initial language server implementation but
submitted separately for easier review.
R=tebbi@chromium.org
Bug: v8:8880
Change-Id: Icea040975e1ed1d587954c3342d8d876e01c26b8
Reviewed-on: https://chromium-review.googlesource.com/c/1479956
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59848}
currently it cannot call run-tests.py since it use Linux path
Change-Id: I15af9c7e6503e6d473611a24f5f223ff68b1dbbd
Reviewed-on: https://chromium-review.googlesource.com/c/1484110
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#59846}
This change implements optimizations for the `in` operator for packed array
elements and object properties. It adds a new feedback slot kind and an IC
path similar to KeyedLoadIC for handling the lookups. TurboFan uses the
feedback to optimize based on the maps and keys.
For more details see:
https://docs.google.com/document/d/1tIfzywY8AeNVcy_sen-5Xev21MeZwjcU8QhSdzHvXig
This can provide 10x performance improvements of on loops of the form:
for (let i = 0; i < ary.length; ++i) {
if (i in ary) {
...
}
}
Bug: v8:8733
Change-Id: I766bf865a547a059e5bce5399bb6112e5d9a85c8
Reviewed-on: https://chromium-review.googlesource.com/c/1432598
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Matt Gardner <magardn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#59843}
This prevents accumulation of non-regular chunks if unmapper tasks
are not making progress.
Bug: chromium:934453
Change-Id: I552bc4f566f4be8877d9e806cca2aa9c284a7f4f
Reviewed-on: https://chromium-review.googlesource.com/c/1483055
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59842}
A custom deoptimization continuation point erroneously cast a parameter
to a number. Tests added.
BUG: v8:7672
Change-Id: I59848aacdedc1de9fd7d83d55045618f37d39fb0
Reviewed-on: https://chromium-review.googlesource.com/c/1485974
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59841}
This is a quirk needed for the regexp fuzzer, which passes its own
custom RegExpMatchInfo object to RegExpImpl::Exec and expects execution
without side effects.
Bug: chromium:934621
Change-Id: I90286fda06593d7c574d8d4629481ebad2fa5b1d
Reviewed-on: https://chromium-review.googlesource.com/c/1485833
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59839}
This fixes the case of accumulating large pages after scavenges if
there is no mark-compact GC.
Bug: chromium:934453
Change-Id: Ide57c64ae985cc79ad9f477a759ab729f894c73b
Reviewed-on: https://chromium-review.googlesource.com/c/1482740
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59838}
Port 591408cba7
Original Commit Message:
We'll need one bit in the SharedFunctionInfo::flags to record whether
it's safe to skip arguments adaptor frames (for v8:8895), so this
just removes the SharedFunctionInfo::IsDerivedConstructorBit which is
redundant, since the same information is already available in the
SharedFunctionInfo::FunctionKindBits, and most places in the code
use that already, with the exception of the JSConstructStubGeneric
builtin.
This changes the JSConstructStubGeneric builtin to just check the
function kind instead of testing the explicit bit, which also makes
this more consistent. It seems like there's not much overhead to
that, doing an additional bitmasking plus two comparisons instead
of one. This shouldn't really matter since invocation and execution
of the constructors is going to dominate and optimized code inlines
all of this anyways. If this turns out to affect performance, we
can still look into encoding the FunctionKindBits more cleverly.
the shift when accessing the function kind. This seems logic, since
for the actual boolean bit fields it doesn't matter where they are
in the flags, whereas for the function kind this saves one shift.
R=bmeurer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com, miladfar@ca.ibm.com
BUG=
LOG=N
Change-Id: I4e3ba5a066285bf50e869c32228d79d26d57258f
Reviewed-on: https://chromium-review.googlesource.com/c/1486411
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#59837}
When calling the `bitmap(chunk)` method of the various *MarkingState accessors
we would receive a raw `Bitmap` pointer which does not tell you if accesses to
markbits should be made atomically or not. As a result, we would default to
doing atomic operation when in fact it may not be necessary.
Here we're introducing a templated `ConcurrentBitmap` class that wraps
operations done on the markbits and allows them to be made non-atomic.
Additionaly, some of the `Bitmap` methods were only used to verify the heap and
in the tests so they do not need atomic implementations. Using them in a
concurrent context should now fail to link to make sure they're not mis-used in
the future.
Change-Id: Ifb55f8522c8bf0c87d65da9227864ee428d21bbd
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1482916
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#59836}
This CL reduces the instruction size of Array.prototype.every and some
by ~20%. Should performance allow it we could do the same for other
array builtins. We attach a boolean to the FastJSArrayWitness that
remembers if it's dealing with a FixedArray or a FixedDoubleArray.
We have to check this in the loop, but it is likely that reduced
code size more than pays for the extra check, since the loop will
be dominated by the call to the users callback function.
BUG: v8:7672
Change-Id: Id3bab2b163d7ba73424250d8bb194712909cd37e
Reviewed-on: https://chromium-review.googlesource.com/c/1484293
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59835}
This was a pair of a set of maps and their common instance type (if
any), but the instance type field was only used in a printing function.
Removing the whole class in favor of ZoneHandleSet<Map> means we avoid
looking at the heap to determine the common instance type. Eventually
we can use the broker to do this if we need to.
Bug: v8:7790
Change-Id: If0cadf9b17e3b9e77cffc4f0b69e2585aff7c85c
Reviewed-on: https://chromium-review.googlesource.com/c/1481214
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59834}
Since our allocations don't guarantee more than kTaggedSize alignment,
it doesn't make sense to warn about mis-alignment beyond that.
Bug: v8:8863 v8:7793
Change-Id: Ia1c2dd25efdb2c1084968ab4ffe8de25b8654cdb
Reviewed-on: https://chromium-review.googlesource.com/c/1486251
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59833}
With stress bytecode flushing it's possible for the main SFI of a script to have it's
bytecode flushed during deserialization of the script. If this happens, just fall-through
to recompile the SFI.
BUG=v8:8901,v8:8395
Change-Id: I786c1ca93167b76810481892ade525d14ff9168f
Reviewed-on: https://chromium-review.googlesource.com/c/1485837
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59831}
Mark the not_ok case as deferred.
Bug: v8:8834
Change-Id: I17536e45fb6aa309347b8faaf5f25fb3bbfbf6cf
Reviewed-on: https://chromium-review.googlesource.com/c/1485973
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59830}
Add some additional safety net to the CSA code for triggering promise
reactions to make sure we catch security bugs (specifically related
to misuse of the V8 Extras API) on the fast-path.
Bug: chromium:931640, chromium:931949
Change-Id: I76b5dc6653e2404411a29dcd9c54245d7c43d883
Reviewed-on: https://chromium-review.googlesource.com/c/1485972
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59829}
All uses of ParseMemberExpression go through
ParseMemberWithNewPrefixesExpression, and ParseMemberExpression always starts
with ParsePrimaryExprssion, so we can simply move Token::NEW handling into
ParsePrimaryExpression. That avoids an unnecessary branch on the hot path.
Change-Id: I2bcce8e106c547c6d308ee6b0fce8747c7214886
Reviewed-on: https://chromium-review.googlesource.com/c/1485838
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59827}
When calling a known function from optimized code, where the number of
actual arguments does not match the number of expected arguments,
TurboFan has to call indirectly via the arguments adaptor trampoline,
which creates an argument adaptor frame underneath the activation record
for the callee. This is done so that the callee can still get to the
actual arguments, using either
1. the arguments object, or
2. rest parameters (to get to superfluous arguments), or
3. the non-standard Function.arguments accessor (for sloppy mode
functions), or
4. direct eval(), where we don't know whether there's a use of the
arguments object hiding somewhere in the string.
However going through the arguments adaptor trampoline is quite
expensive usually, it seems to be responsible for over 60% of the
call overhead in those cases.
So this adds a fast path for the case of calling strict mode functions
where we have an arguments mismatch, but where we are sure that the
callee cannot observe the actual arguments. We use a bit on the
SharedFunctionInfo to indicate that this is safe, which is controlled
by hints from the Parser which knows whether the callee uses either
arguments object or rest parameters.
In those cases we use a direct call from optimized code, passing the
expected arguments instead of the actual arguments. This improves the
benchmark on the document below by around 60-65%, which is exactly
the overhead of the arguments adaptor trampoline that we save in this
case.
This also adds a runtime flag --fast_calls_with_arguments_mismatches,
which can be used to turn off the new behavior. This might be handy
for checking the performance impact via Finch.
Bug: v8:8895
Change-Id: Idea51dba7ee6cb989e86e0742eaf3516e5afe3c4
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Doc: http://bit.ly/v8-faster-calls-with-arguments-mismatch
Reviewed-on: https://chromium-review.googlesource.com/c/1482735
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59825}
We don't need dynamic allocation for these arrays.
Change-Id: I12095ec0e3b6e9d70be56adfb77aded5c25eb3d5
Reviewed-on: https://chromium-review.googlesource.com/c/908462
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59824}
This means ReadOnlyDeserializer can be made isolate independent. Without
this Isolate is needed for rehashing read-only space.
Bug: v8:7464
Change-Id: Id2c9968a0ecfa2362f499ded6c7e0f7b2be00dfb
Reviewed-on: https://chromium-review.googlesource.com/c/1483054
Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59823}
This removes ast.h as include from about ~500 includers of the latter.
Bug: v8:8834
Change-Id: I294026d4bb29b878820d43c117b04a9645a457ae
Reviewed-on: https://chromium-review.googlesource.com/c/1485835
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59822}
