Closed Bug 1007927 Opened 8 years ago Closed 6 years ago
excessive time spent in sync blocking call js::Cancel
Off Thread Ion Compile on jslinux
STR: 1) During booting of http://bellard.org/jslinux/ Profile: http://people.mozilla.org/~bgirard/cleopatra/#report=0705c034076cf86361b20cedc3254d4552347a41 The page seems to be hitting a lot of bailout but the long blocking call to js::CancelOffThreadIonCompile are too expensive.
Maybe Kannan can triage this?
I took a brief look at this last week. CancelOffThreadCompile does some pretty heavy stuff: cancel any pending compiles, wait for in-progress compiles to finish up, and cancel any completed codegens. The first and last of those would probably be pretty lightweight. I'm guessing it's the middle one (wait for compiles to finish up) is taking the time. There are various points during compilation where we check for cancellation. If these are not happening often enough, then CancelOffThreadIonCompile will wait a long time for cancellation requests to be handled by the compiler and then retired. I suspect that simply adding more frequent cancellation checks may resolve the issue here. An alternative is to have the wait-for-compiles-to-cancel, and cancel-code-generation steps move into a background thread. However, this seems like a bit more pain since the cancel-code-generation steps runs |FinishOffThreadBuilder| for each cancelled codegen, which needs to run in the main thread. Referring to bhackett for more info before proceeding. Brian, what do you think?
Flags: needinfo?(kvijayan) → needinfo?(bhackett1024)
I think the only time the main thread should need to block while the off thread compilation is being canceled is for a GC. The compilation thread can look at contents of GC things (i.e. scripts) and if they are collected while it is running then that would be bad. But the normal case of canceling compilations should be when type information changes, and the main thread shouldn't have to block when that happens, it could just mark the builder as canceled and finish the aborted compilation after the compilation thread gets around to finishing up.
I just re-test on nightly. We're still ~50% slower than chrome.
I think the main issue I can see on the profile is: Why are we compiling "http://bellard.org/jslinux/cpux86-ta.js:9" so many times :0. I think fixing that might fix the slowdown.
Oh sigh, I just see that all code is on one line. So it could be that this isn't the same script getting recompiled the whole time. @BenWa: can we include the column number in the profiler like "script.js:row:col"?
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1304081
You need to log in before you can comment on or make changes to this bug.