Intent to Ship: Deprecate module size limit for WebAssembly.Module()

597 views
Skip to first unread message

Andreas Haas

unread,
Apr 5, 2023, 9:05:43 AM4/5/23
to blink-dev

Contact emails

ah...@google.com

Explainer

None

Specification

None

Summary

There exists a limit on the size of a module that can be compiled with `new WebAssembly.Module()` on the main thread. This limit is 4KB, and it was introduced when WebAssembly modules got compiled eagerly with an optimizing compiler, which could block the main thread for many seconds and even minutes. In the meantime V8 launched lazy compilation for WebAssembly modules, and the execution time of `new WebAssembly.Module()` is below 1 second even for the biggest modules we see, even on the weakest devices we measured. Therefore it is time to remove this limit.



Blink component

Blink>JavaScript>WebAssembly

TAG review

None

TAG review status

Not applicable

Risks



Interoperability and Compatibility



Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: Strongly positive We received repeated bug reports because of this limit. Especially for tests synchronous compilation with `new WebAssembly.Module()` is useful, but the size limit prevents bigger tests from using synchronous compilation.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None



Debuggability



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

No

Flag name



Requires code in //chrome?

False

Estimated milestones

Shipping on desktop114
Shipping on Android114
Shipping on WebView114


Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5080569152536576

Links to previous Intent discussions



This intent message was generated by Chrome Platform Status.

--

Andreas Haas

Software Engineer

ah...@google.com


Google Germany GmbH

Erika-Mann-Straße 33

80636 München


Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg


Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.


Daniel Bratell

unread,
Apr 5, 2023, 9:55:01 AM4/5/23
to Andreas Haas, blink-dev

LGTM1

This doesn't show up in our chromestatus UI. Have you sent if for "shipping" there? If no further comments arrive, it may be that it has fallen off our radar because of that.

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAELSTve0zdDNeCDXvG%3D73-zVy8Fps_9eFErWfOocSfxbzOxGHQ%40mail.gmail.com.

Yoav Weiss

unread,
Apr 5, 2023, 9:57:15 AM4/5/23
to Andreas Haas, blink-dev
Is it interoperably tested by other means? I'm not super familiar with WASM testing..
 

Andreas Haas

unread,
Apr 5, 2023, 10:09:15 AM4/5/23
to Yoav Weiss, blink-dev
Hi Yoav,

I'm not sure what you mean. At the moment this 4KB limit exists in Chrome, but it does not exist in Safari or Firefox. I tested this locally on my Macbook. I don't know if there exists another test at the moment which passes on Safari and Firefox but fails on Chrome, and would pass on Chrome after we remove the limit.

Cheers, Andreas

Alex Russell

unread,
Apr 13, 2023, 2:21:46 PM4/13/23
to blink-dev, Andreas Haas, blink-dev, Yoav Weiss
"Below 1 second" for something that can block the main thread is not particularly heartening. Can you please provide the histogram data you're seeing to justify this? Would you be happy to raise the cap to a larger (but still fixed) size based on a baseline device config instead?, e.g.:

https://infrequently.org/2022/12/performance-baseline-2023/

Best,

Alex
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Andreas Haas

unread,
Apr 14, 2023, 5:00:08 AM4/14/23
to Alex Russell, blink-dev, Yoav Weiss
Hi Alex,


I think the question is more, how can we justify such a limit? I mean, I agree, it is not a good experience if the main thread is blocked for 1 second, but we have to consider the scenario in which this is happening. The main thread is blocked for one second after a WebAssembly module was downloaded which is tens of megabytes big.

Additionally, in the current environment it is not likely that you end up serving a big WebAssembly module to the user with synchronous compilation by accident. WebAssembly modules are typically generated by compilers which also generate the JS glue code around it. These compilers produce glue code that uses asynchronous compilation or even streaming compilation. Therefore a developer would have to make an effort to even serve a big WebAssembly module with synchronous compilation.

There are scenarios where developers make this effort, and I don't think we should prevent developers when they make this conscious decision. One such scenario is tests. It is much easier to write and run tests with synchronous compilation. We run nearly all our WebAssembly tests in V8 with synchronous compilation. We also got bug reports repeatedly where developers struggle with their tests because of the 4KB limit.

So overall I think the limit was justified in the beginning, but now with lazy compilation and baseline compilation this justification is gone. I don't think this limit makes the web a better place anymore, it just makes the life of developers difficult in specific niche situations.

Cheers, Andreas

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.


--

Andreas Haas

Software Engineer

ah...@google.com


Google Germany GmbH

Erika-Mann-Straße 33

80636 München


Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg


Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.


Ian Kilpatrick

