4 ms·
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 f
by 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 agoThe 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 agoThis 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 agoKotlin 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 agoJava 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 agoMaybe 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 agoWhat you're asking for is essentially commercial support from Oracle.
- hunterpayne 10mo agoNope, 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.
- Pet_Ant 10mo agoThat feature is necessary to enable future enhancements. It’s an important stepping stone. Just update your code. I’m doing it on 20 year old legacy billion dollar code base. It can be done.
- jolux 10mo agoIt's not just for security, it's also for maintainability. Frankly being able to reflect across package boundaries has always seemed like a misfeature for maintainability to me. The code you have that is broken by Java 9 was already badly behaved, the JVM was just lenient about it.
- gavinray 10mo agoThere are Kotlin compiler flags to default to "indy" optimization, and which may be enabled by default for some time now? Also not all Kotlin inlines are lambdas or even include method calls