[osr] Refactor TieringManager::MaybeOptimizeFrame
This started out as a minor code move of early-osr logic, but became a more general refactor of the tiering decisions. Early-OSR: the intent here is to trigger OSR as soon as possible when matching OSR'd code is cached. Move this out of ShouldOptimize (since it has side effects), and into a dedicated function that's called early in the decision process. Note that with this change, we no longer trigger normal TF optimization along with the OSR request - TF tiering heuristics are already complex enough, let's not add yet another special case right now. Other refactors: - Clarify terminology around OSR. None of the functions in TM actually perform OSR; instead, they only increase the OSR urgency, effectively increasing the set of loops that will trigger OSR compilation. - Clarify the control flow through the tiering decisions. Notably, we only increment OSR urgency when normal tierup has previously been requested. Also, there is a bytecode size limit involved. These conditions were previously hidden inside other functions. Bug: v8:12161 Change-Id: I8f58b4332bd9851c6b299655ce840555fb7efa92 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3529448Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79512}
Showing
Please
register
or
sign in
to comment