Define a JS-API implementation limit for name lengths

[eqrion]

The core spec allows for an implementation limit on the length of names (i.e. strings). The JS-API does not define one and the engines have inconsistent limits. SpiderMonkey has a limit of 100_000 bytes. I'm told JSC has the same, and V8 has no limit.

This is normally not a big issue, but with js-string-builtins and string constants imports the names can get really big. One option would be to not have a limit on name length, but I'd prefer to have a limit even if it's really large.

How would folks feel about a limit of ~10 MiB? I would hope the would be large enough for 99% of string constants, and the pathological ones could use some other mechanism that's better designed for bulk data.

cc @mkustermann @jakobkummerow @kmiller68

[jakobkummerow]

We do have a limit in V8: the same limit as for all other strings, currently (1 << 29) - 24 == 536,870,888 WTF-16 code units on 64-bit platforms, and about half as many on 32-bit.

In the wire bytes there's the effective limit of 1 GiB per module (per the JS API spec), which of course is usually not spent entirely on one massive string constant. Does that qualify as "have a limit even if it's really large"? 😃

Would it work for SpiderMonkey to simply also allow the same string lengths as you allow for JavaScript?

I suppose I wouldn't object to introducing an artificial lower limit such as 10 MiB, but I'm not particularly convinced that we need it, considering that strings themselves will (presumably) always be subject to implementation-defined limits. For example, even if we standardized the length limit of the string constants that can be defined in the wire bytes directly, there would be engine-specific differences in how many "wasm:js-string" "concat" operations you can do on them.

[eqrion]

Would it work for SpiderMonkey to simply also allow the same string lengths as you allow for JavaScript?

Yes, that would be fine.

I still think it'd be valuable to have a JS-API defined limit here, for the same reasons we have limits on everything else (like functions). If 10MiB is too small, how about 2 ^ 28 (i.e. 256 MiB)? That's close to both of our max runtime string sizes.

[syg]

JSC is removing the string limit and letting it hit the implementation-defined limit like in JS for now in the interest of maximal compat.

I'm pretty neutral on whether there should be a spec limit. On the one hand, strings feel like "small allocations" to me, and having limits on it feels odd. On the other hand, if we spec it, we can limit the risk of truly degenerate programs working in one implementation and not the others. 10MB does seem too limiting, esp. given blobs of base64 or whatever. I don't have any bright ideas for how to come up with a reasonable spec limit.

[mkustermann]

My general sense is that we shouldn't restrict things if there's no concrete reason from an implementation point of view. JS engines already have the ability to deal with large strings, so it's unclear if there's a reason for restriction here.

I think specifying more restrictive limits may make more sense in cases where N bytes in module turn into M >>> N bytes in memory/disc or cause excessive cpu usage (e.g. like a zip bomb).

It's also best to avoid a situation where we decide on e.g. 10 MB limit now and later find it's insufficient and raise it. This is a big problem for languages like Dart, because we target older versions of browsers. So as long as we want to make the output runnable on older browser versions we couldn't take advantage of the new limits. (Indeed, the fact that Firefox and Safari impose the 100_000 limit today means that even if we lift it now, we cannot take advantage of the higher limit for some time until we raise the minimum browser version of FF/Safari we want to support).

[eqrion]

It doesn't seem like there's any appetite to define a JS-API limit here (which is fine by me). So I'm going to close this.