Inlining an extension method produces bad bytecode

[strelec]

Compiler version

3.1.3

Minimized code

Simple code, with a simple isEven function, that is also inline.

opaque type Number = Int

object Number {
	extension (n: Number) {
		inline def isEven = n % 2 == 0
	}
	def apply(n: Int): Number = n
}

// another file:
object Test {
	def f(a: Number, b: Number) = if (a.isEven && b.isEven) println("OK")
}

Output

Decompiling function f we get this:

    public void f(final int a, final int b) {
        final Test$package$ module$ = Test$package$.MODULE$;
        final int n$proxy1 = a;
        boolean b2 = false;
        Label_0052: {
            if (n$proxy1 % 2 == 0) {
                final Test$package$ module$2 = Test$package$.MODULE$;
                final int n$proxy2 = b;
                if (n$proxy2 % 2 == 0) {
                    b2 = true;
                    break Label_0052;
                }
            }
            b2 = false;
        }
        if (b2) {
            Predef$.MODULE$.println((Object)"OK");
        }
    }

Expectation

A more reasonable and efficient version would be this:

    public void f(final int a, final int b) {
        if (a % 2 == 0 && b % 2 == 0) {
            Predef$.MODULE$.println((Object)"OK");
        }
    }

I thought extension functions were static and trivially inlineable, same as in Kotlin.
As it stands right now, it is risky to make anything inline, as it might have the opposite effect on performance.

[odersky]

Have you tried to do the same with normal methods? I would bet the result will be exactly the same.

Also, the more "reasonable" version is a source program. Have you tried to decompile its bytecode? I would bet you see the same Label/break sequence.

So if we analyze it, the only difference seem to be the creation of the two pairs of proxy variables.

The first proxy module$N is generated by typer since the type is opaque. It is never used, so the JIT will simply throw it away. We could do a dead code elimination phase, not sure whether the tradeoff between added compile time vs reduced bytecode will be worth it, but it's certainly worth exploring.

The second proxy n$proxyN is created by the inliner. It would be omitted if the argument to the extension is an inline parameter.

So it's all about inlining with opaque types, and not related to extension methods. But my guess is that none of this will matter for performance. Proxies are one of the first things the JIT would throw out (or, rather, it would systematically create temporaries for every step in SSA form and fuse temporaries and proxies in the same slots.)

[odersky]

I believe without a good in-depth argument why this would cost performance (you probably have to analyze the JIT-generated assembly for that) we can close this issue.

[smarter]

FWIW, the generated bytecode is also considerably better in 3.2.0-RC1 thanks to #14890

The first proxy module$N is generated by typer since the type is opaque. It is never used, so the JIT will simply throw it away.

It's not completely trivial to eliminate because it forces the static constructor of Test$package$. I believe the backend always emtis these calls in case the object constructor has side-effects.