For debugging purposes, sometimes, we want to be able to make compilation happen sooner to see if we can accelerate the manifestation of certain events / bugs. Currently, in order to achieve this, we'll have to tweak multiple JIT thresholds which make up the compilation policy. Let's add a single knob that can tune all the thresholds up / down proportionately so that we easily can tweak how soon compilation occurs.
Created attachment 250096 [details] the patch.
Comment on attachment 250096 [details] the patch. I don't like this and find it not too helpful. To come up with a scale, I need to calculate the ration to match the value I want to change. Right now, I use the values that run-jsc-stress-test sets. In fact I typically copy them from the output of a failing tests. The ratio of the various values set in run-jsc-stress-tests wouldn't work with the same ratio. For example, thresholdForJITAfterWarmUp is 500 and thresholdForJITSoon is 100 by default. The "eager" tests set these both to 10, which is a different ratio for each of these parameters.
(In reply to comment #2) > Comment on attachment 250096 [details] > the patch. > > I don't like this and find it not too helpful. To come up with a scale, I > need to calculate the ration to match the value I want to change. Right > now, I use the values that run-jsc-stress-test sets. In fact I typically > copy them from the output of a failing tests. The ratio of the various > values set in run-jsc-stress-tests wouldn't work with the same ratio. For > example, thresholdForJITAfterWarmUp is 500 and thresholdForJITSoon is 100 by > default. The "eager" tests set these both to 10, which is a different ratio > for each of these parameters. To each his own. In my case, I'm looking to reproduce issues that occur naturally in the wild, but are normally rare. As such, I would want the policy to reflect the ratios that are used in real world usage, except that I want it accelerated. This knob gives me a convenient way to tweak that acceleration and re-test my repro case. The alternative approach you prescribed has 3 disadvantages for my use case: 1. Those jsc stress threshold values don't reflect the ratios that trigger compilation in the real world. Hence, it can change the order in which functions are compiled, and is therefore, not necessarily better for reproduction of real world bugs. Granted, scaling down the thresholds proportionately is not exactly perfect either (especially) when it reaches the very small value, but it is better at preserving the natural order of compilations. 2. It's a hassle to have to get a fresh run of the jsc stress tests and then hunt down specific tests to copy their policy values out of the generated scripts. 3. It is also a hassle to have to set and tweak multiple option variables instead of one, especially when I do want to preserve the threshold ratios used in the real world.
Comment on attachment 250096 [details] the patch. r=me
Thanks. Landed in r182337: <http://trac.webkit.org/r182337>.