- 12 Jul, 2019 13 commits
-
-
Peter Marshall authored
Everyone was getting a copy of this through debug.h. Bug: v8:9396 Change-Id: I5189cb4bf27a3381768b0be479d7b3d60dec20bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695472 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62670}
-
Sam Clegg authored
I noticed the indentation was off in one function, but also fixed all the other flake8 issues in this file. Change-Id: I2303ed87da7154484a872315f8355f57621514c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697054Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Sam Clegg <sbc@chromium.org> Cr-Commit-Position: refs/heads/master@{#62669}
-
Sathya Gunasekaran authored
Previously, we didn't have access checks for the megamorphic case cause we'd never get to this IC state for a receiver that doesn't hold the right private field. But now with lazy feedback allocation we share the megamorphic case code paths for the uninitialized loads as well, which exposes our bug. Bug: chromium:982702 Change-Id: I419406bcfc52575260a85d05520c1662735e15f8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697256Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#62668}
-
Darius Mercadier authored
This CL adds a new FreeList strategy, that can be turned on by using flag `--gc-freelist-strategy=1`. It is inspired by FreeListLegacy, and differs from it in the following ways: - Only has 3 categories: Medium, Large and Huge. - Any block that would have belong to tiniest, tiny or small in FreeListLegacy is considered wasted. - Allocation is done only in Huge, Medium and Large (in that order), using a first-fit strategy (only the first block of each freelist is ever considered though). - Performances is supposed to be better than FreeListLegacy, but memory usage should be higher (because fragmentation will probably be higher). Bug: v8:9329 Change-Id: Ib399196788f1dfaa1aeddc3dc721375dd7da65f1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697248 Commit-Queue: Darius Mercadier <dmercadier@google.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#62667}
-
Michael Starzinger authored
R=clemensh@chromium.org BUG=v8:9429,v8:9396 Change-Id: I1d8b5b67e5cd1b1788e6c0dcb45762c555b6f0e0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695471Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#62666}
-
Nico Hartmann authored
This change implements lowering of speculative BigInt addition as well as BigInt heap constants to corresponding int64 versions, if they are used in a context where the result is truncated to the least significant 64 bits (e.g. using asUintN). The JSHeapBroker is extended to provide access to the BigInt's least significant digit during concurrent compilation. The BigInt context (required to introduce correct conversions) is recognized in the RepresentationChanger by either the output type propagated downward or the TypeCheckKind propagated upward. This is necessary, because the TypeCheckKind may only be set by nodes that may potentially deopt (and sit in the effect chain). This is the case for SpeculativeBigIntAdd, but not for BigIntAsUintN. This CL contains a simple fix to prevent int64-lowered BigInts to flow into state values as the deoptimizer cannot handle them yet. A more sophisticated solution to allow the deoptimizer to materialize truncated BigInts will be added in a following CL. Bug: v8:9407 Change-Id: I96a293e9077962f53e5f199857644f004e3ae56e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1684183 Commit-Queue: Nico Hartmann <nicohartmann@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#62665}
-
Georg Schmid authored
This CL adds the --assert-types flag to d8, which is intended to insert additional runtime checks after typed nodes, verifying the validity of our typing rules. So far, only range types are checked. Thanks to Neil Patil for suggesting something similar. R=neis@chromium.org, tebbi@chromium.org Change-Id: I5eb2c482235ec8cd07ee802ca7c12c86c2d3dc40 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1678372 Commit-Queue: Georg Schmid <gsps@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#62664}
-
Frank Tang authored
https://chromium.googlesource.com/external/github.com/tc39/test262/+log/1ef21eb..6cb0a5 Bug: v8:7834 Change-Id: I809d7ddc0c579cf3fa8c9563d8f0ef59d4cc708b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1699302 Auto-Submit: Frank Tang <ftang@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#62663}
-
Michael Achenbach authored
NOTRY=true Bug: chromium:813833,chromium:983128 Change-Id: I449796b761f53bb15a3563604d5a4a9018035cb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697255Reviewed-by: Tamer Tas <tmrts@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#62662}
-
Andreas Haas authored
Even though this is not spec'ed yet, it's good to have an implementation so that we can use clusterfuzz on it. I changed the parameter order (hopefully) everywhere to (table_dst_index, table_src_index, ...). This corresponds to the (dst, src, ...) parameter order for the entry indices. R=binji@chromium.org Bug: v8:7581 chromium:980475 Change-Id: I2fb36ffd4bb2f2be5b22c8366732295fa6759236 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698386Reviewed-by: Ben Smith <binji@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#62661}
-
Jon Kunkee authored
This change fixes missing symbol errors in the Windows 10 on ARM build of Node.js. When a whole class is marked for export, all of its members are marked as well. This can be a problem when inline members call undefined yet inline members of other classes: the exported function will contain a reference to the undefined inline function that should be satisfied at link time, but because the other function is inline no symbol will be produced that will satisfy that reference. Clang gets around this by masking inlined class members from export using /Fc:dllexportInlines-. This is why b0a2a567 worked. Node.js' Windows builds use MSVC and so do not have access to this flag. This results in unresolved symbols at link time. Bug: v8:9465 Change-Id: Ief9c7ab6ba35d22f995939eb62a64d6f1992ed85 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1696771Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62660}
-
Yutaka Hirano authored
This is a reland of https://crrev.com/c/v8/v8/+/1692366. The original change was reverted because it broke some blink tests. This will be landed after suppressing them: https://crrev.com/c/chromium/src/+/1695541 Make native errors serializable. The implementation is mostly straightforward, but there is one exception: the stack property. Although the property is not specified, the spec for error cloning asks us to preserve the property if possible. This implementation serializes the property only when it is a string, and otherwise ignores it. Spec: https://github.com/whatwg/html/pull/4665 Intent-to-Ship: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/f8JngIi8qYs Bug: chromium:970079, v8:9462 Change-Id: Ibf012754f30237f6b5acf119ef834e73727a230f Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695202 Auto-Submit: Yutaka Hirano <yhirano@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#62659}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/40634f1..c989268 Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/80b545b..95c72f3 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/b79dda9..1abe66f Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/d3f6994..78dec04 Rolling v8/tools/luci-go: git_revision:25958d48e89e980e2a97daeddc977fb5e2e1fb8c..git_revision:7d11fd9e66407c49cb6c8546a2ae45ea993a240c Rolling v8/tools/luci-go: git_revision:25958d48e89e980e2a97daeddc977fb5e2e1fb8c..git_revision:7d11fd9e66407c49cb6c8546a2ae45ea993a240c Rolling v8/tools/luci-go: git_revision:25958d48e89e980e2a97daeddc977fb5e2e1fb8c..git_revision:7d11fd9e66407c49cb6c8546a2ae45ea993a240c TBR=machenbach@chromium.org,sergiyb@chromium.org,tmrts@chromium.org Change-Id: I014010e41a1fe31582ab5aa3abbb28b1f1be32f9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698803Reviewed-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@{#62658}
-
- 11 Jul, 2019 27 commits
-
-
Ben Smith authored
The alignment should be 3 (i.e. 8 bytes), but was specified as 2 (i.e. 4 bytes). Bug: v8:9425 Change-Id: I0beb09df25fe0281ed604909e894afd804f5411e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1693836Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Ben Smith <binji@chromium.org> Cr-Commit-Position: refs/heads/master@{#62657}
-
Andreas Haas authored
Even though this is not spec'ed yet, it's good to have an implementation so that we can use clusterfuzz on it. R=binji@chromium.org Bug: v8:7581 Change-Id: I323625322e5240dc6ac224dce8a1f1f7f6070758 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695478Reviewed-by: Ben Smith <binji@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#62656}
-
Jakob Kummerow authored
Change-Id: Id474294a808f5c77321cd12ff5333eb6000b04fa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1692933 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#62655}
-
Tobias Tebbi authored
This is a partial revert of https://chromium-review.googlesource.com/c/v8/v8/+/1675960 Bug: v8:9472 Change-Id: I57ffc8d90a57336197cbf6ee27ebf9d1c914ec73 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697745 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Auto-Submit: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#62654}
-
Mythri A authored
With lazy feedback allocation and bytecode flushing we need to call %PrepareFunctionForOptimize before we call %OptimizeFunctionOnNextCall/ %OptimizeOsr. This cl: 1. Adds an additional state in pending optimized table to check if the optimization was triggered manually. 2. Changes the compilation pipeline to delete the entry from pending optimized table only if the optimization was triggered through %OptimizeFunctionOnNextCall / %OptimizeOsr. 3. Adds a check to enforce %PrepareFunctionForOptimize was called. 4. Adds a new run-time flag to only check in the d8 test runner. We don't want this check enabled in other cases like clusterfuzz that doesn't ensure %PrepareFunctionForOptimize is called. Bug: v8:8394, v8:8801, v8:9183 Change-Id: I9ae2b2da812e313c746b6df0b2da864c2ed5de51 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664810 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#62653}
-
Maciej Goszczycki authored
BasicMemoryChunk sits above the MemoryChunk in the chunk hierarchy and is responsible for storing the bare minimum data to identify a chunk of memory, without worrying about GC etc. This change also completes the MemoryChunk offset asserts, which were previously missing for few key properties. Bug: v8:7464 Change-Id: Id4c7716c4ed5722ceca3cbc66d668aed016c74b0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1688843 Commit-Queue: Maciej Goszczycki <goszczycki@google.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#62652}
-
Jakob Kummerow authored
Change-Id: Id1c46ca22002c358155823e3caae18f0ed9c47f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691033 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#62651}
-
Peter Marshall authored
The simulator builds have bugs which cause invalid frame markers in some cases. Change-Id: I837732c6f5efe24821415a0ae0626578bbcc3a7e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697253Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#62650}
-
Mythri A authored
GetOwnPropertyNameTryFast uses ENUMERABLE_STRINGS filter to trigger fast path in KeyAccumulator::GetKeys conditionally when all properties on the receiver are enumerable. It is not easy to verify if all properties are enumerable and the current check is incorrect in some cases. For ex: when we have non-enumerable properties when we have elements on the receiver. This cl removes this try_fast path from the builtin. This could impact performance. The long term fix for this would be to fix KeyAccumulator::GetKeys to use fast path for more cases. Bug: chromium:977870 Change-Id: Iecde730739c2c452ffa0d893d0d1b3612a45d1b2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1679499Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#62649}
-
Andreas Haas authored
R=mstarzinger@chromium.org Bug: v8:7581 Change-Id: I9db3d2e4b2e2a685f81b516da8e6737db01c1238 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695470 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#62648}
-
Maciej Goszczycki authored
These are ancient artefacts from when HeapObject was a pointer. Bug: v8:9396 Change-Id: I1782837aa5bd4b8393cd084321b90baa614a7373 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691911Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Maciej Goszczycki <goszczycki@google.com> Cr-Commit-Position: refs/heads/master@{#62647}
-
Michael Achenbach authored
In order to migrate the extra flags into the fuzzer and keep bisection stable, we need to use the same RNG state for each call to generating fuzz flags. Throughout one fuzzing session the same random-seed is used (https://crbug.com/983128) and we'll pass it to the fuzz config in a follow up. TBR=tmrts@chromium.org NOTRY=true Bug: chromium:813833 Change-Id: I3203c86028a5d283238e6ef739f82eccee1302b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697254 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#62646}
-
Santiago Aboy Solanes authored
Reverse specialization of https://chromium-review.googlesource.com/c/v8/v8/+/1684075. Again, it skips over Tagged to save some instructions. Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng Bug: v8:7703 Change-Id: I7fc50e0d8eebfef7a1ba02ce3d687ff808f30680 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1693007Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#62645}
-
Ben L. Titzer authored
In the atomics stress, the search for sequential sequences creates lots of new WebAssembly.Memory objects. This memory pressure is not central to this test, so reuse the same memory to make them less flaky. R=mstarzinger@chromium.org Change-Id: I8d135e7b82d572cb1df38f37a4e2f6393f6b2e05 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697247Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#62644}
-
Andreas Haas authored
This removes an include that was added unnecessarily in https://crrev.com/c/1690960. R=clemensh@chromium.org Bug: v8:9396 Change-Id: I5cf7ae49b3a40b6665605af1db6b43b27aeb3a32 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1692927Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#62643}
-
Michael Starzinger authored
R=clemensh@chromium.org BUG=v8:9429,v8:9396 Change-Id: I3b098ea8b5bbbd93ac3bf7acfeb8ee20a867759a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1693004Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#62642}
-
Michael Starzinger authored
This adds support for properly importing {WebAssembly.Function} objects that were constructed in JavaScript and just wrap a JavaScript callable. R=ahaas@chromium.org TEST=mjsunit/wasm/type-reflection BUG=v8:7742 Change-Id: I00e01db0d85b83d405eb28517d00fba62c253985 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690949 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#62641}
-
Frank Tang authored
https: //chromium.googlesource.com/external/github.com/tc39/test262/+log/079b00..1ef21eb Bug: v8:7834 Change-Id: I0c6b42c4bd13839138cf333a311bdd5404dc4496 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687062Reviewed-by: Mathias Bynens <mathias@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#62640}
-
Jakob Kummerow authored
Change-Id: I871659626b41a15723f92150f6f076d356313136 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691028 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#62639}
-
Georg Neis authored
This reverts commit a6eabacf. Reason for revert: as planned Original change's description: > Disabe FLAG_turbo_control_flow_aware_allocation again > > A few changes have been made to this feature and disabling it lets us > best see its current performance impact. > > Bug: v8:9088 > Change-Id: I54d5e09f3fcece215e29d66d5bdb3f19ba07bda0 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690954 > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62586} TBR=neis@chromium.org,sigurds@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:9088 Change-Id: I13b94d90cfb2d8e9372291645729e05b79a9a6ea Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697243Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#62638}
-
Darius Mercadier authored
Change-Id: Ic483412145cabd2fce8f556fd56ca352dbe4ce17 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695466Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Darius Mercadier <dmercadier@google.com> Cr-Commit-Position: refs/heads/master@{#62637}
-
Lei Zhang authored
In a DCHECK inside AddExport(), MSVC gives a C4018 signed/unsigned mismatch warning. Use a cast to silence this. Change-Id: Ie388b95b183d2ca3649475fe2206171800673f88 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697043 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Auto-Submit: Lei Zhang <thestig@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62636}
-
Darius Mercadier authored
Bug: v8:9329 Change-Id: I28619fef8f206fcb749b8974bb3e7547d6da402e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687423 Commit-Queue: Darius Mercadier <dmercadier@google.com> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#62635}
-
Peter Marshall authored
Add a bit on the isolate which indicates that the stack is currently not iterable for the SafeStackFrameIterator. This is needed during deoptimization, when we do a fast C call without a return address on the stack, meaning we can't iterate the stack frames. Re-enable DeoptAtFirstLevelInlinedSource which is fixed by this CL. Bug: v8:9057 Change-Id: I76379a2dd38023be7e6f5153edeb1f838e9ac4d6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1688049 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62634}
-
Clemens Hammacher authored
This removes the last remaining use of the AbortJS opcode. We now use AbortCSAAssert instead, which is not influenced by the --disable-abortjs flag. The AbortJS runtime function should only be called from JS now. R=mstarzinger@chromium.org Bug: v8:9396 Change-Id: I791da99594f9e1e99991ac8b03e943297d7d41e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695476 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#62633}
-
Michael Starzinger authored
This fixes a corner-case where a {WasmExportedFunction} that represents a re-export of a JavaScript callable from another module was identified correctly, but not all corner-cases were correctly covered. Concretely we failed to check for function signatures incompatible with JavaScript. R=ahaas@chromium.org TEST=mjsunit/regress/wasm/regress-9447 BUG=v8:9447 Change-Id: Ia6c73c82f4c1b9c357c08cde039be6af100727d6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690941 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#62632}
-
Jakob Gruber authored
Prior to this CL, it was possible to pollute another context's fast/slow-path state for RegExp builtins due to the species protector being per-isolate rather than per-context. Among other things, this means that iframes can slow down the main site, and slowdowns persist across page reloads and navigation within the same tab. This CL thus moves the RegExpSpeciesProtector to the native context. The same should be done for all other protectors in the future. Bug: chromium:977382, v8:5577, v8:9463 Change-Id: I577f470229cb9dfcd4a88c20b1b9111c65a9b85f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695465 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#62631}
-