Initial GraalVM native images (Substrate VM) support [SPR-16991]

[spring-projects-issues]

Sébastien Deleuze opened SPR-16991 and commented

We have began to work with Dave Syer on improving support for running Spring Framework based application as native images via Substrate VM from GraalVM project.

Oracle is currently working on improving support for Spring based on our feedback, so this issue is mainly intended to track those efforts, but also to track fine tuning we could do to improve Spring Framework support for such platform.

Since Spring relies on reflection and proxies, these documents are worth to read:

• Substrate VM Java Limitations
• Dynamic proxies on Substrate VM
• Reflection on Substrate VM

It has been possible to run a minimal WebFlux.fn + Netty application successfully using functional bean registration, see this Spring Fu issue for more details. Startup time as native image is very fast (30 ms). The self-sufficient executable size is 50 MB and the resident memory is 35 MB.

In parallel to this work, we are also trying to get regular Spring Framework / Boot applications working and to identify how much configuration will be needed (for now we generate it manually). Latest pending issue is being able to run ConversionService, see graal#507 for more details.

---

Issue Links:

• RestTemplate (and probably server side as well) should be able to bootstrap itself if com.sun.org.apache.xalan.* is not available [SPR-17007] #21545 RestTemplate (and probably server side as well) should be able to bootstrap itself if com.sun.org.apache.xalan.* is not available ("depends on")
• Support platforms where Class is not Serializable in SerializableTypeWrapper [SPR-16992] #21530 Support platforms where Class is not Serializable in SerializableTypeWrapper ("depends on")
• Perform explicit class checks in ReactiveAdapterRegistry [SPR-17000] #21538 Perform explicit class checks in ReactiveAdapterRegistry ("depends on")
• DefaultParameterNameDiscoverer should automatically adapt to Graal constraints [SPR-17005] #21543 DefaultParameterNameDiscoverer should automatically adapt to Graal constraints ("depends on")
• Detect GraalVM with system property in SerializableTypeWrapper [SPR-17136] #21673 Detect GraalVM with system property in SerializableTypeWrapper ("depends on")
• Be more defensive in UrlResource about cleaning the path [SPR-17198] #21732 Be more defensive in UrlResource about cleaning the path ("depends on")
• Usage of ClassLoader.loadClass() in ConfigurationClassParser [SPR-17253] #21786 Usage of ClassLoader.loadClass() in ConfigurationClassParser ("depends on")
• Make DefaultListableBeanFactory's javax.inject.Provider implementation invisible for nested class introspection [SPR-17014] #21552 Make DefaultListableBeanFactory's javax.inject.Provider implementation invisible for nested class introspection ("depends on")

22 votes, 56 watchers

[spring-projects-issues]

Sébastien Deleuze commented

We are doing good progress. With #21530 and #21538 fixed + using GraalVM master, we have been able to go pretty far with a Jetty version of spring-boot-micro-apps.
Current blocking error is a UnsupportedFeatureError: Unresolved element found thrown when processing org.springframework.boot.web.reactive.error.ErrorWebExceptionHandler.
Even with custom configuration, error remains so Dave Syer has raised an issue on GraalVM side about that.

Juergen Hoeller Something that looks interesting to me, especially in Spring context, is RuntimeReflection.register() API that could allow Spring Framework to inform GraalVM AOT compiler about the classes it instantiates reflectively, or even about the ones instantiated by the dependencies we integrate (Netty, Jetty, Log4j).

@AutomaticFeature
class RuntimeReflectionRegistrationFeature implements Feature {
  public void beforeAnalysis(BeforeAnalysisAccess access) {
    try {
      RuntimeReflection.register(String.class);
      RuntimeReflection.register(String.class.getDeclaredField("value"));
      RuntimeReflection.register(String.class.getDeclaredField("hash"));
      RuntimeReflection.register(String.class.getDeclaredConstructor(char[].class));
      RuntimeReflection.register(String.class.getDeclaredMethod("charAt", int.class));
      RuntimeReflection.register(String.class.getDeclaredMethod("format", String.class, Object[].class));
      RuntimeReflection.register(String.CaseInsensitiveComparator.class);
      RuntimeReflection.register(String.CaseInsensitiveComparator.class.getDeclaredMethod("compare", String.class, String.class));
    } catch (NoSuchMethodException | NoSuchFieldException e) { ... }
  }
}

[spring-projects-issues]

Sébastien Deleuze commented

For the record, here is the list of the pending GraalVM issues related to Spring (mostly raised by Dave Syer, kudos to him):

Open

• Support for Class.getDeclaredClasses() (blocking for JavaConfig)
• NullPointerException in Inflation.checkType() (blocking 1.0.0-RC6 regression)
• DynamicHub.getProtectionDomain() fails at native image build time
• NoClassDefFoundError: kotlin/reflect/KParameter
• Java beans Introspector causes segfault
• com.oracle.svm.core.util.VMError$HostedError: should not reach here
• Failed to compile spring-boot project to native image (UnsupportedFeatureException)
• Compilation error where classpath should exclude code path
• Annotation attributes not available at runtime

Workaround proposed

• Native image generator ought to be able to ignore type errors from unloadable annotation attributes
• Confusing error message about schema when building native image

Fixed

• Runtime shutdown hook run in the wrong place in a native image
• ClassNotFoundException: com.jcraft.jzlib.Deflater when generating native image
• Make it possible to run Spring ConversionService with Substrate VM (fixed)
• Unresolved element found in Spring DefaultListableBeanFactory (fixed via Make DefaultListableBeanFactory's javax.inject.Provider implementation invisible for nested class introspection [SPR-17014] #21552)

Norman Maurer also fixed this Netty issue on GraalVM we raised.

[spring-projects-issues]

Sébastien Deleuze commented

Very interesting changes in GraalVM: native-image reflection support by automatically detecting reflective calls and intrinsifying them to the corresponding target elements statically.

[spring-projects-issues]

Sébastien Deleuze commented

I have updated the status of the pending issues, we make progress but we are currently blocked by this GraalVM 1.0.0-rc6 regression.

[spring-projects-issues]

Sébastien Deleuze commented

I have created spring-boot-graal-demo that will be used by GraalVM team to avoid regression on their side and for us to create branches demonstrating each issue.

[spring-projects-issues]

Sébastien Deleuze commented

I think we can consider initial support finished from a Spring Framework 5.1 perpective for now since most remaining issues are on GraalVM side. We will continue to collaborate with GraalVM team to provide repro projects and create issues.

The first step to reach will be to get Spring functional application supported. The second milestone step will be to get JavaConfig supported. The third step will be to get GraalVM supported on Spring Boot side.

We will fix remaining issues as part of Spring Framework 5.1.x or 5.2 releases.