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.a...@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
