3 ms·

My somewhat grumpy answer would be that web people almost never do their homework. They are infamous for reimplementing things worse that were well available d

by kaba0 3y ago

My somewhat grumpy answer would be that web people almost never do their homework. They are infamous for reimplementing things worse that were well available decades ago.

0x445442 3y ago
You beat me to it. I thought we covered this ground 20 years ago.
- treis 3y ago
  And rejected it because it was a nightmare of security issues and poor performance. The idea isn't bad. The implementation was.
pie_flavor 3y ago
All the problems with the JVM have been written up to death, and many are easily inferable from surface-level background knowledge. If you don't know them, who's not doing their homework?
- kaba0 3y ago
  The only problem with the JVM were politics. Safety? Should have been whitelisting, nothing inherent with the JVM. Performance? We had shitty hardware back then, the improvements there alone would have solved the issue (see: we use Javascript), but especially today, the JVM is more than fast enough for most workloads.
  - pie_flavor 3y ago
    Fundamentally object-oriented, fundamentally garbage-collected, carries around a massive stdlib that's tightly integrated with precise functioning of the VM. And no, the performance concerns do not reduce to 'hardware'; the point is to eke out more performance than a high-level object-oriented garbage-collected system can muster. V8 is already on par with the JVM; if the JVM's performance was good enough for you, you'd just use JS.
    - kaba0 3y ago
      > Fundamentally object-oriented, fundamentally garbage-collected And? No one said that the performance concerns reduce to hardware — but at the Java Applets days it was most definitely the primary reason for their slowness. Since then, with the improvements of JITs, it became very fast. > than a high-level object-oriented garbage-collected system can muster That’s not a well-defined performance level and the ceiling changes each year. And V8 has no real parallelism, so for many kind of workloads they are not drop-in replacements.
basique 3y ago
The JVM can't really be properly sandboxed, though. Even the JDK developers have stopped trying and deprecated SecurityManager. On the other hand, WASM is specifically designed to not really be able to do anything fancy unless you give it functions that actually do something externally. Besides, how would you even properly run C code on the JVM?
- kaba0 3y ago
  > The JVM can't really be properly sandboxed What happened is that people realized that blacklisting does not work. Whitelisting is the correct approach. There is absolutely zero reason why WASM would be better for that over the JVM — the JVM spec in itself has no visible side effect, not even printing, so it can’t do anything nefarious (besides cpu vulnerabilities, but that also apply to WASM). And you would run C code in a completely trivial way: you have a huge array which is your memory, and you read/write bytes to it.
  - basique 3y ago
    > Whitelisting is the correct approach. Isn't most of the point of using the JVM thrown out if you have a limited standard library? > And you would run C code in a completely trivial way: you have a huge array which is your memory, and you read/write bytes to it. That sounds like it would have terrible performance. Would every read of an int have to manually build it from the 4 bytes it's made of? This just seems like something the JVM won't handle that well. Besides, this would mean that if you want to run a language like C#, which has references and value types (and you can make a reference to a value type from a pointer into a buffer), you would have to emulate them, which will hamper performance, or just use the same strategy as you used for C.
    - kaba0 3y ago
      > That sounds like it would have terrible performance. Would every read of an int have to manually build it from the 4 bytes it's made of? No, a method can have a native implementation, or a compiler intrinsic. Java has ByteBuffers (https://download.java.net/java/early_access/panama/docs/api/java.base/java/nio/ByteBuffer.html https://download.java.net/java/early_access/panama/docs/api/... ), and they have put/get{Long,Short,etc}, that will map to either a native single pointer read with the given size, or even optimize to a more efficient read inside the context of a bigger method, say vectorize them inside a loop (as the compiler knows about this method and can handle it specifically). > Besides, this would mean that if you want to run a language like C#, which has references and value types (and you can make a reference to a value type from a pointer into a buffer), you would have to emulate them, which will hamper performance, or just use the same strategy as you used for C So we are back at where WASM is? Though I think that there is nothing inherently impossible about mapping C# to more efficient Java primitives, especially that value types are the more constrained semantics, each instance being different is semantically the same, just less optimal. A pointer to a region of the aforementioned ByteBuffer with a special memoryToCSharpObject() that has some compiler intrinsics wouldn't perform too bad, I believe.

