[SPR-16991] Initial GraalVM native images (Substrate VM) support Created: 02/Jul/18 Updated: 21/Sep/18 Resolved: 10/Sep/18
|Fix Version/s:||5.1 GA|
|Reporter:||Sébastien Deleuze||Assignee:||Sébastien Deleuze|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Days since last comment:||12 weeks, 6 days ago|
|Last commented by a User:||true|
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.
|Comment by Sébastien Deleuze [ 03/Jul/18 ]|
We are doing good progress. With
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).
|Comment by Sébastien Deleuze [ 05/Jul/18 ]|
For the record, here is the list of the pending GraalVM issues related to Spring (mostly raised by Dave Syer, kudos to him):
Norman Maurer also fixed this Netty issue on GraalVM we raised.
|Comment by Sébastien Deleuze [ 27/Jul/18 ]|
Very interesting changes in GraalVM: native-image reflection support by automatically detecting reflective calls and intrinsifying them to the corresponding target elements statically.
|Comment by Sébastien Deleuze [ 05/Sep/18 ]|
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.
|Comment by Sébastien Deleuze [ 06/Sep/18 ]|
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.
|Comment by Sébastien Deleuze [ 10/Sep/18 ]|
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.