Scala 3 slowed us down?

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.

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.

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.

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

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.

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.

What you're asking for is essentially commercial support from Oracle.

Nope, what I am asking for is disabling an on by default feature that maybe 1% of the market wants and/or needs and creates significant pain for the other 99%. By the time strong encapsulation meets an attacker, the battle is already lost most of the time.