Polish documentation

Author: sdeleuze

scripts/reflectStrip.sh

@@ -1,2 +1,2 @@
 # Creates a compact diff between two reflect json files
-java -classpath `dirname $0`/../spring-graalvm-native-feature/target/spring-graalvm-native-feature-0.7.0-SNAPSHOT.jar org.springframework.graal.support.ReflectionJsonStrip $1 $2
+java -classpath `dirname $0`/../spring-graalvm-native-feature/target/spring-graalvm-native-feature-0.7.0-SNAPSHOT.jar org.springframework.graalvm.support.ReflectionJsonStrip $1 $2

spring-graalvm-native-docs/src/main/asciidoc/agent.adoc

@@ -96,15 +96,9 @@ GraalVM provides a https://www.graalvm.org/docs/reference-manual/native-image/#i
 ----
 ====
 
-The important part is the `<buildArgs>..</buildArgs>` block that shows the options we pass to the `native-image` operation and the `spring-graalvm-native` feature.
+The important part is the `<configuration><buildArgs>..</buildArgs></configuration>` block that shows the options we pass to the `native-image` operation and the `spring-graalvm-native` feature.
 Those prefixed `-D` are aimed at the feature.
 
-NOTE: Notice the `--no-server` option.
-Like a Gradle daemon, the server here is supposed to help accelerate subsequent builds.
-Unfortunately, there is an https://github.com/oracle/graal/issues/1952[issue] where the server causes different results to come out of the compilation.
-In particular, we have seen logging disappear the server is used to aid compilation.
-Hence, using the server to aid compilation is turned off here.
-
 ===== Add the repository for `spring-graalvm-native`
 
 If necessary, add the repository for the `spring-graalvm-native` dependency, as follows:

spring-graalvm-native-docs/src/main/asciidoc/extension_guide.adoc

@@ -21,8 +21,8 @@ Each of these hints specifies a set of types that need accessibility, what kind
 
 These `@NativeImageHint` should be hosted in one of two places.
 
-First, in the `spring-graalvm-native-configuration` module, you can see that they are hosted on types that implement the `org.springframework.graal.extension.NativeImageConfiguration` interface (defined by the feature).
-Implementations of this interface should be listed in a `src/main/resources/META-INF/services/org.springframework.graal.extension.NativeImageConfiguration` file, which the feature loads through regular Java service loading.
+First, in the `spring-graalvm-native-configuration` module, you can see that they are hosted on types that implement the `org.springframework.graalvm.extension.NativeImageConfiguration` interface (defined by the feature).
+Implementations of this interface should be listed in a `src/main/resources/META-INF/services/org.springframework.graalvm.extension.NativeImageConfiguration` file, which the feature loads through regular Java service loading.
 
 Second, they can be put directly onto Spring configuration classes, and they are picked up by the feature.
 
@@ -73,9 +73,9 @@ The feature also chases down references between configurations (`@Import`) and l
 
 This means that, for any application, there is some 'tree' of configurations active with hints scattered across them.
 
-=== Structure of the `spring-boot-graal-configuration` module
+=== Structure of the `spring-graalvm-native-configuration` module
 
-In the `spring-boot-graal-configuration`, numerous package names look like Spring package names.
+In the `spring-graalvm-native-configuration`, numerous package names look like Spring package names.
 That is deliberate.
 Notice the use of direct class references in the hints rather than strings.
 This type safety is a little more robust.
@@ -111,7 +111,7 @@ If you are using a piece of Spring we don't have a sample for, this is likely to
 Usually, we do a few searches for references to the type that is missing, and those searches guide us to the configuration.
 
 . If there is already a `NativeImageConfiguration` implementation for that configuration, augment it with the extra type info.
-If there is not, create one and attach a `@NativeImageHint` to it, to identify the triggering configuration and the classes that need to be exposed.
+If there is not, create one, attach a `@NativeImageHint` to it to identify the triggering configuration and the classes that need to be exposed, and add it to the `META-INF/services/org.springframework.graalvm.extension.NativeImageConfiguration` .
 You also need to set the accessibility in the annotation (in the `@TypeInfo`).
 It is possible that more dependencies may need to be added to the configuration project to allow the direct class references.
 That is OK, so long as you ensure that they are provided scope.

spring-graalvm-native-docs/src/main/asciidoc/hybrid_feature_agent.adoc

@@ -91,19 +91,7 @@ Paste the following XML into the `pom.xml` file (we use it later to invoke the n
 ----
 ====
 
-The important part is the `<buildArgs>..</buildArgs>` block that shows the options we are passing to the `native-image` operation and the `spring-graalvm-native` feature.
-Those prefixed `-D` are aimed at the feature.
-
-NOTE: Notice the `--no-server` option.
-Like a Gradle daemon, the server here is supposed to help accelerate subsequent builds.
-Unfortunately, there is an https://github.com/oracle/graal/issues/1952[issue] where the server causes different results to come out of the compilation.
-In particular, we have seen logging disappear if the server is used to aid compilation.
-Hence using the server to aid compilation is turned off here.
-
-We can use the `-Dspring.native.remove-unused-autoconfig=true` option to evaluate some of the Spring Boot conditions at image-build time.
-For example, it applies to `@ConditionalOnClass`.
-Because `native-image` runs at a point when the full classpath is known, we can know for certain if a class is around.
-If it is not around, the auto-configuration conditional on that class can be discarded and not have an impact on the image startup. More details on options are discussed <<options,here>>.
+You can specify additional <<options>> via a `<configuration><buildArgs>..</buildArgs></configuration>` block.
 
 ===== Add the repository for `spring-graalvm-native`
 

spring-graalvm-native-docs/src/main/asciidoc/troubleshooting.adoc

@@ -19,48 +19,9 @@ The image can fail for a number of reasons. We have described the most common ca
 
 ==== Out of memory error when building the native image
 
-`native-image` consumes a lot of RAM.
-We have most success on 32G RAM desktop machines.
+`native-image` consumes a lot of RAM. We have most success on 32G RAM desktop machines.
 16G is possible for smaller samples but 8G machines are likely to hit problems more often.
-
-==== You get a weird crash
-
-If you get a "`weird crash`", check to see if you get the following error:
-
-====
-[source,bash]
-----
-Exception during JVMCI compiler initialization:
-Exception in thread "main": java.lang.ExceptionInInitializerError
-java.lang.ExceptionInInitializerError
-	at com.oracle.svm.core.hub.ClassInitializationInfo.initialize(ClassInitializationInfo.java:290)
-	at java.lang.Class.ensureInitialized(DynamicHub.java:496)
-	at java.lang.System.getenv(System.java:897)
-	at org.graalvm.libgraal.jni.JNIUtil.traceLevel(JNIUtil.java:268)
-	at org.graalvm.libgraal.jni.JNIUtil.trace(JNIUtil.java:292)
-	at org.graalvm.libgraal.jni.HotSpotToSVMScope.<init>(HotSpotToSVMScope.java:114)
-	at org.graalvm.compiler.hotspot.management.libgraal.HotSpotGraalManagement.defineClassesInHotSpot(HotSpotGraalManagement.java:170)
-	at org.graalvm.compiler.hotspot.management.libgraal.HotSpotGraalManagement.initialize(HotSpotGraalManagement.java:115)
-	at org.graalvm.compiler.hotspot.HotSpotGraalRuntime.<init>(HotSpotGraalRuntime.java:178)
-	at org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.createCompiler(HotSpotGraalCompilerFactory.java:156)
-	at org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.createCompiler(HotSpotGraalCompilerFactory.java:134)
-	at org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.createCompiler(HotSpotGraalCompilerFactory.java:52)
-	at jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.getCompiler(HotSpotJVMCIRuntime.java:599)
-	at jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.compileMethod(HotSpotJVMCIRuntime.java:667)
-	at com.oracle.svm.jni.JNIJavaCallWrappers.jniInvoke_VA_LIST_Nonvirtual:Ljdk_vm_ci_hotspot_HotSpotJVMCIRuntime_2_0002ecompileMethod_00028Ljdk_vm_ci_hotspot_HotSpotResolvedJavaMethod_2IJI_00029Ljdk_vm_ci_hotspot_HotSpotCompilationRequestResult_2(JNIJavaCallWrappers.java:0)
-Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 83 out of bounds for length 82
-	at com.oracle.svm.jni.functions.JNIFunctions.SetObjectArrayElement(JNIFunctions.java:683)
-	at java.lang.ProcessEnvironment.environ(ProcessEnvironment.java)
-	at java.lang.ProcessEnvironment.<clinit>(ProcessEnvironment.java:70)
-	at com.oracle.svm.core.hub.ClassInitializationInfo.invokeClassInitializer(ClassInitializationInfo.java:350)
-	at com.oracle.svm.core.hub.ClassInitializationInfo.initialize(ClassInitializationInfo.java:270)
-	... 14 more
-Error: Image build request failed with exit status 255
-----
-====
-
-This has been seen with Graal 20.0.
-The current workaround is to re-run your application, because the problem is intermittent.
+You can use `-H:+RemoveSaturatedTypeFlows` `native-image` option to reduce the amount of memory required.
 
 === The built image does not run
 
@@ -140,12 +101,6 @@ Currently it will warn about failing to specify `proxyBeanMethods=false` on comp
 there now to take it further than that as we observe common problems that could be more aggressively checked
 earlier.
 
-=== Where has my logging gone?
-
-In standard operation, `native-image` uses a server to optimize compilation speeds.
-Using the server has been known to produce native images that are missing logging.
-In this case, add `--no-server` to the arguments being passed to `native-image`.
-
 ==== No access hint found for import selector: XXX
 
 The feature chases down configuration references to other configurations (`@Import` usages).