-
Notifications
You must be signed in to change notification settings - Fork 46
interpret method gets compiled twice by ION #1832
Comments
(We're marking with the "intex" label the things that block us from landing the intex branch, with "intex-followup" things that we need to do but that don't block us from landing it) |
This is a fascinating problem. SpiderMonkey, after executing the J2ME interpreter loop decides to compile it with Baseline and then ION. Unfortunately, the type information recorded by SpiderMonkey when it first compiles the interpreter loop is not complete since it is likely that parts of the interpreter loop were never executed (for example the code dealing with OSR or bailouts). When those parts of the code are executed, we end up bailing out of ION and back to baseline, then back into ION for another compilation, and so on. If we are really unlucky, SpiderMonkey might give up on ION all together and we never execute in optimized code. The only way to stay in ION from the very beginning is to probably warm up the interpreter loop evenly, before it get compiled by ION. Another thing that might help is it factor out infrequently used parts of the interpreter loop into functions. I pulled a histogram of the startup sequence, showing the top 80% of executed bytecodes.
|
#1843 is an effort to reduce the size of the interpreter loop. |
We should figure out why this is, and make sure it is never compiled more than once. The method is very large and probably takes a while to compile.
The text was updated successfully, but these errors were encountered: