WebAssembly for the Java Geek

https://www.javaadvent.com/2022/12/webassembly-for-the-java-geek.html

by ingve • 4 years ago

162 87 4 years ago

stevefan19992• 4 years ago

also take a look in .NET counterpart: https://dev.to/azure/exploring-net-webassembly-with-wasi-and...

singularity20012• 4 years ago

This seems a bit outdated. There was a recent blog post by intellij Raider that showed that you can just compile to wasm by adding the wasi nuget package, no extra steps required.

stevefan19992• 4 years ago

It's JetBrains Rider not Raider...Plus the blog post I posted also talked about the out of the box experience with just installing one Wasi.Sharp package to get WASI WebAssembly support out of the box for most scenarios...except it is still too big to put into Cloudflare workers because it contains the entire Mono runtime...

evacchi4• 4 years ago

huh, author here, I didn't expect this to be on HN please don't roast me too much :P

lifthrasiir• 4 years ago

Not sure why, but some links in the article seem to be missing, for example one to the draft GC spec for WebAssembly (which should probably link to https://github.com/WebAssembly/gc).

evacchi4• 4 years ago

you are right, I spotted a couple more links being broken. They should be fixed now. Thanks!

ridruejo2• 4 years ago

It is actually a pretty good article and I learnt quite a bit. Thanks for taking the time to write it. The only two things I would add are that, unlike Java, the industry has rallied unanimously behind it (in the 90s it was Java vs .NET and Applets vs ActiveX, etc.) and the big difference that Wasm comes pre-integrated in the browser, has a focus on security and is a proper W3C standard. Everything else that came before it felt like some after-the-fact bolt-on (Flash, Applets, etc.) and had big security issues and often got out of sync with browser releases

evacchi4• 4 years ago

thanks! some of those consideration I made in the article I linked at the beginning of this post: "A History of WebAssembly" https://evacchi.github.io/posts/2022/11/23/a-history-of-weba...

kaba09• 4 years ago

I mean, Applets are just really old, security itself wasn’t considered all that “important” at the time. There is no real difference on a purely runtime level between wasm and the JVM to make one safer than the other. And regarding release strategy, that’s just politics.

rowls66• 4 years ago

There was no .NET in the 90's. It was Java vs. ActiveX vs. Flash. I agree that Java support in browsers was never as good as it could have been. Sun never had direct control over a mainstream browser, and the companies that did each had other technologies that they preferred (Microsoft - ActiveX, Netscape - Javascript).

bullen19• 4 years ago

I'm considering building a Java compatible VM that only has static memory allocation to avoid GC.

Why hasn't this been done by anyone yet?

Also confused why this does not have a binary windows release yet: https://github.com/bytecodealliance/wasm-micro-runtime

Edit: Epsilon is not the answer here you can stop mentioning that.

beardyw• 4 years ago

Not sure how that would play out. Just not running the GC is an unsatisfactory answer. Otherwise what?

bullen19• 4 years ago

Basically you enforce static heap allocation. Meaning you cannot type new in a method only in the class definition. I don't even know if this can be enforced from the bytecode VM... just playing with it in my head.

karussell• 4 years ago

Isn't this already possible with -XX:+UseEpsilonGC? (disables the GC) And then you manage memory manually in big (primitive) arrays.

bzzzt3• 4 years ago

Beat me to this answer ;) - I presume you can just allocate objects but you have to keep those allocations in check to prevent the JVM from terminating when going out of memory.

Maybe object pooling (which helped performance in old JVM's in the 90s) will make a comeback? ;)

bzzzt3• 4 years ago

Because there's no need? There the 'epsilon' no-op GC in OpenJDK: https://openjdk.org/jeps/318

If you keep your object allocation in check you can use this to guarantee no GC pauses.

bullen19• 4 years ago

Yes, but then you are downloading and running executables that contain the GC.

lmm2• 4 years ago

Why hasn't this been done by anyone yet?

What would be the point? Java programs assume GC (or at least, they assume they can allocate memory and not worry about when it will be freed). If you don't have GC then you're not going to be compatible with extant Java programs, so what's the point in trying to be "Java compatible" at all?

singularity20012• 4 years ago

Java programs assume GC

only users of long running programs assume GC, the program itself doesnt care.

bullen19• 4 years ago

Because 1) you don't want GC pauses 2) you don't want GC code to bloat the VM 3) You don't want memory leaks 4) You don't want people to not know what they are allocating 5) Static allocation is enough to make anything.

