Closed Bug 1860309 Opened 2 years ago Closed 9 months ago

Almost continuous bailouts and Invalidations on https://bundlejs.com in part of the js-heavy profile

Categories

(Core :: JavaScript Engine, task, P3)

task

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mayankleoboy1, Unassigned)

References

(Blocks 1 open bug)

Details

First the profile : https://share.firefox.dev/3tHInNb (focus on the Dom Worker thread17592)
Tons of Bailouts and invalidations wherever you see JS in that thread. You can look at the ~2.2 second chunk right at the beginning. For this chunk of time, the profiler also suggests that 30% (40% of 70%) time is spent in Baseline.

STR: Go to https://bundlejs.com
Put this in the input box :
// Click Build for the Bundled, Minified & Compressed package size
export * from "d3@7.8.5";
export * from "d3-milestones@1.4.7";
export * from "@cbinsights/react-d3-graph@1.3.0";
export * from "d3-org-chart@3.1.1";
export * from "d3-org-chart-jc@2.6.16";

Click on Build button.
Wait and wait. The js-heavy bit comes only at the end

I guess this is how "real-world" js code behaves, so feel free to resolve as invalid.

Summary: Almost continuous bailouts on On https://bundlejs.com in part of the js-heavy profile → Almost continuous bailouts and Invalidations on https://bundlejs.com in part of the js-heavy profile
Severity: -- → N/A
Priority: -- → P3

This is what you get today : https://share.firefox.dev/401Xkpx (Focus area: https://share.firefox.dev/4h3puY6)
The time spent in regalloc may also be interesting (although the time spent is only ~200ms)

Perhaps the Bailouts in monomorphic inlining are useful: https://share.firefox.dev/40kp8H5

not all bailouts are bad.

Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → WORKSFORME

Let's leave this one open, actually. I occasionally look at the profile here and think "that's too many bailouts", but I've never managed to figure out why.

Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Okay, finally took a look at this.

I built a version of the browser with the bailout loop detection code enabled, and it didn't trigger here. So it doesn't look like we've got a bailout loop.

Running with IONFLAGS=bl-bails and counting how often we bail in each individual function, nothing looks too bad. The worst function bails out 209 times across four bailout kinds:

      1 https://bundlejs.com/js/typescript.worker.js:327:191416 UnboxFolding
     20 https://bundlejs.com/js/typescript.worker.js:327:191416 MonomorphicInlinedStubFolding
     59 https://bundlejs.com/js/typescript.worker.js:327:191416 FirstExecution
    129 https://bundlejs.com/js/typescript.worker.js:327:191416 TranspiledCacheIR

But it's also just a really big function. It looks like we invalidate six times because we've encountered new paths through this function, and another 12-13 times because a guard started failing. (Oddly, though, I only see two invalidate markers for this code. Not sure what's up with that.)

In general, it seems like this might just be a pile of very bailout-prone code. I don't see any clear signs of anything pathological in the engine.

Re-resolving this.

Status: REOPENED → RESOLVED
Closed: 9 months ago9 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.