[_old_dude_]

In Scala 3, the inline keyword is part of the macro system.

When inline is used on a parameter, it instructs the compiler to inline the expression at the call site. If the expression is substantial, this creates considerable work for the JIT compiler.

Requesting inlining at the compiler level (as opposed to letting the JIT handle it) is risky unless you can guarantee that a later compiler phase will simplify the inlined code.

There's an important behavioral difference between Scala 2 and 3: in 2, @inline was merely a suggestion to the compiler, whereas in 3, the compiler unconditionally applies the inline keyword. Consequently, directly replacing @inline with inline when migrating from 2 to 3 is a mistake.

[AdieuToLogic]

> There's an important behavioral difference between Scala 2 and 3: in 2, @inline was merely a suggestion to the compiler, whereas in 3, the compiler unconditionally applies the inline keyword. Consequently, directly replacing @inline with inline when migrating from 2 to 3 is a mistake.

This reminds me of a similar lesson C/C++ compilers had to learn with the "register" keyword. Early versions treated the keyword as a mandate. As compiler optimizers became more refined, "register" was first a recommendation and then ultimately ignored.

The C++ inline keyword is treated similarly as well, with different metrics used of course.

EDIT:

Corrected reference to early C/C++ keyword from "auto" to "register".

[TuxSH]

> The C++ inline keyword is treated similarly as well, with different metrics used of course.

You are thinking of C's inline/static inline.

C++'s "inline" semantics (which are implied for constexpr functions, in-class-defined methods, and static constexpr class attributes) allow for multiple "weak" copies of a function or variable to exist with external linkage. Rather than just an optimization hint it's much more of a "I don't want to put this in any specific TU" these days.

[cpeterso]

Do you mean the ‘register’ keyword?

[kokada]

And now we have things like `__attribute__((always_inline))` for GCC where you are completely, 100% sure that you want to inline :).

[dtech]

Kotlin heavily uses the inline keyword basically everywhere, to get rid of lamdba overhead for functions like map. Basically every stdlib and 3rd part library function that takes a lamdba is inlined.

In general it's a performance benefit and I never heard of performance problems like this. I wonder if combined with Scala's infamous macro system and libraries like quicklens it can generate huge expressions which create this problem.

[pjmlp]

This is one example why being a guest language isn't optimal.

They should have made use of JVM bytecodes that allow to optimize lambdas away and make JIT aware of them, via invokedynamic and MethodHandle optimizations.

Naturally they cannot rely on them being there, because Kotlin also needs to target ART, JS runtimes, WebAssembly and its own native version.

[gavinray]

The killer is specifically the inlining of macros -- which Kotlin lacks.

And not all macros, but just the ones which expand to massive expressions

Think template expressions in C++ or proc macros in Rust