Windows 32-bit support?

# Arunprasad Rajkumar (4 days ago)

Hello,

I'm a JavaFX WebKit port maintainer and currently working to merge GTK WebKit 2.24.x(608.1) trac.webkit.org/log/webkit/releases/WebKitGTK/webkit-2.24 to

our downstream branch hg.openjdk.java.net/openjfx/jfx-dev/rt/file/tip/modules/javafx.web/src/main/native.

I see couple of issues related to Windows 32-bit build, mostly related to recursion tests(js/dom/modules/import-execution-order.html, fast/dom/Document/document-write-recursion.html).

It used to work on GTK 2.22.x(607.1) trac.webkit.org/log/webkit/releases/WebKitGTK/webkit-2.22 branch,

but it now stopped working. I investigated the issue and I found that it needs more stack space to run. It works when I bump up the stack space to 1MB. I don't see any issues on Linux 32-bit platform.

So my question is, do WebKit/JavaScriptCore still supports 32-bit Windows?

Thanks &

Contact us to advertise here
# Michael Catanzaro (4 days ago)

On Tue, Jun 25, 2019 at 8:31 AM, Arunprasad Rajkumar

<ararunprasad at gmail.com> wrote:

So my question is, do WebKit/JavaScriptCore still supports 32-bit Windows?

Hi Arunprasad,

The last version of WebKitGTK to support Windows was 2.4, from 2014.

If you had 2.22 working, that's news to us. To my knowledge, nobody has ever done that before. You might well be the only one; certainly you're the only one to tell us about it. Anyway, that's cool.

We don't support Windows anymore because nobody seems to be interested in (a) making it work, and (b) maintaining the code upstream. So you're kinda on your own here. If you only needed a few downstream changes required to make it work, then we could consider accepting those upstream if you'd be willing to maintain the Windows-specific parts. We're not going to be willing to bring back real Windows support otherwise, since all current developers use Linux and are only interested in Linux.

Anyway, to answer your question: JavaScriptCore is used on Windows by the Apple Windows port and the WinCairo port, and there is very little GTK-specific code in JSC, so this should be the easiest part of WebKitGTK to get working on Windows. You might consider basing your Windows port on WinCairo rather than WebKitGTK, since that port is designed to run on Windows.

Good luck,

Michael

# Arunprasad Rajkumar (4 days ago)

Hello Michael,

Thanks for your reply.

The last version of WebKitGTK to support Windows was 2.4, from 2014. >

Sorry for the confusion. Though JavaFX WebKit port is based on GTK stable branches, we don't use any GTK specific bits. We rely on GTK release branches to cherry-pick the stabilisation patches to our downstream branch.

Anyway, to answer your question: JavaScriptCore is used on Windows by

the Apple Windows port and the WinCairo port, and there is very little GTK-specific code in JSC, so this should be the easiest part of WebKitGTK to get working on Windows. You might consider basing your Windows port on WinCairo rather than WebKitGTK, since that port is designed to run on Windows.

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?

Thanks & Regards, Arun

On Tue, 25 Jun 2019 at 19:59, Michael Catanzaro <mcatanzaro at igalia.com>

wrote:

On Tue, Jun 25, 2019 at 8:31 AM, Arunprasad Rajkumar

<ararunprasad at gmail.com> wrote:

So my question is, do WebKit/JavaScriptCore still supports 32-bit Windows?

Hi Arunprasad,

The last version of WebKitGTK to support Windows was 2.4, from 2014.

Sorry f

# Michael Catanzaro (4 days ago)

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> 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 (1).

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.

Maybe the Windows port maintainers know more about the status of 32-bit Windows support?

Michael

# Adrian Perez de Castro (4 days ago)

On Tue, 25 Jun 2019 10:42:04 -0500, Michael Catanzaro <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> 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 (1).

JIT works on x86 as long as your CPU has support for SSE2 instructions.

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.

# Michael Catanzaro (4 days ago)

On Tue, Jun 25, 2019 at 10:42 AM, Michael Catanzaro

<mcatanzaro at igalia.com> wrote:

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.

I'm being advised that (2) isn't going to work on 32-bit either. So you'll need to try to make cloop work. Good luck... I'm not aware of anybody else supporting JSC on 32-bit Windows.

Michael

# Adrian Perez de Castro (4 days ago)

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> wrote:

On Tue, 25 Jun 2019 10:42:04 -0500, Michael Catanzaro <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> 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 (1).

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

# Yusuke Suzuki (4 days ago)

On Jun 25, 2019, at 9:13 AM, Adrian Perez de Castro <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> 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> 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 (1).

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. lists.webkit.org/pipermail/webkit-dev/2019-March/030569.html, 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.

# Arunprasad Rajkumar (3 days ago)

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 &

# Arunprasad Rajkumar (3 days ago)

I could see that the following comment from 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?

Thanks & Regards, Arun

On Wed, 26 Jun 2019 at 12:10, Arunprasad Rajkumar <ararunprasad at gmail.com>

wrote:

# Yusuke Suzuki (2 days ago)

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 trac.webkit.org/changeset/245906/webkit, 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

Want more features?

Request early access to our private beta of readable email premium.