RFR (trivial): 8214217: [TESTBUG] runtime/appcds/LotsOfClasses.java failed on solaris sparcv9

[Jiangli Zhou]

Hi Ioi,


On 11/26/18 2:00 PM, Ioi Lam wrote:
> Hi Jiangli,
>
> -Xms3G will most likely fail on 32-bit platforms.

We can make the change for 64-bit platform only since it's a 64-bit 
problem only. We do not archive java objects with 32-bit platform.
>
> BTW, why would this test fail only on Solaris and not linux? The test 
> doesn't specify heap size, so the initial heap size setting is picked 
> by Ergonomics. Can you reproduce the failure on Linux by using the 
> same heap size settings used by the failed Solaris runs?

The failed Solaris run didn't set heap size explicitly. The heap size 
was determined by GC ergonomics, as you pointed out above. I ran the 
test this morning on the same solaris sparc machine using the same 
binary that was reported for the issue. In my test run, a very large 
heap (>26G) was used according to the gc region logging output. So the 
test didn't run into the heap fragmentation issue. All observed 
allocations were done in the lower 2G range.

I don't think it is a Solaris only issue. If the heap size is small 
enough, you could run into the issue on all supported platforms. The 
issue could appear to be intermittent due to alignment and GC activities 
even with the same heap size that the failure was reported.

On linux x64 machine, I can force the test to failure with the 
fragmentation error with 200M java heap.
>
> I think it's better to find out the root cause than just to mask it. 
> The purpose of LotsOfClasses.java is to stress the system to find out 
> potential bugs.

I think this is a test issue, but not a CDS/GC issue. The test loads 
 >20000 classes, but doesn't set java heap size. Relying on GC 
ergonomics to determine the 'right' heap size is incorrect in this case 
since dumping objects requires consecutive gc regions. Specifying the GC 
heap size explicitly doesn't 'mask' the issue, but is the right thing to 
do. :)

Thanks,
Jiangli

>
> Thanks
>
> - Ioi
>
>
> On 11/26/18 1:41 PM, Jiangli Zhou wrote:
>> Please review the following test fix, which sets the java heap size 
>> to 3G for dumping with large number of classes.
>>
>>   webrev: http://cr.openjdk.java.net/~jiangli/8214217/webrev.00/
>>
>>   bug: https://bugs.openjdk.java.net/browse/JDK-8214217
>>
>> Tested with tier1 and tier3. Also ran the test 100 times on 
>> solaris-sparcv9 via mach5.
>>
>> Thanks,
>>
>> Jiangli
>>
>