This test starts a sub-process with -Xcomp and then uses the SA to get a stack trace of it. It expects to see this line:

In code in NMethod for jdk/test/lib/apps/LingeredApp.main

But actually on AArch64 the stack trace looks like this:

 - java.lang.Thread.sleep(long) @bci=0, pc=0x0000ffff74603d08, Method*=0x0000ffff031baf98 (Compiled frame; information may be imprecise)
 - jdk.test.lib.apps.LingeredApp.main(java.lang.String[]) @bci=53, line=502, pc=0x0000ffff6c9276e0, Method*=0x0000ffff03611d48 (Interpreted frame)

The main method is interpreted even though we're running with -Xcomp. That's because it is deoptimized almost immediately, because main calls some methods on java.nio.file.Paths, but that class hasn't been loaded when main is compiled. So we hit an uncommon_trap when we execute this method and deoptimize. You can see this behavior with -XX:+PrintCompilation -XX:+TraceDeoptimization:

    551 1 !b jdk.test.lib.apps.LingeredApp::main (88 bytes)
Uncommon trap bci=28 pc=0x0000ffff989fdcfc, relative_pc=0x000000000000003c, method=jdk.test.lib.apps.LingeredApp.main([Ljava/lang/String;)V, debug_id=0
Uncommon trap occurred in jdk.test.lib.apps.LingeredApp::main compiler=c2 compile_id=1 (@0x0000ffff989fdcfc) thread=152412 reason=unloaded action=reinterpret unloaded_class_index=270 debug_id=0 unresolved class: java/nio/file/Paths
    556 1 ! jdk.test.lib.apps.LingeredApp::main (88 bytes) made not entrant

X86 can patch in the address of the method on-the-fly, but AArch64 can't do this because of restrictions on which instructions can be legally rewritten.