+1 Thanks, /peter
On Oct 18, 2013, at 12:56 PM, Staffan Larsen <staffan.lar...@oracle.com> wrote: > 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 >>> >> >
