The watchdog previously didn't terminate execution, it just prevented
the execution of additional tasks.
This CL fixes that by making {TaskRunner::Terminate} actually terminate
execution in the isolate.
It also adds a regression test for this.
R=szuend@chromium.org
Bug: chromium:1154412, chromium:1142437
Change-Id: Ic6638e8a5c37e8840a85651b4d4bea2ee0f71c43
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622212
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72031}
Use a bit to work around the issue of ICU getType() bug.
Bug: v8:11295
Change-Id: I15d65bd44c489031d789e7638ea8abab90128124
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614216
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72028}
Rolling v8/build: d1a7463..d599553
Rolling v8/buildtools: 2277272..235cfe4
Rolling v8/buildtools/linux64: git_revision:0d67e272bdb8145f87d238bc0b2cb8bf80ccec90..git_revision:595e3be7c8381d4eeefce62a63ec12bae9ce5140
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/e174329..d1a3011
Rolling v8/third_party/depot_tools: c1aa4ec..82b992a
Rolling v8/tools/clang: 01d7e1f..2246beeTBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com
Change-Id: Ib358f0e49fab39cf13fb91a0db2a2b453b28c94a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622902
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#72026}
Prototype these 4 instructions:
- i64x2.widen_low_i32x4_s
- i64x2.widen_high_i32x4_s
- i64x2.widen_low_i32x4_u
- i64x2.widen_high_i32x4_u
Implementation is the same as x64.
Drive-by fix to add a missing CpuFeatureScope to x64.
Bug: v8:10972
Change-Id: Iacc84bce156053d0ac39b1a419727c93c499a8c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612339
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72025}
Also remove some ifdefs since it is implemented on all architectures.
Bug: v8:10997
Change-Id: I06f82e2c67219a8990bdd7c78e63b1300c8f34d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2620907
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72024}
Implementation is the same as x64.
Disassembly support for the new instruction, pmulhrsw, is already
supported due to the macro list.
Bug: v8:10971
Change-Id: I099c4f8c3da521006ef5e2b151626f25a5df1ed9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2620898
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72021}
Currently, the CodeMap utilizes double indirection into a deque for
entries in its map. Since we don't reuse CodeEntry objects, this doesn't
confer any benefits really -- avoid this step and save memory by
maintaining only a single mapping.
Bug: v8:11054
Change-Id: I2cbc188ff64dd2faa9c4c03d9892b4c8e5e68794
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617746
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Cr-Commit-Position: refs/heads/master@{#72019}
This CL fixes a bug in the code generation for I32AtomicCompareExchange
in Liftoff on ia32. The problem is the inconsistency that
LiftoffAssembler::PeekToRegister(...) introduces to the cache state.
PeekToRegister loads the value from the value stack into a register, but
does not pop the value off the stack. When the value was already stored
in a register, the use counter of that register gets decreased, even
though the value is still on the stack.
The problem arises when this register later gets reused, which is
necessary unfortunately on ia32. When SpillRegister is called for this
register, all stack values that are stored in this register get written
to memory. SpillRegister uses the use counter of the register to detect
when the register was spilled to all stack slots that were cached by
this register. However, as described above, the value stack and the use
counter are inconsistent at that moment, so SpillRegister finishes
early and does not spill the register to all stack values, and this
causes the bug later.
With this CL the decrement of the use counter gets delayed until when
the value actually gets popped off the stack.
R=clemensb@chromium.org
Bug: chromium:1145135
Change-Id: I07cb256a7e5135dbce41b246c120650635ad2758
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2602464
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72018}
In memory64, the index is a 64-bit value even on 32 bit. Thus the bounds
check needs to check explicitly that the high word is zero. The (pointer
sized) low word is then checked against the actual memory size.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: I311664ccadaec44a6c88777a60b1a3b45b6c0642
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617088
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72016}
We're making a copy of ieee754.(cc|h) in Chromium in
crrev.com/c/2582607. To ensure this copy stays in sync, we're adding a
watchlist for changes on the original ieee754.(cc|h).
Also, watch for changes in dependency of ieee754.(cc|h)
overflowing-math.h, and for changes in the licenses (LICENSE.fdlibm).
Bug: chromium:1145192
Change-Id: I5a967266c8b5c5c973afc48d9b453915f228a268
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593649
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Caleb Raitto <caraitto@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72015}
This adds a first execution test for memory64 in the form of a cctest.
Several things are still not working correctly, hence this test only
checks TurboFan on 64-bit systems, and Liftoff.
Bounds checks in Liftoff are fixed to work correctly on 32-bit.
Follow-up CLs will extend the test to also test TurboFan on 32-bit, the
interpreter, and traps. All of those features still have issues.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: Ic7edcf3783421634fe2ec99eac6f257c557a29b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610968
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72014}
For simplicity this CL includes a first crude conversion of
tickprocessor.mjs. Later CLs will introduce more ES6 syntax and clean
up more code.
Bug: v8:10667
Change-Id: Ief2ca623f5562114fb976a95d156e2ab3f961114
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2611252
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72013}
This change unifies the locals, stack, and globals objects exposed for
WebAssembly frames via the Scope view and via DebugEvaluate to use the
same underlying objects (implemented via interceptors). This also
means that for locals and globals we now consistently expose names
prefixed by a dollar symbol everywhere.
Drive-by-fix: Move the debug::ScopeIterator implementation for WasmFrame
into debug-wasm-support.cc, so WebAssembly scope details are all found
in one place instead of scattered around the code.
Drive-by-cleanup: Rename GetJSDebugProxy to GetWasmDebugProxy for
consistency. GetJSDebugProxy is a bit misleading, since the debug proxy
is not about JavaScript, but just exposed to JavaScript.
Doc: http://bit.ly/devtools-wasm-entities
Bug: chromium:1159307, chromium:1127914, chromium:1162229
Change-Id: If932bd06bbce72542823f63dac1bd976ab33937a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615348
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72009}
1) Since we collect a stack trace for unhandled promises we might end up
invoking code right before the shutdown phase.
2) Any dynamic module import that happens in this phase will enqueue a
microtask job with a freshly allocated DynamicImportData object. It
only gets deleted when fully emptying the microtask queue.
3) Since we're exiting we might end up with a non-empty microtask queue.
4) LSAN detects this as a leak on shutdown.
To make LSAN happy again d8 now keeps track of DynamicImportData to
free them on destructing PerIsolateData.
Bug: chromium:1158223
Change-Id: I9bb21f71bffc75a0d5f4ffc5bf0727c7b4cbab88
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2599755
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72008}
Previously the implementation of the scope iterator objects and the
debug proxy lived in src/wasm, and they are now being moved to
src/debug, to better align with the JavaScript debugging interface,
which also lives in src/debug.
Bug: chromium:1162229, chromium:1071432
Change-Id: I7f89ced88a1231ad6a923be6e85a93f1876a2024
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2621084
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72007}
We shouldn't be creating those anymore since they are not thread-safe.
Bug: v8:7790
Change-Id: I4546d995fa32eb076c8dfe9d95301fad719c9e07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615347
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72006}
ToNumber was already returning base::Optional but it still needed to be
updated for the internal external uncached string case.
As a note, both IsExternal and IsSeqString do not need to be updated
since they only look at the map.
Bug: v8:7790
Change-Id: Icb5ba7f40982c01cada2a9c2b96b824edce70d44
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615422
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72005}
V8_USE_PERFETTO appears in used in the include directory so should be in
v8_header_features rather than features. Moving it means that all users
of the v8 headers will automatically get the define without having to
define it themselves.
Bug: chromium:1006541
Change-Id: I7eb67787fb42499d29c98a76a19a4ad8c04f7aa7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2621083
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@{#72004}
There's no need for the force_instantiate argument as it's not used by
any of the callers.
Bug: v8:11284
Change-Id: I133ac55b1da7b247b7d4b601372d2b2f3fffe36a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2608204
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72002}
This CL disables the fallback to the experimental breadth-first regexp
engine which was enabled in 1e1f9ffc66.
Bug: chromium:1157044
Change-Id: I669b18eddc15ea49aa58192102e719ae7f0364fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593250
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72001}
New internal properties expose the byte length of an ArrayBuffer as well
as the pointer to the backing store, which will serve as a unique ID
to show when SharedArrayBuffers in different workers are the same buffer.
Bug: chromium:1163800
Change-Id: I49930765cb38f75ba5c6cee5a0a6827f4fec42d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618242
Commit-Queue: Eric Leese <leese@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72000}
When creating a new closure, we check feedback vector for any optimized
code and install it on the newly created closure. We evict the optimized
code from the feedback vector if it is marked for deoptimization. We
used to evict the code before creating the new closure. However,
creating a new closure could cause allocation failures and hence trigger
a GC. This could mark optimized code on feedback vector for
deoptimization if any weak objects held by optimized code are GC'ed.
This cl delays the eviction unitl after the closure was created.
Bug: v8:1163184
Change-Id: I217279e4a51f75b87bb7ae5a00fd1cf57805e3c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613034
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71999}
Changes:
- Add two additional PopTypeError overloads which take a C++/C-style
string as argument over a ValueType.
- Change type errors in decoding to use PopTypeError. This improves
consistency of error formatting as well as code readability.
- Improve some immediate argument errors.
- Adapt decoding unit tests.
Change-Id: Ifd54712965049a80692dbc3fde1ef489596e8662
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614059
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71998}
This allows us to reuse this optimized code sequence in Liftoff.
This is similar to the x64 implementation, except that the
macro-assembler function takes an additional scratch register.
Change-Id: Ieaa5899cd1be65abee1c6e0c0908a357777afcd9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610510
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71996}
Invoking Goto in graph-builder-interface from inside a 'let' can cause
the number of locals between source and target ssa environment to be
different. This CL addresses this bug and adds a few unit tests.
Unfortunately, after this change we have to resort to always using
copy-constructors for SsaEnv, which might cause slowdown in decoding.
Bug: v8:9495
Change-Id: Idf5ace6c7563eff9d774d402f3a81e77959556ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614062
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71993}
This CL just allows the compilation to pass.
Port 673be63e2b
Change-Id: I5d66ba6b353f6f94d22e506ff42ce81859ec876d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2619004
Auto-Submit: Liu yu <liuyu@loongson.cn>
Reviewed-by: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#71992}
In a couple of places we cast between uintptr_t and uint64_t with a
reinterpret_cast. While this is correct when these types are aliased
to the same type, if they are defined to be different integral types
(while still of the same size), reinterpet_cast won't work.
Change-Id: I6e935c6c263d8df16f88659ac285faeb5e073add
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614678
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#71988}
I made some temporary changes in BytecodeArrayWriter to log counts of
how often each pair of bytecodes is adjacent. In data I collected on a
Facebook page with those changes enabled, I noticed that the following
bytecodes were commonly followed by Star, but do not appear in
IsStarLookahead.
LdaImmutableCurrentContextSlot:
4.4% of all instructions, 66% chance to be followed by Star
CreateClosure:
3.9% of all instructions, 57% chance to be followed by Star
LdaImmutableContextSlot:
1.7% of all instructions, 95% chance to be followed by Star
CreateObjectLiteral:
1.4% of all instructions, 92% chance to be followed by Star
CreateArrayLiteral:
1.4% of all instructions, 99% chance to be followed by Star
ThrowReferenceErrorIfHole:
0.7% of all instructions, 100% chance to be followed by Star
GetTemplateObject:
0.6% of all instructions, 100% chance to be followed by Star
CreateEmptyArrayLiteral:
0.4% of all instructions, 87% chance to be followed by Star
CreateEmptyObjectLiteral:
0.2% of all instructions, 79% chance to be followed by Star
I cross-referenced this list with data from google.com and youtube.com
(the top two sites according to Alexa), and found that CreateClosure and
CreateEmpty*Literal are not likely followed by Star on those sites.
Without those three, I suggest that the following bytecode handlers
would likely benefit from Star lookahead:
LdaImmutableCurrentContextSlot
LdaImmutableContextSlot
CreateObjectLiteral
CreateArrayLiteral
ThrowReferenceErrorIfHole
GetTemplateObject
I also ran Octane with --noopt and got the following results.
Name Median change (95% CI) U test result
----------------- ------------------------ -------------------
Richards +1.02% to +3.28% improved p=1.8e-05
DeltaBlue -1.47% to +0.12% regressed p=0.05
Crypto -1.11% to +0.93% inconclusive
RayTrace -1.10% to +0.48% inconclusive
EarleyBoyer -0.25% to +1.29% inconclusive
RegExp -1.46% to +0.08% inconclusive
Splay -1.10% to +0.03% inconclusive
SplayLatency +0.13% to +0.92% improved p=5.8e-05
NavierStokes -0.22% to +1.24% inconclusive
PdfJS -0.69% to +1.04% inconclusive
Mandreel -0.66% to +0.66% inconclusive
MandreelLatency +0.32% to +1.77% improved p=0.00024
Gameboy -1.13% to +0.38% inconclusive
CodeLoad -0.27% to +0.43% inconclusive
Box2D -0.53% to +0.82% inconclusive
zlib -0.19% to +0.19% inconclusive
Typescript -0.23% to +0.59% inconclusive
Score (version 9) -0.18% to +0.68% inconclusive
I'm somewhat puzzled by the DeltaBlue regression, since DeltaBlue
agrees that all of the selected bytecodes are likely to precede Star,
but overall I think this change is more benefit than harm.
Change-Id: Ib9b4033f3cda273e99c9f0252d0055e203921916
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615946
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#71987}
Changing coverage mode generated different bytecode in some cases.
Hence it is not safe to flush bytecode once we toggle coverage mode.
Bug: chromium:1147917
Change-Id: I9e640aeaec664d3d4a4aaedf809c568e9ad924fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615020
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71985}
This is a reland of a3ce2f6da2
(No changes; was reverted because a dependency was reverted.)
Original change's description:
> [wasm-gc] Liftoff support part 5: i31
>
> This implements support for i31.get_s and i31.get_u.
>
> Bug: v8:7748
> Change-Id: Icbfddbc2ff46b4eb6bf3edf7b3a794f9797361d4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595309
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71808}
Bug: v8:7748
Change-Id: Id8e66cab285d2a36fcd712b92a522e83dea93193
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617089
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71984}
