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

[Vladimir Kozlov]

Thank you, Calvin

Note, if default CDS (not AppCDS) only care about java.base classes to have such warnings is fine 
with me. You solved exception problem - which is what I was concerned.

But I want to hear your opinion about Ioi's suggestion.

Thanks,
Vladimir

On 2/27/18 5:21 PM, Calvin Cheung wrote:
> 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
>>>