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

Mikael Auno mikael.auno at oracle.com
Tue Oct 22 06:22:34 PDT 2013


Thanks for the reviews.

Mikael

On 2013-10-18 13:09, Peter Allwin wrote:
> +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