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

[Filip Pizlo]

> On Feb 19, 2018, at 1:03 PM, Adrian Perez de Castro <aperez at igalia.com> wrote:
> 
> Hello everybody,
> 
> On Mon, 19 Feb 2018 13:43:38 -0600, 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 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.
> 
> *Was* basically unmaintained a few months ago.
> 
> I agree that in many cases the JIT may be a marketing point, that not every
> application benefits from it, and that some applications may be better off
> using more CPU and saving memory instead by not having the JIT. Yet many
> applications *do* work better with a JIT — otherwise we would not be having
> this discussion, and the proposal would be to completely remove the JIT
> support, for all platforms ;-)
> 
>> 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
> 
> When we took the decision at Igalia of stepping up and work on keeping the
> 32-bit JIT support alive, we had only one person available to work full-time
> with the needed knowledge.
> 
> It was lucky that Guillaume could start right away when this topic was last
> discussed, but finding more developers to work on JSC is not trivial. Some of
> us have been even chipping in now and then to review patches — sometimes in
> our free time, like my informal reviews of patches for MIPS. Now we have a
> second person who can devote time to JSC, so I would expect things to get even
> better.
> 
>>>> 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. 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.
> 
> Also, we have been playing catch-up to get the 32-bit platforms in shape,
> without working on something more visible. This is the kind of churn that
> often goes unnoticed.
> 
>>>> 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.
> 
> Now that you mention plans: It would be extremely useful for us to have an
> idea of what's the JSC roadmap for the next few months. Being on the same page
> in this regard would allow us all to coordinate better, and better plan the
> focus of work on our side.

Our roadmap is to remove 32-bit JITs and to remove JSVALUE32_64, and then have 32-bit platforms compile cloop with JSVALUE64.

> 
>>>> 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.
> 
> Could you provide a concrete example of a mitigation for 64-bit platforms that
> would not be possible unless the code for 32-bit JIT support is removed?

We need to rewrite the JSArray object model and all JIT support for arrays.  We don’t feel like doing the rewrite for 32-bit, since that would not be useful for us.

Our plan is to either:

A) Replace all 32-bit array accesses with calls to C functions.  This will make the 32-bit JIT slower than the interpreter for every workload that uses arrays.  We’d rather not do this, since even this is more work than we feel like putting in.

B) Remove the 32-bit JIT entirely.

C) Disable 32-bit JITing on macOS and iOS and land the JSArray change without validating (or even compiling) it on 32-bit JITs.

We want to do (B).

-Filip


> 
> Best regards,
> 
> 
> --
> Adrián 🎩