mostly in HandleScopeImplementer and related classes.
Bug: v8:3770
Change-Id: I9da757c60be99434b711fe74a5f5d296a0f08b22
Reviewed-on: https://chromium-review.googlesource.com/c/1300854
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57154}
as part of the continuing quest to get rid of Object*/Object** entirely.
Since it fits nicely, this CL as a bonus includes the planned change to
make Handle::location() return an Address*, in the process dropping the
temporarily needed duplicate Handle::location_as_address_ptr().
Bug: v8:3770
Change-Id: I87480289ce2a62ea1ae503e73d179256b7108c5c
Reviewed-on: https://chromium-review.googlesource.com/c/1298389
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57153}
Port 15c31fe461
Original Commit Message:
This introduces Word64 support for the CheckBounds operator, which now
lowers to either CheckedUint32Bounds or CheckedUint64Bounds after the
representation selection. The right hand side of CheckBounds can now
be any positive safe integer on 64-bit architectures, whereas it remains
Unsigned31 for 32-bit architectures. We only use the extended Word64
support when the right hand side is outside the Unsigned31 range, so
for everything except DataViews this means that the performance should
remain the same. The typing rule for the CheckBounds operator was
updated to reflect this new behavior.
The CheckBounds with a right hand side outside the Unsigned31 range will
pass a new Signed64 feedback kind, which is handled with newly introduced
CheckedFloat64ToInt64 and CheckedTaggedToInt64 operators in representation
selection.
The JSCallReducer lowering for DataView getType()/setType() methods was
updated to not smi-check the [[ByteLength]] and [[ByteOffset]] anymore,
but instead just use the raw uintptr_t values and operate on any value
(for 64-bit architectures these fields can hold any positive safe
integer, for 32-bit architectures it's limited to Unsigned31 range as
before). This means that V8 can now handle huge DataViews fully, without
falling off a performance cliff.
This refactoring even gave us some performance improvements, on a simple
micro-benchmark just exercising different DataView accesses we go from
testDataViewGetUint8: 796 ms.
testDataViewGetUint16: 997 ms.
testDataViewGetInt32: 994 ms.
testDataViewGetFloat64: 997 ms.
to
testDataViewGetUint8: 895 ms.
testDataViewGetUint16: 889 ms.
testDataViewGetInt32: 888 ms.
testDataViewGetFloat64: 890 ms.
meaning we lost around 10% on the single byte case, but gained 10% across
the board for all the other element sizes.
R=bmeurer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Ia86089ca9ccc75405aa13600b031c72bac0279dd
Reviewed-on: https://chromium-review.googlesource.com/c/1305035
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#57152}
- introduced ValueMirror interface, this interface contains methods to generate
different protocol entities,
- introduced DebugPropertyIterator, this iterator iterates through object properties
in the following order: exotic indices, enumerable strings, all other properties,
- removed all injected script infra, e.g. closure compiler,
R=dgozman@chromium.orgTBR=yangguo@chromium.org
Bug: chromium:595206
Change-Id: Idcfc04489ee52e015ad1d1d191c3474cc65e63f2
Reviewed-on: https://chromium-review.googlesource.com/c/1308353
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57150}
The reduer should only fire on increasing memory.
R=ulan@chromium.org
Change-Id: I4abd956ea14730b223724a01af819be574b1aa3a
Reviewed-on: https://chromium-review.googlesource.com/c/1308354
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57149}
Even though we know we're simply parsing a string as statement, we can still
hit a stack overflow on the way there.
Bug: v8:8392
Change-Id: I2471cf8273789aa33239f5c137cc2f54454acb32
Reviewed-on: https://chromium-review.googlesource.com/c/1307429
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57146}
I see no reason why it was excluded.
Bug: v8:8386
Change-Id: I291b12444b890db1636b00dec1837e1634b23b35
Reviewed-on: https://chromium-review.googlesource.com/c/1307428
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57145}
Those trace events are too fine grained and heavily impact metrics
computation.
No-try: true
Change-Id: Ica07bfdf8e695689795abb1d6b215c329413ba3b
Reviewed-on: https://chromium-review.googlesource.com/c/1307431
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57143}
MIPS32r2 doesn't have load-linked/store-conditional instructions
that work with 64-bit values and these are now implemented through
runtime.
TEST=mjsunit/wasm/compare-exchange64-stress
Change-Id: I70d8a454dcbbdac6f30e30ec3ac0eb4d429ef62e
Reviewed-on: https://chromium-review.googlesource.com/c/1296211
Commit-Queue: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57138}
We didn't check if the input typed array was neutered before going to
the fast path, so we hit a CHECK in this case.
Fix this by just checking if the buffer was neutered and then going to
the 'check iterator' case if it is. This will cause a TypeError via
IterableToList, which was the same as the behavior before the
optmization was landed.
Bug: chromium:899519
Change-Id: I09e6389ea2ab1e3bef01e616721b48a9b66c1b2a
Reviewed-on: https://chromium-review.googlesource.com/c/1307422
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57137}
This removes another liability of the finisher: to abort compilation
and publish errors once an error state has been set by a background
compile unit.
This CL makes background threads set the error state directly and
schedule a foreground task to actually publish the error (e.g. via the
promise).
R=mstarzinger@chromium.org
Bug: v8:7921
Change-Id: I7a6a7ca4f235c2ad374b6ffc434eb6ac7d5f54ae
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/1307425
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57135}
We define a TestFailedError exception and raise it when we can reliably detect
that a test has crashed. All other exceptions are treated as infra failures and
are captured by the try-catch clause in MainWrapper function.
This also fixes all tests in run_perf_test.py, run_tests_test.py and makes sure
that both are run on any changes in tools directory.
R=machenbach@chromium.org
Bug: chromium:899028
Change-Id: I283bc87b31c814be476bebe9fdda414975494183
Reviewed-on: https://chromium-review.googlesource.com/c/1303293
Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57134}
to control how the memory for Isolate object is allocated.
This is the support for pointer-compression friendly heap layout.
Bug: v8:8182
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Ida36b81ee22bd865005c394748b62d4c0897d746
Reviewed-on: https://chromium-review.googlesource.com/c/1251548
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57131}
Speculatively mitigation for renderer hangs in Scavenger
while waiting in a barrier.
Bug:
Change-Id: I48520e0ffd99123dbe352d2012c911186c187e4b
Reviewed-on: https://chromium-review.googlesource.com/c/1296463
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57130}
For memory limit checks, we should use the minimum of the
--wasm-max-mem-pages flag and kV8MaxWasmMemoryPages. The former is a
limit set by the user, the latter is the maximum we can handle
internally.
R=titzer@chromium.org
Bug: chromium:898677
Change-Id: I3c549f4e90dd016b5d07475d9353f30134f76dcc
Reviewed-on: https://chromium-review.googlesource.com/c/1305274
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57127}
This is a reland of bf3d7b9ae3
Original change's description:
> [wasm] Store compile errors in CompilationState
>
> We are currently storing compilation errors in the individual
> compilation units and pass it to the ErrorThrower during finishing.
> This CL changes that to store errors on the CompilationState directly.
> From there, it is propagated to the ErrorThrower in the compilation
> state callback.
> This removes more work from the finisher task and slims down the
> WasmCompilationUnits.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:8343, v8:7921
> Change-Id: Id332add43d4219d2a30fee653ed4e53a9b2698d9
> Reviewed-on: https://chromium-review.googlesource.com/c/1303720
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57091}
Bug: v8:8343, v8:7921
Change-Id: Iaa5c89d224cb2bcfca2d12eba305413a9ad95618
Reviewed-on: https://chromium-review.googlesource.com/c/1304547
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57126}
BinaryNumberOpTyper was not monotonic: if one input changes
from Number to Numeric, while the other input stays BigInt,
the result would change from Number to BigInt.
We have some fuzzing tests for monotonicity but unfortunately
they never generated the inputs required for triggering this bug.
We'll look into improving our tests.
Bug: v8:8380
Change-Id: I7320d9ae4b89ad8798bf9e97cc272edba2162a77
Reviewed-on: https://chromium-review.googlesource.com/c/1307418
Commit-Queue: Hai Dang <dhai@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57125}
Until this CL, CSA array allocation methods only handled arrays that
could fit into new space. This behavior was preserved in a bunch
of related builtins (e.g. Array.p.map), which completely bailed out to
the slow path if larger allocations were required.
This CL adds large object space handling to array allocation functions,
which means that callers can use the more permissive kMaxFastArrayLength
boundary instead of kInitialMaxFastElementsArray.
Bug: chromium:890599
Change-Id: Idabb0ef232c2896cd453e2ae10b479bf24cbb1c1
Reviewed-on: https://chromium-review.googlesource.com/c/1301483
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57124}
The register allocator uses std::find to search for an element to be
removed from the active/inactive queues repeatedly. As we already know
the exact position of the element to remove, it is better to use an
iterator right away.
Change-Id: I2cd318a5960113d18b3749b2010f8028fe66158d
Reviewed-on: https://chromium-review.googlesource.com/c/1304542
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57121}
This merges all control edges that are known to unconditionally throw
directly into the graph end node. This applies to the "Throw" as well as
the "Rethrow" operation, and reduces their code size.
R=clemensh@chromium.org
BUG=v8:8091
Change-Id: Idd4918ab084bcc697d5798d512ccc695ca943b00
Reviewed-on: https://chromium-review.googlesource.com/c/1305273
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57119}
This is the V8 side of the implementation. You can take a look at a
prototype of the Chrome side changes in https://crrev.com/c/1273043.
Chrome could also use V8's default implementation of the trap handler,
see https://crrev.com/c/1290952.
Bug: v8:6743
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I9bb3e717db17a4f30bbb8acfd80a1f6510d463ff
Reviewed-on: https://chromium-review.googlesource.com/c/1283111
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57117}
These tests rely on dropping references to objects either explicitly ("o =
null;") or implicitly ("o goes out of scope") and then doing gc. It's essential
that we haven't already marked the WeakCell pointing to o and marked it alive
before dropping the reference.
BUG=v8:8179
Change-Id: Ie0b73f05c4baa937cf6f28325454ff9087a71a2c
Reviewed-on: https://chromium-review.googlesource.com/c/1306437
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57115}
If a caller starts the sampling heap profiler and takes a snapshot, and
then deletes the snapshot before the sampling has completed, a
use-after-free will occur on the StringsStorage pointer.
The same issue applies for StartTrackingHeapObjects which shares the
same StringsStorage object.
Bug: v8:8373
Change-Id: I5d69d60d3f9465f9dd3b3bef107c204e0fda0643
Reviewed-on: https://chromium-review.googlesource.com/c/1301477
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57114}
Turns out TryReuseSpillForPhi does more than reusing a spill slot for a
phi (which is beneficial in general). It also decides whether a phi
should start out to be allocated in a spill slot. The latter, of course,
benefits from control flow knowledge. Hence, this change was detrimental
in cases where a common input to a phi is only spilled on few control
flow pathes.
To fix, we need to disentangle spill-slot reuse and the decision whether
a phi should start out spilled. I will look into this in a follow up
change.
This reverts commit b79cbd5615.
Change-Id: I228185bb1a4b320d3115ba7f1d921593480d8e7d
Reviewed-on: https://chromium-review.googlesource.com/c/1304549
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57113}
MIPS64 is a 64-bit platform and each user space process can
address 2^42 bytes of memory. This fixes the current behavior
when the address range was limited to 2^30, which is the
default value taken for 32-bit platforms.
Change-Id: I310e16631a4dfaf77416e278ddf4386f3e258cc3
Reviewed-on: https://chromium-review.googlesource.com/c/1304197
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com>
Cr-Commit-Position: refs/heads/master@{#57112}
This adds appropriate LoopExit nodes for the JSCallReducer lowerings of
the following higher order Array builtins:
- Array.prototype.every()
- Array.prototype.find()
- Array.prototype.findIndex()
- Array.prototype.some()
Loop peeling allows TurboFan to make loop invariant operations in the
callback passed to the higher order builtin fully redundant, and thus
completely eliminate the loop invariant code from the subsequent loop
iterations. This can have a huge performance impact, depending on what
kind of code runs inside of the callback. For example, on the micro-
benchmarks outlined in http://crbug.com/v8/8273 we go from
forLoop: 364 ms.
every: 443 ms.
some: 432 ms.
find: 522 ms.
findIndex: 437 ms.
to
forLoop: 369 ms.
every: 354 ms.
some: 348 ms.
find: 419 ms.
findIndex: 360 ms.
which is 20% improvement, and essentially brings the Array builtins (the
appropriate ones Array#some() and Array#every() in this case) on par
with the hand-written `for`-loop.
Bug: v8:1956, v8:8273
Change-Id: I9d32736e5402807b4ac79cd5ad15ceacd1945681
Reviewed-on: https://chromium-review.googlesource.com/c/1305935
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57110}
Be more consistent for elements kinds and polymorphism in various Array
builtins, which are only iterating over elements.
Bug: v8:1956
Change-Id: I0c02a1b18d95e678e01b816aa36b259a3ba76170
Reviewed-on: https://chromium-review.googlesource.com/c/1306434
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57108}
and use Mixin pattern with linear inheritance instead. This will
allow to customize the way the Isolate is created.
Bug: v8:8238
Change-Id: Ic611df123653af3a0f2271394387492e440b5ea8
Reviewed-on: https://chromium-review.googlesource.com/c/1306433
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57106}