by kaba0 3y ago

My somewhat grumpy answer would be that web people almost never do their homework. They are infamous for reimplementing things worse that were well available decades ago.

0x445442 3y ago

You beat me to it. I thought we covered this ground 20 years ago.

treis 3y ago
And rejected it because it was a nightmare of security issues and poor performance. The idea isn't bad. The implementation was.

pie_flavor 3y ago

All the problems with the JVM have been written up to death, and many are easily inferable from surface-level background knowledge. If you don't know them, who's not doing their homework?

kaba0 3y ago
The only problem with the JVM were politics. Safety? Should have been whitelisting, nothing inherent with the JVM. Performance? We had shitty hardware back then, the improvements there alone would have solved the issue (see: we use Javascript), but especially today, the JVM is more than fast enough for most workloads.
- pie_flavor 3y ago
  Fundamentally object-oriented, fundamentally garbage-collected, carries around a massive stdlib that's tightly integrated with precise functioning of the VM. And no, the performance concerns do not reduce to 'hardware'; the point is to eke out more performance than a high-level object-oriented garbage-collected system can muster. V8 is already on par with the JVM; if the JVM's performance was good enough for you, you'd just use JS.
  - kaba0 3y ago
    > Fundamentally object-oriented, fundamentally garbage-collected And? No one said that the performance concerns reduce to hardware — but at the Java Applets days it was most definitely the primary reason for their slowness. Since then, with the improvements of JITs, it became very fast. > than a high-level object-oriented garbage-collected system can muster That’s not a well-defined performance level and the ceiling changes each year. And V8 has no real parallelism, so for many kind of workloads they are not drop-in replacements.

basique 3y ago

The JVM can't really be properly sandboxed, though. Even the JDK developers have stopped trying and deprecated SecurityManager. On the other hand, WASM is specifically designed to not really be able to do anything fancy unless you give it functions that actually do something externally. Besides, how would you even properly run C code on the JVM?

kaba0 3y ago
> The JVM can't really be properly sandboxed What happened is that people realized that blacklisting does not work. Whitelisting is the correct approach. There is absolutely zero reason why WASM would be better for that over the JVM — the JVM spec in itself has no visible side effect, not even printing, so it can’t do anything nefarious (besides cpu vulnerabilities, but that also apply to WASM). And you would run C code in a completely trivial way: you have a huge array which is your memory, and you read/write bytes to it.
- basique 3y ago
  > Whitelisting is the correct approach. Isn't most of the point of using the JVM thrown out if you have a limited standard library? > And you would run C code in a completely trivial way: you have a huge array which is your memory, and you read/write bytes to it. That sounds like it would have terrible performance. Would every read of an int have to manually build it from the 4 bytes it's made of? This just seems like something the JVM won't handle that well. Besides, this would mean that if you want to run a language like C#, which has references and value types (and you can make a reference to a value type from a pointer into a buffer), you would have to emulate them, which will hamper performance, or just use the same strategy as you used for C.
  - kaba0 3y ago
    > That sounds like it would have terrible performance. Would every read of an int have to manually build it from the 4 bytes it's made of? No, a method can have a native implementation, or a compiler intrinsic. Java has ByteBuffers (https://download.java.net/java/early_access/panama/docs/api/java.base/java/nio/ByteBuffer.html https://download.java.net/java/early_access/panama/docs/api/... ), and they have put/get{Long,Short,etc}, that will map to either a native single pointer read with the given size, or even optimize to a more efficient read inside the context of a bigger method, say vectorize them inside a loop (as the compiler knows about this method and can handle it specifically). > Besides, this would mean that if you want to run a language like C#, which has references and value types (and you can make a reference to a value type from a pointer into a buffer), you would have to emulate them, which will hamper performance, or just use the same strategy as you used for C So we are back at where WASM is? Though I think that there is nothing inherently impossible about mapping C# to more efficient Java primitives, especially that value types are the more constrained semantics, each instance being different is semantically the same, just less optimal. A pointer to a region of the aforementioned ByteBuffer with a special memoryToCSharpObject() that has some compiler intrinsics wouldn't perform too bad, I believe.