label count soft limit #7
Comments
|
If I remember correctly it was difficult to determine their actual behavior of the brightscript compiler. For sure if you go beyond 256 labels it will always fail (they obviously have some instruction that uses a 1 byte label address or something). However, it also appears like there is some optimization or something they are running that can inadvertently create more labels. I wasn’t able to reverse this behavior and figure out exactly why, hence the soft warning limit of 128 (I found that programs that kept below 128 generally always compiled in BrightScript). I wish I could provide a better answer but only Roku can :/ |
|
Whoops didn’t mean to close |
|
Either way it looks like Roku is not going to do anything about it. https://community.roku.com/t5/Roku-Developer-Program/Label-limit-count-goto-label/m-p/853744 |
|
I just wanted to mention something that I had some success with was changing optimizations. Some wasm optimizations end up producing a lot of labels for brightscript code, you can try adjusting the optimization level to see if it helps. I ran into this constantly when trying to compile any of the different JavaScript implementations into BrightScript (even the Rust one). The huge instruction switch statement in every JS implementation always causes this problem. |
|
Interesting! I'll give it a shot! (although, I don't know if it will help in the case of very large functions) Edit: For that particular function, optimization brought the label count down from 678 to 317. It helps, but not good enough |
|
At this point I'm wondering if it would be better to wasm2brs some form of a tiny WASM runtime, and then use that to load the actual wasm we need... but I'm not sure if it's doable or the performance will be good enough or not |
|
If you have any interest in extending wasm2brs, I could easily see a mode that if the number of labels exceeds a certain amount, that entire function switches to being interpreted WASM. That way entire program doesn’t have to be interpreted (can get speed benefits in some areas). Basically the wasm2brs runtime ships with a compiled Wasm interpreter. |
|
That sounds like it can get pretty complicated, with how to potentially get the interpreted wasm and AOT wasm to play nice together, or share memory. I'll try to test the wasm runtime when I have some time (it could be added as a sample I guess) then we'll explore from there |
|
I put wasm3-wasi.wasm in there, and tried running it with To my surprise, it prints fine Which is a very good sign. Then I tried to add this test file (like the docs) with this Then it prints absolutely nothing, while locally it should print something like I'm not sure if wasm3 can't read the file, or if it's the test wasm that's not printing ======= I see that |
|
Update: Using #8 I got wasm to start running a simple test file. I got hit with a stack overflow. |
|
Bravo on getting it running, but I think you're hitting the exact same thing that burned me out on trying to work on Roku as a platform. And to answer I think that depends on if the WASM interpreter uses the stack for invoking function calls. I've seen different approaches for byte code interpreters where when the call is internally (from a byte code function to another byte code function) they use a heap allocated "stack" rather than making an actual function call. This at least prevents interpreters from being bound by the actual host stack size (somewhat). It may be that a WASM interpreter exists out there that has this property, but I don't know the implementation details of each. But to be honest if it's not the stack overflow, you may hit the label limit with another WASM interpreter especially if it uses the common giant switch for bytecode. I really wish BrightScript limitations were just a bit higher. As for the point of sharing WASM memory with an interpreter, I think that's very possible (not complicated), and if you get to that point ever I can certainly help. |
|
Just to add my research here: Without actually debugging (just reading code) this appears to be where the recursive call happens. Given they have a "ReportNativeStackUsage" call directly below it, I think it pretty heavily implies they hit this similar limit in other host environments: Moreover from https://github.com/wasm3/wasm3/blob/main/docs/Interpreter.md
|
|
Thanks a lot for the detailed response! What you did in this repo is really impressive work, it's sad that it never reached its full potential because of these limitations (limitations that should belong to languages from 40 years ago, not something we use in 2023). I shared my sentiment with Roku at least, maybe they'll do something about it someday. The answer might be a search for another wasm runtime. But at the same time, I doubt there will be a system designed with such constraints in mind (I mean, I got a stack overflow with a hello world wasm, stacktrace shows 55 levels...). As you said, it's going to be either the stack of label limit. Given everything, maybe I'll try another wasm runtime someday, even if it was a long shot |
|
I'm trying to dig further, so I tried asking here if there was a way for wasm-opt to reduce label count (like auto-split functions) Someone suggested that wasm3 has configurable stacksize, so I set it to a very small number, but I still get an overflow unfortunately... |
|
I was able to build wasm-interp (WebAssembly/wabt#2157 (comment))
But then Another dead end unfortunately |
I've been trying to bring label count to under 256, and but I still have a few between 128 and 256.
Even though all functions are below the hard limit, I'm still hitting the
Label/Line Not Found. (compile error &h0e)kind of error.Is 128 actually a hard limit?
The text was updated successfully, but these errors were encountered: