Handle JS Strings bigger than 4 GiB

[daxpedda]

At the time of writing the spec already supports handling JS Strings of that size, with one notable API issue. When users use encodeStringIntoUTF8*() without measureStringAsUTF8(), this is usually done by getting a rough estimation through "wasm:js-string" "length". However, this function returns a i32.

To address this we would have to introduce an overload to "wasm:js-string" "length" returning a i64.

---

Important

Currently no major JS engine supports strings bigger than 1 GiB.

[jakobkummerow]

I would strongly recommend to postpone worrying about this. Especially if the solution is to introduce one or more overloads, that can easily be deferred until such overloads are needed, if ever.

As a data point, here's a complete timeline of maximum string lengths in V8:
In 2008, when V8 first launched, the maximum string length was technically allowed to be 2**32, however the overall heap size was limited to 512 MiB (2**29 bytes, or 2**28 WTF-16 code units), which implied that every individual object also needed to remain smaller than that.
In 2010, this was made explicit: strings got a stated per-object size limit of 512 MiB. Depending on one-byte or two-byte representation being used for a given string, this resulted in different maximum lengths; also with "cons" (aka "rope") strings it was technically possible to construct longer strings as concatenations of shorter building blocks. However, this caused problems, so:
In 2014, the limits for "string length" and "string object size" were unified, and all strings now had a max length of 2**28.
In 2017, we made the max string length platform specific, allowing 2**30 on 64-bit platforms. On 32-bit platforms, the limit remains (to this day) 2**28.
In 2019, enabling "pointer compression" lowered the max string length on 64-bit platforms back to the limit on 32-bit platforms, i.e. 2**28.
In 2020, we found that on 64-bit platforms we could raise the limit to 2**29.

That's still the state of affairs today.

If it becomes important, we might look into what it takes to raise the limit to 2**30 or perhaps even 2**31; I'm not aware of any actual plans to do that any time soon. There are definitely no plans to go further than what you can store in a 32-bit field. One big reason is that increasing the size of strings' size field would increase the size of every string (which are extremely common, and most of which are waaaay shorter than 2**32), which would increase memory consumption of every existing app/website out there. Given that memory is a scarce resource and out-of-memory crashes are common, we're not inclined to accept such a regression unless there's a really strong reason making it unavoidable. Considering how much you can do with today's maximum string lengths, such a strong reason is not in sight. Theoretically, another possible approach would be to have internal string representations with different-sized length fields, but that would come with both performance overhead (more branching in most string-related operations) and a huge cost in code complexity, so that's not a very compelling option either.

Summary: if growth of the max string length continues at the rate that it happened in the last two decades, then we'll all retire before an i32 string length limit becomes a problem, especially with unsigned interpretation of the value. Who knows, perhaps before that happens even Wasm itself will be retired and replaced by whatever comes next...

(Side note for clarity: i64 memory addresses are a thing in Wasm; that's entirely orthogonal to string lengths.)