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