Graal: [native-image] Lambdas get always initialized at image build time.

Created on 30 Apr 2019  Â·  7Comments  Â·  Source: oracle/graal

This causes problems with class initialization as instances of classes that should be initialized at run time get in the image heap. This happens when a lambda inherits a FunctionalInterface that has default methods and static fields. An example of such failure in Micronaut is:

[fresh-graal:7347]    classlist:   3,545.47 ms
[fresh-graal:7347]        (cap):   1,083.99 ms
[fresh-graal:7347]        setup:   2,182.66 ms
Warning: RecomputeFieldValue.FieldOffset automatic substitution failed. The automatic substitution registration was attempted because a call to sun.misc.Unsafe.objectFieldOffset(Field) was detected in the static initializer of io.netty.buffer.AbstractReferenceCountedByteBuf. Detailed failure reason(s): Could not determine the field where the value produced by the call to sun.misc.Unsafe.objectFieldOffset(Field) for the field offset computation is stored. The call is not directly followed by a field store or by a sign extend node followed directly by a field store. 
[fresh-graal:7347]     analysis:  24,348.73 ms
Error: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: No instances are allowed in the image heap for a class that is initialized or reinitialized at image runtime: io.micronaut.core.bind.ArgumentBinder$BindingResult$1
native-image

Most helpful comment

All 7 comments

@vjovanov is this fix in 19.3.1 ? I'm still getting this problem in https://github.com/oracle/graal/issues/2135

I am looking into it.

Yes, please give me a day to extract the code and make an example project that shows the problem

JDK 11, GraalVM 20.0 works for me. It fails at runtime, but I think that is due to wrong reflection config. I applied the following diff to the build:

                                        <buildArgs>
                                                -H:ReflectionConfigurationFiles=../reflect.json
                                                -H:-UseServiceLoaderFeature --no-fallback
-                                               --report-unsupported-elements-at-runtime
-                                               --initialize-at-build-time=com.sun.xml.internal.bind.v2.ContextFactory
-                                               --initialize-at-build-time=com.sun.xml.bind.v2.ContextFactory
-                                               --initialize-at-build-time=Main$Data
+                                                --allow-incomplete-classpath
                                                -H:IncludeResourceBundles=com.sun.xml.bind.v2.model.impl.Messages
                                                -H:IncludeResourceBundles=javax.xml.bind.Messages                                               
                                                -H:+TraceClassInitialization

That project doesn't demonstrate the bug, allowing incomplete classpath isnt a fix . Maybe you could point me to instructions on how to build version 20 from source?

Sent from ProtonMail mobile

-------- Original Message --------
On Feb 19, 2020, 5:25 AM, Vojin Jovanovic wrote:

JDK 11, GraalVM 20.0 works for me. It fails at runtime, but I think that is due to wrong reflection config. I applied the following diff to the build:


-H:ReflectionConfigurationFiles=../reflect.json
-H:-UseServiceLoaderFeature --no-fallback

  • --report-unsupported-elements-at-runtime
  • --initialize-at-build-time=com.sun.xml.internal.bind.v2.ContextFactory
  • --initialize-at-build-time=com.sun.xml.bind.v2.ContextFactory
  • --initialize-at-build-time=Main$Data
  • --allow-incomplete-classpath
    -H:IncludeResourceBundles=com.sun.xml.bind.v2.model.impl.Messages
    -H:IncludeResourceBundles=javax.xml.bind.Messages
    -H:+TraceClassInitialization

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

Was this page helpful?
0 / 5 - 0 ratings