3 ms·
> What one wants is a .class to WASM converter and there already a couple of them to choose from, namely TeaVM and CheerpJ as the most advanced ones Do they pr
by chrisseaton 4y ago
> What one wants is a .class to WASM converter and there already a couple of them to choose from, namely TeaVM and CheerpJ as the most advanced ones
Do they provide the kind of best-in-class whole-world-analysis optimisations that Graal does?
But we should take a look at what they produce some time!
I think in practicality Graal's LLVM output is not terribly platform agnostic, as LLVM lacks some expressiveness for the thing that Graal needs to do for deoptimisation.
- pjmlp 4y agoThat task is taken over by browser JIT engines, hence I still don't get why Graal should be generating WASM bytecodes to start with. Naturally consuming them as yet another WASM runtime makes sense, but that isn't what OP was asking about.
- chrisseaton 4y ago> That task is taken over by browser JIT engines But you can't apply high-level optimisations by the time all you have is WASM bytecode and all your high-level structure is gone. You also don't have enough time to apply these optimisations if you're JIT compiling.
- pjmlp 4y agoI see that as the role of a Java compiler, or the bytecode converter. Maybe if we were talking about SubstrateVM, but even then, I don't get why that should be something to increase its code complexity of backends.
- chrisseaton 4y ago> Maybe if we were talking about SubstrateVM Yeah that's what I was talking about. > I don't get why that should be something to increase its code complexity of backends Backends are pretty well-isolated parts of the code. You can see how simple the LLVM one is for example.