Upcoming removal of org.graalvm.nativeimage:svm from maven?

[zakkak]

In https://graalvm.slack.com/archives/CNBFR78F9/p1639154644225700 @gilles-duboscq referring to org.graalvm.nativeimage:svm mentioned that:

hum... we thought that was already deprecated in 21,3 and were planning to remove it in 22.0. But it was indeed still deployed with 21.3

As discussed in that slack thread there are projects relying on some of the APIs provided by it.

For instance, Quarkus is currently using the following imports from that jar and its removal would be a breaking change:

import com.oracle.svm.core.annotate.Alias;
import com.oracle.svm.core.annotate.AlwaysInline;
import com.oracle.svm.core.annotate.AutomaticFeature;
import com.oracle.svm.core.annotate.Delete;
import com.oracle.svm.core.annotate.Inject;
import com.oracle.svm.core.annotate.InjectAccessors;
import com.oracle.svm.core.annotate.KeepOriginal;
import com.oracle.svm.core.annotate.NeverInline;
import com.oracle.svm.core.annotate.RecomputeFieldValue;
import com.oracle.svm.core.annotate.RecomputeFieldValue.Kind;
import com.oracle.svm.core.annotate.Substitute;
import com.oracle.svm.core.annotate.TargetClass;
import com.oracle.svm.core.annotate.TargetElement;
import com.oracle.svm.core.jdk.JDK11OrLater;
import com.oracle.svm.core.jdk.JDK17OrLater;
import com.oracle.svm.core.jdk.JDK8OrEarlier;
import com.oracle.svm.core.posix.headers.Pthread;
import com.oracle.svm.core.SubstrateUtil;
import com.oracle.svm.core.threadlocal.FastThreadLocalFactory;
import com.oracle.svm.core.threadlocal.FastThreadLocalInt;

I am starting this discussion aiming to find a way to allow the usage of such APIs even after the removal of the svm artifact (possibly by moving them in sdk).

[kirillp]

We have huge list of portability examples. Java is designed to be portable. The core question here is that GraalVM compiler introduced a new better way to JNI. This is cool, however, HotSpot has other focus-pocus (see Java critical), TeaVM-C has its own annotations related to native interop. In order to get all things together svm annotations are essential.

[kirillp]

Another point is that GraalVM is very slow, it is 12x times slower doing jni call with arrays then jvm, and use of SVM annotations makes this a little bit better

[gilles-duboscq]

For 22.0 specifically, we can release the SVM jar as we did for 21.3: it's built with Java 8 and might not work very well on Java 11+.
I think in the cases you mention above you only use this jar to compile against some internal classes and you don't really need the code inside that jar to really work to build native-images. So i think those use-cases will be fine.

It remains a question of what to do moving forward.

Note that the SVM and compiler JARs are definitely not stable APIs. They only contain internal classes that might change in arbitrary way between each release.
They were provided on maven to help with very specific edge use-cases (the old native-image plugin, using the compiler in a non-graalvm JDK to run graal-js).
The Graal SDK was created to provide stable APIs that users can rely on.

[kirillp]

@zakkak you can avoid using annotations because you have the only target, if you had really multiplatfom code that targets 5-6 platforms you'll have to use em

[zakkak]

@zakkak you can avoid using annotations because you have the only target, if you had really multiplatfom code that targets 5-6 platforms you'll have to use em

That's true we only support OpenJDK-HotSpot and GraalVM/Mandrel.

What you describe sounds like something that could also be handled by providing two implementations of the API (hopefully only the native part), one suitable for GraalVM and another suitable for the rest of the platforms. What are the benefits of using substitutions instead of providing two implementations?

[kirillp]

I dont see how this is effectively possible
Assume you have

public class Dispatch {
  static native void dispatchAsync(long threadIsolate, Runnable r);
}

which is located in module platform and used in 7 other modules
and there is class DispatchReplacement that usses grall specific things to implement it

@TargetClass(value = Dispatch.class)
public final class DispatchReplacement {
  public static void dispatchAsync(long isolate, Runnable r) {
    ObjectHandle objectHandle = handles.create(r);
    dispatch_async(
        isolate,
        objectHandle.rawValue(),
        Mth.callBack.getFunctionPointer().rawValue());
  }
}

or another example:

 public final class GL {
  public static native void glFinish();
 }

which is substitued by

  @CFunction(transition=NO_TRANSITION)
  public static native void glFinish();

And if you have this

public class ObjC {
 public static native long sel_getUid(byte[] name);
}

the problem is described here
#2873
the only way to solve is to use

@TargetClass(value = ObjC.class)
public final class ObjCReplacement {
  @Substitute
  public static long sel_getUid(byte[] name) {
    PinnedObject p = PinnedObject.create(name);
    long uid = ObjCNative.sel_getUid(p.addressOfArrayElement(0));
    p.close();
    return uid;
  }
}

OF course we can avoid using the Annotations by introducing two new modules for each substitutions and substitute one module by another ie: compile module A with generic code, while linking (or packaging) the app with A_Graal_Specific instead. But this is pain

Instead one can substitute and feel good.

[gilles-duboscq]

So the second issue here is that you need to use PinnedObject to work around JNI performance issues on SVM.
I don't really understand the first one though, how do you implement that on HotSpot? Can't you use the same JNI code on SVM?

[kirillp]

Jni emulation is extremely slow in GraalVM. JNI C iterface emulation is not that good.
Using it in practice makes performance problems. Anotations does the job. Same time other vms does not have such annotations. So we substitute JNI with SVM

[kirillp]

A solution is to move annotations to a separate module.

[kirillp]

I think in the cases you mention above you only use this jar to compile against some internal classes and you don't really need the code inside that jar to really work to build native-images

Exactly, we need only annotations, not the code.

[kirillp]

About the following inports I agree with @gilles-duboscq point here
import com.oracle.svm.core.jdk.JDK11OrLater; import com.oracle.svm.core.jdk.JDK17OrLater; import com.oracle.svm.core.jdk.JDK8OrEarlier; import com.oracle.svm.core.posix.headers.Pthread; import com.oracle.svm.core.SubstrateUtil; import com.oracle.svm.core.threadlocal.FastThreadLocalFactory; import com.oracle.svm.core.threadlocal.FastThreadLocalInt;

One should not use class like com.oracle.svm.core.*
It is internal implementation details.
If one needs the API he can declare it same way.

[kristofdho]

A few classes we're using for configuration inside custom Feature implementations:
import com.oracle.svm.core.jni.JNIRuntimeAccess;: JNI configuration during analysis should be configurable through the SDK. It is available for reflection, with the RuntimeReflection class.
import com.oracle.svm.core.configure.ResourcesRegistry;: Same argument as JNIRuntimeAccess.
import com.oracle.svm.hosted.FeatureImpl;: to access calls like FeatureImpl.DuringSetupAccessImpl#registerClassReachabilityListener to act on reachable classes with a specific annotation. But could be used to act on any arbitrary class matching.

[jerboaa]

So I've done a comparison of a JDK 11 build svm.jar and a JDK 17 build svm.jar. Note that svm.jar is the artefact discussed for removal in this discussion. Note: I've actually done a diff of all GraalVM specific jars I could find (of a mandrel distro) and only svm.jar shows differences. As expected there are certain classes not present in an earlier JDK-based build that would be available in a later JDK-based build. That is because the build system builds certain classes only conditionally (based on the base JDK version). If people start using the artefact with different JDK versions things are bound to break. A solution for that problem is indeed needed.

--- jdk11_list.txt	2022-01-20 20:45:37.258706026 +0100
+++ jdk17_list.txt	2022-01-20 20:45:46.846747729 +0100
@@ -2230,6 +2230,24 @@
 ./svm.jar.d/com/oracle/svm/core/jdk11/Target_jdk_internal_loader_BuiltinClassLoader.class
 ./svm.jar.d/com/oracle/svm/core/jdk11/Target_jdk_internal_loader_ClassLoaders_JDK11OrLater.class
 ./svm.jar.d/com/oracle/svm/core/jdk11/Target_sun_misc_Unsafe.class
