[webkit-changes] [WebKit/WebKit] 870ce2: [JSC] Adjust CodeBlock::shouldOptimizeNow with ret...
Yusuke Suzuki
noreply at github.com
Tue Aug 8 09:11:15 PDT 2023
Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 870ce28bc85aaa3975f3015430086d014fb31c95
https://github.com/WebKit/WebKit/commit/870ce28bc85aaa3975f3015430086d014fb31c95
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-08-08 (Tue, 08 Aug 2023)
Changed paths:
M Source/JavaScriptCore/bytecode/CodeBlock.cpp
Log Message:
-----------
[JSC] Adjust CodeBlock::shouldOptimizeNow with retry count
https://bugs.webkit.org/show_bug.cgi?id=259918
rdar://113545008
Reviewed by Keith Miller.
In the wild, there are many functions which can be very generic. For example, jQuery's $ function can take various arguments,
and it has many code with `typeof`. When using some frameworks, their functions can be generic, but in many cases, only small
part of these functions can be used in one application.
CodeBlock::shouldOptimizeNow is currently using ValueProfile's liveness / fullness ratio to estimate the coverage of profiling
infomration to decide tiering up. This works well if the function can be fully used. However, as it is said before, if the function
is coming from frameworks, and if only small part of function is used in the application, then this coverage is kept low.
As a result, we always defer tiering up until we hit the maximumOptimizationDelay (5) retry count.
But repeatedly invoking CodeBlock::shouldOptimizeNow is already a good signal of very hot function. So we should leverage this
count in mind too in CodeBlock::shouldOptimizeNow. In this patch, we eventually decreases liveness / fullness threshold while increasing
the retry count. Now, the threshold becomes (livenessThreshold / retry-count), so, the threshold decreases if we invoke CodeBlock::shouldOptimizeNow
more and more (this means this function is really hot).
* Source/JavaScriptCore/bytecode/CodeBlock.cpp:
(JSC::CodeBlock::shouldOptimizeNow):
Canonical link: https://commits.webkit.org/266684@main
More information about the webkit-changes
mailing list