6) int arrays do not have cache misses (but you might need to pad them to avoid cache invalidation) 7) parallel atomic multicore works on int arrays out of the box!

kasperni• 4 years ago

From another comment > Meaning you cannot type new in a method only in the class definition.

How would you handle the ~ 1000 java.x classes that even a minimal HelloWorld programs uses. There are plenty of random allocation.

bullen19• 4 years ago

I'm not writing thus for old code, I'm writing it for new code. Specifically 3D action MMO scripting.

pron2• 4 years ago

Why hasn't this been done by anyone yet?

That depends what you mean by "this." The Java spec requires you to support `new A()` by returning a fresh object or throwing a VMError (like OutOfMemoryError). If by "this" you mean that allocations would succeed until some fixed amount of memory is exhausted, then, as others have pointed out, this has been done even in OpenJDK. If by "this" you mean that the allocation of some particular set of objects -- say, only those allocated during class initialisation -- would succeed regardless of memory consumption and all others would fail with an OutOfMemoryError, then I guess that it hasn't been done in that particular way because people haven't found it particularly useful as most Java programs would fail, but you can give it a try.

RTSJ, the specification for hard-realtime Java [1][2], actually goes further than that and supports both "static" memory (ImmortalMemory) and arenas (ScopedMemory). So if that's what you mean, then it has been done.

[1] https://www.rtsj.org/specjavadoc/book_index.html

[2] https://www.aicas.com/download/rtsj/rtsj_76.pdf

imhoguy• 4 years ago

You can check Java Card to see how GC-less low memory programing was sorted out there. https://en.m.wikipedia.org/wiki/Java_Card

marginalia_nu2• 4 years ago

Why do you want to avoid GC?

bullen19• 4 years ago

See above.

tryfinally• 4 years ago

Not many people are motivated to take optimization this far in the Java world.

On the .NET side, the language is more suitable because you can define your own value types (coming soon in Java AFAIK), and there is a lot of people using C# for game dev which is a big use case for GC optimization.

Unity has been integrating unmanaged allocators in their engine, which lets developers skip the GC much more easily (without having to manually preallocate and reuse memory, which isn’t anyone’s favorite workflow, and doesn’t save you much compared to a fast native allocator). I’ve also seen a couple of roughly equivalent projects, eg. Smmalloc-CSharp, github.com/alaisi/nalloc.

grashalm• 4 years ago

Nobody did that because java is a safe language by design. Manual allocation would make it an unsafe language. For the vast majority of applications correctness wins over performance.

Short lived objects are extremely cheap on the JVM with the right GC. Almost stack allocation cheap. So if you write code that avoids too many long lived objects there is almost no overhead to a GC.

For long lived objects GC based compaction can give you even some performance advantage over manual allocation due to better memory locality. But that heavily depends on the application of course.

In my experience people blame the GC way too early. Most often the application is just poorly written and some small tweaks can fix gc spikes.

wtetzner2• 4 years ago

At that point, why even use Java?

bullen19• 4 years ago

See my other answers...

jffhn• 4 years ago

Why hasn't this been done by anyone yet?

I used to do Java apps which didn't allocate memory in the long run, and so did some banks for high frequency trading, by reusing objects on the spot or using pools for objects with a life cycle. It imposes some programming style/patterns, in particular for APIs design, but it's perfectly doable, so I guess people prefer to just do that. In what context that wouldn't be enough? For proof?

torginus• 4 years ago

Genuine question about GC'd languages on Wasm - how does the GC run?

When running a GC language in its own runtime, usually there is at least 1 GC thread, that runs concurrently with the app code and pauses/preempts the main thread.

Afaik, in WASM, your application only has CPU time when you are inside a WASM function and threading is incredibly hacky and may be disabled due to security reasons related to side-channel attacks (read up on `SharedArrayBuffer` and cross-origin site isolation).

pjmlp3• 4 years ago

It runs alongside the application, basically you're back to using RC as GC algorithm or only when memory needs demand a full GC.

bullen19• 4 years ago

