Bug 182886 – Disable JITs on 32-bit platforms by default.

• Status: RESOLVED
• Resolution: WONTFIX
• Component: New Bugs

[Keith Miller]

Disable JITs on 32-bit platforms by default.

[Keith Miller]

Created attachment 334067 [details]
Patch

[Don Olmstead]

I believe you’ll need to dig into the CMake options as well and disable it whenever a 32-bit CPU is detected.

[Keith Miller]

Created attachment 334124 [details]
TestGTKAndWPEJIT

[Keith Miller]

Created attachment 334125 [details]
Test32bitOff

[Keith Miller]

Created attachment 334126 [details]
Patch

[Guillaume Emont]

Some 32-bit platforms seem to be immune to Spectre and Meltdown [1,2]. I think it would be more appropriate to disable JIT at run time if the CPU is not in a whitelist of known immune processors, as there is no reason to disable JIT and kill performances for these.

[1] https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/
[2] https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/

[Keith Miller]

Created attachment 334164 [details]
Patch

[Keith Miller]

Created attachment 334166 [details]
Patch

[Keith Miller]

(In reply to Guillaume Emont from comment #6)
> Some 32-bit platforms seem to be immune to Spectre and Meltdown [1,2]. I
> think it would be more appropriate to disable JIT at run time if the CPU is
> not in a whitelist of known immune processors, as there is no reason to
> disable JIT and kill performances for these.
> 
> [1]
> https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-
> or-meltdown/
> [2]
> https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-
> channel-vulnerabilities/

Do we have any numbers from those platforms to argue that enabling the JIT is profitable? I don't believe anyone runs 32-bit performance tests anymore.

Regardless, AFAIK, we don't have any automated testing for those platforms. Without regular testing there are probably going to a number of bugs... Finally, there's the question of who's going to maintain those platforms. Is there anyone who has volunteered to maintain the 32-bit JITs?

[Keith Miller]

I don't really understand what's going on with the GTK/WPE builders. It says the a bunch of WebKit/WebCore files failed to build but there's no error message?

[Guillaume Emont]

Comment on attachment 334166 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=334166&action=review

> Source/WTF/ChangeLog:12
> +        1) 32-bit JITs are no longer actively mantained for performancex
> +        and it's not even clear what the performance characteristics of
> +        the 32-bit JITs are anymore.

It is true that we don't have a performance regression testing infrastructure for 32-bit platforms. That does not mean that JIT is useless on 32-bit platforms. I did some benchmarking of a real use application on a MIPS device a few months ago, and we achieved 24 frames per second with JIT and DFG enabled, versus 6 frames per second without JIT (rendering WebKit unusable for that use case). So, it seems like information was missing on that subject, I am providing it here: the JIT is *very* valuable on 32-bit platforms.

> Source/WTF/ChangeLog:15
> +        2) No WebKit contributor has proposed any complete mitigations for
> +        32-bit JITs.

Sorry we are late on that, but we definitely want to provide that, as I explained in https://lists.webkit.org/pipermail/webkit-dev/2018-February/029871.html .

> Source/WTF/ChangeLog:18
> +        3) Keeping the the 32-bit JITs substantially impedes delevelopment
> +        of mitigations for the 64-bit JITs.

Can you explain this further, or point to somewhere where that is explained?

[Guillaume Emont]

