Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-issuemaster opened this issue Jul 2, 2018 · 6 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Jul 2, 2018

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:

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:

  • #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")
  • #21530 Support platforms where Class is not Serializable in SerializableTypeWrapper ("depends on")
  • #21538 Perform explicit class checks in ReactiveAdapterRegistry ("depends on")
  • #21543 DefaultParameterNameDiscoverer should automatically adapt to Graal constraints ("depends on")
  • #21673 Detect GraalVM with system property in SerializableTypeWrapper ("depends on")
  • #21732 Be more defensive in UrlResource about cleaning the path ("depends on")
  • #21786 Usage of ClassLoader.loadClass() in ConfigurationClassParser ("depends on")
  • #21552 Make DefaultListableBeanFactory's javax.inject.Provider implementation invisible for nested class introspection ("depends on")

22 votes, 56 watchers

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 3, 2018

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-issuemaster

This comment has been minimized.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 5, 2018

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 6, 2018

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 10, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.