RFR: 8009681: TEST_BUG: MethodExitReturnValuesTest.java fails with when there are unexpected background threads

Peter Allwin peter.allwin at oracle.com
Fri Oct 18 04:09:31 PDT 2013


+1

Thanks,
/peter

On Oct 18, 2013, at 12:56 PM, Staffan Larsen <staffan.larsen at oracle.com> wrote:

> Looks good!
> 
> Thanks,
> /Staffan
> 
> On 16 okt 2013, at 14:04, Mikael Auno <mikael.auno at oracle.com> wrote:
> 
>> This bug got a bit lost from my radar after vacation, but I've picked it
>> again now. I've moved Arrays.asList() as suggested. In further testing of the fix though, I found that the include list is not enough, as one of the expected method exit events is from String.intern(), which might also be called from background threads. To counter this, I added a thread filter to the events. This also has the added benefit of speeding up the test significantly (from 90 seconds to about 5 seconds) in the cases where there are background threads interfering.
>> 
>> Also added to this webrev is a fix for MethodEntryExitEvents.java which had exactly the same problem and a similar test design as MethodExitReturnValuesTest.java.
>> 
>> The updated webrev is at http://cr.openjdk.java.net/~allwin/auno/8009681/webrev.00/.
>> 
>> Thanks,
>> Mikael
>> 
>> On 2013-05-28 08:46, Staffan Larsen wrote:
>>> Looks good.
>>> 
>>> You could optimize it a bit by not doing the Arrays.asList() on every
>>> methodExit event.
>>> 
>>> /Staffan
>>> 
>>> On 17 apr 2013, at 15:03, Mikael Auno <mikael.auno at oracle.com>
>>> wrote:
>>> 
>>>> Hi, I'd like some reviews on
>>>> http://cr.openjdk.java.net/~nloodin/8009681/webrev.01/ for
>>>> JDK-8009681 (http://bugs.sun.com/view_bug.do?bug_id=8009681).
>>>> 
>>>> The issue here is that when MethodExitReturnValuesTest hooks into
>>>> MethodExit events through JDI it uses an exclude list to filter out
>>>> classes from which it is not interested in these events. This is
>>>> bound to break over and over again as new features are added to the
>>>> JDK. I've changed the test to use an include list instead,
>>>> containing only the handful of classes the test is actually
>>>> interested in.
>>>> 
>>>> Thanks,
>>>> Mikael
>>> 
>> 
> 



More information about the serviceability-dev mailing list