RFR (trivial) 8208074: [TESTBUG] vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java failed with NullPointerException

[coleen.phillimore at oracle.com]

On 7/31/18 1:43 PM, Chris Plummer wrote:
> Hi Coleen,
>
> I just realized that there is also 
> https://bugs.openjdk.java.net/browse/JDK-8208234 filed for this test 
> last week. It results in an OOME. I think it's the same issue, but 
> just want check with you. Please close it as a dup if you think it is 
> the same.

Yes, I think this is the same thing.  One call to InMemoryCompiler 
shouldn't OOME but multiple concurrent calls could.
thanks,
Coleen
>
> thanks,
>
> Chris
>
> On 7/31/18 9:13 AM, Chris Plummer wrote:
>> On 7/31/18 5:06 AM, coleen.phillimore at oracle.com wrote:
>>>
>>>
>>> On 7/31/18 3:29 AM, serguei.spitsyn at oracle.com wrote:
>>>> Hi Chris,
>>>>
>>>> Good catch.
>>>> It is possible that this webrev does not fix the JDK-8202896.
>>>> The JDK-8202896 is about timeouts which are normally intermittent 
>>>> (is it right?).
>>>>
>>>> There are two options here:
>>>>   A: close 8202896 as a dup of 8208074
>>>>   B: keep the test problem listed and labeled with 8202896
>>>>
>>>> Let's wait for Coleen's answer.
>>>
>>> I closed https://bugs.openjdk.java.net/browse/JDK-8206076 (timeouts 
>>> with -Xcomp)
>>>  as a duplicate of
>>> https://bugs.openjdk.java.net/browse/JDK-8203820 (where I took 
>>> InMemoryCompiler out of the threads)
>>> because that's where the attempted fix was.
>>>
>>> I think
>>> https://bugs.openjdk.java.net/browse/JDK-8202896 (getting Too many 
>>> open files intermittently)
>>> should be closed as a duplicate too because it's the same root cause.
>>>
>>> And this one:
>>> https://bugs.openjdk.java.net/browse/JDK-8208074 (broken fix)
>>> fixes my fix and will remove the test from the ProblemList.txt.
>>>
>>> I believe it should be removed fromt he problem list because I don't 
>>> think it will time out or intermittently fail again for the same 
>>> reason.  If it times out or fails for a different reason, we should 
>>> file a whole new bug, with that specific analysis.
>>>
>>> Thanks,
>>> Coleen
>>
>> Hi Coleen,
>>
>> That all sounds reasonable. Thanks for cleaning up the bug situation.
>>
>> Chris
>>>
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>>
>>>> On 7/31/18 00:16, Chris Plummer wrote:
>>>>> Sorry, I thought this had been pushed already, but it hasn't. But 
>>>>> it still looks like JDK-8202896 should be closed as a dup, and 
>>>>> it's unclear to me if JDK-8206076 has been fixed and this test can 
>>>>> be removed from the problem list.
>>>>>
>>>>> Chris
>>>>>
>>>>> On 7/30/18 6:34 PM, Chris Plummer wrote:
>>>>>> Hi Coleen,
>>>>>>
>>>>>> Now that this had been pushed, I assume JDK-8202896 should be 
>>>>>> closed as a dup. And what about JDK-8206076? Is it fixed by this 
>>>>>> change also?
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>> On 7/30/18 1:49 PM, coleen.phillimore at oracle.com wrote:
>>>>>>> Summary: fixed refactoring caused by JDK-8203820
>>>>>>>
>>>>>>> open webrev at 
>>>>>>> http://cr.openjdk.java.net/~coleenp/8208074.01/webrev
>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8208074
>>>>>>>
>>>>>>> Ran the test in mach5 on all Oracle supported platforms. Also 
>>>>>>> took the test out of ProblemList.txt because JDK-8203820 fixes 
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202896.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Coleen
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>