Looks good! Thanks, /Staffan On 16 okt 2013, at 14:04, Mikael Auno <mikael.auno@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@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