unread,
Apr 14, 2023, 2:18:23 PM4/14/23
to Andreas Haas, Alex Russell, blink-dev, Yoav Weiss
Out of curiosity - 
What is performance like on a low tier Android phone (I see only a Pixel 7 tested above)?
What is the performance of your benchmark on other browsers - across device classes? (Even if they don't have this limit - this intent will mean that it'll be interoperable to use the sync method - potentially causing compat problems for the other browsers).

Ian

Andreas Haas

unread,
Apr 17, 2023, 6:12:04 AM4/17/23
to Ian Kilpatrick, Alex Russell, blink-dev, Yoav Weiss
Hi Ian,


You need corp access for it, and I didn't have access to low tier Android phones with corp access.

Safari also compiles lazily, so their compile times are similar to ours. Firefox compiles modules eagerly, and therefore takes longer. I don't really have the devices or the setup to do the measurements on other browsers. I measured the performance of Firefox on my workstation, where the compilation of the 80MB module takes slightly less than 1.6 seconds. This is about 60% slower than Chrome with eager compilation. I tried Chrome with eager compilation on the atlas Chromebook. Compilation of the 80MB module takes 2.8 seconds there.

Cheers, Andreas

Philip Jägenstedt

unread,
Apr 19, 2023, 11:59:21 AM4/19/23
to Andreas Haas, Ian Kilpatrick, Alex Russell, blink-dev, Yoav Weiss
Hey Andreas,

Do you know what the limits of other browsers are? If testing a 1 GB module is too slow to be reliable (sometimes timing out) then perhaps there's a large-ish module you can test with that still exceeds the current limits?

Note that you could also add a manual test in WPT for the real limit (1 GB) and run it at least once manually to ensure it works the same in all browsers.

Best regards,
Philip

Andreas Haas

unread,
Apr 20, 2023, 6:58:25 AM4/20/23
to Philip Jägenstedt, Ian Kilpatrick, Alex Russell, blink-dev, Yoav Weiss
Hi Philip, Yoav,

I added a test to the wasm spec tests now, see https://github.com/WebAssembly/spec/pull/1642. It creates modules of size 1GB and 1GB+1 and checks that compilation passes or fails, respectively. The modules consist of a single custom section, so that minimal processing time and module creation time should be introduced.

As far as I know, the other browsers never had a special limit on the module size, other than the spec'ed 1GB limit. I confirmed that now with Firefox.

Cheers, Andreas

Yoav Weiss

unread,
Apr 20, 2023, 7:06:30 AM4/20/23
to Andreas Haas, Philip Jägenstedt, Ian Kilpatrick, Alex Russell, blink-dev
LGTM2

Thanks for testing this! :)

Alex Russell

unread,
Apr 20, 2023, 2:58:27 PM4/20/23
to blink-dev, Yoav Weiss, Philip Jägenstedt, Ian Kilpatrick, Alex Russell, blink-dev, Andreas Haas
Thanks for the document, Andreas.

The numbers in it are still hugely concerning, and I'm a -1 until and unless we have data from P75-P90 Androids and Windows devices. Our telemetry from Edge shows that nearly half of users are on slow, spinning rust and 2-4 core devices, and the only system in your test list that reflects something in this range is the N2840 in the HP Chromebook 13 G1.

Motivations in the document regarding testing are not compelling. Folks doing testing can provide flags to the browser (which you could expose to raise the limit without an Intent).

Would you be willing to accept a higher cap? Your document suggests that ~10MiB (unzipped) might be reasonable, but would want to see data from low-end Android before going even that far.

Thanks.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.


--

Andreas Haas

Software Engineer

ah...@google.com


Google Germany GmbH

Erika-Mann-Straße 33

80636 München


Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg


Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Andreas Haas

unread,
Apr 21, 2023, 7:47:29 AM4/21/23
to Alex Russell, blink-dev, Yoav Weiss, Philip Jägenstedt, Ian Kilpatrick
Hi Alex,

I will try to organize a low-end device to do the measurements you are asking for. Could you please describe how the results would guide your decision on this issue?

I would also ask you to clarify your concerns. What are the scenarios you have in mind, and what are the improvements a user would get from this limit?

When I think of concrete scenarios, then I end up either with the scenario being unlikely, or that the limit would not make a big difference for the user experience:
* Unlikely, because it is hard to end up with a big WebAssembly module that you compile synchronously. You don't write WebAssembly modules by hand, you generate them with a compiler like Emscripten. The compiler typically does not only generate the WebAssembly module for you, it also generates the code for you that downloads and compiles the WebAssembly module. A scenario where the limit may matter is that the compiler decides to use synchronous compilation instead of asynchronous compilation. However, why would the compiler do that?
    * Because synchronous compilation provides benefits? What would these benefits be? The WebAssembly module already gets downloaded asynchronously, so continuing with synchronous compilation has no advantage to asynchronous compilation.
    * By accident, because the compiler writer does not know better? I think it's unlikely that a compiler writer would choose to use synchronous compilation by accident, and that this compiler is then used to produce a WebAssembly module with 10s of MB, and that the resulting WebAssembly module is then used in any reasonable webpage.
