1007927 - excessive time spent in sync blocking call js::CancelOffThreadIonCompile on jslinux

Status: RESOLVED DUPLICATE of bug 1304081

(Core :: JavaScript Engine: JIT, defect)

Description

[Benoit Girard (:BenWa)]

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.

Comment 1

[Benoit Girard (:BenWa)]

Maybe Kannan can triage this?

Comment 2

[Kannan Vijayan [:djvj]]

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?

Comment 3

[Brian Hackett [Laid off!]]

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.

Comment 4

[Benoit Girard (:BenWa)]

I just re-test on nightly. We're still ~50% slower than chrome.

Comment 5

[Hannes Verschore [:h4writer]]

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.

Comment 6

[Hannes Verschore [:h4writer]]

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"?