When GraalVM is building its points-to analysis graph using jdk11u-dev, we see the JVM process fail with the following NPE:

Caused by: java.lang.NullPointerException
        at java.base/java.lang.ClassValue$ClassValueMap.loadFromCache(ClassValue.java:535)
        at java.base/java.lang.ClassValue$ClassValueMap.probeHomeLocation(ClassValue.java:541)
        at java.base/java.lang.ClassValue.get(ClassValue.java:101)
        at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIMetaAccessContext.fromClass(HotSpotJVMCIMetaAccessContext.java:163)
        at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.fromClass(HotSpotJVMCIRuntime.java:339)
        at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedObjectTypeImpl.fromObjectClass(HotSpotResolvedObjectTypeImpl.java:83)
        at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotResolvedObjectTypeImpl.fromMetaspace(HotSpotResolvedObjectTypeImpl.java:97)
        at jdk.internal.vm.ci/jdk.vm.ci.hotspot.CompilerToVM.resolveTypeInPool(Native Method)
        at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotConstantPool.loadReferencedType(HotSpotConstantPool.java:727)
        at java.base/jdk.internal.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)

The issue is with ClassValue.ClassValueMap.cacheArray field, which can sometimes be seen as null.

A discussion was started in core-lib-devs (see https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068086.html ) which confirmed the possibility of such issue and ideas were provided for potential fixes.

As a side note: an Oracle GraalVM distribution uses a special Oracle Labs JDK as base that has a more modern JVMCI stack compared to JDK 11, hence this issue is unlikely to be seen in that environment.

A fix will be sent for RFR shortly.