Thanks for the reviews.
Mikael
On 2013-10-18 13:09, Peter Allwin wrote:
+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
