[webkit-dev] Disabling the 32-bit JITs by default.

[Filip Pizlo]

> On Feb 19, 2018, at 11:43 AM, Guillaume Emont <guijemont at igalia.com> wrote:
> 
> Quoting Filip Pizlo (2018-02-19 13:05:27)
>> 
>>> On Feb 19, 2018, at 10:53 AM, Guillaume Emont <guijemont at igalia.com> wrote:
>>> 
>>> Hi Keith,
>>> 
>>> We at Igalia have been trying to provide a better story for 32-bit
>>> platforms, in particular for Armv7 and MIPS. These platforms are very
>>> important to us, and disabling JIT renders many use cases impossible.
>> 
>> What use cases?
> 
> I'm not sure of how much I can elaborate here, but in this particular
> case that was for a set-top-box UI.

I bet that this doesn’t need a JIT.

If you want me to believe that it does, you need to show perf numbers.

> 
>> 
>> I realize that having a JIT is good for marketing, but it’s better to have a stable and well-maintained interpreter than a decrepit JIT.  Right now the 32-bit JIT is basically unmaintained.
> 
> Indeed these platforms used to be practically abandoned in WebKit. I
> don't think that is true any more though. We've been working on fixing
> this and getting mips32 and armv7+thumb2 to pass all the tests. We have
> achieved that for mips32[1] and we are almost there for armv7[2]. I
> would appreciate it if you could acknowledge that effort.
> 
> [1] https://build.webkit.org/builders/JSCOnly%20Linux%20MIPS32el%20Release
> [2] https://build.webkit.org/builders/JSCOnly%20Linux%20ARMv7%20Thumb2%20Release <https://build.webkit.org/builders/JSCOnly%20Linux%20ARMv7%20Thumb2%20Release>

Passing all of the tests does not constitute stability in my book.  You need a lot of people using the JIT in anger for a while before you can be sure that you did it right.

Also, you need to prove that the JIT is actually a progression.  Last time we had such a conversation, you guys had perf regressions from enabling the JIT.  So, use cases that needed perf would have been better off with the interpreter.

> 
>> 
>>> We
>>> want to continue this effort to support these platforms. We have been
>>> short on resources for that effort, which is why we did not realize
>>> early enough that more mitigation was needed for 32-bit platforms. We
>>> now have grown our team dedicated to this and we are hopeful that we
>>> will avoid that kind of issue in the future.
>> 
>> I feel like I’ve heard this exact story before.  Every time we say that there isn’t any effort going into 32-bit, y’all say that you’ll put more effort into it Real Soon Now.  And then nothing happens, and we have the same conversation in 6 months.
> 
> I'm sorry it took us time to grow our team for this purpose, but that is
> now a reality since the beginning of this month.

I’ve heard this before.

> And beside that, I
> think you can agree that there has been significant progress on that
> aspect, we were very far from having a green tree on mips32 about a year
> ago, when we still had hundreds of test failures.

I don’t agree that there has been significant progress.  The level of maintenance going into those JITs is a rounding error compared to how much work is done on ARM64 and x86_64.

-Filip


> 
>> 
>>> 
>>> We are working on a plan to mitigate Spectre on 32-bit platforms. We
>>> would welcome community feedback on that, as well as what kinds of
>>> mitigations would be considered sufficient.
>>> 
>>> Regarding your patch, I think you should note that some specific 32-bit
>>> CPUs are immune to Spectre (at least the Raspberry Pi[1] and some
>>> MIPS[2] devices), I think the deactivation should be done at run-time
>>> for CPUs not on a white list.
>> 
>> Keith’s main point is that the presence of 32-bit makes it harder to implement mitigations for 64-bit.  I don’t think it’s justifiable to hold back development of 64-bit Spectre mitigations because of a hardly-used and mostly-broken 32-bit JIT port that will be maintained by someone Real Soon Now.
> 
> I can't answer to that as I don't know enough what is hindering these
> mitigations exactly.
> 
> 
> Best regards,
> 
> Guillaume

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20180219/19ad5b98/attachment.html>