- 09 Jan, 2021 3 commits
-
-
Milad Fa authored
Bug: v8:11086 Change-Id: Ic59e270282b5b7f3d2f8e8b46586964c69e4447a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618289Reviewed-by:
Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#71991}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/3480342..9bc4494 Rolling v8/third_party/aemu-linux-x64: e-bgBYXeOkMw5xrqjCgQDp16bMPZeKKmilHzC-t2-1QC..luM2HIHgfBKxr1C7UPo8RdQPAvyLNd74T9rYfhWFOC8C Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/d9d7213..e174329 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/4c392af..0e4e5ae TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I68df6308e99fc5495765cfcf56a414b81217f1e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2619278Reviewed-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@{#71990}
-
Sathya Gunasekaran authored
This reverts commit 8aa6b15f. Reason for revert: broke TSAN https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/1497/overview Original change's description: > Disable bytecode flushing once we toggle coverage mode. > > 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} TBR=rmcilroy@chromium.org,mythria@chromium.org Change-Id: Id4c95da337e291437b7856e2fe7004e1e6405515 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1147917 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2619402Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#71989}
-
- 08 Jan, 2021 28 commits
-
-
Georgia Kouveli authored
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/+/2614678Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Cr-Commit-Position: refs/heads/master@{#71988}
-
Seth Brenith authored
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/+/2615946Reviewed-by:
-
Milad Fa authored
Port 5af79398 Original Commit Message: Prototype load lane instructions on Liftoff, only for x64. R=zhin@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG= LOG=N Change-Id: If9429791139d08a3dd7548220b4eb28e99d6fc7e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618241Reviewed-by:
-
Mythri A authored
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:
-
Jakob Kummerow authored
This is a reland of a3ce2f6d (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/+/2617089Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#71984}
-
Junliang Yan authored
Change-Id: I68ef1a97ac857106e014d561be3d7e845ec9fbdc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618280Reviewed-by:
Milad Fa <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/master@{#71983}
-
Santiago Aboy Solanes authored
Follow-up that continues to make StringRefs's methods return optional values. Bug: v8:7790 Change-Id: I34f907810747216b047a3da8db035cf4f62728c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615162Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#71982}
-
Benedikt Meurer authored
Previously the Debug Proxy API that's exposed on Wasm frames by Runtime.evaluateOnCallFrame() was implemented via actual JSProxy instances. That means that all entities such as "memories", "tables", "stack", "globals", etc. were JSProxy instances with "get" and "has" traps. But that has a couple of down-sides: 1. In DevTools front-end, the proxies are shown as JSProxy, which is not very useful to developers, since they cannot interact with them nor can they inspect their contents. And the object preview also only shows "Proxy {}" for them. 2. The performance doesn't scale well, which becomes a painful bottleneck with larger Wasm modules that contain hundreds of thousands of functions or globals. 3. We cannot use the JSProxy instances in the Scope view (for the reasons outlined in 1.) and hence we have different logic to provide Scope values than values in the rest of DevTools, which led to subtle but annoying bugs and inconsistencies. This also changes the "locals" implementation by querying the values ahead of time, similar to the object exposed to the Scope view, instead of on-demand, since the "locals" object might survive the current debugger pause and peeking into the stack afterwards would read invalid memory (and might even be a security issue). For being able to change locals we need to look into a similar solution as what we have for JavaScript locals already. The expression stack already works this way. For performance reasons (especially scaling to huge, realistic Wasm modules), we cache the per-instance proxies ("functions", "memories", "tables" and "globals") on the WasmInstanceObject and reuse them (which is safe since they have a `null` prototype and are non-extensible), and we also cache the proxy maps (with the interceptors) on the JSGlobalObject per native context. Doc: http://bit.ly/devtools-wasm-entities Bug: chromium:1127914, chromium:1159402, chromium:1071432, chromium:1164241 Change-Id: I6191035fdfd887835ae533fcdaabb5bbc8e661ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606058 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@{#71981}
-
Zhi An Ng authored
Prototype load lane instructions on Liftoff, only for x64. Bug: v8:10975 Change-Id: Ifdf58f08b65762d592e99de91c7c622d2a964a9a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612335 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#71980}
-
Michael Lippautz authored
Similar to V8, we provide the include/ headers through a "base" target. Without this change, `gn check` complains about including cppgc headers in Blink. Bug: chromium:1056170 Change-Id: I09ad943cdfedae8c83ab7f957efba796637b8d48 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617087Reviewed-by:
Omer Katz <omerkatz@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#71979}
-
Santiago Aboy Solanes authored
They weren't initializing the VM at the start of the test. Also updated the test description. Bug: v8:7790 Change-Id: I7b9df9e3aebb43fc526e16ec260aa071c0fdeb92 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615019 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#71978}
-
Santiago Aboy Solanes authored
In order to avoid internal external uncached Strings, we can copy the String at the moment of internalizing if it is an external & uncached String. Bug: v8:7790 Change-Id: Ie7ed287c105a127b8b4c867aab1a808265a922b7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613029 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
-
Zhi An Ng authored
We were incorrectly clearing the high reg from the list of regs to load. The intention was to prevent double (and incorrect) loading - loading 128 bits from the low fp and the loading 128 bits from the high fp. But this violates the assumption that the two regs in a pair would be set or unset at the same time. The fix here is to introduce a new enum for register loads, a nop, which does nothing. The high fp of the fp pair will be tied to this nop, so as we iterate down the reglist, we load 128 bits using the low fp, then don't load anything for the high fp. Bug: chromium:1161654 Change-Id: If2ea79132b78623e5990237c60cf0883d9a8223f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617380Reviewed-by:
-
Santiago Aboy Solanes authored
We are planning on moving String to kNeverSerialized. For this, we are modifying its methods to bail out if they encounter a NeverSerialized non-internalized String. Bug: v8:7790 Change-Id: Ia83c1385e53707ddec374e1730963c29b928a08c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615420Reviewed-by:
-
Thibaud Michaud authored
Delegating to the current control depth is valid and rethrows the exception to the caller. See https://github.com/WebAssembly/exception-handling/pull/143. R=clemensb@chromium.org CC=aheejin@chromium.org Bug: v8:8091 Change-Id: I6f14663751736ec6de29eefebfccdf5eb9e955e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617081 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
-
Leszek Swirski authored
This fixes failures on bots running with --extra-flags=--future Change-Id: I9594f44db9cc749d02151b695300b5c888f2c99b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617085 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Georg Neis authored
Now that the underlying bug is fixed, we can expect the test to always pass. Also simplify the test a tiny bit and skip it on debug builds because it's slow. Bug: chromium:1161357 Change-Id: I2ce5e064b4f707f4bd680f04df95d5a342bec1b0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2616220Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#71972}
-
Michael Achenbach authored
Bug: chromium:1163882 Change-Id: Iecb5ac5a42f0000b2c5daf5c27412e3bd833a953 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2616222 Auto-Submit: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
-
Camillo Bruni authored
Change the background of source position markers based on the events they link to. Bug: v8:10644 Change-Id: I108d9f5670acdaf5835905c2b44648c0eaf6dbd0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2604708 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
-
Sathya Gunasekaran authored
The IC object's interface is changing all the time and this code is just bitrotting. Rather than trying to keep this updated all the time, let's just use Object.values to print all the key value pairs in the ic object. This looks slightly worse than the previous text format but it has the critical advantage of being broken less often. Change-Id: Ia3580d1ba82a981d8442682f66d6002436e70f42 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615418 Auto-Submit: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#71969}
-
Almothana Athamneh authored
Bug: v8:11264 Change-Id: I9563ede8e4a5f1eea17e5ee93a8ab8609c3000b9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614426 Commit-Queue: Almothana Athamneh <almuthanna@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#71968}
-
Zhi An Ng authored
For Float64Abs, Float64Neg, F64x2Abs, and F64x2Neg, we can use the Abspd and Negpd helpers. These helpers will load the necessary masks as an ExternalReference. We cannot do the same with AVX, since the AVX codegen can already have one of the inputs as an Operand. Change-Id: I85f0a7437747b9cfe8bff735d7b27a957736818c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2599850 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#71967}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/dc0b854..3480342 Rolling v8/third_party/aemu-linux-x64: eNKL3iFnDydKoCyqA9rVhylE7ud5a_9wRt0b0HFtLvIC..e-bgBYXeOkMw5xrqjCgQDp16bMPZeKKmilHzC-t2-1QC Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/3f5c581..d9d7213 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/81098e5..4c392af Rolling v8/third_party/googletest/src: https://chromium.googlesource.com/external/github.com/google/googletest/+log/4fe0180..1b0cdaa Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/1283870..01d7e1f TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: Ie045e572a2e7927f84358510e97f32c58c166eb2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617446Reviewed-by:
-
Zhi An Ng authored
This is a reland of 94f2212b Nothing changed, think the failures were flaky. Original change's description: > [wasm-simd] Scalar lowering for extended multiply > > R=bbudge@chromium.org > > Bug: v8:11262 > Change-Id: Idd6a7514a16c561832af603dbf63779a0e402f45 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2603771 > Reviewed-by: Bill Budge <bbudge@chromium.org> > Commit-Queue: Zhi An Ng <zhin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71920} Bug: v8:11262 Change-Id: I6c504b2e0d1ad39e202483a72419dadb3b66eea8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612330Reviewed-by:
-
Zhi An Ng authored
When AVX2 is available, we can use vbroadcastss. On AVX, use vshufps, since it is non-destructive. On SSE, shufps is 1 byte shorter. FIXED=b/175364402 Change-Id: I5bd10914579d8db012192a9c04f7b0038ec1c812 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2599849Reviewed-by:
-
Zhi An Ng authored
Change-Id: Ia25cc038c09a900d906bd8e724244418a5708675 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610511Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71963}
-
Benedikt Meurer authored
Previously we had introduced a special `v8::internal::WasmValue` type which we used to expose Wasm values to the Scope view in Chromium DevTools. The problem however is that these values cannot be exposed to JavaScript (and in particular not to Debug Evaluate), which means that particularly for v128 and i64 we have inconsistent representations across the various parts of DevTools. This change removes the `wasm` type from the RemoteObject and all the adjacent logic, and paves the way for a uniform representation of Wasm values throughout DevTools. For i64 we will simply use BigInt consistently everywhere, and for i32, f32 and f64 we'll just use Number. For externref we will represent the values as-is directly. For v128 values we currently use a Uint8Array, but will introduce a dedicated WasmSimd128 class in a follow-up CL. Bug: chromium:1071432 Fixed: chromium:1159402 Change-Id: I0671e5736c9c27d7ca376e23ed74f16d36e03c80 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614428Reviewed-by:
Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Zhi An Ng authored
This is a reland of 2d5f981a The fix is in liftoff-assembler-x64, to call S128Select with dst as the mask when AVX is not supported and dst != mask. Original change's description: > [wasm-simd][liftoff][x64] Move v128.select into macro-assembler > > This allows us to reuse this optimized code sequence in Liftoff. > > We can't do the same thing in IA32 yet, there is no kScratchDoubleReg > defined in the macro-assembler-ia32.cc, it is defined in code-generator-ia32 > as xmm0 but I'm not sure if it is safe to just use that in the macro assembler. > > Change-Id: I6c761857c49d2518fbc82cd0796c62fc86665cb5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596581 > Commit-Queue: Zhi An Ng <zhin@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Bill Budge <bbudge@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71915} Change-Id: Ib96ce0e1d5762f6513ef87f240b25ef3ae59441f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612324Reviewed-by:
-
- 07 Jan, 2021 9 commits
-
-
Daniel Clark authored
There's a bit more work to do to add support for import assertions for dynamic import(). This is the first of a series of changes to do that. This adds parser support for the form of import() that takes import assertions per https://tc39.es/proposal-import-assertions/#prod-ImportCall A future change will pass the assertions expression along to Runtime_DynamicImportCall where the assertions will be unpacked and filtered per Isolate::supported_import_assertions_. Bug: v8:10958 Change-Id: Ib1c80d15ac44923d97c5fdfcc4bd732cb9245cf9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612038Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
-
Michael Lippautz authored
Previously, for wrapper/wrappable pairs, only JS object size was accounted for. With this change, the C++ part is also accounted for. Change-Id: Ibd945cb28c808d8c01fa41453f94a6de9883b764 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615258Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#71959}
-
Sathya Gunasekaran authored
Bug: v8:11256 Change-Id: Iec03fc77daeed9aeaacde13f5be2304d2a7e2c26 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610969Reviewed-by:
-
Sathya Gunasekaran authored
Instead of always using v8::ConstructorBehavior::kAllow and then immediately calling FunctionTemplate::RemovePrototype, this patch changes FunctionTemplateInfo::New to pass in the correct value for v8::ConstructorBehavior. There is no change in observable behavior with this patch. Bug: v8:11288 Change-Id: Ia7dd8a0c1ac6d081bc0d9b73d7c7cb4164638144 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612990Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#71957}
-
Dan Clark authored
When --harmony-dynamic-import was removed in https://chromium-review.googlesource.com/c/v8/v8/+/2509942 it looks like we were left with some redundant invocations of RunParserSyncTest/RunModuleParserSyncTest in ImportExpressionErrors. This removes them. Change-Id: I2fb68c7e21bc4e039ab77396cdca7ca0d18eca95 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613370Reviewed-by:
-
Shu-yu Guo authored
This implements the spec change in https://github.com/tc39/ecma262/pull/2164 Making TA elements configurable has interaction with delete. While the elements are configurable, they are only "deletable" via detaching the underlying ArrayBuffer, not via `delete`. That is, `delete ta[idx]` for an in-bounds `idx` still returns false. Bug: v8:11281 Change-Id: I2e9348a7ec3c3239a92cc35e51b7182423736834 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2605234Reviewed-by:
-
Mythri A authored
When bytecode gets flushed from SFI and we generate the bytecode again, we expect that the generated bytecode is exactly the same as the earlier bytecode. We reuse the same closure feedback cell array allocated earlier and hence it is required that number of closure feedback slots remain the same. This cl just adds a CHECK for that, so we fail when this is not the case. Bug: chromium:1147917 Change-Id: I4b09ce3f741bc15c3b141b1fe057a667496c925d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613037 Commit-Queue: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Auto-Submit: Mythri Alle <mythria@chromium.org> Reviewed-by:
-
Andreas Haas authored
When --single-threaded is set, and therefore --wasm-num-compilation-tasks=0, the compilation job for JSToWasm wrapper compilation is executed directly instead of first posted and then joined on the main thread. R=clemensb@chromium.org Bug: v8:11279 Change-Id: Idba150cf9d32a6a6b12b322f46c0ba36fd220c5b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595441 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Leszek Swirski authored
Bug: chromium:1163847 Change-Id: Iabb152cd1a5c04e2032cb1254d8b27ea081cbb27 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614427 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
