Hacker News Reader

Comment by saagarjha | Hacker News Reader

> In SpiderMonkey there is no mechanism currently to tier down; if you need to debug WebAssembly code, you need to refresh the page, causing the wasm code to be compiled in debugging mode.

Is there ever a reason to "tier down" WebAssembly besides debugging? In JavaScript functions will often get deoptimized back to the baseline interpreter if they side exit too often, but is this a thing that needs to be done in WebAssembly?

View on HN

As far as I know: Not really the initial "downgraded" code is normally worse in more or less any aspect. It's just emitted fastly.

The only reason I could come up with is to downgrade to them upgrade again to a differently optimized code. But then WebAssembly doesn't need to do speculative optimizations like JS needs. So I guess it's not really relevant.

In theory, you could generate better code after having observed the actual arguments to various functions and recompile while treating them as constants. Basically profile-guided (re)optimization. But the observation would slow down the initial code, it would be a large implementation effort, and the gains would be dubious imho. Especially given how much information was already lost via the initial AOT (ahead of time) optimizing compile; you might need to keep the original source around or something.

Unlikely to happen.

Thanks.

I considered this scenario as llvm does somewhat support profile-guided optimizations but it would be a fundamental change where we go from "unoptimized" to "optimized-with-tracing" instead of optimized, so that step could still have optimization upgrade hooks, so we still wouldn't need a downgrade to "base-line". I guess.

I agree that it's anyway unlikely to happen, at least in the browser.

I could imagine that some WebAssembly based cloud provider (or similar) would be potentially interested in generating profiles and then use that for better optimizations in other instances (so still no down-/upgrade ).

> you could generate better code after having observed the actual arguments to various functions and recompile while treating them as constants

This transformation is valid for pure functions; therefore you can mark it constexpr before compiling to WASM. There's the `constexpr-everything` project (among others) that uses libclang to apply constexpr to all legal functions/expressions in a codebase.

That's for C++ - Rust is working on `const fn`.

> This transformation is valid for pure functions; therefore you can mark it constexpr before compiling to WASM.

It's also valid for non-pure functions at runtime.

JS functions go back and forth because they're trying to provide optimized representation of functions based on guesses they make about the code. WASM plays an entirely different game. WASM bytecode is generally already extremely optimized (compiled with compiler -O flags, etc), the optimizations that a browsers apply are more about the machine the WASM running on (dealing with register allocation, simd instructions, etc). There is no guessing or opportunistic optimization like there is in JS.

There's still profile-guided optimization.

Isn't it because the compiled code makes some assumptions about the types of the arguments? So if the types of the arguments change, it would need to downgrade to interpreted code?

Webassembly is statically typed.

I'm trying to remember why, but the JVM backtracks for a couple of different scenarios.

wasm can still lazily load code, right? "Static" in that situation is a little fuzzy. You can't make wholesale changes to the types already loaded, no, but the behavior out at the leaf-nodes can be altered by a new leaf showing up.

Some assumption or inlined conditional may be wrong or simply ill-advised once new code arrives.

IIRC the JVM optimizes very aggressively based on runtime profile, and just adds traps to the optimized-out paths to collect new runtime profile.

Imagine code like this, where at runtime foo is always null

  if (foo != null) {
    foo.bar();
    foo.baz();
  }

if foo is always null the compiler will just remove all of the statements inside and places a trap there. If foo happens to be non-null (say, due to external environment changes) then the it hits the trap and the whole method is deoptimized and goes through the profiler again.

The optimizations in the JVM are quite fascinating - https://advancedweb.hu/profile-based-optimization-techniques... I imagine javascript engines employ similar techniques

The runtime optimisations are remarkable but it does look like runtime performance can change unpredictably. Has this been your experience?

Yes, the JVM tends to speed up over time as it applies these optimizations.

A fair question. In principle this can happen, and HotSpot can respond to changes in the program's execution patterns, but to my knowledge it's not a problem in practice with real-world Java servers. Other than a 'warming up' phase, real-world performance doesn't tend to vary wildly as time progresses.

(Disclaimer: I've not done a great deal of real-world Java work.)

Another example: if MyClass is the only class that implements MyInterface, HotSpot can generate code that takes advantage of that assumption, removing vtable indirection in method-calls. If, later in the program's execution, the Java classloader loads another class which implements MyInterface, HotSpot will detect that the assumption it made earlier no longer holds. Having determined that the code it generated earlier is no longer safe, it will discard that code.

I recall reading that in earlier versions of HotSpot, it was sometimes possible to improve performance by making your class 'final', enabling the JVM to remove indirection for method-calls. This is not true of the later versions of HotSpot, where it can use the technique described above to safely make optimisations based on tentative assumptions, giving you the same enhanced performance either way.

Even older than that, hotspot would in-line the common case for method dispatch in situations where there is one implementation or where one implementation dominates. (Kind of wonder if Spring would perform at all without it).

Reply on news.ycombinator.com