The JVM knows nothing about any of it. After compilation it only sees classes, methods, fields and bytecode instructions.

So I compiled a dozen of the common ones, one at a time, and opened them with javap to see what they turn into. The sorting came out clean: three are genuinely free, a few only save typing, and a few quietly charge you.

Start with the cleanest one

s?.length ?: -1, a safe call plus an elvis fallback.

Compiled, it is 8 instructions:

aload reads the parameter, dup copies it, ifnull jumps to the branch, call length, goto to merge, pop the leftover top of stack, push -1, return.

No object allocation, no extra function call, no try catch. It is an ifnull jump.

That is true zero cost. The bytecode from ?. and from hand-writing if (s != null) s.length else -1 is essentially identical.

But !! charges you

Same goal, convincing the compiler to trust me: s!!.length compiles to 5 instructions with an Intrinsics.checkNotNull static call wedged in the middle.

Every time execution reaches !!, it really does run a null check, and throws NullPointerException when that fails.

This is not a compile-time guarantee. It is one function call at runtime.

Ordinary parameters are more interesting. I wrote fun checked(s: String): Int = s.length, a non-null parameter type and a body that does nothing at all. Compiled, 6 instructions, and the first thing it does is Intrinsics.checkNotNullParameter(s, "s").

Which means the public entry point of every Kotlin function with a non-null parameter checks it first. !! is an explicit check, a non-null parameter is an implicit one, and in bytecode they are the same category of thing.

Extension functions and infix calls: pure rewriting

fun String.shout(): String compiles to a static method shout(String), with the receiver becoming the first parameter.

infix fun Int.plus2(other: Int) is also a static method, plus2(int, int).

operator fun plus(o: Op) is just an ordinary member method, plus(Op).

None of the three leaves a trace in bytecode saying it used to be syntactic sugar. The call site is a plain invokestatic or invokevirtual.

Zero cost, because they never changed the program’s structure. They are a different way of writing down the same method.

when compiles to tableswitch

when (n) { 0 -> ...; 1 -> ...; 2 -> ...; else -> ... } compiles to tableswitch, as long as the branch values are consecutive integers.

That is the fastest branch the JVM has: one table lookup and jump, no comparing cases in sequence.

Sparse values degrade to lookupswitch, which is a binary search underneath. Non-constant branches turn into a chain of if checks.

So when’s performance is entirely a function of which values you write, and the compiler guarantees nothing. Consecutive constants get you tableswitch. Anything else and it downgrades.

data class: ten methods

One data class Point(val x: Int, val y: Int) produces a 2111-byte class file and ten things:

two fields, a constructor, two getters, component1, component2, copy, copy$default, toString, hashCode, equals.

You wrote one line of source. The bytecode holds an entire class.

Two of those ten exist purely for destructuring. val (a, b) = point compiles to two componentN calls.

copy$default exists to serve copy with default arguments. Its signature is (Point, int, int, int, Object), where the third int is a bitmask telling it which parameters took their defaults.

object: one static field

object Singleton compiles to:

a public static final Singleton INSTANCE field, a private constructor, and a static initializer block.

A singleton is a class that locks itself down and holds its only instance in a static field. Writing Singleton.name in Kotlin becomes getstatic INSTANCE plus one method call in bytecode. No reflection, none of the lazy-initialization machinery.

Default parameters: one more method

fun greet(name: String, title: String = "engineer") generates greet(String, String) and also greet$default(String, String, int, Object).

That int is a bitmask: bit n set means parameter n took its default. The Object is a marker slot reserved for inline classes.

The call site decides what to do. Pass everything and it takes the normal method; miss one and it jumps to $default, which fills the gap and delegates.

I timed passing all of them against missing one, 5,000,000 iterations each, both landing between 8 and 9 milliseconds, the same as an ordinary five-parameter function. That overhead does not measure.

lazy delegation: one field plus one class

val text: String by lazy { ... } compiles to 1416 bytes:

a private final kotlin.Lazy text$delegate field, a getText() method, and a static method to hold the lambda.

Every read of text goes through getText(), which delegates to Lazy.getValue(). So a lazy property access always costs one more virtual call than a plain property.

A counterintuitive observation while I was in there. The docs list three LazyThreadSafetyMode values; I ran SYNCHRONIZED, PUBLICATION and NONE 5,000,000 times each, and differences like 5 milliseconds against 36 milliseconds flip from run to run. I could not measure a stable conclusion. At that level JIT behavior matters more than the mode itself.

So do not pick a mode off a blog post unless you have actually measured it on your own workload.

inline: saves objects, costs code

inline is the most interesting of the set because it cuts both ways: it removes one call and duplicates the code several times over.

I wrote an inline fun inlined(x: Int) and a plain function with an identical body, each called from six functions.

In the plain version the call sites hold nothing but invokestatic, and the body exists once in the bytecode.

In the inline version all six call sites have the body pasted in. Every useX method shows imul and ishl directly.

