[webkit-dev] Windows 32-bit support?
ysuzuki at apple.com
Thu Jun 27 15:11:28 PDT 2019
> On Jun 26, 2019, at 7:57 AM, Arunprasad Rajkumar <ararunprasad at gmail.com> wrote:
> Hi Yusuke,
> I could see that the following comment from https://trac.webkit.org/changeset/245906/webkit <https://trac.webkit.org/changeset/245906/webkit>,
> >> We also disable this op_wide16 feature in Windows CLoop, which is used in AppleWin port. When the code size of
> >> CLoop::execute increases, MSVC starts generating CLoop::execute function with very large stack allocation
> >> requirement. Even before introducing this 16bit bytecode, CLoop::execute in AppleWin takes almost 100KB stack
> >> height. After introducing this, it becomes 160KB. While the semantics of the function is correctly compiled,
> >> such a large stack allocation is not essentially necessary, and this leads to stack overflow errors quite easily,
> >> and tests fail with AppleWin port because it starts throwing stack overflow range error in various places.
> >> In this patch, for now, we just disable op_wide16 feature for AppleWin so that CLoop::execute takes 100KB
> >> stack allocation because this patch is not focusing on fixing AppleWin's CLoop issue. We introduce a new backend
> >> type for LLInt, "C_LOOP_WIN". "C_LOOP_WIN" do not generate wide16 version of code to reduce the code size of
> >> CLoop::execute. In the future, we should investigate whether this MSVC issue is fixed in Visual Studio 2019.
> >> Or we should consider always enabling ASM LLInt for Windows.
> Does that mean high stack usage in Windows is a known issue?
Yes, I think this is MSVC’s issue.
You can try using LLInt ASM for Windows if stack height problem is critical to you now, it would work because WinCairo is using it.
But TBH, I’m not sure whether LLInt ASM works on Win32. If the stack height problem is not critical, I strongly recommend using CLoop for now.
> Thanks & Regards,
> On Wed, 26 Jun 2019 at 12:10, Arunprasad Rajkumar <ararunprasad at gmail.com <mailto:ararunprasad at gmail.com>> wrote:
> Thank you all for your guidance.
> I understand that JIT and LLInt bytecode interpreter is not supported on X86(32-bit). The only option I can use is C_LOOP, which have high stack usage issue in the latest code. I will continue with my investigation on C_LOOP's stack usage.
> Thanks & Regards,
> On Wed, 26 Jun 2019 at 04:13, Yusuke Suzuki <ysuzuki at apple.com <mailto:ysuzuki at apple.com>> wrote:
>> On Jun 25, 2019, at 9:13 AM, Adrian Perez de Castro <aperez at igalia.com <mailto:aperez at igalia.com>> wrote:
>> I was mistaken about one thing (sorry!), please read below...
>> On Tue, 25 Jun 2019 19:01:54 +0300, Adrian Perez de Castro <aperez at igalia.com <mailto:aperez at igalia.com>> wrote:
>>> On Tue, 25 Jun 2019 10:42:04 -0500, Michael Catanzaro <mcatanzaro at igalia.com <mailto:mcatanzaro at igalia.com>> wrote:
>>>> It's great that you find our stable branches helpful, but keep in mind
>>>> those branches do not include Windows-specific fixes.
>>>> On Tue, Jun 25, 2019 at 9:53 AM, Arunprasad Rajkumar
>>>> <ararunprasad at gmail.com <mailto:ararunprasad at gmail.com>> wrote:
>>>>> Right. Actually the problem is in 32-bit Windows platform. I see that
>>>>> the JIT support has been dropped some time ago, and CLOOP based
>>>>> backend seems to be unstable on 32-bit Windows. Any thoughts on that?
>>>> So I'm not an expert here, but I understand there are three ways you
>>>> can build JSC:
>>>> (1) -DENABLE_JIT=ON, -DENABLE_C_LOOP=OFF
>>>> (2) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=OFF (?)
>>>> (3) -DENABLE_JIT=OFF, -DENABLE_C_LOOP=ON
>>>> (-DENABLE_JIT=ON and -DENABLE_C_LOOP=ON are incompatible.)
>>>> I believe that nowadays the only 32-bit platforms supported by JIT are
>>>> Linux, and there only for ARM and MIPS, not x86. So you're almost
>>>> certainly going to need to use -DENABLE_JIT=OFF. That eliminates option
>>> JIT works on x86 as long as your CPU has support for SSE2 instructions.
>> Oops, this is not quite true: JIT does NOT work on 32-bit x86 at the moment.
>> (The JIT compiler does emit SSE2 instructions, though. When/If the JIT is
>> made to work on 32-bit x86, support for SSE2 will be needed.)
> WebKit no longer supports non-SSE2 x86 CPUs even without JIT.
> https://lists.webkit.org/pipermail/webkit-dev/2019-March/030569.html <https://lists.webkit.org/pipermail/webkit-dev/2019-March/030569.html>
> And I think we are not supporting 32bit Windows x86 JIT. CLoop (AppleWin) is recommended.
>>>> You say the cloop seems unstable for you, which is option (3). So
>>>> perhaps you should try option (2) if you haven't already. I'm not
>>>> actually sure if that works, because I'm not an expert, which is why I
>>>> added that (?) to it. But at least it couldn't hurt to try.
>>> Option (2) would be using the LLint bytecode interpreter, without JIT.
>>> In principle CLoop is expected to work “everywhere” because the interpreter
>>> is generated C/C++ code, which gets then built by the same compiler used to
>>> build all the rest of WebKit.
>>>> Maybe the Windows port maintainers know more about the status of 32-bit
>>>> Windows support?
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev