- 09 May, 2022 1 commit
-
-
Jakob Linke authored
New trace events: - finished OSR compilation. - entry into OSR code. Since the latter now happens without a trip into runtime, tracing is a bit more involved - we need to check FLAG_trace_osr in generated code, and call a runtime function if it is set. Drive-by: Slightly reorganize other OSR tracing. Bug: v8:12161 Change-Id: I3096424ca7d47a19802281a0e0a39f7f3394c12b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3629331 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Auto-Submit: Jakob Linke <jgruber@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#80420}
-
- 02 May, 2022 1 commit
-
-
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 Gruber authored
.. when deoptimization occurs after the outermost loop containing the loop that triggered OSR compilation. The reasoning is that the main benefit of OSR'd code is speeding up the OSR'd loop; the speedup of the OSR'd loop is assumed to be higher than deoptimization overhead. This is a slightly modified version of crrev.com/c/3521361, credit goes to tao.pan@intel.com for most of the investigation and implementation work. Bug: v8:12161 Change-Id: Ie729dd5d1df9c7f529a1cf1b9471bb60ce76c41a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607988Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#80177}
-
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}
-
- 11 Apr, 2022 1 commit
-
-
Jakob Gruber authored
This particular branch in CompileOptimizedOSR relies on a precise invocation count at counts 0 and 1. The invocation count is unreliable not only in the previously described situation (--always-opt), but also e.g. when forcing optimization on the first execution through other means like %OptimizeFunctionOnNextCall. Let's simply rewrite the condition to explicitly exclude kIsInProgress. Fixed: chromium:1314536 Change-Id: I27432f689c866bad3b407df7bbf276ec32c25c0d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3578644Reviewed-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@{#79913}
-
- 06 Apr, 2022 1 commit
-
-
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 4 commits
-
-
Jakob Gruber authored
.. to simplify logic within compiler.cc. GetOrCompileOptimized now only returns Code object if the requested optimized Code object is available. This change also required updating CompileLazy to install the appropriate Code object before potentially calling CompileOptimized_* runtime functions in order to satisfy the is_compiled precondition. Bug: v8:12161 Change-Id: I991dbcc0ba8f3d635aa1e1f06e4cffd89e08a47b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3562978Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79762}
-
Jakob Gruber authored
If we've already cached OSR'd code for the current function but with a different osr offset, fall back to synchronous compilation. This avoids degenerate cases where we repeatedly spawn OSR jobs but then fail to install them. Drive-by: More consistent --trace-osr output. Drive-by: Rename kCompileForOnStackReplacement to kCompileOptimizeOSR for name consistency. Drive-by: Add JSFunction::DebugNameCStr() for more convenient PrintF's. Bug: v8:12161 Change-Id: I2b4a65bc9e082d85d7048a3e92ef86b07d396687 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560431Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79761}
-
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}
-
Jakob Gruber authored
.. since they are the same as eager deopts (% an unused counter). Fixed: v8:12765 Change-Id: I2be6210e476ead4ac6629a49259f28321e965867 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3565717Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79729}
-
- 01 Apr, 2022 1 commit
-
-
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}
-
- 30 Mar, 2022 1 commit
-
-
Jakob Gruber authored
.. with readability and simplicity in mind. - Rename OptimizationMarker to the (shorter) TieringState. 'Tiering' also matches 'TieringManager' terminology. - Rename the values: kNone -> kNone kInOptimizationQueue -> kInProgress kCompileFoo_NotConcurrent -> kRequestFoo_Synchronous kCompileFoo_Concurrent -> kRequestFoo_Concurrent - Likewise rename ConcurrencyMode::kNotConcurrent to kSynchronous. - Add predicates to test enum values. - Consistent lower case names for accessors on JSFunction and FeedbackVector. - Instead of having to call HasOptimizationMarker() before using any other accessor, simply have optimization_marker() return kNone if no feedback vector exists. - Drive-by: Enable the Unreachable() in MaybeOptimizeCode() unconditionally - this should never happen, there's no reason not to protect against this in release builds as well. Bug: v8:12161 Change-Id: I67c03e2b7bd0a6b86d0c64f504ad8cb47e9e26ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3555774Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-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@{#79669}
-
- 24 Mar, 2022 1 commit
-
-
Leszek Swirski authored
Rather than emitting eager deopt code inline, use the full DeoptimizationData+TranslationArray mechanism in maglev, for consistency with TurboFan and simplification of implementing lazy deopts in the future. Bug: v8:7700 Change-Id: I67282b27493772c78ad28feaa4ad6a2c35c8e239 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3545169Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79600}
-
- 17 Mar, 2022 1 commit
-
-
Jakob Gruber authored
- Restructure the runtime function implementation. - Rename osr_loop_nesting_level to osr_urgency and add helpers. The motivation for the latter: I've always struggled with the `osr_loop_nesting_level` term; it neither matches terminology of what it's compared against (= the loop depth), nor implies what it's used for (= osr is triggered when `loop depth < osr nesting level`). In this CL it's renamed to `osr_urgency` to reflect that as urgency rises, we consider more and more loops as OSR candidates. Bug: v8:12161 Change-Id: I194ec5a3f1f02526641af1c7796ee0956b6fd3a1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3528735Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79509}
-
- 10 Mar, 2022 1 commit
-
-
Jakob Gruber authored
This reverts commit 190b5d95. Reason for revert: We should understand & fix regressions, see crbug.com/1304870#c9. Original change's description: > [compiler] Don't remove OSR code cache if deoptimizing at out of loop > > The main purpose of OSR compilation is fasten inner loop execution, the > OSR code cache is still correct for loop if optimizing at out of loop, > keep OSR code cache can reduce unnecessary slow bytecode execution with > feedback collection and avoid re-OSR compilation. > This CL can improve JetStream2 case navier-stokes by ~6%. > > Change-Id: I9518317fb922071b131cab5b56998a0fc198804a > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3494981 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Tao Pan <tao.pan@intel.com> > Cr-Commit-Position: refs/heads/main@{#79413} Bug: chromium:1304870 Change-Id: I8791edc34b66ef9dd0b477d3e340e85b0617ef59 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3515732 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79435}
-
- 09 Mar, 2022 2 commits
-
-
Camillo Bruni authored
Replace all CONVERT_XXX_ARG_XXX() macros from runtime-util.h with direct calls to Arguments or the fully expanded equivalent. - This replaces many of the hard CHECKs with DCHECK (as is common practice in most V8 code) - Instead of relying on verbose comments we now have readable code - Rename Arguments.::xxx_at with Arguments::xxx_value_at since these methods don't return the Object but rather their double/int value - Add Oddball::ToBool helper - Add and use v8::internal::PropertyAttributesFromInt helper - Add stronger DCHECK for PropertyAttributes returned in GetPropertyAttributesWithInterceptorInternal Bug: v8:11263 Change-Id: I8d531857e05d19f3198753b05af28d993a391854 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497768Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#79418}
-
Pan, Tao authored
The main purpose of OSR compilation is fasten inner loop execution, the OSR code cache is still correct for loop if optimizing at out of loop, keep OSR code cache can reduce unnecessary slow bytecode execution with feedback collection and avoid re-OSR compilation. This CL can improve JetStream2 case navier-stokes by ~6%. Change-Id: I9518317fb922071b131cab5b56998a0fc198804a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3494981Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tao Pan <tao.pan@intel.com> Cr-Commit-Position: refs/heads/main@{#79413}
-
- 01 Mar, 2022 1 commit
-
-
Jakob Gruber authored
- Add the Isolate as an explicit param (we already have it at all callsites) - Pass an explicit CodeKind param to MarkForOptimization in preparation for Maglev. - Split EnsureFeedbackVector into that, plus CreateAndAttachFeedbackVector for when we know it has to be created. Bug: v8:7700 Change-Id: Ie9022deccd31d472d6df3d442b25583af5569ab0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497383 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79318}
-
- 24 Feb, 2022 1 commit
-
-
Leszek Swirski authored
Maglev is mid-tier optimising compiler designed mainly for compilation speed that can still generate good code for straightforward JS. This initial commit is an MVP for Maglev which can compile and run some very simple code, and sets up a framework that we can build upon. Design: https://docs.google.com/document/d/13CwgSL4yawxuYg3iNlM-4ZPCB8RgJya6b8H_E2F-Aek/edit# Bug: v8:7700 Change-Id: I5ae074ae099126c2c0d50864ac9b3d6fa5c9e85a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3483664Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79247}
-
- 21 Feb, 2022 2 commits
-
-
Leszek Swirski authored
This reverts commit 9f902b74. Reason for revert: Reverting due to various fuzzing issues (numfuzz issues listed in original CL comments, ochang fuzzer in https://bugs.chromium.org/p/chromium/issues/detail?id=1299418) Original change's description: > [turbofan] Making OSR concurrent > > ... to reduce compilation overhead on the main thread for OSR > > Bug: v8:12161 > Change-Id: I54ca5fa6201405daf92dac9cf51d5de4b46577b3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3369361 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> > Cr-Commit-Position: refs/heads/main@{#79188} Bug: v8:12161 Change-Id: Id6f6086517cd77fb1aa60b20fd03528b8e2ca686 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3477104 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Owners-Override: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79194}
-
Fanchen Kong authored
... to reduce compilation overhead on the main thread for OSR Bug: v8:12161 Change-Id: I54ca5fa6201405daf92dac9cf51d5de4b46577b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3369361Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> Cr-Commit-Position: refs/heads/main@{#79188}
-
- 15 Feb, 2022 2 commits
-
-
Jakob Gruber authored
This was mostly unused. We should simply be able to use CodeKind plus related predicates instead. Replace FeedbackVector::optimization_tier with maybe_has_optimized_code, which states whether the optimized code cache is filled. The value is updated lazily and may lag behind the actual code cache state. We only use this field for quick cache-empty? checks from generated code. Bug: v8:7700,v8:12552 Change-Id: Ibfc5c0128eac56167a68ecba5690eab2e9369640 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3460741Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79107}
-
Jakob Gruber authored
.. in preparation for integrating addtl tiers into a single tiering system. 1. Explicitly spell out whether the request is concurrent or not. 2. Explicitly request the target compiler. Bug: v8:7700 Change-Id: I9d6e9f6a5d5f0f7218fe136ff50cea2ad7987f67 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3460739 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79092}
-
- 27 Jan, 2022 1 commit
-
-
Jakob Gruber authored
The functionality is unused and we are simplifying OptimizationMarker usage. Drive-by: Remove unused return value of Compiler::CompileOptimized. Drive-by: Don't add kStackSpaceRequiredForCompilation as gap to the stack check when compiling concurrently, i.e. on another thread. Bug: chromium:757467 Change-Id: Ibbe204b82bf937b9eb74f9eb2c3fd2d719d53ef9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3416245Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#78800}
-
- 20 Jan, 2022 1 commit
-
-
Jakob Gruber authored
Bug: v8:12552 Change-Id: I99e4d8e8aeba5460f11e54cc1b2bcaea98a5276d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3400964Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#78698}
-
- 16 Dec, 2021 2 commits
-
-
Igor Sheludko authored
This CL * removes Builtins::codet() and Builtins::codet_handle() returning builtins as CodeT objects in favor of code() and code_handle(), * removes BUILTIN_CODET macro in favor of BUILTIN_CODE, * removes CodeDataContainer table. Bug: v8:11880 Change-Id: Ic868549030744b0ff3ea5d5edbfcacf77c6de96d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3344650Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78399}
-
Igor Sheludko authored
... in order to avoid Code <-> CodeT conversions in builtins. This CL changes the meaning of RelocInfo::CODE_TARGET which now expects CodeT objects as a code target. In order to reduce code churn this CL makes BUILTIN_CODE and friends return CodeT instead of Code. In the follow-up CLs BUILTIN_CODET and friends will be removed. Bug: v8:11880 Change-Id: Ib8f60973e55c60fc62ba84707471da388f8201b4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3338483Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78393}
-
- 14 Dec, 2021 1 commit
-
-
Igor Sheludko authored
This CL migrates JSFunction's code accessors to CodeT. Bug: v8:11880 Change-Id: I8cf367eb79cc1d59548dd4f3e18c010f76f101cb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3330466Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78365}
-
- 08 Nov, 2021 3 commits
-
-
Ng Zhi An authored
Bug: v8:12244,v8:12245 Change-Id: I4bc0378a7d4ad3033485f98e446daa7ff2e83e0a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3264646Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/main@{#77769}
-
Igor Sheludko authored
This CL * adds forwarding accessors to CodeDataContainer for certain widely used Code object's fields and predicates, * adds JSFunction::set_code() overloads accepting CodeT values, * migrates SharedFunctionInfo getters to CodeT, * migrates InterpreterData::interpreter_trampoline to CodeT. Drive-by-fix: replace #if V8_EXTERNAL_CODE_SPACE with #ifdef to be consistent. Bug: v8:11880 Change-Id: I1e114076a0568068038ca6f70a86431a3a9cfb9f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3262716 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/main@{#77762}
-
Igor Sheludko authored
Bug: v8:11880 Change-Id: I53166b226c29a9244b047431e0830de109975306 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3262128Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#77760}
-
- 06 Sep, 2021 1 commit
-
-
Leszek Swirski authored
Remove the BaselineData intermediate structure for baseline code, and write the baseline Code object into the SharedFunctionInfo directly. We still need a pointer to the BytecodeArray/InterpreterData, so re-use the Code object's deoptimization data slot for this (baseline code doesn't have deoptimization data). A consequence of this is that the BytecodeArray pointer becomes immutable when there is baseline code. This means that we cannot install a debug BytecodeArray while baseline code is active (we have to flush it first), and we can't tier-up code with debug BytecodeArray to baseline. Change-Id: I53b93ec4d4c64b833603d7992f246982fcd97596 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3118548 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#76675}
-
- 23 Jun, 2021 1 commit
-
-
Leszek Swirski authored
This is a reland of 3296de2f It includes pthier@'s fix of overzealous OSR Original change's description: > [sparkplug] Trigger compilation when a FBV exists > > We were gating baseline compilation on FBV allocation, but in some > cases, the feedback vector may be allocated eagerly (notably, if we are > logging function events). Instead, unconditionally try baseline > compilation after ensuring the feedback vector exists. > > Bug: v8:11420 > Change-Id: I1264a1d541a74d4eccb5caf65c360ac23836a1a8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953161 > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Patrick Thier <pthier@chromium.org> > Reviewed-by: Patrick Thier <pthier@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75242} Bug: v8:11420 Change-Id: Ia6864856926d6760bbe6c89ee010fa62cf23b6ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2976660 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#75319}
-
- 22 Jun, 2021 1 commit
-
-
Maya Lekova authored
This reverts commit 3296de2f. Reason for revert: Blocks the roll - https://chromium-review.googlesource.com/c/chromium/src/+/2970676 Original change's description: > [sparkplug] Trigger compilation when a FBV exists > > We were gating baseline compilation on FBV allocation, but in some > cases, the feedback vector may be allocated eagerly (notably, if we are > logging function events). Instead, unconditionally try baseline > compilation after ensuring the feedback vector exists. > > Bug: v8:11420 > Change-Id: I1264a1d541a74d4eccb5caf65c360ac23836a1a8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953161 > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Patrick Thier <pthier@chromium.org> > Reviewed-by: Patrick Thier <pthier@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75242} Bug: v8:11420 Change-Id: Ia9524e3a57eda7ec069f29652acc7593bf680509 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2976654 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#75287}
-
- 18 Jun, 2021 1 commit
-
-
Leszek Swirski authored
We were gating baseline compilation on FBV allocation, but in some cases, the feedback vector may be allocated eagerly (notably, if we are logging function events). Instead, unconditionally try baseline compilation after ensuring the feedback vector exists. Bug: v8:11420 Change-Id: I1264a1d541a74d4eccb5caf65c360ac23836a1a8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953161 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#75242}
-