GraalVM 20.3.0 webinar tomorrow: https://twitter.com/graalvm/status/1328734753349103617
Looks like 20.3.0 is now live: https://www.graalvm.org/release-notes/20_3/
Hadn’t noticed the https://www.graalvm.org/docs/tools/dashboard/?ojr=help%3Btopic%3Dcode-size-histogram.md before, looking forward to giving it a whirl.
Interesting: > Added support for method handles that represent a call to a single method accessible by the Reflection API Maybe this fixes the issue with clojure.lang.Reflector
@borkdude, have you tried a compile yet? I’m doing some tests on rewrite-cljc. Under GraalVM 20.3.0 jdk8 https://github.com/oracle/graal/issues/2898#issuecomment-704233795. When I remove
--initialize-at-run-time=java.lang.Math$RandomNumberGeneratorHolder
the compile works.@lee I'm now trying. I'm indeed running into this error.
Released clj-reflector-graal-java11-fix for GraalVM 20.3.0 https://github.com/borkdude/clj-reflector-graal-java11-fix
which still seems necessary, removing it caused this error, which seems a bit different than previous versions:
Error: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: Invoke with MethodHandle argument could not be reduced to at most a single call or single field access. The method handle must be a compile time constant, e.g., be loaded from a `static final` field. Method that contains the method handle invocation: java.lang.invoke.Invokers$Holder.invoke_MT(Object, Object, Object, Object)
To enable method handles that do not require LambdaForm interpretation (e.g. because of a call to MethodHandle.bindTo()) or to diagnose the issue, you can add the option --report-unsupported-elements-at-runtime. The error is then reported at run time when the invoke is executed and the method handle has to be interpreted.