Run the inliner/optimizer as a separate tool (linker)

[lrytz]

We've been talking a few times already about running the optimizer separately from compilation, let's collect the thoughts here.

This obviously overlaps with @DarkDimius' work on the dotty linker, and is similar to Scala.js' linker.

The idea is to run the Scala inliner and optimizer separately from compilation in 2.13, in a linking step. Some advantages

• The classpath is known. When using the 2.12 compile-time optimizer, it's up to the user to make sure that the compile-time classspath has exactly the same versions as the one at run-time.
• Better optimizations, for example through static class hierarchy analysis.

Instead of writing a new tool, it might make sense to work with the dotty linker, @DarkDimius has certainly given that some thought already (would we need to emit TASTY?).

[DarkDimius]

The idea is to run the Scala inliner and optimizer separately from compilation in 2.13, in a linking step.

I think this is a really good idea. It may also help to generalize the way how @scala-native and @scala-js link their IRs.

Instead of writing a new tool, it might make sense to work with the dotty linker, @DarkDimius has certainly given that some thought already (would we need to emit TASTY?).

Linker currently is entirely driven by Tasty, and more specifically a custom section. My first approximtion would be that the part which would be nice to unify is a common api that "optimizes\compiles those jars with those entry-points" + options, such as if the world should be closed. Or are there other use-cases that would be nice to cover?

it's up to the user to make sure that the compile-time classspath has exactly the same versions as the one at run-time

I am worried that we may be simply gifting a can of worms to users. Implications on binary compatibility are quite unclear and "it may just work or fail" depending on what optimizations trigger. I'd prefer to add a run-time static constructor that performs sanity check in runtime.

[lrytz]

I think this is a really good idea. It may also help to generalize the way how @scala-native and @scala-js link their IRs.

I'm not sure our work would help js/native, because the inliner works at the Java bytecode level.

common api that "optimizes\compiles those jars with those entry-points" + options

That's a good idea, yes.

up to the user to make sure that the compile-time classspath has exactly the same versions as the one at run-time

I am worried that we may be simply gifting a can of worms to users

Note that this is the current situation on 2.12 when inlining across the classpath, and yes, it's a problem.