+./svm.jar.d/com/oracle/svm/core/jdk14
+./svm.jar.d/com/oracle/svm/core/jdk14/Target_java_nio_DirectByteBuffer_JDK14OrLater.class
+./svm.jar.d/com/oracle/svm/core/jdk14/Target_java_nio_DirectByteBufferR_JDK14OrLater.class
+./svm.jar.d/com/oracle/svm/core/jdk14/Target_sun_nio_ch_Util.class
+./svm.jar.d/com/oracle/svm/core/jdk15
+./svm.jar.d/com/oracle/svm/core/jdk15/HiddenClassFeature.class
+./svm.jar.d/com/oracle/svm/core/jdk15/HiddenClassSupportImpl.class
+./svm.jar.d/com/oracle/svm/core/jdk15/Target_java_lang_ClassLoader_JDK15OrLater.class
+./svm.jar.d/com/oracle/svm/core/jdk15/Target_java_lang_Module_JDK15OrLater.class
+./svm.jar.d/com/oracle/svm/core/jdk15/Target_jdk_internal_loader_BootLoader_JDK15OrLater.class
+./svm.jar.d/com/oracle/svm/core/jdk15/Target_jdk_internal_loader_NativeLibraries_JDK15OrLater.class
+./svm.jar.d/com/oracle/svm/core/jdk15/Target_jdk_internal_loader_NativeLibraries_NativeLibraryImpl_JDK15OrLater.class
+./svm.jar.d/com/oracle/svm/core/jdk16
+./svm.jar.d/com/oracle/svm/core/jdk16/JDKClassLoadingDeadlockWorkaround.class
+./svm.jar.d/com/oracle/svm/core/jdk16/RecordFeatureJDK16OrLater.class
+./svm.jar.d/com/oracle/svm/core/jdk16/RecordSupportJDK16OrLater.class
+./svm.jar.d/com/oracle/svm/core/jdk17
+./svm.jar.d/com/oracle/svm/core/jdk17/Target_jdk_internal_platform_CgroupMetrics_JDK17OrLater.class
 ./svm.jar.d/com/oracle/svm/core/jdk/AccessControlContextFeature.class
 ./svm.jar.d/com/oracle/svm/core/jdk/AccessControllerUtil.class
 ./svm.jar.d/com/oracle/svm/core/jdk/AllPermissionsPolicy.class
@@ -4196,6 +4214,7 @@
 ./svm.jar.d/com/oracle/svm/hosted/jdk/JNIRegistrationsJavaZip.class
 ./svm.jar.d/com/oracle/svm/hosted/jdk/JNIRegistrationSupport$1.class
 ./svm.jar.d/com/oracle/svm/hosted/jdk/JNIRegistrationSupport.class
+./svm.jar.d/com/oracle/svm/hosted/jdk/JNIRegistrationSupport_JDK14OrLater.class
 ./svm.jar.d/com/oracle/svm/hosted/jdk/package-info.class
 ./svm.jar.d/com/oracle/svm/hosted/lambda
 ./svm.jar.d/com/oracle/svm/hosted/lambda/LambdaProxyRenamingSubstitutionProcessor.class

[kirillp]

As I already mentioned above the solution is trivial - make a new module annotations or move annotations to the sdk so that people can remove the svm dependency

[gilles-duboscq]

A solution we have used for this issue previously is multi-release jars.

In this case it will only make a difference if JDK and svm.jar version are mixed when actually building native-images. If svm.jar is only used to compile against some internal APIs i don't think it's an issue since none of the classes shown here are likely to be used in this way.

[jerboaa]

IMHO, multi-release jars seem a better approach than the status quo for svm.jar ;-) I agree it's unlikely to be hit in practice, but still something worth cleaning up (i.e. make it harder for people to make the mistake to begin with).

[gilles-duboscq]

It is now a 11+17 multi-release jar.

[kristofdho]

It's unclear to me if the svm jar is still going to be released or not. If not, this should get some more attention as according to #4310 the feature freeze for the next release will be on March 11 already.

[gilles-duboscq]

As far as I can see, in the current state we don't have much choice and we will keep pushing the SVM jar out. It is now a 11+17 multi-release jar.

[meltsufin]

Is version 22.1.0 going to be released?

[gilles-duboscq]

Yes, #4518 is tracking the missing SVM jars on maven for 22.1.0

[gilles-duboscq]

For reference, another usage of @AutomaticFeature can be seen in #4518