[wasm] Implement the ENDFINALLY opcode in the jiterpreter #84273
Conversation
|
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsBy marking the opcode following each CALL_HANDLER opcode as a back-branch target, we can then generate a conditional backwards branch in the jiterpreter for ENDFINALLY opcodes and allow traces to keep executing after a finally block. This should improve performance for traces containing try/finally, especially ones that have it inside of a loop body. Currently the support is limited for methods with at most three CALL_HANDLER opcodes, because the codegen for the ENDFINALLY will get too bloated beyond that. One risk to this is that now more traces will contain backwards branches than before, which results in them having a dispatch loop at entry.
|
Logging cleanup Don't generate dispatch entries for back branches we haven't seen targeted
Add browser-bench measurement for try-finally
kg
requested review from
lewing,
pavelsavara,
BrzVlad and
kotlarmilos
as code owners
ghost
locked as resolved and limited conversation to collaborators
By marking the opcode following each CALL_HANDLER opcode as a back-branch target, we can then generate a conditional backwards branch in the jiterpreter for ENDFINALLY opcodes and allow traces to keep executing after a finally block. This should improve performance for traces containing try/finally, especially ones that have it inside of a loop body. I added a simple browser-bench measurement that shows a measurable improvement (950usec -> 700usec) from this.
Currently the support is limited for methods with at most three CALL_HANDLER opcodes, because the codegen for the ENDFINALLY will get too bloated beyond that.
One risk to this is that now more traces will contain backwards branches than before, which results in them having a dispatch loop at entry.
This PR also tweaks the CFG to generate fewer entries in the backward branch dispatcher in some cases, which helps compensate for the new targets introduced by finally support.