> On Feb 19, 2018, at 11:43 AM, Guillaume Emont <guijem...@igalia.com> wrote: > > Quoting Filip Pizlo (2018-02-19 13:05:27) >> >>> On Feb 19, 2018, at 10:53 AM, Guillaume Emont <guijem...@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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
