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

[Mikael Auno]

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
>