[WebAssembly] Could C++ EH avoid `catch_ref` and `throw_ref`?

[sunfishcode]

Currently, WebAssemblyLateEHPrepare.cpp rewrites pseudo "rethrow" instructions to catch_ref and throw_ref.

Would it work to instead rewrite it to catch and throw, effectively discarding the old exception object and creating a new one? From my reading of the code, it doesn't look like clang/libcxxabi/libunwind/etc. depend on the state or identity of the thrown exception object, so I'm curious if this might work.

Doing this could help Wasm engines that don't implement Wasm GC, as they could then omit throw_ref, catch_ref, catch_all_ref, and exnref, while still supporting enough to run C++ exceptions and setjmp/longjmp.

Would it be less efficient? In an engine that omits catch_ref/catch_all_ref, there wouldn't be any overhead to creating a new exception object because it wouldn't ever need to be reified. In an engine that does implement Wasm GC, optimized implementations often use bump allocation for short-lived objects, and these would be very short-lived objects. It also seems like there might be ways engines could avoid using the GC heap in common cases. But I'm curious what others think.

[llvmbot]

@llvm/issue-subscribers-backend-webassembly

Author: Dan Gohman (sunfishcode)

Currently, WebAssemblyLateEHPrepare.cpp rewrites pseudo "rethrow" instructions to `catch_ref` and `throw_ref`.

Would it work to instead rewrite it to catch and throw, effectively discarding the old exception object and creating a new one? From my reading of the code, it doesn't look like clang/libcxxabi/libunwind/etc. depend on the state or identity of the thrown exception object, so I'm curious if this might work.

Doing this could help Wasm engines that don't implement Wasm GC, as they could then omit throw_ref, catch_ref, catch_all_ref, and exnref, while still supporting enough to run C++ exceptions and setjmp/longjmp.

Would it be less efficient? In an engine that omits catch_ref/catch_all_ref, there wouldn't be any overhead to creating a new exception object because it wouldn't ever need to be reified. In an engine that does implement Wasm GC, optimized implementations often use bump allocation for short-lived objects, and these would be very short-lived objects. It also seems like there might be ways engines could avoid using the GC heap in common cases. But I'm curious what others think.

[sbc100]

Would this loose the original backtrace information associated with the original exception?

[aheejin]

C++'s throw; keyword calls __cxa_rethrow, which creates a new exception anyway:
https://github.com/emscripten-core/emscripten/blob/edd85ecb6cc305b50eb9a62aeb5516b8a70a4879/system/lib/libcxxabi/src/cxa_exception.cpp#L664
https://github.com/emscripten-core/emscripten/blob/edd85ecb6cc305b50eb9a62aeb5516b8a70a4879/system/lib/libunwind/src/Unwind-wasm.c#L68-L69
So the backtraces are not preserved for throw;s. That's in line with native environments like x86.

throw_ref (or legacy rethrow) are used only for

1. When a type does not match in catch. In native platforms the exception does not even stop at user code because this is all done within the personality function and libunwind stack walking, but because we can't do that, we stop at the Wasm (generated) code and rethrow:

   // In Wasm, the exception is 'rethrown' (using throw_ref) if the exception type is not int
   try {
     foo();
   } catch (int) {
   }

2. After running a destructor when an exception is thrown. So Itanium EH's resume or WinEH's cleanupret instruction

And AFAIK C++ libraries these stack traces in these two cases.

[sunfishcode]

Ok, so it seems the answer is yes, it would work, however we'd lose backtraces, in engines that provide backtraces, in the cases where an exception doesn't match any catch clause, or when there's a destructor call during an unwind. Thanks!

[aheejin]

No what I meant was the opposite. We will NOT lose backtraces when there is no matching catch clauses or destructors. When we do lose backtraces is a user explicitly uses throw; in C++ code. Both behaviors match the native behavior. Was this matching the native behavior what you meant, or something else?

[sunfishcode]

If we switched things that use catch_ref and throw_ref to use catch and throw instead, those things would then lose backtrace info, right?

[aheejin]

I'm not sure what is the behavior you want in the first place, for these three scenarios:

1. C++'s throw; keyword
2. No matching catch clause
3. At the end of a destructor when exception is thrown

Both Wasm and the native do not preserve stack traces for 1 and do preserve stack traces for 2 and 3.
Which among these behaviors do you want to make different from the status quo?

[dschuff]

I think what @sunfishcode actually wants is to use different wasm instructions to implement throwing, catching, and propagating exceptions, ideally without changing those user-visible behaviors.
So I think this would mainly affect the behavior when there is no call into the runtime (e.g. cases 2 and 3). Currently in any frame that might handle an exception or that runs a destructor, we catch the wasm exception with catch_ref, and then rethrow it with throw_ref if there is no matching catch clause. IIUC if we used catch instead, we'd lose any stack trace that was taken by the engine at the site of the original throw.

A couple of notes on this. Currently on the web the throw instruction does not take a stack trace, because there was a strong desire in the CG for throws to be as cheap as possible (e.g. for using EH as a low-overhead form of control flow). The only way to get a stack trace attached to an exnref is to create it with the JS API (new WebAssembly.Exception(<tag>, <payload>, {traceStack: true})). In a non-web embedding you'd have to either choose to have throw take a stack trace (thus making it more expensive), or not, have some out-of-band way to configure the behavior like the JS embedding does, or maybe try to come up with some other clever compromise.

[aheejin]

I think what @sunfishcode actually wants is to use different wasm instructions to implement throwing, catching, and propagating exceptions, ideally without changing those user-visible behaviors.

Do you mean he wants to use throw and catch in case of 2 and 3 without losing stack traces?

throw and catch by definition lose stack traces. But I wonder why someone would want to change instructions in the first place. If he doesn't want to use new exnref instructions, he can use -wasm-use-legacy-eh=true (which is by default, so you don't need it) and he will get catch_all andrethrow. Oh, is this possibly because he wants to use only legacy instructions but not-to-be-deprecated ones?

So anyway to answer this question, we can in theory change it to use throw and catch instead, but we don't have the option and the impl for that. Also to do that we need to bake the assumption that an exception is always a single i32 pointer, which is true for all C++ programs, because we need to extract it and re-throw it as a new exception. But this will lose stack traces.

[dschuff]

I think the real desire here is that non-web engines (which mostly don't have existing support for legacy EH IIUC) want to implement the standard EH (and nothing deprecated), but they don't want to implement GC. So they want to try to get away with just part of the standard EH, the part that doesn't require exnref. Presumably these are the same engines that didn't want to implement reference types or bulk table instructions in order to get bulk memory and call-indirect-overlong.

So yeah I agree with your assessment, I don't see a way to keep stack traces. Even if someone said they were willing to lose stack traces, presumably we'd have to "split" the proposal the way we did with bulk-memory-opt and call-indirect-overlong. I'm a little more hesitant to do this unilaterally in the toolchain compared to those 2 though, partly because... well I was a little hesitant in the first place but even more because I think there would be more complexity involved the further we go down this path. I do think there could still be a reasonable subset of wasm we could define as a profile: we've talked about a "no-gc" version and you could maybe argue for a "no-reftypes" version too. But you would be giving up real functionality with exceptions.