Fwd: RFR (XXS): 8169643: [TESTBUG] GCBasher test fails with G1, CMS and Serial.

[Dmitry Fazunenko]

For the record, the final version of change:
http://cr.openjdk.java.net/~dfazunen/8169643/webrev.03/


Thanks
Dima
PS: JDK-8172556 <https://bugs.openjdk.java.net/browse/JDK-8172556> was 
submitted for the further improvement.


On 10.01.2017 22:58, Thomas Schatzl wrote:
> Hi Dima,
>
> On Tue, 2017-01-10 at 19:09 +0300, Dmitry Fazunenko wrote:
>> Hi Thomas,
>>
>>
>>
>> On 09.01.2017 17:38, Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On Mon, 2017-01-09 at 16:50 +0300, Dmitry Fazunenko wrote:
>>>> Hi in the new year!
>>>>
>>>> I got off line comment from Igor I. that  Xmx is not needed here
>>>> at
>>>> all.
>>>> And I agree with Igor.
>>>> GCBasher test was written many years ago, probably in those times
>>>> when default maximum heap size was 64MB.
>>>> So, specifying Xmx was necessary to increase heap to allocate
>>>> such a
>>>> big structure.
>>>> Nowadays, it's hard to find a host where maximum heap size set by
>>>> the
>>>> ergonomics will be less than 256MB.
>>>> GCBasher doesn't try to allocate all available memory, it just
>>>> allocates a big structure several time.
>>>> So, I think -Xmx option could be removed from this test:
>>>>
>>>> http://cr.openjdk.java.net/~dfazunen/8169643/webrev.02/
>>>>
>>>> Tested by RBT with and without -XX:-UseCompressedOpps
>>>>
>>>     I think the limitation has been introduced so that gcbasher does
>>> something useful, i.e. execute enough GCs. With a multi-GB heap at
>>> its
>>> disposal, I expect that the amount of GCs executed will be
>>> significantly lower than it is now.
>> Your arguments do certainly make sense.
>>> I prefer to have a 256M limit to none; and maybe the test could be
>>> run
>>> once with and without UseCompressedOops with appropriate heap sizes
>>> instead if there is enough cpu time in our testing infrastructure.
>> I suggest to start with original version of the fix:
>> http://cr.openjdk.java.net/~dfazunen/8169643/webrev.00/
>> (+ copyright updates)
>>
>> and submit an RFE to limit max heap size depending of
>> UseCompressedOops
>> value.
>> Such RFE could implemented much easily after integration of
>>       JDK-8172417 Verundy: Library to simplify using TestNG for
>> Hotspot  test development
>> Now it's a bit tricky to get known from the test the values of
>> external tags.
>>
>> Are you okay with that?
>   yes, thanks.
>
> Thomas
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20170111/47adbab8/attachment.htm>