RFR(XS) 8240548 [TESTBUG] CDS NoClassToArchive.java fails with Graal

[Ioi Lam]

On 3/9/20 9:43 AM, Mandy Chung wrote:
> Hi Ioi,
>
> On 3/8/20 9:52 PM, Ioi Lam wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8240548
>> http://cr.openjdk.java.net/~iklam/jdk15/8240548-NoClassToArchive.graal.v01/ 
>>
>>
>
> 65 if (output.getStdout().contains("jrt:/") ||
> 66 output.getStdout().contains("unsafe anonymous") ||
> 67 output.getStdout().contains("Unsafe anonymous")) {
Hi Mandy, thanks for the review.

These lines are supposed to look for classes that are not loaded from 
CDS, with patterns like this:

[0.050s][info ][class,load] LambHello$$Lambda$1/0x0000000800b6d840 
source: LambHello
[0.050s][debug][class,load]  klass: 0x0000000800b6d840 super: 
0x0000000800003440 interfaces: 0x00000008000e2b30 loader: [loader data: 
0x00007f851c30bb50 for instance a 
'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x0000000451017380} 
unsafe anonymous] bytes: 315 checksum: aa68e916

but the "unsafe anonymous" part is no longer printed out by the nestmate 
branch due to the hidden class changes.

In the latest fix, I changed the code to test for the "bytes: 315 
checksum: aa68e916" part of the log, which is more reliable in finding 
out any non-CDS classes.

http://cr.openjdk.java.net/~iklam/jdk15/8240548-NoClassToArchive.graal.v02/

Thanks
- Ioi


> Do you mean to filter hidden classes? there are duplicated checks for 
> unsafe anonymous. LMF will be defining hidden classes instead of VM 
> anonymous class by JEP 371. Mandy
>> This test should not be executed with graal.
>>
>> This test started failing in valhalla/nestmate because the string
>> "unsafe anonymous" is no longer printed by -Xlog:class+load=trace. 
>> However,
>> the underlying problem is unrelated to nestmate. So I will fix the 
>> test in
>> the mainline jdk/jdk and it can be synced down to nestmate.
>>
>> The test assumes that when "java -version" is executed, only a very 
>> limited
>> number of classes are loaded, and all of those are loaded from the 
>> default
>> shared archive.
>>
>> However, when graal is used as the JIT, many extra classes are loaded
>> during VM start-up. Some of those are loaded dynamically from jrt:/.
>> Some classes are also defined by LambdaMetafactory. This causes 
>> complexity
>> that cannot be easily handled by this test.
>>
>> The VM code covered by this test can be sufficiently tested with 
>> C1/C2. So
>> there's no need to bend over backwards to run this test with graal.
>>
>> Thanks
>> - Ioi
>