That is the essence of inline: one function call and a possible lambda object removed, paid for in duplicated code.

But how much does it actually save. I measured 1,000,000 higher-order calls with a lambda: the inline version allocates 0 B, the plain version 9,872 B.

9,872 out of a million is 0.01 B per call, 0.03% of that 36 B object.

Because JIT escape-analyzed the lambda away. On a modern JVM, the object overhead of a non-inline higher-order function basically does not exist.

The ironic part is that my inline example emitted a warning at compile time. The official docs say inline only matters for function-type parameters, and the compiler threw that sentence straight into the build output:

expected performance impact from inlining is insignificant. Inlining works best for functions with parameters of function types.

The compiler is telling you your inline is useless, and only worth it when a parameter is a function type.

The compiler talking you out of abusing inline is more honest than most technical blogs.

String templates still use StringBuilder

One left, and it was the most surprising.

"$name is $age years old, ${age * 2}" compiles to new StringBuilder with five appends and a toString.

Java has been on invokedynamic plus String Concat Factory since 9. Kotlin is a beat behind on this one.

I assumed it was a flag problem, so I tried -Xstring-concat=indy-with-constants, and the compiler warned: this flag does nothing with JVM target 1.8.

Because Kotlin’s default jvmTarget is 1.8, class file major version 52.

I tried all four combinations: target 1.8 is StringBuilder whether or not you pass the flag; target 21 needs no flag and becomes invokedynamic on its own, major version 65.

The deciding factor is jvmTarget, not the flag.

So which implementation your string templates get depends on what jvmTarget says in your build script. Most Android projects are still on 1.8 or 11, which means StringBuilder.

The tiers, after taking it apart

Once it is laid out, three tiers.

Genuinely free: safe calls, extension functions, infix calls, operator overloading. In bytecode they are ordinary method calls and jumps, not one instruction extra.

More code, no more time: data class, object, default parameters, when. The generated output looks alarming, but runtime behavior matches hand-written code.

Real cost: !! and the runtime check on every non-null parameter, lazy’s delegated call on every access, inline’s code duplication, and StringBuilder for string templates at a low jvmTarget.

And one more tier, “depends on config”: which string template implementation you get changes the moment you edit one line of jvmTarget.

The feeling I came away with is that “syntactic sugar” makes people assume the compiler will sort it out anyway. The compiler just faithfully translates what you wrote into instructions, and whether that is good or bad is entirely a question of what you wrote.

Last month, when Beta2 came out, I wrote up a changelog round covering release formats and a few changed defaults. This time I wanted to measure something I skipped last time: does it actually save memory?

After installing the compiler, the first thing I did was not write a demo from the docs. It was run javap and read what the compiler emitted.

The conclusion first: in the bytecode it is an ordinary class. Not a trace of inline anywhere.

First, confirm what the compiler accepts

Download kotlin-compiler-2.5.0-RC.zip, unzip it, and the version is kotlinc-jvm 2.5.0-RC, running on JRE 21.0.10.

The first step hit a wall. Write a value class VComplex(val real: Double, val imaginary: Double) and the compiler refuses:

the feature “full value classes” is experimental and should be enabled explicitly.

You need -Xfull-value-classes before it accepts anything. The docs say the feature is Experimental and must be enabled explicitly. All true, it just does not tell you what you will see once it is enabled.

Bytecode is more honest than the docs

I wrote two controls. One data class DComplex(real, imaginary), one value class VComplex(real, imaginary). Same fields, same types.

javap -p on VComplex: a private final double real, a private final double imaginary, a two-argument constructor, two getters, one toString.

That is all. No box-impl, no unbox-impl, and no packing of the two doubles into some other representation.

Now the single-field @JvmInline value class VUserId(val raw: Long), which looks completely different: constructor-impl(long), box-impl(long), unbox-impl(), hashCode-impl(long), equals-impl(long, Object), and every one of those methods takes a primitive long.

That is what inline means. The multi-field one is not it.

So does it save anything?

I measured allocation with ThreadMXBean.getCurrentThreadAllocatedBytes, 1,000,000 runs, looking at average bytes per run.

First round, reading fields off local variables: VComplex 9.3 B, DComplex 10.4 B. Both numbers are far below what an object should occupy, because JIT did scalar replacement and the object was never created at all.

That measurement does not hold up. So I moved them into an ArrayList, forcing the objects to exist.

VComplex into a List: 36.0 B per run. DComplex into a List: 36.0 B per run.

Identical. Zero bytes apart.

The 36 is easy enough to explain: a 16-byte object header plus 16 bytes for the two doubles. A clean integer.

So on the JVM, a multi-field value class saves not a single byte. The only size difference from the data class is in the class file: VComplex.class is 1,760 bytes, DComplex.class is 2,216 bytes, 21% smaller, and what is missing is copy and componentN.

Not even @JvmInline escapes

