RFR: 8009681: TEST_BUG: MethodExitReturnValuesTest.java fails with when there are unexpected background threads
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
Hi Mikael, It looks good. Thank you for figuring out how to make it more stable! BTW, the webrev frames mode does not work. Thanks, Serguei On 4/17/13 6:03 AM, Mikael Auno 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
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
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
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
+1 Thanks, /peter On Oct 18, 2013, at 12:56 PM, Staffan Larsen <staffan.larsen@oracle.com> wrote:
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
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.larsen@oracle.com> wrote:
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
participants (4)
-
Mikael Auno
-
Peter Allwin
-
serguei.spitsyn＠oracle.com
-
Staffan Larsen