Andreas Woess

Suggested fix: https://github.com/oracle/graal/pull/8908. Let me know if you want to test this before merging @JaroslavTulach.

ok, so I assume this does not need to be backported, since you can use the latest version on LTS JDK. good.

Unfortunately, there's not enough information in this stack trace to figure out what's going on. It would be great if you could try with the latest GraalVM release to see...

I believe this issue has been fixed in 23.1 (or 23.0?) already. As of 24.0, WebAssembly support is enabled by default, too, so the env vars above should not be...

WebAssembly should work out-of-the-box in GraalNodeJS now, i.e. since 24.0.0. I can confirm that `npx python-wasm@latest` now works, albeit it's very slow to start as you've noticed. We should investigate...

I've looked into why it's so slow and found 2 performance issues in the JS↔WASM interface, fixed in https://github.com/oracle/graaljs/commit/edbfa8e109dddfe460e46bb0afe5497946b162ed. It should start up much faster now, within seconds not minutes.

I can't comment on this without a runnable reproducer that demonstrates the performance problem. So my only advice would be to ensure that compiled code can be cached between runs,...

As of 24.x, WebAssembly is enabled by default in Node now, so it should not be necessary to use these options anymore. I think in the graalnodejs-community-jvm standalone, both `--vm.cp`...

@JaroslavTulach thanks for confirming! I like simple fixes like this one. :)

Thanks for the report. The problem is that our Polyglot function proxies only consider the generic return type of the declared method in the proxied interface but not the generic...