I measured the single-field control while I was at it. VUserId into a List: 28.0 B. DUserId as well: 28.0 B.

Again not a byte apart.

The reason is plain: once it goes into a generic container it has to be boxed, and once boxed it is an object, indistinguishable from an ordinary class.

So the claim that an inline value class is a zero-cost abstraction holds only at the layer of passing arguments directly. Put it inside a List, a Map, an Array<Any>, and the cost comes straight back.

This is not a 2.5 problem, it is the old rule of JVM generic erasure. It is just that a lot of people reach for value classes as a memory-saving tool.

What it saves is semantics

So what is a multi-field value class for?

It is for the idea that two instances with identical contents should not differ by identity. A data class == compares contents, but two instances are still two objects, each with its own reference, its own lock, its own place on the heap.

A value class removes that identity. You cannot rely on reference equality, which means you cannot use it as a lock and cannot use object identity as a cache key.

The price is no copy() and no componentN(). The docs mention copy vars coming later. Not yet.

I did measure deduplication and equals: setOf(a, b).size is 1 both ways, and toString prints VComplex(real=1.0, imaginary=2.0), the same as the data class.

So what it gives you is a constraint, not performance.

Where it really differs from a data class

I measured the equals edge cases too, because that is where surprises like to hide.

NaN against NaN: true for VComplex, true for DComplex. Negative zero against positive zero: false on both sides. Same behaviour as a data class, all of it following Double.compare semantics. No extra surprise, no extra trap.

Inheritance does have something new. A value class can implement a sealed interface, and a value object can join in:

sealed interface Resp
value class Found(val id: Int) : Resp
value object Unknown : Resp

Unknown::class.java.name prints Unknown, and the compiler resolves Found(1) is Resp to true outright, with a warning that the check is always true. Because a value class’s inheritance is fixed at compile time, there is no second possibility at runtime.

So the substantive differences from a data class are three: no copy(), no componentN(), no object identity.

The first two are subtractions. The third is the reason it exists.

Destructuring has a silent trap

The RC made only-syntax the default mode for name-based destructuring. I wrote about the trap last time, so here is harder evidence.

data class User(val username: String, val email: String), an instance of User("alice", "alice@example.com"), and then one line: val (email, username) = user.

The variable names and the property names are swapped. This is extremely common in production code. You type by position, not by name.

Default mode prints: email is alice, username is alice@example.com. Completely transposed.

Add -Xname-based-destructuring=complete, recompile the same source, not one character changed, and it prints: email is alice@example.com, username is alice.

Both modes compile. Neither reports an error. The runtime results are exact opposites.

There is a name-mismatch mode in between that does not change behaviour, only warns, and its exact wording is variable name ’email’ differs from accessed property name ‘username’, this code will change its meaning.

It does not say this is a bug. It says the meaning of this code will change. If you want to clear the mines early, this is the only mode you can use.

The migration flags are still missing in RC

The docs, in the migration section, say: starting with 2.5.20, unmarked single-field value classes produce a warning, 2.6 or 2.7 promotes that to an error, and until then you can use -Xinline-value-class-migration=warning and strict to prepare.

I tried exactly that. The compiler replied: flag is not supported by this version of the compiler. Neither one is accepted.

All three destructuring modes work, not one of the two migration flags exists. The docs are not wrong, they describe a state that is coming, but written on the RC page they read as available now.

Verify it yourself in two minutes

Do not take my word for it. The commands are below.

Download and unzip the compiler, write a minimal comparison file, compile with the flag, then open both classes with javap. Look for the -impl suffix and you know at a glance whether it is inline.

The allocation measurement is simple too, ThreadMXBean in two lines:

val mx = ManagementFactory.getThreadMXBean() as com.sun.management.ThreadMXBean
val before = mx.getCurrentThreadAllocatedBytes()
// 这里跑你的循环
val after = mx.getCurrentThreadAllocatedBytes()
println((after - before) / 循环次数)

One thing you have to watch: the local-variable scenario measures nothing. JIT eliminates the object entirely and both numbers come out at a dozen bytes or so. Put it in a collection and measure that, because that is what it looks like when the object is really created.

I fell into this on my first attempt and nearly wrote down the wrong conclusion, that both sides save memory.

What you can do before upgrading

Three things.

First, hang -Xname-based-destructuring=name-mismatch on your build and run it once. Zero behaviour change, pure checking, and the warnings it produces are the line numbers whose meaning will change later.

Second, if you are using multi-field value classes, work out whether you are after memory or after semantics. If it is memory, the measurements say you will not get it.

Third, do not put value classes on your list of performance optimizations. True zero cost only holds for single-field direct argument passing, and you have to write @JvmInline explicitly, because from 2.5 on the words value class no longer automatically mean inline.

As for full value classes themselves: experimental, gone the moment the flag is off, and production use will have to wait.

The one thing I most want to say after all this measuring: a type with value in its name is still an object on the JVM. If you want to save memory, you still have to look at where your data structures actually live.