RFR: JDK-8206007: nsk/jdb/exclude001 test is taking a long time on some builds

Gary Adams gary.adams at oracle.com
Fri Jul 6 12:54:58 UTC 2018


Yes, as part of the testing I went back to include windows-x64-debug
and found the crashes are removed by this simplification that
removes VirtualMachineManger. Once this fix is pushed, I'll close
8197938 as a duplicate.

On 7/5/18, 7:26 PM, serguei.spitsyn at oracle.com wrote:
> Hi Gary,
>
> One thing is not clear.
> The 8206007 is linked to the 8197938 which tags this test in the 
> ProblemList.txt.
> This line is removed:
> -vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java 8197938 windows-all
>
>
> but the bug 8197938 is still open.
> Is it intentional or some kind of a typo?
> Or maybe we have to close the 8197938 as a dup of 8206007?
>
> Otherwise, the fix looks good to me.
>
> Thank you for the extra testing!
>
> Thanks,
> Serguei
>
>
> On 7/5/18 07:48, Gary Adams wrote:
>> A simple test run using "exclude none" shows 625K methods are being 
>> observed.
>> The bulk of those methods were due to the last class accessed in the 
>> test - VirtualMachineManager.
>>
>> It's not important that this particular call is used. The test is 
>> simply demonstrating that
>> filters work for other packages than java and javax.
>>
>> This proposed fix uses a simpler lookup for GregorianCalendar.
>>
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8206007
>>   Webrev: http://cr.openjdk.java.net/~gadams/8206007/webrev.00/
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180706/5d368bb9/attachment.html>


More information about the serviceability-dev mailing list