Runtime performance: ~700× slower than native on a `geo` benchmark; analysis and a 2× prototype fix

[mipastgt]

After a long time of silence I evaluated rustc_codegen_jvm (5ed31a3) again on a real-world crate: geo 0.33 buffering a line string and doing point-in-polygon tests. The results are identical to native in every run, including the i_overlay buffer construction. Very impressive!

Performance is about 700× native. It's not the JVM: a line-by-line Java port of the kernel runs at 1.5× native, and the same program compiled to Wasm and run through Chicory on the same JVM reaches about 3× native. Profiles put ~90% of the time in org.rustlang.runtime, mainly memory views (field reads through &T into Vec/Box storage decode and register whole structs), projectStructField's by-name lookups and Range::next allocations.

The attached patch (~220 lines) lowers primitive field reads through shared references to Freeze types to a single scalar load at a constant offset. It makes buffer and classify 2× faster, and python3 Tester.py --release passes.

The attached zip has the full write-up (geo_buffer_bench/docs/FINDINGS.md), the patch, the benchmark and the probes, with commands to reproduce everything.

This analysis was conducted with the help of Claude Opus 5.5.

[LDemetrios]

The attached patch (~220 lines) lowers primitive field reads through shared references to Freeze types to a single scalar load at a constant offset. It makes buffer and classify 2× faster, and python3 Tester.py --release passes.

The attached zip has the full write-up (geo_buffer_bench/docs/FINDINGS.md), the patch, the benchmark and the probes, with commands to reproduce everything.

I'm not sure if it's just me, but I don't see any attached files. Did you mean to attach them here or somewhere else?

The important caveat when comparing this project to Chicory is where the conversion between native data and java data happens. Chicory exposes native-like functions where arguments are i32, i64 etc. So the conversion mostly happens on these boundaries: for example, I found myself doing a lot of "serialize into json, print into string, pass as pointer + length, deseriaize from that". With this compiler you it happens inside, when pointers and references are made.

I previously said that it's strange to me that Pointer is created anywhere where &T is, so &T isn't just a java object passed around by reference. It turns out my Rust is a bit rusty (pun intended) and I forgot one can do this:

fn mutate(x: &mut i32) {
    *x = 43;
}

fn main() {
    let mut y = 42;
    mutate(&mut y);
    println!("{}", y); // 43
}

, that the reference in Rust is just a glorified pointer.

However, here's a little trick Kotlin does with noinline lambdas. In analyzes whether a captured value is a var or val (would be mut or not in Rust):

 1: fun measure(body: () -> Unit): Long {
 2:    val t0 = System.nanoTime()
 3:    body()
 4:    val t1 = System.nanoTime()
 5:    return t1 - t0
 6: }

 8: fun main() {
 9:    var x = 42
10:    val time = measure {
11:        x = 43
12:    }
13:    println(x) // Prints 43
14:    println(time)
15: }

and here's roughly what it compiles to, skipping basic leg work about nullability checks:

import kotlin.jvm.functions.Function0
import kotlin.Unit
import kotlin.jvm.internal.Ref.IntRef
import java.lang.invoke.LambdaMetafactory
import java.lang.invoke.MethodHandles.Lookup
import java.lang.invoke.MethodHandle
import java.lang.invoke.MethodType
import java.lang.invoke.CallSite

public class ExampleKt {
    public final static long measure(Function0<Unit> a0) {
  2:    long l1 = System.nanoTime();
  3:    Object _ = a0.[interface]invoke();
  4:    long l3 = System.nanoTime();
  5:    return l3 - l1;
    }

    public final static void main() {
  9:    Uninitialized tmp0 = new IntRef;
        tmp.[special]<init>();
        IntRef a0 = tmp0;

        a0.element = 42;

 10:    Function0 tmp1 = INVOKEDYNAMIC {
            bootstrap = static LambdaMetafactory.metafactory(
                /* MethodHandles.Lookup caller, */
                /* String interfaceMethodName = */ "invoke",
                /* MethodType factoryType = */ (IntRef) -> Function0,
                /* MethodType interfaceMethodType = */ () -> Object,
                /* MethodHandle implementation = */ static ExampleKt::main$lambda$0(IntRef) -> Unit,
                /* MethodType dynamicMethodType = */ () -> Unit
            )
            arguments = [a0]
        };
        long l1 = ExampleKt.measure(tmp1);

 13:    System.out.[interface]println(a0.element);
 14:    System.out.[interface]println(l1);
 15:    return
    }

    private final static Unit main$lambda$0(IntRef a0) {
 11:    a0.element = 43;
 12:    return Unit.INSTANCE;
    }
}

Int is wrapped into IntRef object and put on heap. The same would go for object types: ObjectRef is just providing a second indirection. And as these *Ref classes are never put in anything type-erased and are never assigned nulls, jit can usually optimize out their allocation and convert to just carrying pointers to stack, as Rust, C++ and alike do it.

I am not completely sure, but I think most of what can be done with &muts without some sort of unsafe, can be achieved with this trick. And it is my hope that unsafe is usually limited to few spaces where it's either not that bad or can be configured to have different code for jvm backend specifically. Well, you can convert a ref to a pointer without unsafe, but you'll then have to use unsafe to do anything with that pointer. Hope you get what I mean.

[mipastgt]

Sorry, my fault. Just forgot the attachement.
rustc_codegen_jvm-geo-benchmark.zip

[mipastgt]

@LDemetrios For interfacing Kotlin with Rust I have successfully used CBOR serialization in the past. It can be used with Kotlin serialization out of the box, is a standard, is binary and has therefore much better performance than JSON. There is also a Rust crate which can directly handle CBOR too.