Why does `b()` produces more complex bytecode than `a()`, instead of just adding a private field to ...

# compiler

[louiscad]

Why does b() produces more complex bytecode than a(), instead of just adding a private field to the anonymous class?

fun interface Counter {
    fun getAndIncrement(): Int
}

fun a(): Counter = object : Counter {
    var number = 42
    override fun getAndIncrement(): Int {
        return number++
    }
}

fun b(): Counter {
    var number = 42
    return Counter { number++ }
}

[simon.vergauwen]

Within b() you’re not defining an anonymous class, but it’s just lambda definition of the single abstract method.

So the compiler needs to treat it like a variable capture that could be coming from anywhere.

[simon.vergauwen]

I guess it would be possible to write a more optimised version, depending on what scope the capture variable is coming from.

[louiscad]

But that's becoming an anonymous class in the bytecode anyway

[simon.vergauwen]

The captured variable could also be a property of a surrounding class, or anything else.

[louiscad]

So it seems like an unnecessary wrapper

[louiscad]

If it's from a surrounding class, I think a reference to that class instance is kept instead

[simon.vergauwen]

Wasn’t aware the compiler was already taking this into account. I thought it was doing to most naive thing always.

[simon.vergauwen]

So is it here generating an anonymous class that surrounds the counter to pass the reference?

[louiscad]

I don't see how it could work otherwise for the surrounding class thing. You don't want 2 disconnected variables, so the only sensible solution is to keep what owns the variable.

[louiscad]

In b, wraps the number variable inside an extra object instead of doing like b does.

[simon.vergauwen]

Thanks for clarifying. Now I’m curious too if there is a reason for this 😅

[Youssef Shoaib [MOD]]

Might be something related to invoke-dynamic and the like not having support for capturing (afaik)

[shikasd]

If you are talking about ref wrapping, it only happens because of var, I believe. You can potentially use the variable outside of captured scope (e.g. in b body), so compiler does the simplest thing

[Youssef Shoaib [MOD]]

I'd be interested to see if a minifier like Proguard would deal well with that. Maybe also the JVM escape analysis would be able to get rid of the ref wrapper

[shikasd]

Tbh r8/proguard are probably not smart enough, but JIT might be