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

[Ioi Lam]

As I commented on the bug report, we should improve the error message. 
Also, maybe we can force GC to allow the test to run with less heap.

A 3GB heap seems excessive. I was able to run the test with -Xmx256M on 
Linux.

Also, I don't understand what you mean by "all observed allocations were 
done in the lower 2G range.". Why would heap fragmentation be related to 
the location of the heap?

Thanks

- Ioi


On 11/26/18 3:23 PM, Jiangli Zhou wrote:
> 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
>>>
>>
>