The reason is that the patch is reverted because it broke Windows DFG. This is not acceptable to us since we have no EWS bots running tests. Without active maintainers / EWS bots, we cannot land JIT changes since it can break Windows, and it becomes huge burden than before (previously there was a Windows EWS bot running tests).
This is unfortunate, but if nobody steps up as a maintainer of JSC JIT on Windows (it involves adding test-running EWS bots, bug fixes of JSC on Windows etc.), then I think only the solution is disabling this feature. So, if we would like to keep it, we need someone who steps up as a maintainer of JIT on Windows, and setting up bots running tests on Windows on EWS. -Yusuke > On Mar 25, 2023, at 9:27 PM, Kirsling, Ross <[email protected]> wrote: > > This seems unfortunate and unexpected to me—I thought having a singular > Windows port was supposed to mean reduced maintenance burden, since we don't > have to divide the number of Windows maintainers into two. > > Although reconciling FTL with Windows' calling convention is a challenge that > no one's ever had the time to prioritize, we've had a fully working DFG on > Windows for so many years. If we turn that off, I can't imagine it ever being > revived again. > > How come the discussion here is immediately about getting rid of such a large > swath of functionality instead of starting with consideration of the EWS > situation itself? > > Ross > From: Yusuke Suzuki via webkit-dev <[email protected]> > Sent: Sunday, March 26, 2023 7:23:04 AM > To: Fujii Hironori <[email protected]>; Brent Fulgham > <[email protected]>; Mark Lam <[email protected]> > Cc: WebKit Development <[email protected]> > Subject: Re: [webkit-dev] Proposal on retiring JIT on Windows > >> How about LLInt? LLInt has some Windows specific code. >> Can I revert the change if the JSC team breaks Windows port even though we >> have no EWS nor maintainers? > > I think, ultimately, we cannot guarantee that it is working given that there > is no EWS bots running tests on Windows, it means it is not debuggable to us. > Frequency of breakage on LLInt would be smaller than breakage on JIT. But if > it happens, then I think reverting is not OK since nothing is doable to JSC > team. > > @Brent @Mark What is your thought and plan? > > -Yusuke > >> On Mar 25, 2023, at 3:02 PM, Fujii Hironori <[email protected]> wrote: >> >> It sounds reasonable. I don't object to removing Windows JIT support. >> >> How about LLInt? LLInt has some Windows specific code. >> Can I revert the change if the JSC team breaks Windows port even though we >> have no EWS nor maintainers? >> >> On Sun, Mar 26, 2023 at 6:52 AM Yusuke Suzuki via webkit-dev >> <[email protected] <mailto:[email protected]>> wrote: >> Hello, >> >> I would like to propose retiring JIT on Windows JavaScriptCore. >> Recently, Apple Windows EWS bots get removed. As a result, there is no >> test-running EWS bots on Windows. >> >> This can work for the other part of WebKit since other ports EWS bots are >> running tests. However this does not work well for JSC. >> Compile-tests is not sufficient for JIT since JIT is dynamically generated. >> And JIT is very architecture and platform specific. >> Windows has different ABI, different calling convention, and register usage. >> JIT on Windows has very specific things. >> >> Now, because there is no running EWS bots on Windows, it is not possible to >> catch Windows specific JIT related issues before landing. >> Recently, JSC DFG patch has been reverted because Windows gets broken[1]. >> But this puts high burden to JSC maintenance since >> there is no way to test it before landing, and it makes DFG changes very >> hard due to Windows. >> >> So, given that there is no active maintainers of Windows JSC JIT and no EWS >> bots running tests, I propose retiring JIT on Windows. >> >> [1]: >> https://github.com/WebKit/WebKit/commit/58f0d9e4a395e0173e4d3f59888bf0e761cf6ce3 >> >> -Yusuke >> _______________________________________________ >> webkit-dev mailing list >> [email protected] <mailto:[email protected]> >> https://lists.webkit.org/mailman/listinfo/webkit-dev >
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
