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.


> On Mar 25, 2023, at 9:27 PM, Kirsling, Ross <> 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 <>
> Sent: Sunday, March 26, 2023 7:23:04 AM
> To: Fujii Hironori <>; Brent Fulgham 
> <>; Mark Lam <>
> Cc: WebKit Development <>
> 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 <> 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 
>> < <>> 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]: 
>> -Yusuke
>> _______________________________________________
>> webkit-dev mailing list
>> <>

webkit-dev mailing list

Reply via email to