mips load/store instructions can only handle when the memory offset is in range
[int16_min, int16_max], when beyond this range, we can use macro instructions which
will adjust base and offset first.
Change-Id: I84319b7fef9de8d0b8f507374654e38827503bdd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1596046
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Yu Yin <xwafish@gmail.com>
Cr-Commit-Position: refs/heads/master@{#61255}
New revision: 2039736177ee11d96a096cdab9c58cc1d78faa43
This modifies roll.py to update namespaces and header guards.
Also I'm removing --reverse, to avoid making this more complicated.
third_party/encoding/encoding{.h,cc} are already up to date,
since I manually propaged them earlier. So this is why this change
is only updating the template.
Change-Id: I5ddb075c9d6dad28b5665348023860683e964841
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1596392
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Johannes Henkel <johannes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61253}
Bug: v8:8996
Change-Id: Ie4b17928fcb9d426bade5afc1238d24bc75ec13e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594275
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#61252}
It's not necessarily helpful, and can actually cause pretty bad performance and
memory usage.
I moved up the next_ field to where allocation_ used to be since apparently the
alignment caused by it has huge impact on perf (>10% diff...) at least on my
machine.
Change-Id: I1026a2e954d061b1a178f6a733d8ef81ae6d0cab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594432
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61250}
Error messages are unspecified in JavaScript and occasional small
differences in the compared configurations lead to an unjustified
maintenance burden of correctness-fuzzing issues.
This CL replaces most error messages with a fixed suppression
message during correctness fuzzing (behind a flag).
The flag covering all extra behavior for correctness fuzzing is now
renamed to --correctness-fuzzer-suppressions.
Bug: chromium:958668,chromium:946476
Change-Id: Iba1197f765138a962d5bbb176730322e5a411707
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594730
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61249}
Original change's description:
> [runtime] Inline SeqOneByteSubStringKey IsMatch and AsHandle
>
> The performance actually matters to JSON parsing and this improves it by a % or
> 2.
>
> In the longer run we should probably share the IsMatch implementation in
> StringTableKey directly and call a virtual GetBytes on the key implementation.
>
> Change-Id: I838a106f9c8c52f0385057a52a8c0b9141ae025b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1589977
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Auto-Submit: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61183}
Change-Id: I3fc73b4d123f193f7c2ce3078b0b030a652efc17
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1596735
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61248}
This is a reland of b0c4a8764b
Original change's description:
> [json] Speed up json parsing
>
> - scan using raw data pointers + GC callback
> - scan using scanner tables
> - cap internalizing large string values
> - inline fast transitioning logic
>
> Fixes previous CL by moving AllowHeapAllocation to callers of
> ReportUnexpectedCharacter where needed to make it clear we need to exit.
>
> Tbr: ulan@chromium.org
> Change-Id: Icfbb7cd536e0fbe153f34acca5d0fab6b5453d71
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591778
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61159}
Change-Id: I0d713e02d243723df2d2a7c252eae44a6648b6b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1596444
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61247}
Until this CL, the Memory benchmark was the only one to be based on a
cctest runner; all others use d8. Besides being a tedious exception to
the rule, this caused issues such as described in the linked bug
(summary: refbuilds are built with v8_static_library, and neither
cctests nor unittests support this configuration).
Here, we move the Memory benchmark into a d8 runner.
Bug: v8:9189, chromium:957029
Change-Id: I9b45ff36f4842cb0bdef2c1c4b0184c5509d3385
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588464
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Belozorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61245}
To reduce physical memory consumption, discard code pages that are
fully freed.
To determine pages which only become fully free after several freed
wasm code objects, this CL adds a {DisjointAllocationPool} to track all
freed code ({freed_code_space_} in {NativeModule}).
R=mstarzinger@chromium.org
Bug: v8:8217
Change-Id: I22ad92d2c0bd4469e92f0dfd5aec05c03b5a47d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594728
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61244}
This fixes a performance regression.
Bug: v8:9197, chromium:958730
Change-Id: I70a59dd85d74275b967a196e9ab4623293b92756
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1596446
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61241}
The interpreter accesses code directly from the code manager. With lazy
validation, however, this code is not guaranteed to exist. The
interpreter now checks for this and compiles it lazily if needed. It
also handles exceptions that may arise from lazy validation.
Bug: v8:9003
Change-Id: I37c365f0a4d755ed55630d01c8526f2a3efa9a9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594567
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Frederik Gossen <frgossen@google.com>
Cr-Commit-Position: refs/heads/master@{#61240}
This fixes the source position printed in the stack trace for exceptions
thrown from within Wasm code. Specifically this affects the stack trace
attached to the exception object, as well as the message propagated to
the console. Both are tested by the new message test.
R=clemensh@chromium.org
TEST=message/fail/wasm-exception-throw
BUG=v8:8091
Change-Id: I5b2f76191cf47457ac113dce9d9601a8a810ee19
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591603
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61239}
It was a std::list for no obvious reason. This CL turns it into a
vector, which is the standard data structure we use if we don't have
any special requirements.
R=mstarzinger@chromium.org
Change-Id: Iefc321db9327e0743772dd804e2325266a9bff64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594727
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61235}
This CL improves SourcePosition support inside the Torque compiler.
It starts with the parser, where the SourcePosition of the
MatchedInput now encompasses all tokens, not just the first one.
Second, AST nodes can now be created with an explicit source position.
This can be used to forward the "all encompassing" source position
via MatchedInput -> ParseResultIterator to AST nodes.
Third, declarables are extended to hold two different SourcePositions:
- One represents the whole declarable. For a macro this would
inlcude the body as well as the signature.
- The other is the SourcePosition of the identifying part of a
declarable. In most cases this is the name. For the rest this
will stay invalid.
R=sigurds@chromium.org, tebbi@chromium.org
Bug: v8:7793
Change-Id: I509f83aeef7a040d0ea6363b5b7c31ff1b11f47b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591600
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61234}
This CL extends the stack frame API to include a flag to distinguish
between user and V8 builtin frames. The intention is to extend the API in
a later CL, so stack traces include builtin frames.
This flag gives embedders more control what to do with builtin frames.
R=jgruber@chromium.org, yangguo@chromium.org
Bug: v8:8742
Change-Id: Ieda5782dd2073c1e7fd49492bfdfa829a43dc710
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1583723
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61233}
Remove DCHECK because the interpreter may still have activations when
the isolate is torn down. This can happen in particular, when {quit} is
called in d8. A test for this will follow when v8:9209 is resolved.
Change-Id: Ia3ab0daa061d6427df3f778ba5fb195218910280
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594560
Commit-Queue: Frederik Gossen <frgossen@google.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61232}
FNMUL is efficient arm64 instruction, which can save 1 cycle
by optimizing FNEG(FMUL x y)) to FNMUL x y and
FMUL((FNEG x) y) to FNMUL x y
Change-Id: If25d9de1253098b17033a9d8736ff6a1c06601f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1572681
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61230}
This CL adds navigation support for labels in "goto" statements.
Similar to labels listed in the "otherwise" clause of call expression,
definitions of such a label can be found in two places:
- The signature of the current macro.
- A label block of a "try" statement that surrounds the "goto".
R=sigurds@chromium.org
Bug: v8:8880
Change-Id: I6c5ebea0b0f80b1882e6672bbb0f45196a7201ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594433
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61229}
This CL adds navigation support for labels listed in the "otherwise"
part of a call expression. There are two places where a definition for
such a label can be found:
- The signature of the current macro (caller)
- A label block of a "try" statement that surrounds the call
expression.
R=tebbi@chromium.org
Bug: v8:8880
Change-Id: If8849ad29abcf94f301d7a51e3e52c5517601bc0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593295
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61228}
Overall, total test runtime that was wasted due to timeouts is 3420 seconds in
the last 2 weeks. Even with 4 retries, assuming all of them time out, needed
additional capacity is under 2 hours per week. Based on this analysis, I think
it's safe to land this CL.
Note that this is not intended as a long-term solution of the timeout problem,
but rather a temporary solution to prevent ongoing errors. Proper investigation
and correct long-term solution are still needed and tracked in the bug.
R=machenbach@chromium.org, tmrts@chromium.org
Bug: chromium:841700
Change-Id: Id16e6b784fa85bb9e28ed8c6b267b583636e2dc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593342
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61224}
Bug: v8:8996
Change-Id: I86104991d9732157c1fbdff273046bf4f7e0186f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593853
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61221}
My recent change
https://chromium-review.googlesource.com/c/v8/v8/+/1570666 introduced an
error, found by ClusterFuzz, because I forgot to use EnsureSpace in a
new method in assembler-x64.
Bug: chromium:959014
Change-Id: I4c1b564b05de6d4403632e1521520f87706d56c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594977
Auto-Submit: Seth Brenith <seth.brenith@microsoft.com>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61219}
This reverts commit 964edc251f.
Reason for revert: chromium:959190
Original change's description:
> [heap] Set read-only space's and its pages' heap_ to null.
>
> Various small changes are required to enable this.
>
> HeapObject::GetReadOnlyRoots no longer uses the Space's heap when
> possible (see comment in ReadOnlyHeap::GetReadOnlyRoots definition).
> This requires that ReadOnlyRoots be construct-able using a raw pointer
> to the read-only space's roots array.
>
> Global read-only heap state is now cleared by tests where appropriate
> and extra DCHECKs in ReadOnlyHeap::SetUp should make catching future
> issues easier.
>
> String padding is now always cleared just before read-only space is
> sealed when not deserializing.
>
> Change-Id: I7d1db1c11567be5df06ff7066f3a699125f8b372
> Bug: v8:7464
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1535830
> Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61188}
TBR=ulan@chromium.org,hpayer@chromium.org,delphick@chromium.org,goszczycki@google.com
Change-Id: I53cecf3976dfeabae309040313351385f651f010
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7464, chromium:959190
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591608
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61217}
This is a reland of b6fb27077d.
Unchanged reland, TSan issue were fixed in https://crrev.com/c/1593340
and https://crrev.com/c/1594553.
Original change's description:
> [wasm][gc] Free WasmCode objects
>
> This adds the next step to freeing code: We free the actual C++
> {WasmCode} objects. This will cause UAF if any C++ code uses stale
> references.
> The underlying machine code will still not be freed.
>
> For simplicity, this CL changes the vector of owned_code to an ordered
> set, such that lookup and removal is much simpler. The drawback is that
> insertion is now more expensive.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:8217
> Change-Id: I07fc81167816637fbaad6c06ff79e3f952f2fde8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593080
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61165}
TBR=mstarzinger@chromium.org
Bug: v8:8217
Change-Id: I809832bb609663d794c7aafcf071823db7fb6212
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594436
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61215}
Keep the existing method for compatibility, by converting
to json from CBOR using the inspector_protocol_encoding library,
via a v8 specific interface library that directs routines for
converting between strings and doubles to v8's implementations.
This change also brings in the encoding.h / encoding.cc files from the
upstream inspector_protocol project. The only modification here
are the header guards, and the namespace. I will fix roll.py to
make it so that we pick up future changes.
third_party/inspector_protocol/BUILD.gn is specific to v8, by necessity.
third_party/inspector_protocol/.clang-format is a copy of the upstream
file. If we don't put this, we'll find ourselves auto-formatting the roll,
which is annoying.
This is a reland of
https://chromium-review.googlesource.com/c/v8/v8/+/1590627 with the
only modification in the DEPS file; this time I'm including
third_party/inspector_protocol/encoding/encoding{.h,cc} in addition to
the relative include there. Not sure why this is needed but I'm hoping
it gets me past the presubmit which may resolve the include path
relative to the V8 base (the ../../third_party is needed for when V8 is
embedded into Chromium).
Change-Id: Ic76b2b5faa7e1cbdceb15aff3f369e9a303e3e85
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593646
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Johannes Henkel <johannes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61214}
This adds either %EnsureFeedbackVectorForFunction or
%PrepareFunctionForOptimization to allocate feedback vectors when testing
optimization, allocation sites, IC transitions etc.,
Bug: v8:8394
Change-Id: I6ad1b6d460e4abda693b326cddb87754e080a0a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593303
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61212}
CodeBuilder was calling AllocateRawWithLightRetry when it should have been
calling AllocateRawWithRetryOrFail (and vice versa).
Also improved variable naming.
Bug: chromium:957934
Change-Id: I03a95165f6d5b44c1f47d08d338d48bcc37c6d04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1590075
Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61210}
Based on Primiano's prototype:
https://chromium-review.googlesource.com/c/v8/v8/+/1290549
This is still behind a build flag. I'll add functionality incrementally
rather than land everything in one giant CL.
This CL sets up the basic classes that will be used for the Perfetto
implementation, e.g. the producer, consumer, controller and task runner.
This implementation produces a binary proto file in the current
directory named v8_trace.proto. It doesn't yet produce JSON output,
that is coming in a following CL.
Currently the old tracing and perfetto tracing are both run alongside
each other if the build flag is enabled.
Cq-Include-Trybots: luci.v8.try:v8_linux64_perfetto_dbg_ng
Bug: v8:8339
Change-Id: I0eb9ecefa191ceead60aadd5b591d75c99395a6e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1408995
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61209}
