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

[Adrian Perez de Castro]

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.

> > > 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?
 
Best regards,


--
 Adrián 🎩
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20180219/a89c917f/attachment.bin>