31–40 of 179 posts
Just in case those who prefer not to allow Java need this, here's some info about disabling WASM in various browsers. https://github.com/stevespringett/disable-webassembly
I was hoping to see an AOT - but they say that currently it is just interpreter + JIT. This is beneficial for compatibility but counterproductive for speed. Nevertheless, an interesting project.
Do any of the native AOT implementations outperform the best JITs? I remember trying bcc’s Java compiler years ago, and it was significantly slower than standard JITted Java, but maybe better systems exist.
I'd personally always bet on AOT performance to beat JIT - to convince me otherwise is what I would require evidence for.
On the flip side, is there a JVM-based Wasm interpreter? JNI is great and all, but I love the thought of compiling native code to WASM to provide a single package for all plaform without extra redundant packages.
Yes, and it will JIT compile the code to native if you're using GraalVM: https://github.com/oracle/graal/tree/master/wasm But the point of JNI is to provide language bindings. WASM doesn't automatically fix the need for those.
True. I was imprecise. I'm fine with needing the language bindings / JNI. My main beef is with the platform specific native binaries that JNI binds too, and the complications (size or platform targeting) that they introduce to the build and distribution process.
All we need now is to run ActiveX. I think BottledWine can run Windows executables in the browser, how hard would it be to simulate the ActiveX bindings?
Just in case those who prefer not to allow Java need this, here's some info about disabling WASM in various browsers. https://github.com/stevespringett/disable-webassembly
Might be worth mentioning that Java applets could call into native DLLs (which was a major security risk), while there's no way to do the same from WASM.
Java in the browser! There is nothing new under the sun.
Just in case those who prefer not to allow Java need this, here's some info about disabling WASM in various browsers. https://github.com/stevespringett/disable-webassembly
I feel like the original primary reasons (security?) for doing so don't exist to the same degree for WASM-compiled Java.
Earlier quoted context omitted.
Do any of the native AOT implementations outperform the best JITs? I remember trying bcc’s Java compiler years ago, and it was significantly slower than standard JITted Java, but maybe better systems exist.
Considering the time-limit of JIT compilation, I'd say almost certainly yes. AOT can analyze code basically forever (ask C++ compilers), so there's a whole class of time-intensive optimizations that JIT simply cannot do. I'd personally always bet on AOT performance to beat JIT - to convince me otherwise is what I would require evidence for.
As a counter-point to your argument, consider a highly dynamic language such as JavaScript, in particular the '+' operator. An AOT compiler would have no choice but dispatch to a generic heavy implementation that could handle any possible combination of inputs. On the other hand a JIT compiler can observe the runtime values used and specialize using Inline Caches, potentially down to just a few instructions.
Earlier quoted context omitted.
Yes, and it will JIT compile the code to native if you're using GraalVM: https://github.com/oracle/graal/tree/master/wasm But the point of JNI is to provide language bindings. WASM doesn't automatically fix the need for those.
> But the point of JNI is to provide language bindings. WASM doesn't automatically fix the need for those. True. I was imprecise. I'm fine with needing the language bindings / JNI. My main beef is with the platform specific native binaries that JNI binds too, and the complications (size or platform targeting) that they introduce to the build and distribution process.
And then you also have the problem that WASM/WASI is basically a new OS which is incompatible with every other, so it requires ports.
On the other hand, if you had something like ELF, PE or Mach-O but designed for cross-platform distribution and which had a nice and convenient cross-building toolchain and a portable dynamic linker, then it'd be a lot easier to compile and distribute once but use on every OS. Sort of like MachO fat binaries but more fine grained and not Apple specific.
Graal also has some sort of capacity for that in the way it can execute LLVM bitcode. You can do it either inside a sandbox that looks like a virtualized Linux (syscalls are recompiled into upcalls into the JVM), or it can be allowed to access native code. There is a toolchain that you simply point your PATH at and it produces the necessary files. But, it's not well known, LLVM bitcode still requires JIT compilation before it can execute on the CPU, and the toolchain doesn't really cross-compile in the way I mean above. Plus bitcode isn't a stable format.
This is pretty awesome technically. Java everywhere without a JVM install. What's its footprint?
Yeah it's not really JVM. The thing with these kinds of ports is that they do some 'neat stuff' but ultimately, they don't come close to the real thing, often, not close enough to be a material substitute. The JVM is a very sophisticated and nuanced thing, 'duplicating it' and the standard libs is a very big deal. Theses are cool projects though and they have their use.
From the link:
"CheerpJ is based on an unmodified OpenJDK environment, guaranteeing the same behavior on the browser compared to a native JVM. It includes many emulation layers to ensure Filesystem, Networking, Printing, Clipboard and many other subsystems work seamlessly."
Did you actually manage to find anything that works in OpenJDK but not in CherpJ 3.0?