Proposal on retiring JIT on Windows
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/58f0d9e4a395e0173e4d3f59888bf0e761cf... -Yusuke
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 < webkit-dev@lists.webkit.org> 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/58f0d9e4a395e0173e4d3f59888bf0e761cf...
-Yusuke _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
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 <fujii.hironori@gmail.com> 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 <webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>> 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/58f0d9e4a395e0173e4d3f59888bf0e761cf...
-Yusuke _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> https://lists.webkit.org/mailman/listinfo/webkit-dev
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 <webkit-dev@lists.webkit.org> Sent: Sunday, March 26, 2023 7:23:04 AM To: Fujii Hironori <fujii.hironori@gmail.com>; Brent Fulgham <bfulgham@apple.com>; Mark Lam <mark.lam@apple.com> Cc: WebKit Development <webkit-dev@lists.webkit.org> 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 <fujii.hironori@gmail.com> 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 <webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org>> 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<https://github.com/WebKit/WebKit/commit/58f0d9e4a395e0173e4d3f59888bf0e761cf6ce3> -Yusuke _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org> https://lists.webkit.org/mailman/listinfo/webkit-dev<https://lists.webkit.org/mailman/listinfo/webkit-dev>
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 <Ross.Kirsling@sony.com> 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 <webkit-dev@lists.webkit.org> Sent: Sunday, March 26, 2023 7:23:04 AM To: Fujii Hironori <fujii.hironori@gmail.com>; Brent Fulgham <bfulgham@apple.com>; Mark Lam <mark.lam@apple.com> Cc: WebKit Development <webkit-dev@lists.webkit.org> 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 <fujii.hironori@gmail.com> 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 <webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>> 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/58f0d9e4a395e0173e4d3f59888bf0e761cf...
-Yusuke _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> https://lists.webkit.org/mailman/listinfo/webkit-dev
I guess the shock to me is that bots were taken down instead of reconfigured. Maybe I misunderstood that part of the AppleWin removal—I was excited about this change because it seemed like a net *gain* in resources. Ross ________________________________ From: Yusuke Suzuki <ysuzuki@apple.com> Sent: Sunday, March 26, 2023 3:18:36 PM To: Kirsling, Ross <Ross.Kirsling@sony.com> Cc: Fujii Hironori <fujii.hironori@gmail.com>; Brent Fulgham <bfulgham@apple.com>; Mark Lam <mark.lam@apple.com>; WebKit Development <webkit-dev@lists.webkit.org> Subject: Re: [webkit-dev] Proposal on retiring JIT on Windows 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 <Ross.Kirsling@sony.com> 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 <webkit-dev@lists.webkit.org> Sent: Sunday, March 26, 2023 7:23:04 AM To: Fujii Hironori <fujii.hironori@gmail.com>; Brent Fulgham <bfulgham@apple.com>; Mark Lam <mark.lam@apple.com> Cc: WebKit Development <webkit-dev@lists.webkit.org> 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 <fujii.hironori@gmail.com> 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 <webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org>> 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<https://github.com/WebKit/WebKit/commit/58f0d9e4a395e0173e4d3f59888bf0e761cf6ce3> -Yusuke _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org> https://lists.webkit.org/mailman/listinfo/webkit-dev<https://lists.webkit.org/mailman/listinfo/webkit-dev>
Hi, As we're still to have discussion on our side, I can't speak for us as a group, only individually. I agree with Fujii-san that from our use-cases turning off JIT seems reasonable. However, I do also think regardless of what happened with that, we should make sure that we get bots set up to catch issues in the future on Windows. Possibly a JSC tests bot set for Windows or additional bots to run tests on Windows in general (although I worry about the performance and how long it'd take for those to respond). Stephan From: Yusuke Suzuki via webkit-dev <webkit-dev@lists.webkit.org> Sent: Saturday, March 25, 2023 2:51 PM To: WebKit Development <webkit-dev@lists.webkit.org> Subject: [webkit-dev] Proposal on retiring JIT on Windows 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<https://github.com/WebKit/WebKit/commit/58f0d9e4a395e0173e4d3f59888bf0e761cf6ce3> -Yusuke
participants (4)
-
Fujii Hironori
-
Kirsling, Ross
-
Szabo, Stephan (San Francisco)
-
Yusuke Suzuki