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