- 13 Jun, 2022 1 commit
-
-
Igor Sheludko authored
... setting too low --max-old-space-size value. Fixes: v8:12725 Change-Id: I5b1b533992d6b1024e81263525ed90914582e27a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695594 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#81107}
-
- 08 Jun, 2022 2 commits
-
-
Thibaud Michaud authored
Context: https://github.com/WebAssembly/exception-handling/pull/197 This change removes the wasm exception -> JS Error inheritance. R=jkummerow@chromium.org Bug: v8:8091 Change-Id: I479f16fe03d4d77d2ecd8409e96f9a3c063912b5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688401 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/main@{#80997}
-
Jakob Kummerow authored
Performing the "swap with TypeCast" input optimization causes inconsistent types for unreachable AssertNonNull instructions (that should inherit that TypeCast's <bot> type). Fixed: v8:12945 Change-Id: Ie51cd6531267a2828c6aac92948edda5c2a5db37 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3693708 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/main@{#80989}
-
- 07 Jun, 2022 1 commit
-
-
Nico Hartmann authored
In typed-optimization, Turbofan optimized NumberFloor(NumberDivide(...)) patterns where both inputs are known to be of Unsigned32 type, but the replacement couldn't be typed consistently. This CL introduces a new operator Unsigned32Divide, which has the same semantics, but can be typed consistently and thus allows the simplified lowering verifier to validate the graph correctly. Bug: v8:12619 Change-Id: Iad77154d3d840c94edfd3ab91ffa37c840da0bc9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644790 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#80967}
-
- 31 May, 2022 1 commit
-
-
Maya Lekova authored
Bug: chromium:1329234 Change-Id: I59f171d3e2ab0c07f79f631971b1695b9f706600 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3677294Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/main@{#80850}
-
- 24 May, 2022 1 commit
-
-
Solomon Kinard authored
Change-Id: I924a2b4dc4ab5e7be22fd2a9a1084473ba65fc35 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3651039Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#80711}
-
- 23 May, 2022 1 commit
-
-
Joyee Cheung authored
Previously the LookupIterator ignores private symbols (including private names) for the access check. This patch removes these exceptions so that they are always checked. Drive-by: removes the unused should_throw parameter in Runtime::DefineObjectOwnProperty() Bug: chromium:1321899 Change-Id: I9677b1e377f01d966daa1603eee1ed9535ffab92 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3623419Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#80700}
-
- 20 May, 2022 1 commit
-
-
Jakob Kummerow authored
Fixed: chromium:1327321 Change-Id: I4868e0127b9dd14a0812cafca1681280534faa46 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652788Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/main@{#80661}
-
- 17 May, 2022 2 commits
-
-
Solomon Kinard authored
Change-Id: Ib5d2e24ee4a83547b9d403d5d8b5d75173b8310b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3648093Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Solomon Kinard <solomonkinard@chromium.org> Cr-Commit-Position: refs/heads/main@{#80597}
-
Manos Koukoutos authored
Loading from/storing to the same field with incompatible mutabilities is possible in unreachable code, specifically when a value is cast to two different types with incompatible mutability for the same field offset. Therefore, we allow this pattern in CsaLoadElimination. When we detect it, we emit an Unreachable node to immediately crash the program in case this unreachable code is somehow executed. Bug: v8:7748, v8:12874 Change-Id: Ieb359d3e1b9f7bc4a91c556af2bba0507526d20e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644806 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#80587}
-
- 16 May, 2022 2 commits
-
-
Solomon Kinard authored
Change-Id: Ib8ca0c771b50b712e5fd6acb470213235f69a99b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3650833Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Solomon Kinard <solomonkinard@chromium.org> Cr-Commit-Position: refs/heads/main@{#80569}
-
Jakob Kummerow authored
The LookupIterator only handles JSReceivers, so special-case oddballs. Change-Id: I03d2875124775390c9b928fb7cfe4d938213b5d0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3645409 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/main@{#80548}
-
- 12 May, 2022 2 commits
-
-
Jakob Kummerow authored
Fixed: v8:12866 Change-Id: Icba2ffc7837bf4942fd4bc741abeb7c98694c2d8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644607Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Andy Wingo <wingo@igalia.com> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/main@{#80500}
-
Jakob Kummerow authored
The IsValidSectionCode function shouldn't include internally-used numeric identifiers of well-known optional sections. Fixed: v8:12867 Change-Id: I9d894ee57157455e92a17ddcde94f32f05fb038d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644612 Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/main@{#80494}
-
- 03 May, 2022 1 commit
-
-
Camillo Bruni authored
To be consistent with the all the other tiers and avoid confusion, we rename --opt to ---turbofan, and --always-opt to --always-turbofan. Change-Id: Ie23dc8282b3fb4cf2fbf73b6c3d5264de5d09718 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610431Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#80336}
-
- 02 May, 2022 2 commits
-
-
Patrick Thier authored
https://crrev.com/c/3571817 introduced a bug that string table lookups failed on SlicedStrings with a start offset of 0. This CL fixes the issue by re-using the already computed hash only if the length of the source string matches the length of the string to lookup. Bug: chromium:1320179, chromium:1321573 Change-Id: Ic8755a0266a9ec67fe5eb9c96fdab1b55d5009f2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616723 Auto-Submit: Patrick Thier <pthier@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#80309}
-
Jakob Linke authored
This is a reland of commit 91453880 Fixed: properly reference the ClearedValue in CSA (i.e. without the cage_base upper 32 bits). Original change's description: > Reland "[osr] Use the new OSR cache" > > This is a reland of commit 91da3883 > > Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization > on arm64. > > Original change's description: > > [osr] Use the new OSR cache > > > > This CL switches over our OSR system to be based on the feedback > > vector osr caches. > > > > - OSRing to Sparkplug is fully separated from OSR urgency. If > > SP code exists, we simply jump to it, no need to maintain an > > installation request. > > - Each JumpLoop checks its dedicated FeedbackVector cache slot. > > If a valid target code object exists, we enter it *without* > > calling into runtime to fetch the code object. > > - Finally, OSR urgency still remains as the heuristic for > > requesting Turbofan OSR compile jobs. Note it no longer has a > > double purpose of being a generic untargeted installation > > request. > > > > With the new system in place, we can remove now-unnecessary > > hacks: > > > > - Early OSR tierup is replaced by the standard OSR system. Any > > present OSR code is automatically entered. > > - The synchronous OSR compilation fallback is removed. With > > precise installation (= per-JumpLoop-bytecode) we no longer > > have the problem of 'getting unlucky' with JumpLoop/cache entry > > mismatches. Execution has moved on while compiling? Simply spawn > > a new concurrent compile job. > > - Remove the synchronous (non-OSR) Turbofan compile request now > > that we always enter available OSR code as early as possible. > > - Tiering into Sparkplug no longer messes with OSR state. > > > > Bug: v8:12161 > > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167 > > Commit-Queue: Jakob Linke <jgruber@chromium.org> > > Auto-Submit: Jakob Linke <jgruber@chromium.org> > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Cr-Commit-Position: refs/heads/main@{#80147} > > Bug: v8:12161 > Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232 > Auto-Submit: Jakob Linke <jgruber@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/main@{#80167} Bug: v8:12161,chromium:1320189 Change-Id: Ibd9a2ab61f51ebb32a3f5a66f7c602faead71c3e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620273Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#80306}
-
- 29 Apr, 2022 1 commit
-
-
Rohan Pavone authored
This reverts commit 91453880. Reason for revert: Breaking the Fuchsia Deterministic Builder Original change's description: > Reland "[osr] Use the new OSR cache" > > This is a reland of commit 91da3883 > > Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization > on arm64. > > Original change's description: > > [osr] Use the new OSR cache > > > > This CL switches over our OSR system to be based on the feedback > > vector osr caches. > > > > - OSRing to Sparkplug is fully separated from OSR urgency. If > > SP code exists, we simply jump to it, no need to maintain an > > installation request. > > - Each JumpLoop checks its dedicated FeedbackVector cache slot. > > If a valid target code object exists, we enter it *without* > > calling into runtime to fetch the code object. > > - Finally, OSR urgency still remains as the heuristic for > > requesting Turbofan OSR compile jobs. Note it no longer has a > > double purpose of being a generic untargeted installation > > request. > > > > With the new system in place, we can remove now-unnecessary > > hacks: > > > > - Early OSR tierup is replaced by the standard OSR system. Any > > present OSR code is automatically entered. > > - The synchronous OSR compilation fallback is removed. With > > precise installation (= per-JumpLoop-bytecode) we no longer > > have the problem of 'getting unlucky' with JumpLoop/cache entry > > mismatches. Execution has moved on while compiling? Simply spawn > > a new concurrent compile job. > > - Remove the synchronous (non-OSR) Turbofan compile request now > > that we always enter available OSR code as early as possible. > > - Tiering into Sparkplug no longer messes with OSR state. > > > > Bug: v8:12161 > > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167 > > Commit-Queue: Jakob Linke <jgruber@chromium.org> > > Auto-Submit: Jakob Linke <jgruber@chromium.org> > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Cr-Commit-Position: refs/heads/main@{#80147} > > Bug: v8:12161 > Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232 > Auto-Submit: Jakob Linke <jgruber@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/main@{#80167} Bug: v8:12161 Change-Id: I73e2d98660e9edfbe07a152a14402380ea9227de Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3615219Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Owners-Override: Deepti Gandluri <gdeepti@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#80287}
-
- 27 Apr, 2022 1 commit
-
-
Jakob Gruber authored
This logic was confused in the presence of inlined frames; the deopt exit offset would point inside the innermost inlined frame while we incorrectly assumed it points at the outermost frame. Fix this by always referring to the bytecode offset of the outermost frame. Bug: v8:12161 Fixed: chromium:1320094 Change-Id: I2eb28498639432c5344859f64a9388d93ee23bde Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3608630 Auto-Submit: Jakob Linke <jgruber@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#80212}
-
- 26 Apr, 2022 2 commits
-
-
Jakob Kummerow authored
When passing anyref-typed things to Wasm, we cannot expect that all functions are WasmExternalFunctions. Instead of adding a relatively expensive type check to such calls, this patch disables function unwrapping for anyref-typed values. Fixed: v8:12789 Change-Id: Ied57187bac7fde0326634f7b4fc428ad21dc9c2f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605231 Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/main@{#80179}
-
Jakob Gruber authored
This is a reland of commit 91da3883 Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization on arm64. Original change's description: > [osr] Use the new OSR cache > > This CL switches over our OSR system to be based on the feedback > vector osr caches. > > - OSRing to Sparkplug is fully separated from OSR urgency. If > SP code exists, we simply jump to it, no need to maintain an > installation request. > - Each JumpLoop checks its dedicated FeedbackVector cache slot. > If a valid target code object exists, we enter it *without* > calling into runtime to fetch the code object. > - Finally, OSR urgency still remains as the heuristic for > requesting Turbofan OSR compile jobs. Note it no longer has a > double purpose of being a generic untargeted installation > request. > > With the new system in place, we can remove now-unnecessary > hacks: > > - Early OSR tierup is replaced by the standard OSR system. Any > present OSR code is automatically entered. > - The synchronous OSR compilation fallback is removed. With > precise installation (= per-JumpLoop-bytecode) we no longer > have the problem of 'getting unlucky' with JumpLoop/cache entry > mismatches. Execution has moved on while compiling? Simply spawn > a new concurrent compile job. > - Remove the synchronous (non-OSR) Turbofan compile request now > that we always enter available OSR code as early as possible. > - Tiering into Sparkplug no longer messes with OSR state. > > Bug: v8:12161 > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167 > Commit-Queue: Jakob Linke <jgruber@chromium.org> > Auto-Submit: Jakob Linke <jgruber@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/main@{#80147} Bug: v8:12161 Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232 Auto-Submit: Jakob Linke <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#80167}
-
- 25 Apr, 2022 2 commits
-
-
Nico Hartmann authored
This reverts commit 91da3883. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20arm64%20-%20sim%20-%20pointer%20compression%20-%20builder/21150/overview Original change's description: > [osr] Use the new OSR cache > > This CL switches over our OSR system to be based on the feedback > vector osr caches. > > - OSRing to Sparkplug is fully separated from OSR urgency. If > SP code exists, we simply jump to it, no need to maintain an > installation request. > - Each JumpLoop checks its dedicated FeedbackVector cache slot. > If a valid target code object exists, we enter it *without* > calling into runtime to fetch the code object. > - Finally, OSR urgency still remains as the heuristic for > requesting Turbofan OSR compile jobs. Note it no longer has a > double purpose of being a generic untargeted installation > request. > > With the new system in place, we can remove now-unnecessary > hacks: > > - Early OSR tierup is replaced by the standard OSR system. Any > present OSR code is automatically entered. > - The synchronous OSR compilation fallback is removed. With > precise installation (= per-JumpLoop-bytecode) we no longer > have the problem of 'getting unlucky' with JumpLoop/cache entry > mismatches. Execution has moved on while compiling? Simply spawn > a new concurrent compile job. > - Remove the synchronous (non-OSR) Turbofan compile request now > that we always enter available OSR code as early as possible. > - Tiering into Sparkplug no longer messes with OSR state. > > Bug: v8:12161 > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167 > Commit-Queue: Jakob Linke <jgruber@chromium.org> > Auto-Submit: Jakob Linke <jgruber@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/main@{#80147} Bug: v8:12161 Change-Id: I4a6955f4f20b6f3b13e98d5600c7c6a5205915bc No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605608 Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Owners-Override: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#80148}
-
Jakob Gruber authored
This CL switches over our OSR system to be based on the feedback vector osr caches. - OSRing to Sparkplug is fully separated from OSR urgency. If SP code exists, we simply jump to it, no need to maintain an installation request. - Each JumpLoop checks its dedicated FeedbackVector cache slot. If a valid target code object exists, we enter it *without* calling into runtime to fetch the code object. - Finally, OSR urgency still remains as the heuristic for requesting Turbofan OSR compile jobs. Note it no longer has a double purpose of being a generic untargeted installation request. With the new system in place, we can remove now-unnecessary hacks: - Early OSR tierup is replaced by the standard OSR system. Any present OSR code is automatically entered. - The synchronous OSR compilation fallback is removed. With precise installation (= per-JumpLoop-bytecode) we no longer have the problem of 'getting unlucky' with JumpLoop/cache entry mismatches. Execution has moved on while compiling? Simply spawn a new concurrent compile job. - Remove the synchronous (non-OSR) Turbofan compile request now that we always enter available OSR code as early as possible. - Tiering into Sparkplug no longer messes with OSR state. Bug: v8:12161 Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167 Commit-Queue: Jakob Linke <jgruber@chromium.org> Auto-Submit: Jakob Linke <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#80147}
-
- 20 Apr, 2022 1 commit
-
-
Clemens Backes authored
The fix is merged to all channels, add the regression test. R=thibaudm@chromium.org Bug: chromium:1314184 Change-Id: I7b7ca13ff34b19c3dbb727d248619dc1ff874873 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596161Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#80044}
-
- 12 Apr, 2022 1 commit
-
-
jameslahm authored
... in Runtime::kCopyDataPropertiesWithExcludedPropertiesOnStack. Bug: v8:11614 Change-Id: Ief6d62fff242d3d38c4e586c7252935d3527ddf1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3581534Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: 王澳 <wangao.james@bytedance.com> Cr-Commit-Position: refs/heads/main@{#79937}
-
- 11 Apr, 2022 1 commit
-
-
Clemens Backes authored
The roundss / vroundss instruction is only available on AVX or SSE4_1 hardware. Thus bring back the old code path with much longer code for such old hardware. R=tebbi@chromium.org Bug: chromium:1314363 Change-Id: I79a58627c8b406817330e9f9601234cea28182c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3578642Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#79914}
-
- 07 Apr, 2022 1 commit
-
-
Clemens Backes authored
Some test variants and fuzzers set their own GC interval, so the flag specified in the regression test causes flag contradictions. The test failure was flaky anyway, so this change is only a slight reduction in reproducability, and the test will still be used as seed for the fuzzers. R=machenbach@chromium.org Bug: chromium:1313475 Change-Id: I7c7084ab34fe46d691b841921d42a487cc8a1cad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3576114Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#79845}
-
- 06 Apr, 2022 3 commits
-
-
Shu-yu Guo authored
Bug: v8:12744 Change-Id: I3e356c16554e8bc19afc06b18f4afd7fed2f228e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563540 Commit-Queue: Shu-yu Guo <syg@chromium.org> Auto-Submit: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/main@{#79833}
-
Clemens Backes authored
A worker might be terminated while creating a new Realm. While this was handled mostly correctly already, a DCHECK was places slightly too early, which is fixed by this CL. Also, we avoid printing an error message if we fail to install an extension due to isolate termination. As this is externally triggered, it's not really an error condition. R=jkummerow@chromium.org Bug: chromium:1313475 Change-Id: I67b7fd27002d9b9a33439378d8336fefb2a2371a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571811Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#79825}
-
Jakob Gruber authored
This flag was a leftover from very early Turbofan days and serves no purpose. Non-OSR TF code automatically uses function context specialization (FCS) when appropriate without looking at the flag value. OSR TF code should never use FCS since it is cached by the SharedFunctionInfo (not by the JSFunction). Bug: v8:12161 Change-Id: Ifb5a10918dbdf34a7164f7e665a230698b793e9e Fixed: chromium:1313419 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571895 Auto-Submit: Jakob Linke <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79802}
-
- 04 Apr, 2022 3 commits
-
-
Jakob Gruber authored
This is a reland of commit 3ce690ee Changed for the reland: - Remove the currently-unused BytecodeArray member to avoid MSAN failures. - s/return/continue/ in optimizing-compile-dispatcher. Original change's description: > [osr] Basic support for concurrent OSR > > This CL adds basic support behind --concurrent-osr, > disabled by default. > > When enabled: > 1) the first OSR request starts a concurrent OSR compile job. > 2) on completion, the code object is inserted into the OSR cache. > 3) the next OSR request picks up the cached code (assuming the request > came from the same JumpLoop bytecode). > > We add a new osr optimization marker on the feedback vector to > track whether an OSR compile is currently in progress. > > One fundamental issue remains: step 3) above is not guaranteed to > hit the same JumpLoop, and a mismatch means the OSR'd code cannot > be installed. This will be addressed in a followup by targeting > specific bytecode offsets for the install request. > > This change is based on fanchen.kong@intel.com's earlier > change crrev.com/c/3369361, thank you! > > Bug: v8:12161 > Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Jakob Linke <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79685} Bug: v8:12161 Change-Id: I48b100e5980c909ec5e79d190aaea730c83e9386 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3565720Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Auto-Submit: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79746}
-
Nikolaos Papaspyrou authored
This CL removes two obsolete regression tests that were taking too long on debug engine builds. Bug: v8:12753 Bug: v8:12754 Change-Id: I818101725caa22fb4b2ed22381f01a2dd9436fe4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563563Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org> Cr-Commit-Position: refs/heads/main@{#79727}
-
jameslahm authored
In DisassembleFunction runtime, function may have available optimized code and we could directly set the optimized code for the function like in CompileLazy if it's not compiled, which avoids calling Compiler::Compile and failed in DCHECK(!function->HasAvailableOptimizedCode()). Bug: v8:12762 Change-Id: I00001fc598f3fc96dfe86b2367e8ba88f0085fd3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563448Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79722}
-
- 01 Apr, 2022 2 commits
-
-
Thibaud Michaud authored
The current safety margin between the JS stack limit and the actual boundary of the stack space reserved by the simulator can be overrun by a large frame. Raise this margin to 4KiB, corresponding to the "large frame" threshold. This ensures that the stack check is executed before the frame is allocated if the frame is larger than this margin. R=clemensb@chromium.org Bug: chromium:1308333 Change-Id: I3e1a51bb36c630c7e37e58679971392dada2a83e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560435Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/main@{#79711}
-
Adam Klein authored
This reverts commit 3ce690ee. Reason for revert: failures on CrOS MSan build: https://crbug.com/1312188 Original change's description: > [osr] Basic support for concurrent OSR > > This CL adds basic support behind --concurrent-osr, > disabled by default. > > When enabled: > 1) the first OSR request starts a concurrent OSR compile job. > 2) on completion, the code object is inserted into the OSR cache. > 3) the next OSR request picks up the cached code (assuming the request > came from the same JumpLoop bytecode). > > We add a new osr optimization marker on the feedback vector to > track whether an OSR compile is currently in progress. > > One fundamental issue remains: step 3) above is not guaranteed to > hit the same JumpLoop, and a mismatch means the OSR'd code cannot > be installed. This will be addressed in a followup by targeting > specific bytecode offsets for the install request. > > This change is based on fanchen.kong@intel.com's earlier > change crrev.com/c/3369361, thank you! > > Bug: v8:12161 > Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Jakob Linke <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79685} Bug: v8:12161, chromium:1312188 Change-Id: Iac1e3fd67ecc658a1cdee8f4d13354c097ed6697 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3564983 Auto-Submit: Adam Klein <adamk@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/main@{#79702}
-
- 31 Mar, 2022 1 commit
-
-
Jakob Gruber authored
This CL adds basic support behind --concurrent-osr, disabled by default. When enabled: 1) the first OSR request starts a concurrent OSR compile job. 2) on completion, the code object is inserted into the OSR cache. 3) the next OSR request picks up the cached code (assuming the request came from the same JumpLoop bytecode). We add a new osr optimization marker on the feedback vector to track whether an OSR compile is currently in progress. One fundamental issue remains: step 3) above is not guaranteed to hit the same JumpLoop, and a mismatch means the OSR'd code cannot be installed. This will be addressed in a followup by targeting specific bytecode offsets for the install request. This change is based on fanchen.kong@intel.com's earlier change crrev.com/c/3369361, thank you! Bug: v8:12161 Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79685}
-
- 29 Mar, 2022 1 commit
-
-
Marja Hölttä authored
Bug: v8:11111,chromium:1307310 Change-Id: I41175d759e71d2016880eae1cd42e420ee9cc229 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3540262Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/main@{#79646}
-
- 28 Mar, 2022 1 commit
-
-
jameslahm authored
According to https://tc39.es/ecma262/#sec-InnerModuleLinking step 10 and https://tc39.es/ecma262/#sec-source-text-module-record-initialize-environment step 8-25, variables must be declared in Link. And according to https://tc39.es/ecma262/#sec-module-namespace-exotic-objects-get-p-receiver, accessing the exported variable with the hole value should throw uninitialized error. Bug: v8:12729 Change-Id: I6fd2fcc580f7bafca986448b37adb8ba8f077929 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3552281Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79637}
-
- 24 Mar, 2022 2 commits
-
-
Nico Hartmann authored
Bug: chromium:1309769, v8:12619 Change-Id: I880c7326f2ec91f1aa985d6b7ed67f8f5afc074b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548897 Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/main@{#79608}
-
Joyee Cheung authored
- When the property being defined with DefineKeyedOwnIC or DefineNamedOwnIC already exists, we should use the slow path to check if the operation is allowed in case the property is non-configurable or Object.preventExtensions() has been called on the property. - Since KeyedStoreIC:Store() reuses StoreIC::Store() when the key is a name, we should use Runtime::DefineObjectOwnProperty() for DefineKeyedOwnIC too. - When dealing with public fields, Runtime::DefineObjectOwnProperty() should use JSReceiver::CreateDataProperty() instead of Object::SetProperty() for the specified semantics. This patch also adds JSReceiver::AddPrivateField() for it and StoreIC::Store to define private fields without triggering traps or checking extensibility. - To emit a more specific error message when redefining properties on non-extensible objects, Object::AddDataProperty() now also takes a EnforceDefineSemantics enum to distinguish between set and define. - Drive-by: fix JSReceiver::CheckIfCanDefine() which should check for extensibility even if the configurability check passes. Bug: chromium:1259950, v8:9888 Change-Id: Ib1bc851ffd4b9c3a0e98cac96dafe743c08ee37e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3517934Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#79603}
-