I guess i don't understand the push to wasm. Why not just embed hotspot, or a branch of it. Is there any difference?
Or going the other way, could hotspot be replaced with a wasm jit by compiling java to wasm? I know they have slightly different memory models, but I don't understand why they seem to be treated so separately.
Why Hotspot? There are many bytecode languages, with their own execution environments - .NET/CLR, Parrot, BEAM, etc. wasm is an attempt to design one specifically for the web, rather than trying to shoehorn one made for a different environment.
HotSpots optimization and code generation is far superior than any other VM.
But that is kind of my point - there are advanced vms out there. I don't see why the web needs its own vm apart from them. All the differences I see are fairly minimal.
But the bytecode and stdlib it works with are the least suitable. I could go on for a long time about JVM insns and the class model and GC assumptions that make it bad for the web. Similarly, I could go on forever about the stdlib that supports this bytecode (strings, threads, class loaders, etc) and why it's bad for the web too.
I'm not sure that JVM allows for streaming code, its centred around class-loading and classes in general. Shipping in fragments of code will require quite an overhaul of that entire architecture. Lambdas and other constructs were added much later via JSR-292 and invokedynamic, streaming stuff in will require quite a bit of shoehorning.
Streaming in this case means that you can start generating (or even executing) code before you have complete input. There are some mostly ignorable reasons (having to do with bytecode verification) why you should not stream-JIT Java bytecode. On the other hand in the whole ecosystem you will not gain anything wothwhile given the fact that you need the JVM state to be essentially complete before you start executing anything and on slightly lower-level the .class file format is designed to be compact and not meaningfully streamable.
Hotspot and wasm are both stack languages. All the other differences seem to be rather small (you could change or ditch the security model fairly easily), and wasm needs some bytecode verification too.
wasm is not a browser plugin, it is part of the browser. That means the plugin architechture does not need to exist (which has already been removed by all major browsers). Building wasm support into browsers was not an easy task, and "just embed hotspot" is not any easier.
This was tried (search for "LiveConnect"). It failed for many reasons, but the one that's most relevant to today is probably that most interesting client-side stuff (that isn't already written in JS) is written in C and C++, not a JVM language.
If that is why out failed, then wouldn't wasm fail for the same reason?
It looks like LiveConnect was a much bigger thing that MS pushed.
I'm not really understanding how this means anything. Why not just compile js et al to java bytecode? Or is wasm just another NIH protect in a long list of them in the JavaScript world? That is what it is looking like.
Sure hotspot itself couldn't be used straight up, but the changes are certainly much less than creating a whole new vm.
> If that is why out failed, then wouldn't wasm fail for the same reason?
Web Assembly targets C and C++ as source languages, unlike the JVM.
> Why not just compile js et al to java bytecode?
Because JS and Java semantics are different, and emulating JS semantics on top of the JVM is slow.
> Sure hotspot itself couldn't be used straight up, but the changes are certainly much less than creating a whole new vm.
The Web Assembly VM shares as much code as possible with the engine's JS VM. This is obviously better than using HotSpot, as the relevant code is already shipping in browsers.
Nobody is going around rewriting code for no reason.
> Web Assembly targets C and C++ as source languages, unlike the JVM.
So wasm (and hence JavaScript if you translating js into wasm) are closer c/c++ than to java? Considering all the UB in C, this cannot possibly be true.
> Because JS and Java semantics are different, and emulating JS semantics on top of the JVM is slow.
Given javas JavaScript implementation is pretty comparable, not very big, and even written in java, this also doesn't seem to be true at all.
Once you add gc into wasm, it is almost guaranteed to be closer to java than c/c++.
Yes. For example, Web Assembly has unsigned integer arithmetic and explicit memory allocation/deallocation, neither of which the JVM has.
> Considering all the UB in C, this cannot possibly be true.
Undefined behavior is a concern of the compiler of the source language. Web Assembly doesn't compile C or C++. It simply interprets a VM, the semantics of which are designed to be relatively free of undefined behavior.
> Given javas JavaScript implementation is pretty comparable, not very big, and even written in java, this also doesn't seem to be true at all.
I would highly doubt it's performance competitive at the level that browsers are at now. It strikes me as likely impossible to get performance competitive on, say, SunSpider if you aren't highly tuned for it.
Nashorn is anywhere to faster on primitive heavy computation to 50% slower post JIT. Graal is supposed to be even faster.
> Web Assembly has unsigned integer arithmetic
This is your idea of a major difference that affects implementation so much that is separate VM needs to be written? Many Java programs already do essentially manual memory management already too. Those aren't the big differences. Things like safe-memory access are bigger issues. And once wasm gets gc, it will even be closer to Java and JS.
I hope Graal outperforms everything else, so we can stop pretending like WASM is something different than what Java has been trying to do.
Or going the other way, could hotspot be replaced with a wasm jit by compiling java to wasm? I know they have slightly different memory models, but I don't understand why they seem to be treated so separately.