Playground: WASM Out of memory

[skorfmann]

I tried this:

Open more than 5 tabs of the playground with this link

This happened:

The sixth tab threw an error

Uncaught (in promise) RangeError: WebAssembly.instantiate(): Out of memory: Cannot allocate Wasm memory for new instance

Subsequent new tabs were stuck in loading mode.

I expected this:

• Don't consume that much memory
• Alternatively, present a nice message to the user what the problem is

Is there a workaround?

Don't open too many tabs (or buy more memory?) :)

Component

Playground

Wing Version

0.19.6

Wing Console Version

No response

Node.js Version

?

Platform(s)

MacOS

Anything else?

• Chrome Version 114.0.5735.106 (Official Build) (x86_64)
• Memory: 32 GB 2667 MHz DDR4
• macOS: 13.3.1 (a)

Notes:

While the first occurrence of this happened in a browser session with plenty of tabs, I was able to reproduce this with a fresh Chrome instance.

Each new tab seems to consumer 900 MB - 1 GB

Here's the related Slack thread

Community Notes

• Please vote by adding a 👍 reaction to the issue to help us prioritize.
• If you are interested to work on this issue, please leave a comment.

Definition of Done

• [ ] send analytics event
• [ ] When this issue is happening, open a popup on screen that shows the original message and notify the user that he probably has too many open tabs

  Title: Out Of memory Description: Please close other tabs on and reload this page

Implementation notes

• [ ] need to decide if this should rely on the message or limit the number of tabs
• [ ] Need to implement this in the playground/learn not in the console

[skorfmann]

There seems to be a 4GB memory limit for WASM in Chrome https://chat.openai.com/share/eae464a8-ecdd-4fd9-abca-6ba55916f626 (which is confirmed by https://v8.dev/blog/4gb-wasm-memory). However, this is per WASM instance according to ChatGPT, not sure how trustworthy that info is though 😆

[ainvoner]

@ekeren let's priorities

[ekeren]

@eladcon , as we use the playground more, it is becoming an issue.

can you take a look?

[ekeren]

Noticed this

https://blog.stackblitz.com/posts/debugging-v8-webassembly/

[ekeren]

It happens to me on the forth tab

[eladcon]

seems like this is a websontainer issue. even when not running the console at all and just installing the dependencies (running npm install i can only open 6 tabs. using wing wasm outside of webcontainers works fine (the lsp is working even with 20 open tabs)

[ekeren]

Checked with @eladcon

Even when you open https://stackblitz.com/edit/stackblitz-webcontainer-api-starter-tvjtvf?file=README.md 3 times, it stops working with the same issue

[ekeren]

updated definition of done of the ticket

[skyrpex]

I got an idea to overcome this issue. As far as my experiments go, the memory is allocated per domain (eg: play.winglang.io vs learn.winglang.io).

If we instantiate the webcontainer in random subdomains such as abc-123.play.winglang.io, we can open any number of apps. So, play.winglang.io would use an iframe to random-345.play.winglang.io. The users shouldn't notice a thing.

[eladcon]

i think it would work, though we would need to manage those domains

[ekeren]

Great idea. What do we need to serve from these subdomain?

We can have a wildcard subdomain going to the same location

[ShaiBer]

Do we still need to solve this problem if we go with the backend solution?

[ekeren]

I think that util we know that the backend solution is solid, we should treat it as a P2.

I want to be risk averse at this point in time

[ShaiBer]

👍

[skyrpex]

So I tried going forward with my tests using dynamic subdomains such as abc123.play-test.winglang.io, def456.play-test.winglang.io, etc, inside an iframe published in play-test.winglang.io.

There's a problem and is that the WASM files are being loaded in the topmost frame on the browser tab, which would be play-test.winglang.io, so it works the same unless we make our users open the playground using the subdomain URLs directly.

As @ainvoner mentioned, we prefer to receive traffic to from winglang.io directly so using subdomains isn't a viable option, but what if we do the following?

• Users open the playground normally at winglang.io/play
• The page runs a check: if there's more than two or three tabs open at winglang.io/play, we redirect you to xxx.play.winlang.io
• We can do the inverse check: if xxx.play.winlang.io is opened but there's no tab at winglang.io/play, we redirect you back to winglang.io/play

We can enable tab to tab communication between subdomains, so technically it isn't a problem.

[ShaiBer]

Sounds reasonable to me

[ekeren]

@skyrpex , this should be for learn as well