Skip to content

experiment: Don't duplicate code generation for finally block in every exit path #4090

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

WojciechMazur
Copy link
Contributor

@WojciechMazur WojciechMazur commented Dec 1, 2024

     *  Emitting try-catch is easy, emitting try-catch-finally not quite so.

https://github.com/scala/scala3/blob/6bf4483932b37415bf2d1e6753eb26e3cc9f7986/compiler/src/dotty/tools/backend/jvm/BCodeSyncAndTry.scala#L119-L124

Current code generator for try-finally works but is quite primitive - if the finally block exists then we adjust every path in which control flow can exit the try.expr or any of the try.catch handlers in such a way for each of them we emit a finally block before continuing execution.
Becouse every input callsite of the finalizer may have a different destination implementing correct control flow is not trivial. Previously we duplicated the finalizer body for each of the control flows, that means that code of finalizer block is repeated at least 2 + CatchHandlerCount + EarlyReturnsCount times (we always emitted at least twice - for happy patch and for uncought exception path

The new approach takes advantage of the enumerating inputs to create tableswitch that would control where to resume execution (refered as trampolines). Unfortunetlly we cannot pass values directly becouse LLVM would crash - it cannot confirm that saved throwables/result values are always initialized. To workaround this problem we need to introduce a temporary variable that could stash results/throwables when we suspend execution to run finalizer.

What's important is fact that constructs like try { return 1 } finally {try () finally return 2} can be expressed in Scala (always yielding 2) and needs to be supported. In case of explicit early return from method we need to introduce additional variables to stash results - these would always have the same type as method, and might use different type then type of try block expression. Becouse some paths can be never reachable these might be (correctly) removed after dead-code analysis. We need to ensure that removed branches would not infer with the reachable execution path. For this reason and for optimization reasons we create a single variable for early return and throwable instance for all nested try blocks.

Benchmarks: TODO
Size gains: In case of Java standard library (javalib_3) the jar is smaller by ~15kB (~0.25% improvement)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant