851450 - Consider disabling JM inlining everywhere, rm ExpandInlineFrames

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Jan de Mooij [:jandem]]

I just ran into an issue with baseline in the browser: we were using ScriptFrameIter a lot and its constructor calls mjit::ExpandInlineFrames for all compartments. The browser has more compartments of course, so this is slow.

We want to remove JM eventually, but if we could disable JM inlining right now and remove the call to ExpandInlineFrames it could be an easy win in some cases.

Currently JM inlines only if Ion is disabled and TI is enabled. We are going to enable Ion on b2g (bug 849103), so I don't know which platforms this would affect (maybe ARM v6?).

Comment 1

[Nicolas B. Pierron [:nbp]]

(In reply to Jan de Mooij [:jandem] from comment #0)
> We want to remove JM eventually, but if we could disable JM inlining right
> now and remove the call to ExpandInlineFrames it could be an easy win in
> some cases.

This sounds reasonable to me.

> Currently JM inlines only if Ion is disabled and TI is enabled. We are going
> to enable Ion on b2g (bug 849103), so I don't know which platforms this
> would affect (maybe ARM v6?).

Bug 836486 should bring IonMonkey support for ARMv6, and avoid regression caused by this patch.

With this patch on top of Bug 849103, we should be able to remove the Android no-ion case that we have on tbpl.

Comment 2

[David Anderson [:dvander] - inactive, e-mail if emergency]

Yeah, definitely, the inlining JM code will be dead after bug 849103. I don't think we need to block this on ARMv6 stuff. I don't think TI even runs on ARMv6 right now, so inlining is dead there too.

Comment 3

[Dave Garrett]

Is this bug now completely obsolete post JM removal?

Comment 4

[Till Schneidereit [:till]]

Yes, it is. Thanks.