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}
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.
Drive-by-fix: Move the FunctionKindBits first in the flags to avoid
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.
Bug: v8:8834, v8:8895
Change-Id: I184a8f5cc5c140bdc272cf9a5ad546093c457306
Reviewed-on: https://chromium-review.googlesource.com/c/1482915
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59821}
Field representation tracking is only used by TurboFan.
Bug: v8:7777
Change-Id: I0d930f8dc0b68ff030111f12092b183c4c257ac6
Reviewed-on: https://chromium-review.googlesource.com/c/1481218
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59820}
since these operators don't have any variable arguments.
Bug: v8:8183
Change-Id: I602fe65a2137d6ffc6ece702da53d660577eee4a
Reviewed-on: https://chromium-review.googlesource.com/c/1482736
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59819}
Template objects should be cached after they are first created and reused on
subsiquent calls to tag functions. Currently these cached objects are stored
on the feedback vector, which has appropriate lifetime, however with bytecode
flushing the feedback vector could be cleared when the bytecode is flushed,
causing the template object to be dropped.
In order to retain the cached template objects in the face of bytecode flushing,
this CL adds a weakmap for each native context that is (weakly) keyed by
shared function info, and holds a linked list of cached template objects
associated with that shared function info, indexed by feedback vector slot id.
Misses will check this weakmap, and if no entry is found, a new template object
is created and added into this weakmap alongside the feedback vector.
BUG=v8:8799,v8:8799,v8:8395
Change-Id: Ia95d5cfc394ce58dc9fe6a1e49780f05299acc17
Reviewed-on: https://chromium-review.googlesource.com/c/1477746
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59818}
When stubbing out source line information emission for Windows, the
ARM64 Windows branch was missed. This change copies the x86/x64 stubs
as appropriate.
Bug: chromium:893460,v8:8870
R=jgruber@chromium.org
Bug: chromium:893460,v8:8870
Change-Id: I1416b602a4f96a68c37fdeeb816ce1ce33b12407
Reviewed-on: https://chromium-review.googlesource.com/c/1453637
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59817}
This merges all the possible targets for 'member expressions' previously
parsed in ParseMemberExpression into ParsePrimaryExpression; since that's
not independently used anyway. This will make it faster since we don't
need to go through unnecessary branches before ParsePrimaryExpression on
the fast path, *and* it will make the binary smaller since
ParseMemberExpression is inlined but ParsePrimaryExpression is not. It
saves 4kb. Yay :)
Bug: chromium:913222
Change-Id: Ib92e1c2a128fffff1db85b625bb5f311ec8c24ef
Reviewed-on: https://chromium-review.googlesource.com/c/1480379
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59814}
That way we can continue running in failure mode.
Bug: chromium:933214
Change-Id: I975901a72f615e2b7ed9955b75ce86bbcad0bbbb
Reviewed-on: https://chromium-review.googlesource.com/c/1481219
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59813}
Do not leak handles to the outer scopes from inspector methods.
Add `SealHandleScope`s to the tests and the d8 binding, and
`HandleScope`s in the places in the inspector source where
handles are actually used.
Change-Id: I80b1bb0ccc4778b32e9198513f63d5c0652c8f59
Reviewed-on: https://chromium-review.googlesource.com/c/1484304
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59812}
This fixes an early handle dereference before a potential allocation
in ReplacementStringBuilder.
Bug: chromium:935101
Change-Id: I03cf2b18b577a38af818dcc42f7c430faba23450
Reviewed-on: https://chromium-review.googlesource.com/c/1485831
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59811}
This read can cause a guard page violation on Windows, where the sp is
sometimes incorrect and points far into the future stack space.
Bug: v8:8883, v8:5193
Change-Id: I55c1fcac873a9c43484a5d1c3f2661f3589b1daf
Reviewed-on: https://chromium-review.googlesource.com/c/1480378
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59810}
When using a shared WebAssembly.Memory, always try to reserve up to the
maximum to avoid having to move the buffer. If after multiple retries
it is not possible to reserve the maximum, fall back to initial size
reservation.
- Add new methods to allocate a Shared WebAssemblyMemory.buffer
- Use these to reserve upto the mazimum for a Shared WebAssembly.Memory
- Cleanup js-api so actual allocation is done inside the constructor
BUG: v8:8564
Change-Id: I97815c7c94a2b84416cd867fb23b3c815d7f0f12
Reviewed-on: https://chromium-review.googlesource.com/c/1480910
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59805}
Implement the ReturnCall functionality for the interpreter.
Note that some tests have had to be deferred to the implementation
of ReturnCall for TurboFan.
Bug: v8:7431
Change-Id: I091528e72f9113ddf1929bd1a5650b490bc8cc0c
Reviewed-on: https://chromium-review.googlesource.com/c/1467343
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59803}
This fixes a corner case where the main thread has items in the local
segments but the global pool is empty. In such case concurrent marking
tasks are not posted and marking is performed on the main thread.
Bug: chromium:934453
Change-Id: Ic34cd4ecb59b848021d8d8b086904b415669f5e6
Reviewed-on: https://chromium-review.googlesource.com/c/1482739
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59802}
This is to get better handle on improvements and regressions.
Bug: v8:8361, chromium:930680
Change-Id: I2963b55f3480036ada885267a277a95d24a67656
Reviewed-on: https://chromium-review.googlesource.com/c/1482737
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59800}
This now makes it so TurboFan now uses full pointer loads for arguments values
located on stack.
Bug: v8:8876, v8:7703
Change-Id: Ib82d6f3b0f4c8d33669c7f86ce803381d210c019
Reviewed-on: https://chromium-review.googlesource.com/c/1480382
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59798}
... which will work for 32-bit kTaggedSize but we are not there yet.
Bug: v8:7703
Change-Id: Iaceb126ba316f37532221597cbd4f7e85ceb4fb9
Reviewed-on: https://chromium-review.googlesource.com/c/1482917
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59797}
Port b0b1ba9add
Original Commit Message:
This CL changes the secondary stack check for WebAssembly functions
with big stack frames in the code generator from calling a runtime
function to calling a code stub. The runtime function caused problems
with serialization.
R=ahaas@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Ie2175eedb043304405fd271c3bf1337dac76ab49
Reviewed-on: https://chromium-review.googlesource.com/c/1483210
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#59796}
Also cleans up the code slightly.
Change-Id: I9d1e7305f69e5f746833ed7985a320023fc90f2e
Reviewed-on: https://chromium-review.googlesource.com/c/1477744
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59795}
All HeapObjects already have roots access so this was redundant and
made ComputeAndSetHash difficult to use.
Eventually we need to get rid of the Isolate version of HashSeed,
but this will touch a lot of files, so leaving it for now.
Bug: v8:8562
Change-Id: I27d8fe10df72494d0a2146f408a2158cf02ce226
Reviewed-on: https://chromium-review.googlesource.com/c/1481630
Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59792}
