Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Opt: Get rid of the LiftTry phase; instead handle things in the back-end. #18619

Merged
merged 2 commits into from
Oct 4, 2023
Merged

Opt: Get rid of the LiftTry phase; instead handle things in the back-end. #18619

merged 2 commits into from
Oct 4, 2023

Commits on Sep 30, 2023

  1. BCode: Track the exact types on the stack, rather than only the height.

    @sjrd
    sjrd committed Sep 30, 2023
    Configuration menu
    Copy the full SHA
    a82248f View commit details
    Browse the repository at this point in the history

  2. Opt: Get rid of the LiftTry phase; instead handle things in the back-… 

    …end.

When we enter a `try-catch` at the JVM level, we have to make sure
that the stack is empty. That's because, upon exception, the JVM
wipes the stack, and we must not lose operands that are already
on the stack that we will still use.

Previously, this was achieved with a transformation phase,
`LiftTry`, which lifted problematic `try-catch`es in local `def`s,
called `liftedTree$x`. It analyzed the tree to predict which
`try-catch`es would execute on a non-empty stack when eventually
compiled to the JVM.

This approach has several shortcomings.

It exhibits performance cliffs, as the generated def can then
cause more variables to be boxed in to `XRef`s. These were the
only extra defs created for implementation reasons rather than
for language reasons. As a user of the language, it is hard to
predict when such a lifted def will be needed.

The additional `liftedTree` methods also show up on stack traces
and obfuscate them. Debugging can be severely hampered as well.

Phases executing after `LiftTry`, notably `CapturedVars`, also had
to take care not to create more problematic situations as a result
of their transformations, which is hard to predict and to remember.

Finally, Scala.js and Scala Native do not have the same restriction,
so they received suboptimal code for no reason.

In this commit, we entirely remove the `LiftTry` phase. Instead, we
enhance the JVM back-end to deal with the situation. When starting
a `try-catch` on a non-empty stack, we stash the entire contents of
the stack into local variables. After the `try-catch`, we pop all
those local variables back onto the stack. We also null out the
leftover vars not to prevent garbage collection.

This new approach solves all of the problems mentioned above.
    @sjrd
    sjrd committed Sep 30, 2023
    Configuration menu
    Copy the full SHA
    52e8e74 View commit details
    Browse the repository at this point in the history