[iOS] Wrong values on JNI methods with 8+ arguments of same type

[jperedadnr]

Describe the issue

When building a native image for iOS AAarch64 without LLVM backend, there is an issue if the JNI methods have 8 or more arguments of the same type, and the values that are passed from the Java method are wrong starting from the 8th argument of that same type.

Steps to reproduce the issue
HelloWorld.java

package hello;

public class HelloWorld {

    public static void main(String[] args) {
        System.out.println("Hello World!! ");
        foo15(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15);
        foo19(1, 2.0d, 3, 4.0d, 5, 6.0d, 7, 8.0d, 9, 10.0d, 11, 12.0d, 13, 14.0d, 15, 16.0d, 17, 18.0d, 19);
        System.exit(0);
    }

    native static void foo15(int a1, int a2, int a3, int a4, int a5, int a6, int a7, int a8, int a9, int a10, int a11, int a12, int a13, int a14, int a15);
    native static void foo19(int a1, double a2, int a3, double a4, int a5, double a6, int a7, double a8, int a9, double a10, int a11, double a12, int a13, double a14, int a15, double a16, int a17, double a18, int a19);
}

native:

#include "jni.h"

JNIEXPORT void JNICALL Java_hello_HelloWorld_foo15(JNIEnv *env, jclass class, jint a1, jint a2, jint a3, jint a4, jint a5, jint a6, jint a7, jint a8, jint a9, jint a10, jint a11, jint a12, jint a13, jint a14, jint a15) {
    fprintf(stderr, "a1=%d, a2=%d, a3=%d, a4=%d, a5=%d, a6=%d, a7=%d, a8=%d, a9=%d, a10=%d, a11=%d, a12=%d, a13=%d, a14=%d, a15=%d\n", a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11, a12, a13, a14, a15);
}

JNIEXPORT void JNICALL Java_hello_HelloWorld_foo19(JNIEnv *env, jclass class, jint a1, jdouble a2, jint a3, jdouble a4, jint a5, jdouble a6, jint a7, jdouble a8, jint a9, jdouble a10, jint a11, jdouble a12, jint a13, jdouble a14, jint a15, jdouble a16, jint a17, jdouble a18, jint a19) {
    fprintf(stderr, "a1=%d, a2=%.3f, a3=%d, a4=%.3f, a5=%d, a6=%.3f, a7=%d, a8=%.3f, a9=%d, a10=%.3f, a11=%d, a12=%.3f, a13=%d, a14=%.3f, a15=%d, a16=%.3f, a17=%d, a18=%.3f, a19=%d\n", a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11, a12, a13, a14, a15, a16, a17, a18, a19);
}

Building and deploying to iOS gives:

[SUB] Hello World!! 
[SUB] a1=1, a2=2, a3=3, a4=4, a5=5, a6=6, a7=7, a8=1, a9=8, a10=1, a11=9, a12=1, a13=10, a14=1, a15=11
[SUB] a1=1, a2=2.000, a3=3, a4=4.000, a5=5, a6=6.000, a7=7, a8=8.000, a9=9, a10=10.000, a11=11, a12=12.000, a13=13, a14=14.000, a15=1, a16=16.000, a17=15, a18=0.000, a19=0
[SUB] Process 42630 exited with status = 0 (0x00000000) 

Running with LLVM backend works as expected. But without LLVM backend, after the 7th argument there is a "1" inserted on every other argument (int type).

Describe GraalVM and your environment:

• GraalVM version built from head: commit 4ec2571 including patch from [GR-31170] Add some AArch64 Windows and Darwin features. #3864
• JDK major version: 11]
• OS: macOS Big Sur
• Architecture: AMD64

[teshull]

Thanks for reporting this. Can you see if #4077 solves the issue?

[jperedadnr]

@teshull Yes, it does!
I've run several tests (the one I posted here and a few more complex ones), all good!

[teshull]

#4077 has been merged now. Please let me know if you run into any other issues

[jperedadnr]

Thanks @teshull
I've just built from head, and deploying to iOS works perfectly fine without a LLVM backend.

Coincidently, since last night our CI integration tests are failing building for iOS with a LLVM backend:

[SUB] [6/7] Compiling methods...    [*******]                                                                 (52.5s @ 3.35GB)
[SUB] 3 fatal errors detected:
[SUB] Fatal error: org.graalvm.compiler.graph.GraalGraphError: com.oracle.svm.core.util.VMError$HostedError: Can only write to registers in a method where it is expected.
[SUB]      at node: 160|WriteCurrentVMThread { stamp=void,  }
[SUB]      at method: int com.oracle.svm.jni.functions.JNIInvocationInterface$Exports$JNICreateJavaVMPrologue.enter(JNIJavaVMInitArgs)  [Direct call from int IsolateEnterStub.JNIInvocationInterface$Exports_JNI_CreateJavaVM_8df18e9ea6eb1ed7b1c899a0bbc578da0e2cc0ad(JNIJavaVMPointer, JNIEnvironmentPointer, JNIJavaVMInitArgs)]
[SUB]      at com.oracle.svm.core.graal.llvm.NodeLLVMBuilder.doBlock(NodeLLVMBuilder.java:293)
[SUB]      at com.oracle.svm.core.graal.llvm.SubstrateLLVMBackend.generate(SubstrateLLVMBackend.java:148)
[SUB]      at com.oracle.svm.core.graal.llvm.SubstrateLLVMBackend.emitLLVM(SubstrateLLVMBackend.java:124)
[SUB]      at com.oracle.svm.core.graal.llvm.SubstrateLLVMBackend.emitBackEnd(SubstrateLLVMBackend.java:104)
[SUB]      at jdk.internal.vm.compiler/org.graalvm.compiler.core.GraalCompiler.compile(GraalCompiler.java:146)
[SUB]      at jdk.internal.vm.compiler/org.graalvm.compiler.core.GraalCompiler.compileGraph(GraalCompiler.java:130)
[SUB]      at com.oracle.svm.hosted.code.CompileQueue.defaultCompileFunction(CompileQueue.java:1306)

I'll try to isolate the commit that causes this, but maybe you already have an idea?

[teshull]

My guess would be #3827 @loicottet hopefully would know more

[jperedadnr]

It was working fine until last night. I've bisected the recent commits, and it seems this commit: 3292bbb is causing the issue.

Indeed, this commit has as parent d263c53 that was committed yesterday by @loicottet

[jperedadnr]

I've reverted now both commits, and building from head, it works fine with and without LLVM backend.

[loicottet]

I have recently noticed this as well, I'm working on a fix.

[jperedadnr]

@loicottet that is great news, do you have an ETA for it? As mentioned before, our integration tests are failing, and we are about to start migrating them to use the non-LLVM backend, but it would be good to know it we can wait just a little bit longer.

[loicottet]

The fix is ready to be merged, it should be in early this week.