1811363 - Lots of bailouts during React-Stockcharts

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine: JIT, defect, P3)

Description

[Denis Palmeiro [:denispal]]

Profile: https://share.firefox.dev/3D1fMEc

Seems to be mostly these ones:
Bailout - InstructionReordering at JumpTarget on line 2 of https://grandprixbench.netlify.app/resources/benchmarks/react-stockcharts/build/static/js/2.035b79cd.chunk.js:2
Bailout - TranspiledCacheIR at GetGName on line 2 of https://grandprixbench.netlify.app/resources/benchmarks/react-stockcharts/build/static/js/2.035b79cd.chunk.js:2
Bailout - TranspiledCacheIR at GetAliasedVar on line 2 of https://grandprixbench.netlify.app/resources/benchmarks/react-stockcharts/build/static/js/2.035b79cd.chunk.js:2

Perhaps this explains why we spend so much time in the Interpreter and are roughly 2x behind Chrome on this benchmark.

Comment 1

[Jan de Mooij [:jandem]]

The profile doesn't look too unusual to me. We allow a small number of bailouts before we invalidate/recompile, so seeing some similar ones in a row is expected. For the interpreter time, I see this in the side bar for the whole profile:

Baseline: 98 samples
Ion: 79 samples
Baseline Interpreter: 26 samples
C++ Interpreter: 11 samples

These numbers suggest we don't have a lot of very hot code here, so the interpreter numbers are reasonable.

I'll take a closer look at this test today.

Comment 2

[Denis Palmeiro [:denispal]]

(In reply to Jan de Mooij [:jandem] from comment #1)

These numbers suggest we don't have a lot of very hot code here, so the interpreter numbers are reasonable.

ah, perhaps you're right. I was fixated on the perf profile for this https://share.firefox.dev/3Wv0qP4 where we seem to spend a lot of time in blinterp and interpreter, but it's harder to accumulate the total Ion time there. There seemed to be a lot more bailouts here than other tests but if you think the bailouts are nothing to worry about, feel free to close the bug.

Comment 3

[Jan de Mooij [:jandem]]

I took a new profile of React-Stockcharts on Nightly and filtered the Marker Table on "bailout". There's a fair number of bailouts, but I don't see anything unusual. It's executing a lot of JS code and this triggers a number of (mostly) FirstExecution and TranspiledCacheIR bailouts.

We'll often have the same bailout repeated up to 10 times. This is due to JitOptions.frequentBailoutThreshold (= 10) and InvalidateIfFrequent.