Reference Counting, ok!

titzer2• 4 years ago

Virgil compiles its tracing semi-space collector into the application. It's the same code as the native GC. The major difference is that the call stack is not visible, so the compiler must spill all live references on the stack into a shadow stack in memory. That last part was the trickiest and most inefficient part of porting.

saurik• 4 years ago

Garbage collection isn't generally something that happens periodically as it isn't needed until you get a bunch of new allocations and classically did not happen on some background thread as that's both extremely difficult to pull off and requires threading support in the first place. The simpler way to think about garbage collection is you establish a heap, set a size, and when you run out of space in that heap you run a garbage collection pass during the memory allocation that failed. If you fail to free enough memory, you either kill the program or request a larger heap.

kaba09• 4 years ago

This is the way it is described in the GC Handbook as well.

  New(): 
    ref <- allocate()
    if ref = null
      collect()
      ref <- allocate()
      if ref = null
        error "Out of memory"
    return ref

pulse7• 4 years ago

Currently there is no official support for GC in WASM. So currently any compilation of GC'd language into WASM must provide it's own GC which will be part of the WASM binary.

gernb• 4 years ago

WASM is a virtual processor spec. There's no GC support in X64 assembly nor ARM assembly and there's no GC support in Web Assembly because they are all assembly languages. You get a hunk of memory, you manage it however you want. If you want GC you you implement GC the same way the JVM implements GC on various processors.

kaba09• 4 years ago

While it is an informative article, I fail to be convinced that wasm is somehow superior (even for its current role).

Validation is faster due to it being structured, but stackmaps make it fast for class files as well. It is lower level, but is that really a good thing? It is quite trivial to just assign a huge ‘long’ array to some jvm byte code for the same result, and while I will look at the linked GC proposal, because haven’t been kept up-to-date on that, I think having a good GC is the single most important thing, as that is much harder to do than just providing a linear array. Which will in turn decimate the implementations (or at least mark a toy vs prod ready divide).

Also, will that structured nature not make it a less than great compilation target? This means that certain, more niche languages will have to use ugly (and slow) hacks to get implemented. And it being lowish level it is much harder to optimize it well (in that you express the exact semantics).

kodablah• 4 years ago

For many, language freedom/portability outweigh other concerns and this is where WASM has value. Running an algorithm written in Rust, Go, C, Zig, etc on the JVM with no JNI has value vs rewriting.

It is lower level, but is that really a good thing? It is quite trivial to just assign a huge ‘long’ array to some jvm byte code for the same result

That's basically what the WASM implementations on the JVM currently do. But it is actually _higher_ level from a dev POV due to language choice (at a not-huge performance expense).

sandGorgon• 4 years ago

Just fyi - there is an open bug to target wasm for Graal java compilation. https://github.com/oracle/graal/issues/3391

to a very large extent, it is open till LLVM upstream is more functionally complete to support GC.

wasm doesnt support GC to the way Java and Graal does. Which is why Graal is seriously impressive piece of tech. so it is not wasm vs java. Because that is really apples verus oranges.

it is just a matter of time before java gets compiled to wasm. that's what makes me puzzled about this article. Maybe its really about rust or golang vs java.

nilslice2• 4 years ago

For anyone who want to experiment with WebAssembly in Java, we just shipped a Java Host SDK[0] for Extism[1] which makes it about as easy as possible to call wasm functions from your Java programs.

0: https://extism.org/docs/integrate-into-your-codebase/java-ho...

1: https://github.com/extism/extism

evacchi4• 4 years ago

Author here, I just added a reference to Extism to the post! :)

nilslice2• 4 years ago

hey thank you! appreciate you putting this article together.

TeaVMFan• 4 years ago

+1 for TeaVM. Not only is there the Fermyon friendly fork, but WASM/WASI/debugging is seeing a large number of checkins in recent weeks in the main fork.

However, true "Java Geeks" should try the JavaScript support in TeaVM. It is mature and battle-tested. The resulting code runs great in a browser.

Live TeaVM-based game: https://frequal.com/wordii

Getting started with TeaVM: https://frequal.com/TeaVM/

Performance Comparison: https://frequal.com/java/TeaVmPerformance.html

WebAssembly for the Java Geek

Related Stories