RFR(XXS): 8213707: [TEST] vmTestbase/nsk/stress/except/except011.java failed due to wrong class name

[Zhengyu Gu]

On 11/11/18 4:47 PM, David Holmes wrote:
> On 11/11/2018 12:03 AM, Zhengyu Gu wrote:
>> Hi JC,
>>
>> Thanks for reviewing.
>>
>> On 11/9/18 10:24 PM, JC Beyler wrote:
>>> Hi Zhengyu,
>>>
>>> The fix looks good to me (I'm not a reviewer though ;-)), I was 
>>> wondering if the other forName methods don't have the same issue:
>>> except002.java:            trash = 
>>> Class.forName("nsk.stress.except.except002.except002$Abra$Cadabra"); 
>>> //   correct - should pass
>>> except002.java://          trash = 
>>> Class.forName("nsk.stress.except.except002.except002.Abra.Cadabra"); 
>>> // incorrect - should fail
>>> except003.java://          trash = 
>>> Class.forName("nsk.stress.except.except003.except003$Abra$Cadabra"); 
>>> //   correct - should pass
>>> except003.java:            trash = 
>>> Class.forName("nsk.stress.except.except003.except003.Abra.Cadabra"); 
>>> // incorrect - should fail
>>
>> I got except002 timed out, has yet gotten to it. except003 passed, 
>> will check if it is due to OOM.
> 
> I would have fixed them anyway as they are obviously incorrect.

Bug filed: https://bugs.openjdk.java.net/browse/JDK-8213718

Thanks,

-Zhengyu

> 
> David
> 
>> This one happens to be low hanging fruit :-)
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>>
>>> Seems like they also have an extra exceptXXX in the name, no? 
>>> Could/Should we try to fix them at the same time?
>>> Jc
>>>
>>>
>>> On Fri, Nov 9, 2018 at 6:00 PM Zhengyu Gu <zgu at redhat.com 
>>> <mailto:zgu at redhat.com>> wrote:
>>>
>>>     Thanks for reviewing, David.
>>>
>>>     On 11/9/18 5:58 PM, David Holmes wrote:
>>>      > Looks good - thanks for finding and fixing.
>>>      >
>>>      > I see cases internally where we fail because of this:
>>>      >
>>>      > Failure: ExceptionInInitializerError: target class not found
>>>      >
>>>      > but no bug was ever filed. I wonder if we will now fail because
>>>     of the
>>>      > OOME ...
>>>
>>>     Actually, it has to avoid OOME to get to here.
>>>
>>>     Several nsk/stress/except tests, e.g. except001, except002 and etc.
>>>     depend on quick OOME to pass.
>>>
>>>     Shenandoah has mechanism to gradually slow down allocation, so it is
>>>     more resist to OOME. Unfortunately, it usually fails due to timeout.
>>>
>>>     I am wondering of the usefulness of these tests.
>>>
>>>     Thanks,
>>>
>>>     -Zhengyu
>>>
>>>      >
>>>      > Thanks,
>>>      > David
>>>      >
>>>      > On 10/11/2018 7:43 AM, Zhengyu Gu wrote:
>>>      >> Please review this trivial fix.
>>>      >>
>>>      >> Currently, only Shenandoah experiences the failure, since 
>>> other GCs
>>>      >> run out Java heap memory, then the rest of test is skipped.
>>>      >>
>>>      >> E.g.
>>>      >> pool[125131189]=new Object(); // elapsed 10.287s
>>>      >> pool[126306334]=new Object(); // elapsed 7.947s
>>>      >> Heap seems exhausted - OutOfMemoryError thrown.
>>>      >> Skipped: ExceptionInInitializerError: thrown OutOfMemoryError
>>>      >> Test passed.
>>>      >>
>>>      >>
>>>      >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213707
>>>      >> Webrev: http://cr.openjdk.java.net/~zgu/8213707/webrev.00/
>>>      >>
>>>      >> Thanks,
>>>      >>
>>>      >> -Zhengyu
>>>
>>>
>>>
>>> -- 
>>>
>>> Thanks,
>>> Jc