* The limit would not make a difference for the following reason: On the website you cite above the average network bandwidth is 9Mbps. Even compressed the 80MB module in my measurements would take 10s of seconds to download. Does blocking the main thread of less than 1 second really matter to the user after they waited many times as long for the download?

As I wrote before, I understand why this limit was introduced originally. However, these reasons don't exist anymore, and all that remains is a spec violation, see https://webassembly.github.io/spec/js-api/index.html#limits. Even a limit of 10MB is still a spec violation, and as I wrote before, I don't see any justification for that.

Cheers, Andreas

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.


--

Andreas Haas

Software Engineer

ah...@google.com


Google Germany GmbH

Erika-Mann-Straße 33

80636 München


Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg


Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.


--

Andreas Haas

Software Engineer

ah...@google.com


Google Germany GmbH

Erika-Mann-Straße 33

80636 München


Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg


Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.


K. Moon

unread,
Apr 21, 2023, 9:44:23 AM4/21/23
to Andreas Haas, Alex Russell, blink-dev, Yoav Weiss, Philip Jägenstedt, Ian Kilpatrick
I don't have any authority here, but my two cents: Given there's a synchronous and an asynchronous API already, why not let the page author decide the right trade-off for themselves? I know in general we'd like to discourage authors from blocking the renderer main thread, but there already seem to be plenty of incentives not to do that already, and the well-lit paths don't encourage large synchronous compilations. It'd be different if this somehow required blocking the browser main thread, of course.

Alex Russell

unread,
Apr 24, 2023, 1:13:23 PM4/24/23
to blink-dev, Andreas Haas, blink-dev, Yoav Weiss, Philip Jägenstedt, Ian Kilpatrick, Alex Russell
  Hey Andreas,

First, I deeply appreciate your willingness to do the work to get us data.

I'm generally interested in understanding the potential for modules to create main-thread jank. If we accept the CWV INP threshold of ~200ms, would like to make sure that for the vast majority of users (P90? P95?) don't hit synchronous operations longer than that. So the question about sizing is relative to that goal.

Put differently, if we raise the limit to XMB vs. YMB, and developers begin to develop to that new threshold, how much jank can this introduce?

As for "does blocking the main thread for 1s really matter?", all I can tell you is that this project has worked diligently for more than a decade to try to eliminate sources of main-thread jank. It would be surprising if we relaxed that goal for this specific feature.

Best,

Alex



To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.


--

Andreas Haas

Software Engineer

ah...@google.com


Google Germany GmbH

Erika-Mann-Straße 33

80636 München


Geschäftsführer: Paul Manicle, Liana Sebastian

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg


Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Andy Wingo

unread,
Apr 26, 2023, 3:30:06 AM4/26/23
to 'Andreas Haas' via blink-dev, Alex Russell, Andreas Haas, Yoav Weiss, Philip Jägenstedt, Ian Kilpatrick
Hi,

Just a note about use-cases:

On Fri 21 Apr 2023 13:47, "'Andreas Haas' via blink-dev" <blin...@chromium.org> writes:

> * You don't write WebAssembly modules by hand, you generate them with
> a compiler like Emscripten.

The WebAssembly module itself may well generate, compile, and
instantiate a module -- a form of JIT code generation. See
https://wingolog.org/archives/2022/08/18/just-in-time-code-generation-within-webassembly
for a longer discussion. Probably at some point there will be a
WebAssembly proposal to address this use case.

Sometimes synchronous compilation can be useful for the JIT use case,
for example so you can embed pointers to linear memory in the generated
module and be sure they are still valid by the time the generated module
runs. Of course, generally you would still want to design for
asynchronous compilation to avoid blocking the main loop, but in
development at least it's nice that synchronous instantiation is
possible.

Regards,

Andy

Andreas Haas

unread,
Apr 26, 2023, 11:49:31 AM4/26/23
to Alex Russell, blink-dev, Yoav Weiss, Philip Jägenstedt, Ian Kilpatrick

Hi Alex,

Here are the performance measurements you requested on some Android phones I found.

