Miguel de Icaza Talks Up WebAssembly Greatness

[bug77]

You're assuming that people don't block Javascript.

I don't assume anything, I'm running NoScript as I type. If anything, you're assuming WASM will not be blockable in the same manner.

Regardless, I believe it is actually different.

I know you believe that, but you are wrong. I was asking why, hoping I could address your concerns.

[cjcox]

I don't assume anything, I'm running NoScript as I type. If anything, you're assuming WASM will not be blockable in the same manner.

Is NoScript blocking (allowing control) right now? WASM is live ... now....

I know you believe that, but you are wrong. I was asking why, hoping I could address your concerns.

Uh... why am I wrong? So, you have total control over WASM right now? What runs, what doesn't run? Full source?

Don't be belligerent just because...

[cynical]

So if it's a primitive type it's loaded on the stack, if it's a class type it's loaded on the heap.

The JVM can turn heap allocations into stack allocations for the simple cases where it is actually possible.

Everything else... Doesn't have this problem. In .NET everything is an Object and it's generics are also more intelligently designed

Java didn’t have the luxury of breaking backwards compatibility and forcing everyone to rewrite their software. They are looking at possible solutions that are less disruptive. Some of that is coming in Java 14/15.

[bug77]

Is NoScript blocking (allowing control) right now? WASM is live ... now....

I don't know whether you can block WASM directly, but WASM is always bootstrapped/called from JS. Block JS and WASM goes away as well.

Uh... why am I wrong? So, you have total control over WASM right now? What runs, what doesn't run? Full source?
Don't be belligerent just because...

You have exactly the same level of control as you have for JS.

[Luke_Wolf]

The JVM can turn heap allocations into stack allocations for the simple cases where it is actually possible.

It's cute of you to say that, but there's a reason that JVM programs are uniquely memory heavy, and that reason has nothing in particular to do with the underlying architecture of say a Java vs a C# application. In fact most of the broad strokes of how they're written are going to be the exact same, it is more in the fine strokes where they differ, and therefore an average C# and Java program should be using a similar amount of memory. Well they for all intents and purposes are (with the caveat mentioned in my previous post), the difference is that in the real world Java is throwing everything on the heap and you're at the mercy of the Garbage Collector whereas .NET handles about as much as a program written in other languages on the stack, and so the automatic memory management of the stack limits the impact on the memory overhead of the program.

Java didn’t have the luxury of breaking backwards compatibility and forcing everyone to rewrite their software. They are looking at possible solutions that are less disruptive. Some of that is coming in Java 14/15.

Java like every Sun Microsystems products other than Solaris didn't have the luxury of skilled developers, and even then that was mostly Bill Joy. They were almost as bad as Adobe. Sun Microsystems could have very easily have resolved the issue without forcing everyone to rewrite their software, a simple recompile with the artificial delineation between primitive types and Object derivatives being removed from the JVM ByteCode would have been enough, to be quite clear there's nothing in Java's fundamental language design that says primitive types can't be Objects and participate in generics. However there's plenty wrong with the type system that the Java Virtual Machine Bytecode implements, and merely gutting the JVM (and its bytecode) from the language, and reimplementing the language ontop of CIL (Common Intermediate Language, .NET's version of Bytecode) would allow for immediate fixing of the generics system, with no changes required in client software... simply a recompile. It's really not a language layer but an implementation (Or rather in this case an Intermediate Language) layer problem.

[mgiammarco]

Simply speaking,
De Icaza is a Microsoft fanboy and (secretly) evangelist.
Some years ago pushed mono to try to persuade opensource developers to use Microsoft tools and he get promoted in Xamarin.
Now Microsoft has a big problem: has lost control of web developing.
Web developers use opensource technologies and not microsoft ones. Also there are so many legacy third party Windows applications that must be ported on web.
The solutions is to push developers to use Blazor which is based on WebAssembly so C# developers can be recycled in building web applications and Microsoft can take again control of the developers' world.
So De Icaza again wears the evangelist hat and starts pushing WebAssembly.

[kpedersen]

there's a reason that JVM programs are uniquely memory heavy, and that reason has nothing in particular to do with the underlying architecture of say a Java vs a C# application..

Java and .NET *are* the same technologies based on the ancient Alef, Limbo design from the Plan 9 days. They have the same problems and "solutions".

Check out escape analysis for Java using stack memory
https://en.wikipedia.org/wiki/Escape...#Example_(Java)

You can "box" data in VB.NET (and its sibling, Csharp.NET) but ultimately it is up to the VM processing the Bytecode to try to do the right thing. Just like the JVM.

[bug77]

Luke_Wolf I'm confused, are you saying throwing 1MB of data onto the stack uses less RAM than throwing the same amount on the heap?

[cynical]

It's cute of you to say that, but there's a reason that JVM programs are uniquely memory heavy, and that reason has nothing in particular to do with the underlying architecture of say a Java vs a C# application. In fact most of the broad strokes of how they're written are going to be the exact same, it is more in the fine strokes where they differ, and therefore an average C# and Java program should be using a similar amount of memory. Well they for all intents and purposes are (with the caveat mentioned in my previous post), the difference is that in the real world Java is throwing everything on the heap and you're at the mercy of the Garbage Collector whereas .NET handles about as much as a program written in other languages on the stack, and so the automatic memory management of the stack limits the impact on the memory overhead of the program.

No, Java is not throwing everything on the heap. That's what would happen if you had no optimizations at all (scalar replacement, escape analysis), but thankfully the JVM does do them in many cases. Also, you have to box value types in C# as well when doing anything interesting with them, and I'm not aware of C# applications being particularly memory efficient compared to Java, so this is all kind of academic stuff.

(besides, the main benefit here would not be a reduction in overall memory usage, it would be increased performance from reduced object allocations and GC pressure, which is something that counts as an advantage C# has over Java for now)

They were almost as bad as Adobe. Sun Microsystems could have very easily have resolved the issue without forcing everyone to rewrite their software, a simple recompile with the artificial delineation between primitive types and Object derivatives being removed from the JVM ByteCode would have been enough, to be quite clear there's nothing in Java's fundamental language design that says primitive types can't be Objects and participate in generics.

Changing the bytecode specification is a big deal... it's also completely unnecessary. They are implementing value types and generic specialization in what they call Project Valhalla.

[Luke_Wolf]

No, Java is not throwing everything on the heap. That's what would happen if you had no optimizations at all (scalar replacement, escape analysis), but thankfully the JVM does do them in many cases. Also, you have to box value types in C# as well when doing anything interesting with them, and I'm not aware of C# applications being particularly memory efficient compared to Java, so this is all kind of academic stuff.

(besides, the main benefit here would not be a reduction in overall memory usage, it would be increased performance from reduced object allocations and GC pressure, which is something that counts as an advantage C# has over Java for now)

Real world C# programs are vastly more memory efficient than Java programs, they are within the same order as similar C++ programs. Toy C++ programs that don't require automatic memory management schemes like parent child hierarchies can still be more efficient but that's the difference we're talking about here. I made a post about this years ago where I compared the memory usage of comparable real world C++ and C# programs, and some Java programs thrown in for comparison if you want to look back through my history. If you want a simple comparison check out the memory usage of Monodevelop vs KDevelop or QtCreator vs your Java based IDE of choice with a decent sized project loaded.

Changing the bytecode specification is a big deal... it's also completely unnecessary. They are implementing value types and generic specialization in what they call Project Valhalla.

Good luck with that. Project Valhalla is trying to work around the problem rather than actually solve it.