As the TODO's indicate, these helpers only used by TypedArray#join when it was
implemented in JS. As of https://chromium-review.googlesource.com/c/v8/v8/+/1369330
TypedArray#join is now implemented Torque and was optimized in a way that no longer
requires these helpers anymore.
Bug: v8:7624
Change-Id: I1d1ff80235a12feb3846ff92764e8593ce7c72c9
Reviewed-on: https://chromium-review.googlesource.com/c/1498692
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#59999}
BytecodeArray::SourcePosition and BytecodeArray::SourceStatementPosition
have no implementations and are never called.
Bug: v8:8834
Change-Id: I919c871795084766856dfbff5344c037b6f33dd0
Reviewed-on: https://chromium-review.googlesource.com/c/1497009
Commit-Queue: Dan Elphick <delphick@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59998}
After 54a1889, Bug:7464, the permission of the page is read only, but this function need write permission.
Since this function is not used, just remove it.
Change-Id: I5a5976ab773bd808920893bbd2e3d9796e89e804
Reviewed-on: https://chromium-review.googlesource.com/c/1490813
Reviewed-by: Predrag Rudic <prudic@wavecomp.com>
Commit-Queue: Yu Yin <xwafish@gmail.com>
Cr-Commit-Position: refs/heads/master@{#59995}
Remove the duplication of the allocation logic via the
AllocateOneByteConsString and AllocateTwoByteConsString helpers, and
instead just have a diamond to figure out the result map. This reduces
code size of the StringAdd_CheckNone builtin and even seems to be
beneficial performance wise. It seems to improve the performance on
the `bench-dom-serialize.js` test by around 1% just doing this.
Drive-by-fix: Remove the `flags` from CodeStubAssembler::StringAdd()
and its helpers, since we no longer support pretenuring of string
additions (for quite a while now).
Bug: v8:8834, v8:8939
Change-Id: Ia23e02c974b5f572930fcd45be0643094ab2fa98
Doc: https://bit.ly/fast-string-concatenation-in-javascript
Reviewed-on: https://chromium-review.googlesource.com/c/1498133
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59993}
Stringification of Json wrongly used quotes for "true", "false" and
"null".
Drive-by: Manually flush std::cout when sending messages. This might
fix the server on windows.
R=tebbi@chromium.org
Bug: v8:8880
Change-Id: Ie499595a1b429514c5d8b1d3ece24f4690ece02e
Reviewed-on: https://chromium-review.googlesource.com/c/1498132
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59992}
This is a cosmetic change aimed to reduce compilation
time spent on instantiating things and potentially reduce
code (in case instantiated specializations are in
different shared objects).
Change-Id: I719b4d376a0d707f4724555a2f404327d19d8477
Reviewed-on: https://chromium-review.googlesource.com/c/1484298
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59988}
When running under simulator, all arm64 JIT instructions are interpreted by
simulator via normal memory read, then no need to do icache/dcache flush.
Also when running under simulator, cache_type_register_ is set to 0 explicitly
in above CacheLineSizes class, which results in 0 value in both dstart and
istart, then causes flush on this incorrect range.
Bug: chromium:893460
Change-Id: Ief6cb09a0e89f7ede0761ad676ea6a882e9f4600
Reviewed-on: https://chromium-review.googlesource.com/c/1492514
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59987}
I thought about potentially adding the identifer ref to the error but
that would require allocating a new string or at the very least
increasing the size of the resulting cons string. Given that the
parser is pretty performance sensitive, I've decided to not display
the identifier.
Previously, the error was:
_test.js:3: Error
a[foo].c = () => { throw Error(); };
^
Error
at a.(anonymous function).c (_test.js:3:26)
at _test.js:5:1
With this patch, the error becomes:
_test.js:3: Error
a[foo].c = () => { throw Error(); };
^
Error
at a.<computed>.c (_test.js:3:26)
at _test.js:5:1
Bug: v8:8823
Change-Id: I557b3517e317652c447ca06c5a400e9625353d9b
Reviewed-on: https://chromium-review.googlesource.com/c/1495017
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59985}
This is a port of the improvements to the ArgumentsAdaptorTrampoline
that previously landed for x64. It skips the arguments adaptor frame
creation if the callee cannot observe the actual arguments (as indicated
by the "is_safe_to_skip_arguments_adaptor" bit on the SharedFunctionInfo),
and instead just massages the current stack frame appropriately (either
by pushing more undefineds in case of under application, or by removing
the superfluous arguments in case of over application).
Due to the 16 byte stack alignment requirement on arm64, we only skip
the arguments adaptor frame creation when the difference between the
expected and the actual argument number is even. When it is odd, we
would still need to copy the actual arguments in the existing frame to
account for the padding, which would defeat the point of the improvement.
Bug: v8:8895
Tbr: jgruber@chromium.org
Doc: http://bit.ly/v8-faster-calls-with-arguments-mismatch
Change-Id: I7f13f6f0ba86edb483e088aac145cfcf9c937fef
Reviewed-on: https://chromium-review.googlesource.com/c/1491633
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59983}
Replaces assertErrorMessage by assertThrows. Previously
assertErrorMessage didn't assert the error message that was
provided.
Change-Id: I30410b43ff16db448776d9f3cae817b1c0966b3d
Reviewed-on: https://chromium-review.googlesource.com/c/1496973
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sven Sauleau <ssauleau@igalia.com>
Cr-Commit-Position: refs/heads/master@{#59982}
There is both a v8::internal::SourcePosition and a
v8::internal::torque::SourcePositon and in jumbo builds
an unqualified SourcePositon ended up referring to the wrong
one since nobody had told the compiler that the correct one
existed. This broke jumbo builds of v8 cctests
on Windows (because only in Windows will the compiler look for
the symbol in a parent namespace).
R=szuend@chromium.org
Bug: v8:8880
Change-Id: I7c9ebf68629642b65e86d6a8ae458ec5ff01f2ce
Reviewed-on: https://chromium-review.googlesource.com/c/1496972
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Daniel Bratell <bratell@opera.com>
Cr-Commit-Position: refs/heads/master@{#59980}
If we make use of this in the generic Array.prototype.filter case
we get a performance boost of over 60%.
Bug: v8:8213, chromium:920187
Change-Id: Ia116a852f355a9f037850aee86db7284f0023929
Reviewed-on: https://chromium-review.googlesource.com/c/1484297
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59979}
To make it obvious these are not defined in C++.
Bug: v8:7793
Change-Id: Ib846023992e32ddd10dadc3834ce42b7604a1f48
Reviewed-on: https://chromium-review.googlesource.com/c/1495993
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59978}
This CL changes 'Value' to use an 'Identifier' for its name, where
the source position represents the point where it is defined. This is
used to support "goto definition" for constants and extern constants.
R=tebbi@chromium.org
Bug: v8:8880
Change-Id: Ifb9ff08b36cbd9fb2691dbae579d2df29edd651d
Reviewed-on: https://chromium-review.googlesource.com/c/1495986
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59977}
This makes the test runner and numfuzz share the same exit code behavior on
errors. This is needed as they also share the same infrastructure logic
to collect swarming tasks.
Bug: chromium:937228
Change-Id: I155b37c7b10dd22959a4dcf30bbd0321c452236b
Reviewed-on: https://chromium-review.googlesource.com/c/1495987
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59976}
I tried to use more specific union types where appropriate, even though
many of these fields are accessed as Object from C++.
Bug: v8:7793
Change-Id: I771d9b6459bdc1413019f8ff5ddfd611d1adf61f
Reviewed-on: https://chromium-review.googlesource.com/c/1490573
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59975}
Port 4f62b4bb61
Original Commit Message:
This is a port of the improvements to the ArgumentsAdaptorTrampoline
that previously landed for x64. It skips the arguments adaptor frame
creation if the callee cannot observe the actual arguments (as indicated
by the "is_safe_to_skip_arguments_adaptor" bit on the SharedFunctionInfo),
and instead just massages the current stack frame appropriately (either
by pushing more undefineds in case of under application, or by removing
the superfluous arguments in case of over application).
R=bmeurer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com, miladfar@ca.ibm.com
BUG=
LOG=N
Change-Id: I94824c4b3d94f7c93c7526c865b82649426cd3a4
Reviewed-on: https://chromium-review.googlesource.com/c/1495014
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#59974}
gcc requires the <algorithm> header for compiling std::sort. This issue
is not present when using Clang.
Change-Id: Ief7bfd6152754f71194c784b09dce39e357ddd5c
Reviewed-on: https://chromium-review.googlesource.com/c/1496280
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59973}
This CL moves the following builtins from CSA to Torque:
TypedArray.prototype.forEach
TypedArray.prototype.reduce
TypedArray.prototype.reduceRight
A space-saving decision was made in the design -- instead of emitting
versions of the central loop for each ElementsKind, a function
pointer which knows how to read from the appropriate TypedArray
ElementsKind is constructed at the outset, and passed into the
loop. This enormously reduces codesize for the TypedArray builtins.
We'll have to see if the overhead of the builtin call affects
performance too adversely.
BUG: v8:8906
Change-Id: I808cd70f58ddbde18f85e5b2a9be0b883a3f6647
Reviewed-on: https://chromium-review.googlesource.com/c/1484292
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59970}
Instead of accessing JsonValue struct fields directly, typed
accessors check that the tag matches with the type access.
Drive-by: The factory methods are now static methods on the JsonValue
type itself, making call-sites more readable.
R=tebbi@chromium.org
Bug: v8:8880
Change-Id: I49b37b3ba8eaf1153b8aa93ea08913077c923fdc
Reviewed-on: https://chromium-review.googlesource.com/c/1495559
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59968}
The interpreter is set up specially in cctests to allow more direct
testing. This requires sometimes to write special testing code in the
interpreter which is different than production code. This CL fixes one
instance of testing code which deals with indirect calls.
In production code, indirect calls go through the indirect function
table which can change over time. In cctests, however, the indirect
function table is not set up completely. In cctests the interpreter
uses information from the module instead to acquire the target of an
indirect call. In that testing code, calls to imported JS functions
were not handled. This handling gets added with this CL.
CC=fgm@chromium.orgR=titzer@chromium.org
Bug: v8:7431
Change-Id: I3b90d4ea8fec2633c010dd8359814440c7988509
Reviewed-on: https://chromium-review.googlesource.com/c/1495560
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59965}
The performance regression comes from the extra time of
ExtractHandlerContext called by TriggerPromiseReaction,
On the previous code, it takes the current Context from Isolate,
and on the typical case of the new code, the Context is taken from
the promise reaction function, that adds a few memory read ops and
a few conditional branches.
This CL adds Label::kDeferred to non-typical cases of
ExtractHandlerContext, so that newly added instructions have smaller
impact under the speculative execution.
On a local benchmark, this fixes half of the regression.
Bug: chromium:936717
Change-Id: I34ce858f77d7d604dd596711a239160ed8dac383
Reviewed-on: https://chromium-review.googlesource.com/c/1496774
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59964}
The {AsyncCompileJob} can now always be deleted when initial
compilation finished. The previous conditions are redudant, since
{baseline_compilation_finished()} is always true when calling
{FinishModule()}.
R=ahaas@chromium.org
Bug: v8:8689
Change-Id: I95c0cf83943630b83216c83db0edbabdfbd71284
Reviewed-on: https://chromium-review.googlesource.com/c/1494008
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59962}
After python3 migration, the new print usage started causing leftover character
issues.
This CL fixes the print usage.
R=clemensh@chromium.org,neis@chromium.org
CC=machenbach@chromium.org
Bug: v8:8918
Change-Id: Ibee06677c3bae3e1141579693aa16a539309a566
Reviewed-on: https://chromium-review.googlesource.com/c/1495558
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59961}
Design Doc: https://goo.gl/9G9d9k
The initial prototype consists of a few parts:
The VS Code extension is now built using TypeScript. The build artifact
is checked-in along side the extension. The extension now starts up
the language server when it is activated. The path to the LS
executable is configurable via VS Code settings.
The language server is a separate executable. It adds a light-weight
object model on top of a Json Parser for reading/writing LSP requests
and responses. The current server is very much bare-bones featurewise:
- Tell the client that the server can handle "goto definition"
- Recompile when Torque files change
- Goto definition support for Macros/Builtins, local variables
and arguments.
R=mathias@chromium.org, mvstanton@chromium.org, tebbi@chromium.org
Bug: v8:8880
Change-Id: Ie9b433e64ee63e9aa757b6bf71e5d52beb15b079
Reviewed-on: https://chromium-review.googlesource.com/c/1494354
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59960}
This pooling introduces severe lock contention for Liftoff compilation,
since each compilation uses its own Zone which does at least one
segment allocation.
It's also unclear whether pooling improves performance, since {malloc}
should implement a similar pooling mechanism, but better optimized for
multithreaded uses.
Feel free to revert if this introduces significant regressions.
R=verwaest@chromium.org
Bug: v8:8916
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Change-Id: Iaf988bed898e35700f5f7f3310df8e01918de4c9
Reviewed-on: https://chromium-review.googlesource.com/c/1491632
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59959}
The original was reverted for breaking webkit layout tests:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/30270
It also caused the following clusterfuzz failures:
chromium:935832
This was a correctness bug due to not properly handling the case of arrays with prototypes other
than Array.prototype. Accesses that were TheHole were not being handled property, both in bounds
holes in holey arrays and out of bounds on either holey or packed arrays. Handling was incorrect
both in access-assembler and in Turbofan.
chromium:935932
This bug was that there was no handling for Has checks on the global object. Turbofan was emitting
code for a store (the 'else' condition on 'access_mode == AccessMode::kLoad'). It hit a DCHECK in
debug builds but in release could show up in different places. This is the bug that caused the
webkit layout test failure that led to the revert.
Both bugs are fixed by in CL, and tests are added for those cases.
Bug: v8:8733, chromium:935932, chromium:935832
Change-Id: Iba0dfcfce6e15d2c0815a7670ece67bc13ba1925
Reviewed-on: https://chromium-review.googlesource.com/c/1493132
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Matt Gardner <magardn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#59958}
Assembler::AbortedCodeGeneration() is defined in assembler-arm64.h, but it calls
into Constant::Clear() which is defined in assembler-arm64.cc. This introduces
dependency to v8_base component when including assembler-arm64.h which is not
always possible like for V8 unittests target. To fix this, we could define both
in the same file, like Assembler::IsConstPoolEmpty() calls Constant::Clear() and
both are defined in assembler-arm64.h, so it works fine.
Bug: chromium:893460
Change-Id: I895cf0147950fca20142ea5ed18bcd020c1ab866
Reviewed-on: https://chromium-review.googlesource.com/c/1493293
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59955}
This provides a single point where read-only space sharing will be
controlled. Eventually ReadOnlyDeserializer will take ReadOnlyHeap
instead of Isolate, first steps include
https://chromium-review.googlesource.com/c/v8/v8/+/1483054
Bug: v8:7464
Change-Id: I213819aeca6fca335235025c9195edf474230eda
Reviewed-on: https://chromium-review.googlesource.com/c/1489087
Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59954}
This changes DebugObjectCache to be a vector of Handles rather than
tagged pointers, meaning it's not GC-safe.
This will allow PrintStack to allocate memory if required (if for
instance source positions must be regenerated).
Bug: v8:8834, v8:8510
Change-Id: Ieec9a827af9abbcb9b5b237d79984eedf0cdcc57
Reviewed-on: https://chromium-review.googlesource.com/c/1494755
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59952}
Rather than manually tracking basic blocks in the bytecode array builder,
use the existing dead code elimination to generate an implicit return iff
the block ending the bytecode is not dead by the time all statements have
been visited.
Change-Id: I9520486a523ec4e01bc203e9a847eb1f57b130b6
Reviewed-on: https://chromium-review.googlesource.com/c/1494756
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59951}