sizeNokia 1PixelPixel 2Pixel 3Pixel 7
713B4.57ms2.96ms1.46ms0.47ms0.22ms
25.92KB5.54ms3.79ms1.44ms1.77ms0.98ms
35.12KB86.39ms46.52ms16.32ms13.17ms8.70ms
249.84KB13.99ms7.53ms3.17ms3.27ms2.16ms
294.95KB14.70ms8.02ms3.86ms3.23ms2.34ms
378.2KB18.61ms10.56ms7.06ms4.83ms4.48ms
768.98KB78.11ms38.79ms28.45ms18.43ms5.70ms
1.26MB45.29ms22.59ms18.35ms7.20ms5.20ms
2.89MB89.30ms35.56ms32.37ms13.77ms11.06ms
3.28MB215.52ms83.29ms84.42ms32.57ms21.96ms
6.65MB127.58ms59.96ms42.95ms22.00ms16.34ms
8.9MB398.86ms218.55ms114.45ms49.70ms42.54ms
10.08MB535.84ms281.89ms144.76ms65.43ms53.22ms
13.56MB327.44ms136.32ms87.69ms51.83ms44.26ms
19.12MB504.83ms232.17ms133.18ms88.73ms75.36ms
34.54MB1541.58ms910.30ms423.14ms261.57ms275.40ms
60.37MBOOM609.99ms307.16ms219.67ms183.00ms
63.77MB1491.76ms735.30ms360.98ms214.80ms168.56ms
64.08MB1473.18ms727.87ms350.73ms251.27ms180.56ms
67.41MB1499.28ms809.60ms380.74ms298.00ms228.82ms
83.26MBOOM708.36ms384.34ms272.90ms

As far as I understand the discussion here there are worries that if we remove this limit, then the user experience will regress, especially on low-end devices.

On the other hand, my goal with this proposal is to improve the developer experience.

Additionally I want to mention that this limit on synchronous WebAssembly compilation is an inconsistency in the web platform, and a violation of the WebAssembly standard which recommends a maximum WebAssembly module size of 1GB. In principle we should implement the standard, and if we don't agree with the standard, then we should work on changing the standard and not ignore it.

Back to user experience vs developer experience. I think for both sides this limit does not make a big difference. Developers will use asynchronous compilation anyways because that's what to-WebAssembly compilers generate automatically. Also, typically a WebAssembly module has to be downloaded first, and with the `WebAssembly.compileStreaming()` API there exists a tool that allows you to download and compile a WebAssembly module at the same time. So in the typical scenario where you first download a WebAssembly module and then you compile it, synchronous WebAssembly compilation does not provide any benefits to the developer, and it is also not the default. So developers would only decide consciously in special situations to use synchronous compilation.

So which scenarios would cause a bad user experience?
A bad user experience would be if the main thread is blocked repeatedly for longer amounts of time, or at bad moments in time like during an animation. 
Now, WebAssembly module compilation takes time because new code gets provided to the web page. However, there is only so much code you want to load in your web page, especially code in modules that are bigger than 1MB. So the chance that the main thread gets blocked repeatedly for longer amounts of time is low.
So what about jank during animations? If we look at JavaScript, then JavaScript code gets typically loaded in one big script, or in many small scripts. The big script gets loaded during the startup of a web page, small scripts may get loaded over time. For WebAssembly it is the same so far, and will probably stay the same: big modules get loaded during the startup of a web page, only smaller modules would get loaded later. During page startup, users are used to waiting a bit for the page to start up, to load data from the server and to execute initialization code. Jank introduced by synchronous WebAssembly compilation would only be a small part during startup. Note that downloading the big WebAssembly module takes typically much longer than compiling it.
To sum up, jank introduced by synchronous WebAssembly compilation would either happen during page startup where it's dominated by other delays like the much longer module download. Small modules may also get compiled later, but then the introduced jank would be small because the module is small.

Then, how does the limit make the developer experience bad?
First, as mentioned above, the limit is an inconsistency in the web platform and a violation of the WebAssembly standard. Inconsistencies in the web platform are known as big developer pain points, and the bug reports we got about this limit show the same.
Second, there are special scenarios where synchronous compilation has advantages. I already mentioned testing, where the order in which you compile and execute tests is important. Saying that developers should just set special browser flags to disable the limit sounds arrogant to me. You want to test your code in an as realistic context as possible, as all special configurations of the testing setup may lead to missed bugs.
But there are also other situations, especially for experimental projects where synchronous compilation could make things easier, like the JIT compiler that Andy Wingo mentioned.
There is also the situation where you would like to add a custom section to your WebAssembly module which supports debugging. One example would be a name section that can be loaded by DevTools. This custom section would not change the compile time at all because custom sections get ignored by the WebAssembly engine. For the developer this custom section can be very valuable, but also very big. It would be a big developer pain point if the developer has a module which is far below the limit in release mode, but with the debugging information in the custom section the module would be bigger than the limit, and they would not be able anymore to run their web page, at least not in Blink.
To sum up, the web developers only notice the limit in very specific scenarios, but when they do, the limit is surprising and a big developer pain point.

So overall I don't think this limit matters for most users or developers, but in the cases where it matters it is much more painful for the developer than for the user.

To answer to your email specifically:

I don't think that the CWV INP threshold is a good guideline here, because, as I mentioned above, the main-thread jank caused by WebAssembly compilation is likely to happen when it matters less, and when it's dominated by other delays like the module download.

Cheers, Andreas