RFR(S): 8193434: [GRAAL] Graal classes are not loaded with -Xshare:dump

[Calvin Cheung]

Hi Vladimir,

On 2/27/18, 2:49 PM, Vladimir Kozlov wrote:
> Hi Calvin,
>
> I tried to run your patch with test case from bug and I got next 
> warnings about Graal classes:
Thanks for trying the patch and noticing the warnings.
>
> Loading classes to share: done.
> [0.935s][info][cds       ] Shared spaces: preloaded 1187 classes
> Rewriting and linking classes ...
> Preload Warning: Verification failed for 
> org.graalvm.compiler.hotspot.replacements.arraycopy.ArrayCopyNode
> Preload Warning: Verification failed for 
> org.graalvm.compiler.hotspot.replacements.arraycopy.ArrayCopyWithSlowPathNode
You'll see more info if you enable the following logging: 
-Xlog:class+init=info -Xlog:class+load=debug
[3.308s][info ][class,load] 
org.graalvm.compiler.hotspot.replacements.arraycopy.ArrayCopyNode 
source: jrt:/jdk.internal.vm.compiler
[3.308s][debug][class,load]  klass: 0x00000008c0128f50 super: 
0x00000008c0128880 interfaces: 0x00000008c00d50e0 loader: [class loader 
0x00007fdff074a460 a 
'jdk/internal/loader/ClassLoaders$PlatformClassLoader'{0x000000046425cf68}] 
bytes: 2866 checksum: af714378

super: 0x00000008c0128880 is:

[3.305s][info ][class,load] 
org.graalvm.compiler.replacements.nodes.BasicArrayCopyNode source: 
jrt:/jdk.internal.vm.compiler
[3.305s][debug][class,load]  klass: 0x00000008c0128880 super: 
0x00000008c00d93a8 interfaces: 0x00000008c00d2948 0x00000008c00d7780 
0x00000008c00d6a78 0x00000008c00d50e0 0x00000008c00d8a98 loader: [class 
loader 0x00007fdff074a460 a 
'jdk/internal/loader/ClassLoaders$PlatformClassLoader'{0x000000046425cf68}] 
bytes: 13151 checksum: 922d7ccf

BasicArrayCopyNode failed verification:

[4.189s][info ][class,init] Start class verification for: 
org.graalvm.compiler.replacements.nodes.BasicArrayCopyNode
[4.191s][info ][class,init] 1038 Initializing 
'java/lang/ClassNotFoundException'(no method) (0x00000008c00043a8)
[4.191s][info ][class,init] 1039 Initializing 
'java/lang/NoClassDefFoundError'(no method) (0x00000008c00048c8)
[4.191s][info ][class,init] Verification for 
org.graalvm.compiler.replacements.nodes.BasicArrayCopyNode has exception 
pending java.lang.NoClassDefFoundError

After some debugging, the NoClassDefFoundError was referring to the 
following class:
org/graalvm/compiler/nodes/virtual/VirtualObjectNode

The NoClassDefFoundError was thrown in 
SystemDictionary::handle_resolution_exception() at line #221.

It is because the VirtualObjectNode was loaded after the force init of 
JVMCI runtime. At that time, the _force_init_jvmci_runtime flag had been 
reset to false and so in SystemDictionary::resolve_from_stream(), it 
didn't load the class but threw the CNFE.
>
> I see that Graal classes are loaded:
That's good.
>
> [0.717s][info][class,load] 
> org.graalvm.compiler.hotspot.replacements.arraycopy.ArrayCopyWithSlowPathNode 
> source: jrt:/jdk.internal.vm.compiler
> [0.718s][info][class,load] 
> org.graalvm.compiler.hotspot.replacements.arraycopy.ArrayCopyNode 
> source: jrt:/jdk.internal.vm.compiler
>
> Is it because CDS is limited to java.base? With UseAppCDS I don't have 
> this problem.
If the UseAppCDS is enabled, it will load classes defined to other class 
loaders in additional to the null class loader.
Without the fix, the UseAppCDS can be used as a workaround.

thanks,
Calvin


>
> Thanks,
> vladimri
>
> On 2/27/18 11:01 AM, Calvin Cheung wrote:
>> bug: https://bugs.openjdk.java.net/browse/JDK-8193434
>>
>> webrev: http://cr.openjdk.java.net/~ccheung/8193434/webrev.01/
>>
>> java -Xshare:dump -Xlog:cds,cds+hashtables 
>> -XX:+UnlockDiagnosticVMOptions -XX:SharedArchiveFile=./test.jsa 
>> -Xbatch -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI 
>> -XX:+UseJVMCICompiler -Djvmci.Compiler=graal
>>
>> The above command causes the CNFE to be thrown in 
>> SystemDictionary::resolve_from_stream() during CDS dump time.
>> The proposed change is to add a _force_init_jvmci_runtime flag which 
>> is set at the beginning of JVMCIRuntime::force_initialization() and 
>> reset at the end of the initialization. The flag will be checked in 
>> SystemDictionary::resolve_from_stream() so that it will not throw 
>> CNFE during the eager initialization of JVMCI runtime during vm init.
>>
>> The proposed change passed hs-tier1 through hs-tier3 testing on 
>> linux-x64, windows-x64, sparcv9, and Mac OS X.
>>
>> thanks,
>> Calvin
>>