6 ms·

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

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.

dtech 10mo ago
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.
- gavinray 10mo ago
  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
- pjmlp 10mo ago
  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.
  - dtech 10mo ago
    Kotlin existed before Java 7 and kept support JVM 1.6 for a long time (mainly because of Android) Even then, they benchmarked it, and inlining was still faster* than invokedynamic and friends, so they aren't changing it now JVM 1.8+ is a requirement. * at the expense of expanded bytecode size
    - pjmlp 10mo ago
      Java 7 to Java 25 is a world apart, and then on which JVM? Naturally it is a requirement, JetBrains and Google only care about the JVM as means to launch their Kotlin platform, pity that they aren't into making a KVM to show Kotlin greatness. If it feels salty, I would have appreciated if Android team was honest about Java vs Kotlin, but they weren't and still aren't. If they were, both languages would be supported and compete on merit, instead of sniffling one to push their own horse. Even on their Podcast they reveal complete lack of knowledge where Java stands.
      - hunterpayne 10mo ago
        Maybe the JVM team should listen to the market then and disable the jigsaw encapsulation that keeps devs on 1.8. Forcing a questionable security framework on everyone is why 1.8 is still used. Again, this is a problem because the PMs (and some devs) refuse to listen to what the market wants. So they are stuck keeping a 20 year old version of the code working. Serves them right to have to do this. It is their penance for being too arrogant to listen to the market. PS Yes, I know, there is some weird way to disable it. Somehow that way changes every version and is about as non-intuitive as possible. And trying to actually support the encapsulation is by a wide margin more work than it is worth.
        imtringued 10mo ago
        What you're asking for is essentially commercial support from Oracle.
        10mo ago
AdieuToLogic 10mo ago
> 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".
- cpeterso 10mo ago
  Do you mean the ‘register’ keyword?
  - AdieuToLogic 10mo ago
    > Do you mean the ‘register’ keyword? Yes I did, my bad.
  - AdieuToLogic 10mo ago
    My root-cause analysis: I was visualizing Scala method definitions and associated the language's type inference with keyword use, thus bringing C++'s "auto" keyword to mind when the long-since deprecated "register" keyword was the correct subject. It would appear LLM's are not the only entities which can "hallucinate" a response. :-D
- kokada 10mo ago
  And now we have things like `__attribute__((always_inline))` for GCC where you are completely, 100% sure that you want to inline :).
- TuxSH 10mo ago
  > 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.

dtech 10mo ago

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.

gavinray 10mo ago
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
pjmlp 10mo ago
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.
- dtech 10mo ago
  Kotlin existed before Java 7 and kept support JVM 1.6 for a long time (mainly because of Android) Even then, they benchmarked it, and inlining was still faster* than invokedynamic and friends, so they aren't changing it now JVM 1.8+ is a requirement. * at the expense of expanded bytecode size
  - pjmlp 10mo ago
    Java 7 to Java 25 is a world apart, and then on which JVM? Naturally it is a requirement, JetBrains and Google only care about the JVM as means to launch their Kotlin platform, pity that they aren't into making a KVM to show Kotlin greatness. If it feels salty, I would have appreciated if Android team was honest about Java vs Kotlin, but they weren't and still aren't. If they were, both languages would be supported and compete on merit, instead of sniffling one to push their own horse. Even on their Podcast they reveal complete lack of knowledge where Java stands.
    - hunterpayne 10mo ago
      Maybe the JVM team should listen to the market then and disable the jigsaw encapsulation that keeps devs on 1.8. Forcing a questionable security framework on everyone is why 1.8 is still used. Again, this is a problem because the PMs (and some devs) refuse to listen to what the market wants. So they are stuck keeping a 20 year old version of the code working. Serves them right to have to do this. It is their penance for being too arrogant to listen to the market. PS Yes, I know, there is some weird way to disable it. Somehow that way changes every version and is about as non-intuitive as possible. And trying to actually support the encapsulation is by a wide margin more work than it is worth.
      - imtringued 10mo ago
        What you're asking for is essentially commercial support from Oracle.
        10mo ago

AdieuToLogic 10mo ago

> 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".

cpeterso 10mo ago
Do you mean the ‘register’ keyword?
- AdieuToLogic 10mo ago
  > Do you mean the ‘register’ keyword? Yes I did, my bad.
- AdieuToLogic 10mo ago
  My root-cause analysis: I was visualizing Scala method definitions and associated the language's type inference with keyword use, thus bringing C++'s "auto" keyword to mind when the long-since deprecated "register" keyword was the correct subject. It would appear LLM's are not the only entities which can "hallucinate" a response. :-D
kokada 10mo ago
And now we have things like `__attribute__((always_inline))` for GCC where you are completely, 100% sure that you want to inline :).
TuxSH 10mo ago
> 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.