(In reply to Keith Miller from comment #9)
> (In reply to Guillaume Emont from comment #6)
> > Some 32-bit platforms seem to be immune to Spectre and Meltdown [1,2]. I
> > think it would be more appropriate to disable JIT at run time if the CPU is
> > not in a whitelist of known immune processors, as there is no reason to
> > disable JIT and kill performances for these.
> > 
> > [1]
> > https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-
> > or-meltdown/
> > [2]
> > https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-
> > channel-vulnerabilities/
> 
> Do we have any numbers from those platforms to argue that enabling the JIT
> is profitable? I don't believe anyone runs 32-bit performance tests anymore.
As I replied somewhere else, in real use-cases, this makes the difference between "WebKit is a relevant solution" to "WebKit is unusable".

> 
> Regardless, AFAIK, we don't have any automated testing for those platforms.
> Without regular testing there are probably going to a number of bugs...
> Finally, there's the question of who's going to maintain those platforms. Is
> there anyone who has volunteered to maintain the 32-bit JITs?

We do have a green buildbot for MIPS:
https://build.webkit.org/builders/JSCOnly%20Linux%20MIPS32el%20Release
We are working on having the same thing for armv7.

We at Igalia volunteer to maintain armv7 and mips, and I believe some of my colleagues made it explicit in some offline discussions in the last WebKit contributor meeting.

[Guillaume Emont]

(In reply to Guillaume Emont from comment #12)
> We are working on having the same thing for armv7.

I forgot to add the link:
https://build.webkit.org/builders/JSCOnly%20Linux%20ARMv7%20Thumb2%20Release
We are working on the last 10 test failures.

JIT must be turned off by default for X86. If I compile with -DENABLE_JIT=ON (which is the default so it is not even needed to provide this parameter) then WebKit is crashing on Athlon XP, probably on everything else (X86). Maybe it could run on a Pentium 4 because maybe SSE2 is causing the crash, but I couldn't obtain any crashlogs, it just cannot load most of the websites which have JavaScript. Actually there is no visible crash, just nothing happens and the whole page stays white.

For MIPS or armv7 it might work, but for X86 please disable it, otherwise WebKit is unusable on 32bit X86 machines. So it is not even a question of performance anymore. This is a blocker bug.

When JIT is turned off with the LFENCE fix (see below), WebKit works again on my Athlon XP machine:
https://bugs.webkit.org/show_bug.cgi?id=188145

So please, disable JIT at least for X86, because otherwise WebKit is completely unusable on most of the webpages.

[Guillaume Emont]

(In reply to karogyoker2+webkit from comment #14)
> JIT must be turned off by default for X86. If I compile with -DENABLE_JIT=ON
> (which is the default so it is not even needed to provide this parameter)
> then WebKit is crashing on Athlon XP, probably on everything else (X86).
> Maybe it could run on a Pentium 4 because maybe SSE2 is causing the crash,
> but I couldn't obtain any crashlogs, it just cannot load most of the
> websites which have JavaScript. Actually there is no visible crash, just
> nothing happens and the whole page stays white.
> 
> For MIPS or armv7 it might work, but for X86 please disable it, otherwise
> WebKit is unusable on 32bit X86 machines. So it is not even a question of
> performance anymore. This is a blocker bug.
> 
> When JIT is turned off with the LFENCE fix (see below), WebKit works again
> on my Athlon XP machine:
> https://bugs.webkit.org/show_bug.cgi?id=188145
> 
> So please, disable JIT at least for X86, because otherwise WebKit is
> completely unusable on most of the webpages.

I think you mean "disable JIT on X86 without SSE2". The JIT works on mips 32-bits[1], armv7 with thumb2[2] and i686 devices with SSE2[3], and is a great benefit on these platforms. Please don't kill performances on platforms that have millions of users to make it work for a much smaller number of users (at least I would think not that many people use webkit with non-SSE2 x86, please correct me with numbers if I am wrong).

[1] https://build.webkit.org/builders/JSCOnly%20Linux%20MIPS32el%20Release
[2] https://build.webkit.org/builders/JSCOnly%20Linux%20ARMv7%20Thumb2%20Release
[3] https://build.webkit.org/builders/GTK%20Linux%2032-bit%20Release (some webkit tests fail, but note that all jsc tests pass).

> I think you mean "disable JIT on X86 without SSE2". The JIT works on mips
> 32-bits[1], armv7 with thumb2[2] and i686 devices with SSE2[3], and is a
> great benefit on these platforms. Please don't kill performances on
> platforms that have millions of users to make it work for a much smaller
> number of users (at least I would think not that many people use webkit with
> non-SSE2 x86, please correct me with numbers if I am wrong).

I think you have misunderstood my comments, sorry for the confusion I caused here, I think it will be better if I create my own bug and fix for my specific problem.

[Maciej Stachowiak]

Is this something we're still planning to do?

[Caio Lima]

(In reply to Maciej Stachowiak from comment #17)
> Is this something we're still planning to do?

Hi Maciej,

We at Igalia are heavily invested on 32 bit platforms and have been maintaining ARMv7 and MIPS backend[1][2][3][4], improving the infrastructure (adding EWS and built support) and hoping to start regular benchmarking in the near future. We would like to reinforce that 32-bits JIT support is still important to some customers of WPE relying on those architectures. 

[1] - https://trac.webkit.org/changeset/261610
[2] - https://trac.webkit.org/changeset/257856
[3] - https://trac.webkit.org/changeset/256850
[4] - https://trac.webkit.org/changeset/258143

[Keith Miller]

(In reply to Caio Lima from comment #18)
> (In reply to Maciej Stachowiak from comment #17)
> > Is this something we're still planning to do?
> 
> Hi Maciej,
> 
> We at Igalia are heavily invested on 32 bit platforms and have been
> maintaining ARMv7 and MIPS backend[1][2][3][4], improving the infrastructure
> (adding EWS and built support) and hoping to start regular benchmarking in
> the near future. We would like to reinforce that 32-bits JIT support is
> still important to some customers of WPE relying on those architectures. 
> 
> [1] - https://trac.webkit.org/changeset/261610
> [2] - https://trac.webkit.org/changeset/257856
> [3] - https://trac.webkit.org/changeset/256850
> [4] - https://trac.webkit.org/changeset/258143

Sorry for the confusion, I think Maciej was asking why this patch was still open and marked for review. I've closed this since there's obviously no plan to do this now.