From jeremymanson at google.com Thu May 1 00:24:17 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 30 Apr 2014 17:24:17 -0700 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DB145.5030109@oracle.com> References: <524DB145.5030109@oracle.com> Message-ID: Did the new bugs get filed for this? I'm triggering this check with a redefined class (from the bootclasspath, if that matters). To investigate it a little, I instrumented StackTraceElement::create thus: oop java_lang_StackTraceElement::create(methodHandle method, int bci, TRAPS) { Handle mirror (THREAD, method->method_holder()->java_mirror()); int method_id = method->method_idnum(); InstanceKlass* holder = method->method_holder(); Method* m = holder->method_with_idnum(method_id); Method* mp = holder->find_method(method->name(), method->signature()); method->print_name(); fprintf(stderr, " method = %p id = %d method' = %p \n", m, method_id, mp); return create(mirror, method_id, method->constants()->version(), bci, THREAD); } m is null, and mp isn't. method->print_name works fine. This makes me feel that the idnum array is out of date somehow. Before I go down the rabbit hole and try to figure out why that is, does someone else know why? Thanks! Jeremy On Thu, Oct 3, 2013 at 11:02 AM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > Summary: Redefined class in stack trace may not be found by method_idnum > so handle null. > > This is a simple change. I had another change to save the method name (as > u2) in the backtrace, but it's not worth the extra footprint in backtraces > for this rare case. > > The root problem was that we save method_idnum in the backtrace (u2) > instead of Method* to avoid Method* from being redefined and deallocated. > I made a change to InstanceKlass::method_from_idnum() to return null > rather than the last method in the list, which causes this crash. Dan and > I went down the long rabbit-hole of why method_idnum is changed for > obsolete methods and we think there's some cleanup and potential bugs in > this area. But this is not that change. I'll file another bug to continue > this investigation for jdk9 (or 8uN). > > Staffan created a test - am including core-libs for the review request. > Also tested with all of the vm testbase tests, mlvm tests, and > java/lang/instrument tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ > bug link https://bugs.openjdk.java.net/browse/JDK-8025238 > > test case for jdk8 repository: > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk > > Thanks, > Coleen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Thu May 1 01:34:02 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 30 Apr 2014 21:34:02 -0400 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: References: <524DB145.5030109@oracle.com> Message-ID: <5361A48A.6090104@oracle.com> We didn't file any bugs because I don't remember finding anything specific, other than "gosh that code is scary" and "I wish we didn't have to do this". If you find a null 'm' below and call m->print() is the method "obsolete"? Coleen On 4/30/14, 8:24 PM, Jeremy Manson wrote: > Did the new bugs get filed for this? > > I'm triggering this check with a redefined class (from the > bootclasspath, if that matters). To investigate it a little, I > instrumented StackTraceElement::create thus: > > oop java_lang_StackTraceElement::create(methodHandle method, int bci, > TRAPS) { > Handle mirror (THREAD, method->method_holder()->java_mirror()); > int method_id = method->method_idnum(); > > InstanceKlass* holder = method->method_holder(); > Method* m = holder->method_with_idnum(method_id); > Method* mp = holder->find_method(method->name(), method->signature()); > method->print_name(); > fprintf(stderr, " method = %p id = %d method' = %p \n", m, > method_id, mp); > return create(mirror, method_id, method->constants()->version(), > bci, THREAD); > } > > m is null, and mp isn't. method->print_name works fine. This makes > me feel that the idnum array is out of date somehow. Before I go down > the rabbit hole and try to figure out why that is, does someone else > know why? > > Thanks! > > Jeremy > > > > On Thu, Oct 3, 2013 at 11:02 AM, Coleen Phillimore > > > wrote: > > Summary: Redefined class in stack trace may not be found by > method_idnum so handle null. > > This is a simple change. I had another change to save the method > name (as u2) in the backtrace, but it's not worth the extra > footprint in backtraces for this rare case. > > The root problem was that we save method_idnum in the backtrace > (u2) instead of Method* to avoid Method* from being redefined and > deallocated. I made a change to > InstanceKlass::method_from_idnum() to return null rather than the > last method in the list, which causes this crash. Dan and I went > down the long rabbit-hole of why method_idnum is changed for > obsolete methods and we think there's some cleanup and potential > bugs in this area. But this is not that change. I'll file > another bug to continue this investigation for jdk9 (or 8uN). > > Staffan created a test - am including core-libs for the review > request. Also tested with all of the vm testbase tests, mlvm > tests, and java/lang/instrument tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ > > bug link https://bugs.openjdk.java.net/browse/JDK-8025238 > > test case for jdk8 repository: > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk > > > Thanks, > Coleen > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremymanson at google.com Thu May 1 05:13:01 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 30 Apr 2014 22:13:01 -0700 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <5361A48A.6090104@oracle.com> References: <524DB145.5030109@oracle.com> <5361A48A.6090104@oracle.com> Message-ID: I'll have to check tomorrow, but it's not unreasonable to think that it is. It is a stack frame on a thread that was started before the class redefinition happened. I guess the question is: what makes sense to do here? I put in a workaround such that, if m is null, method_id is replaced by the method_id from mp. I could refactor the code a little, such that the full version of create() took the Method* instead of taking the method_id, and pass it mp if m is null. It'll be hard to get you a reproducible test case, though. This only happens in an integration test in our test cluster. Debugging was painful. Jeremy On Wed, Apr 30, 2014 at 6:34 PM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > We didn't file any bugs because I don't remember finding anything > specific, other than "gosh that code is scary" and "I wish we didn't have > to do this". > > If you find a null 'm' below and call m->print() is the method "obsolete"? > > Coleen > > > On 4/30/14, 8:24 PM, Jeremy Manson wrote: > > Did the new bugs get filed for this? > > I'm triggering this check with a redefined class (from the > bootclasspath, if that matters). To investigate it a little, I > instrumented StackTraceElement::create thus: > > oop java_lang_StackTraceElement::create(methodHandle method, int bci, > TRAPS) { > Handle mirror (THREAD, method->method_holder()->java_mirror()); > int method_id = method->method_idnum(); > > InstanceKlass* holder = method->method_holder(); > Method* m = holder->method_with_idnum(method_id); > Method* mp = holder->find_method(method->name(), method->signature()); > method->print_name(); > fprintf(stderr, " method = %p id = %d method' = %p \n", m, method_id, > mp); > return create(mirror, method_id, method->constants()->version(), bci, > THREAD); > } > > m is null, and mp isn't. method->print_name works fine. This makes me > feel that the idnum array is out of date somehow. Before I go down the > rabbit hole and try to figure out why that is, does someone else know why? > > Thanks! > > Jeremy > > > > On Thu, Oct 3, 2013 at 11:02 AM, Coleen Phillimore < > coleen.phillimore at oracle.com> wrote: > >> Summary: Redefined class in stack trace may not be found by method_idnum >> so handle null. >> >> This is a simple change. I had another change to save the method name >> (as u2) in the backtrace, but it's not worth the extra footprint in >> backtraces for this rare case. >> >> The root problem was that we save method_idnum in the backtrace (u2) >> instead of Method* to avoid Method* from being redefined and deallocated. >> I made a change to InstanceKlass::method_from_idnum() to return null >> rather than the last method in the list, which causes this crash. Dan and >> I went down the long rabbit-hole of why method_idnum is changed for >> obsolete methods and we think there's some cleanup and potential bugs in >> this area. But this is not that change. I'll file another bug to continue >> this investigation for jdk9 (or 8uN). >> >> Staffan created a test - am including core-libs for the review request. >> Also tested with all of the vm testbase tests, mlvm tests, and >> java/lang/instrument tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8025238 >> >> test case for jdk8 repository: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >> >> Thanks, >> Coleen >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shanliang.jiang at oracle.com Fri May 2 09:17:11 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 02 May 2014 11:17:11 +0200 Subject: RFR 8038322: CounterMonitorDeadlockTest.java fails intermittently, presumed deadlock Message-ID: <53636297.5050403@oracle.com> Please review this test fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8038322 Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8038322/00/ The test had a timeout of 500*10 ms, better to remove this timeout and to wait the harness timeout. Thanks, Shanliang From daniel.fuchs at oracle.com Fri May 2 10:40:49 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 02 May 2014 12:40:49 +0200 Subject: RFR 8038322: CounterMonitorDeadlockTest.java fails intermittently, presumed deadlock In-Reply-To: <53636297.5050403@oracle.com> References: <53636297.5050403@oracle.com> Message-ID: <53637631.50704@oracle.com> Hi Shanliang, This looks reasonable to me. Another possibility could have been to use the timeout factor to adapt the delay of Thread.sleep in the loop. What you have might be more reliable, but it also means that if the test ever fails in timeout again then it could be more difficult to diagnose what was wrong. Maybe you should add a trace before entering and after leaving any of your two loops, so that you at least will know where the test was being blocked? best regards, -- daniel On 5/2/14 11:17 AM, shanliang wrote: > Please review this test fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8038322 > Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8038322/00/ > > > The test had a timeout of 500*10 ms, better to remove this timeout and > to wait the harness timeout. > > Thanks, > Shanliang From shanliang.jiang at oracle.com Fri May 2 11:20:36 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 02 May 2014 13:20:36 +0200 Subject: RFR 8038322: CounterMonitorDeadlockTest.java fails intermittently, presumed deadlock In-Reply-To: <53637631.50704@oracle.com> References: <53636297.5050403@oracle.com> <53637631.50704@oracle.com> Message-ID: <53637F84.50206@oracle.com> Daniel Fuchs wrote: > Hi Shanliang, > > This looks reasonable to me. > Another possibility could have been to use the timeout factor > to adapt the delay of Thread.sleep in the loop. Yes we could adapt our timeout, but it is simpler to use the testing harness timeout. > > What you have might be more reliable, but it also means > that if the test ever fails in timeout again then it could > be more difficult to diagnose what was wrong. > > Maybe you should add a trace before entering > and after leaving any of your two loops, so that you > at least will know where the test was being blocked? Yes, absolutely useful to add trace: http://cr.openjdk.java.net/~sjiang/JDK-8038322/01/ Thanks, Shanliang > > best regards, > > -- daniel > > On 5/2/14 11:17 AM, shanliang wrote: >> Please review this test fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8038322 >> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8038322/00/ >> >> >> The test had a timeout of 500*10 ms, better to remove this timeout and >> to wait the harness timeout. >> >> Thanks, >> Shanliang > From daniel.fuchs at oracle.com Fri May 2 12:11:08 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 02 May 2014 14:11:08 +0200 Subject: RFR 8038322: CounterMonitorDeadlockTest.java fails intermittently, presumed deadlock In-Reply-To: <53637F84.50206@oracle.com> References: <53636297.5050403@oracle.com> <53637631.50704@oracle.com> <53637F84.50206@oracle.com> Message-ID: <53638B5C.5070301@oracle.com> Looks good! On 5/2/14 1:20 PM, shanliang wrote: > Daniel Fuchs wrote: >> Hi Shanliang, >> >> This looks reasonable to me. >> Another possibility could have been to use the timeout factor >> to adapt the delay of Thread.sleep in the loop. > Yes we could adapt our timeout, but it is simpler to use the testing > harness timeout. >> >> What you have might be more reliable, but it also means >> that if the test ever fails in timeout again then it could >> be more difficult to diagnose what was wrong. >> >> Maybe you should add a trace before entering >> and after leaving any of your two loops, so that you >> at least will know where the test was being blocked? > Yes, absolutely useful to add trace: > http://cr.openjdk.java.net/~sjiang/JDK-8038322/01/ > > > Thanks, > Shanliang >> >> best regards, >> >> -- daniel >> >> On 5/2/14 11:17 AM, shanliang wrote: >>> Please review this test fix. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038322 >>> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8038322/00/ >>> >>> >>> The test had a timeout of 500*10 ms, better to remove this timeout and >>> to wait the harness timeout. >>> >>> Thanks, >>> Shanliang >> > From jeremymanson at google.com Fri May 2 23:02:20 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 2 May 2014 16:02:20 -0700 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: References: <524DB145.5030109@oracle.com> <5361A48A.6090104@oracle.com> Message-ID: Finally had a chance to look at this again. The method is not marked obsolete. I can't refactor the code so that the full version of create takes the Method *, because it is called to resolve stack traces from Throwables, and there is no way to map back to Method * from the method_ids that are stored in Throwables. So, my workaround (below) works fine to deal with getAllStackTraces, but doesn't work if there is an obsolete method in a Throwable's stack trace. I can't reproduce that, but that doesn't mean it won't happen. The only thing I can think to do about this is to keep track of obsolete method_ids. For example, when we do a retransform, InstanceKlass.methods could keep the old method around. Or, Methods could keep track of previous method ids (or a subclass of Method could keep track of previous method ids, so that most Methods don't suffer from bloat issues keeping track of something that is rarely / never there). I assume that there is a reason we don't do this, though. Here's my diff. I think it is fair to call it a crude hack. If there is something else you would like me to try, I'm happy to do so. diff --git a/src/share/vm/classfile/javaClasses.cpp b/src/share/vm/classfile/javaClasses.cpp --- a/src/share/vm/classfile/javaClasses.cpp +++ b/src/share/vm/classfile/javaClasses.cpp @@ -1857,6 +1857,14 @@ oop java_lang_StackTraceElement::create(methodHandle method, int bci, TRAPS) { Handle mirror (THREAD, method->method_holder()->java_mirror()); int method_id = method->method_idnum(); + InstanceKlass* holder = method->method_holder(); + Method* m = holder->method_with_idnum(method_id); + if (m == NULL) { + Method* mp = holder->find_method(method->name(), method->signature()); + if (mp != NULL) { + method_id = mp->method_idnum(); + } + } return create(mirror, method_id, method->constants()->version(), bci, THREAD); } Jeremy On Wed, Apr 30, 2014 at 10:13 PM, Jeremy Manson wrote: > I'll have to check tomorrow, but it's not unreasonable to think that it > is. It is a stack frame on a thread that was started before the class > redefinition happened. > > I guess the question is: what makes sense to do here? I put in a > workaround such that, if m is null, method_id is replaced by the method_id > from mp. I could refactor the code a little, such that the full version of > create() took the Method* instead of taking the method_id, and pass it mp > if m is null. > > It'll be hard to get you a reproducible test case, though. This only > happens in an integration test in our test cluster. Debugging was painful. > > Jeremy > > > On Wed, Apr 30, 2014 at 6:34 PM, Coleen Phillimore < > coleen.phillimore at oracle.com> wrote: > >> >> We didn't file any bugs because I don't remember finding anything >> specific, other than "gosh that code is scary" and "I wish we didn't have >> to do this". >> >> If you find a null 'm' below and call m->print() is the method "obsolete"? >> >> Coleen >> >> >> On 4/30/14, 8:24 PM, Jeremy Manson wrote: >> >> Did the new bugs get filed for this? >> >> I'm triggering this check with a redefined class (from the >> bootclasspath, if that matters). To investigate it a little, I >> instrumented StackTraceElement::create thus: >> >> oop java_lang_StackTraceElement::create(methodHandle method, int bci, >> TRAPS) { >> Handle mirror (THREAD, method->method_holder()->java_mirror()); >> int method_id = method->method_idnum(); >> >> InstanceKlass* holder = method->method_holder(); >> Method* m = holder->method_with_idnum(method_id); >> Method* mp = holder->find_method(method->name(), method->signature()); >> method->print_name(); >> fprintf(stderr, " method = %p id = %d method' = %p \n", m, method_id, >> mp); >> return create(mirror, method_id, method->constants()->version(), bci, >> THREAD); >> } >> >> m is null, and mp isn't. method->print_name works fine. This makes me >> feel that the idnum array is out of date somehow. Before I go down the >> rabbit hole and try to figure out why that is, does someone else know why? >> >> Thanks! >> >> Jeremy >> >> >> >> On Thu, Oct 3, 2013 at 11:02 AM, Coleen Phillimore < >> coleen.phillimore at oracle.com> wrote: >> >>> Summary: Redefined class in stack trace may not be found by method_idnum >>> so handle null. >>> >>> This is a simple change. I had another change to save the method name >>> (as u2) in the backtrace, but it's not worth the extra footprint in >>> backtraces for this rare case. >>> >>> The root problem was that we save method_idnum in the backtrace (u2) >>> instead of Method* to avoid Method* from being redefined and deallocated. >>> I made a change to InstanceKlass::method_from_idnum() to return null >>> rather than the last method in the list, which causes this crash. Dan and >>> I went down the long rabbit-hole of why method_idnum is changed for >>> obsolete methods and we think there's some cleanup and potential bugs in >>> this area. But this is not that change. I'll file another bug to continue >>> this investigation for jdk9 (or 8uN). >>> >>> Staffan created a test - am including core-libs for the review request. >>> Also tested with all of the vm testbase tests, mlvm tests, and >>> java/lang/instrument tests. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8025238 >>> >>> test case for jdk8 repository: >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >>> >>> Thanks, >>> Coleen >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.auno at oracle.com Mon May 5 13:26:32 2014 From: mikael.auno at oracle.com (Mikael Auno) Date: Mon, 05 May 2014 15:26:32 +0200 Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests In-Reply-To: References: <534EC2F9.9000305@oracle.com> <9178805f-7014-45ae-9c16-884c282dd045@default> <53595180.40906@oracle.com> Message-ID: <53679188.10005@oracle.com> I've updated this change to use ProblemList.txt instead of @ignore (since that was only intended for hotspot/test and not jdk/test). I've also updated the data to nightly failures from the last two weeks with issues since then filtered out manually. Hopefully this should address all concerns. New webrev at http://cr.openjdk.java.net/~miauno/8040748/webrev.02/ Thanks, Mikael On 2014-04-25 08:15, Staffan Larsen wrote: > For test/com/sun/jdi/JdbReadTwiceTest.sh, you list JDK-8002116, but that bug is resolved so should not be reason to quarantine the test. > > For test/com/sun/jdi/RepStep.java you list JDK-6471769 JDK-6766320 but both of those are closed so should not be reason to quarantine the test. > > For test/demo/jvmti/mtrace/TraceJFrame.java you list JDK-8035195 and JDK-8039432, but 8035195 seems to be just an old name for 8039432 (looking it up in JBS takes you to 8039432). So 8035195 should not be listed. > > For test/sun/tools/jinfo/Basic.sh, there are no open bugs against it (except JDK-6542634 which is a timeout from 2007 and I?m not sure it is valid) so I don?t think it should be quarantined. > > /Staffan > > > On 24 apr 2014, at 20:01, Mikael Auno wrote: > >> I've now added the keyword "quarantine" as well as fixed an issue with >> placement of the @ignore tag (it's not allowed to come before @library). >> >> New webrev at http://cr.openjdk.java.net/~miauno/8040748/webrev.01/ >> >> Local testing: >> >>> % jtreg -jdk $JAVA_HOME -k:quarantine -ignore:quiet -verbose:summary /localhome/ws/jdk9-dev/jdk/test/ >>> Test results: no tests selected >>> Report written to /localhome/temp/run/JTreport/html/report.html >>> Results written to /localhome/temp/run/JTwork >> >> Thanks, >> Mikael >> >> On 2014-04-22 17:12, Stefan S?rne wrote: >>> Hi Mikael, >>> >>> I think we should use a key word to group quarantined tests, which can be used to run the tests as a separate batch. Recommend to add this to all tests: >>> @key quarantine >>> >>> Note that you may have to add the key word as a known key word to the TEST.ROOT file as well. >>> >>> Best regards, >>> Stefan >>> >>> -----Original Message----- >>> From: Mikael Auno >>> Sent: den 16 april 2014 19:51 >>> To: serviceability-dev at openjdk.java.net >>> Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests using @ignore >>> >>> Please, review the following fix adding the @ignore tag to a couple of serviceability tests >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8040748 >>> Webrev: http://cr.openjdk.java.net/~miauno/8040748/webrev.00/ >>> >>> Thanks, >>> Mikael >>> >> > From staffan.larsen at oracle.com Mon May 5 14:18:41 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 5 May 2014 16:18:41 +0200 Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests In-Reply-To: <53679188.10005@oracle.com> References: <534EC2F9.9000305@oracle.com> <9178805f-7014-45ae-9c16-884c282dd045@default> <53595180.40906@oracle.com> <53679188.10005@oracle.com> Message-ID: <0125990A-6485-4249-A9CA-0DB9964ECFE7@oracle.com> 8039432 is Resolved and should not be listed. /Staffan On 5 maj 2014, at 15:26, Mikael Auno wrote: > I've updated this change to use ProblemList.txt instead of @ignore > (since that was only intended for hotspot/test and not jdk/test). I've > also updated the data to nightly failures from the last two weeks with > issues since then filtered out manually. > > Hopefully this should address all concerns. > > New webrev at http://cr.openjdk.java.net/~miauno/8040748/webrev.02/ > > Thanks, > Mikael > > On 2014-04-25 08:15, Staffan Larsen wrote: >> For test/com/sun/jdi/JdbReadTwiceTest.sh, you list JDK-8002116, but that bug is resolved so should not be reason to quarantine the test. >> >> For test/com/sun/jdi/RepStep.java you list JDK-6471769 JDK-6766320 but both of those are closed so should not be reason to quarantine the test. >> >> For test/demo/jvmti/mtrace/TraceJFrame.java you list JDK-8035195 and JDK-8039432, but 8035195 seems to be just an old name for 8039432 (looking it up in JBS takes you to 8039432). So 8035195 should not be listed. >> >> For test/sun/tools/jinfo/Basic.sh, there are no open bugs against it (except JDK-6542634 which is a timeout from 2007 and I?m not sure it is valid) so I don?t think it should be quarantined. >> >> /Staffan >> >> >> On 24 apr 2014, at 20:01, Mikael Auno wrote: >> >>> I've now added the keyword "quarantine" as well as fixed an issue with >>> placement of the @ignore tag (it's not allowed to come before @library). >>> >>> New webrev at http://cr.openjdk.java.net/~miauno/8040748/webrev.01/ >>> >>> Local testing: >>> >>>> % jtreg -jdk $JAVA_HOME -k:quarantine -ignore:quiet -verbose:summary /localhome/ws/jdk9-dev/jdk/test/ >>>> Test results: no tests selected >>>> Report written to /localhome/temp/run/JTreport/html/report.html >>>> Results written to /localhome/temp/run/JTwork >>> >>> Thanks, >>> Mikael >>> >>> On 2014-04-22 17:12, Stefan S?rne wrote: >>>> Hi Mikael, >>>> >>>> I think we should use a key word to group quarantined tests, which can be used to run the tests as a separate batch. Recommend to add this to all tests: >>>> @key quarantine >>>> >>>> Note that you may have to add the key word as a known key word to the TEST.ROOT file as well. >>>> >>>> Best regards, >>>> Stefan >>>> >>>> -----Original Message----- >>>> From: Mikael Auno >>>> Sent: den 16 april 2014 19:51 >>>> To: serviceability-dev at openjdk.java.net >>>> Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests using @ignore >>>> >>>> Please, review the following fix adding the @ignore tag to a couple of serviceability tests >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8040748 >>>> Webrev: http://cr.openjdk.java.net/~miauno/8040748/webrev.00/ >>>> >>>> Thanks, >>>> Mikael >>>> >>> >> > From mikael.auno at oracle.com Mon May 5 14:42:52 2014 From: mikael.auno at oracle.com (Mikael Auno) Date: Mon, 05 May 2014 16:42:52 +0200 Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests In-Reply-To: <0125990A-6485-4249-A9CA-0DB9964ECFE7@oracle.com> References: <534EC2F9.9000305@oracle.com> <9178805f-7014-45ae-9c16-884c282dd045@default> <53595180.40906@oracle.com> <53679188.10005@oracle.com> <0125990A-6485-4249-A9CA-0DB9964ECFE7@oracle.com> Message-ID: <5367A36C.7080602@oracle.com> Thanks for spotting it. New webrev at http://cr.openjdk.java.net/~miauno/8040748/webrev.03/. Mikael On 2014-05-05 16:18, Staffan Larsen wrote: > 8039432 is Resolved and should not be listed. > > /Staffan > > On 5 maj 2014, at 15:26, Mikael Auno wrote: > >> I've updated this change to use ProblemList.txt instead of @ignore >> (since that was only intended for hotspot/test and not jdk/test). I've >> also updated the data to nightly failures from the last two weeks with >> issues since then filtered out manually. >> >> Hopefully this should address all concerns. >> >> New webrev at http://cr.openjdk.java.net/~miauno/8040748/webrev.02/ >> >> Thanks, >> Mikael >> >> On 2014-04-25 08:15, Staffan Larsen wrote: >>> For test/com/sun/jdi/JdbReadTwiceTest.sh, you list JDK-8002116, but that bug is resolved so should not be reason to quarantine the test. >>> >>> For test/com/sun/jdi/RepStep.java you list JDK-6471769 JDK-6766320 but both of those are closed so should not be reason to quarantine the test. >>> >>> For test/demo/jvmti/mtrace/TraceJFrame.java you list JDK-8035195 and JDK-8039432, but 8035195 seems to be just an old name for 8039432 (looking it up in JBS takes you to 8039432). So 8035195 should not be listed. >>> >>> For test/sun/tools/jinfo/Basic.sh, there are no open bugs against it (except JDK-6542634 which is a timeout from 2007 and I?m not sure it is valid) so I don?t think it should be quarantined. >>> >>> /Staffan >>> >>> >>> On 24 apr 2014, at 20:01, Mikael Auno wrote: >>> >>>> I've now added the keyword "quarantine" as well as fixed an issue with >>>> placement of the @ignore tag (it's not allowed to come before @library). >>>> >>>> New webrev at http://cr.openjdk.java.net/~miauno/8040748/webrev.01/ >>>> >>>> Local testing: >>>> >>>>> % jtreg -jdk $JAVA_HOME -k:quarantine -ignore:quiet -verbose:summary /localhome/ws/jdk9-dev/jdk/test/ >>>>> Test results: no tests selected >>>>> Report written to /localhome/temp/run/JTreport/html/report.html >>>>> Results written to /localhome/temp/run/JTwork >>>> >>>> Thanks, >>>> Mikael >>>> >>>> On 2014-04-22 17:12, Stefan S?rne wrote: >>>>> Hi Mikael, >>>>> >>>>> I think we should use a key word to group quarantined tests, which can be used to run the tests as a separate batch. Recommend to add this to all tests: >>>>> @key quarantine >>>>> >>>>> Note that you may have to add the key word as a known key word to the TEST.ROOT file as well. >>>>> >>>>> Best regards, >>>>> Stefan >>>>> >>>>> -----Original Message----- >>>>> From: Mikael Auno >>>>> Sent: den 16 april 2014 19:51 >>>>> To: serviceability-dev at openjdk.java.net >>>>> Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests using @ignore >>>>> >>>>> Please, review the following fix adding the @ignore tag to a couple of serviceability tests >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8040748 >>>>> Webrev: http://cr.openjdk.java.net/~miauno/8040748/webrev.00/ >>>>> >>>>> Thanks, >>>>> Mikael >>>>> >>>> >>> >> > From staffan.larsen at oracle.com Mon May 5 14:54:57 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 5 May 2014 16:54:57 +0200 Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests In-Reply-To: <5367A36C.7080602@oracle.com> References: <534EC2F9.9000305@oracle.com> <9178805f-7014-45ae-9c16-884c282dd045@default> <53595180.40906@oracle.com> <53679188.10005@oracle.com> <0125990A-6485-4249-A9CA-0DB9964ECFE7@oracle.com> <5367A36C.7080602@oracle.com> Message-ID: <36713B24-9B57-42C5-9A7E-1D8C902345AE@oracle.com> Good! On 5 maj 2014, at 16:42, Mikael Auno wrote: > Thanks for spotting it. New webrev at > http://cr.openjdk.java.net/~miauno/8040748/webrev.03/. > > Mikael > > On 2014-05-05 16:18, Staffan Larsen wrote: >> 8039432 is Resolved and should not be listed. >> >> /Staffan >> >> On 5 maj 2014, at 15:26, Mikael Auno wrote: >> >>> I've updated this change to use ProblemList.txt instead of @ignore >>> (since that was only intended for hotspot/test and not jdk/test). I've >>> also updated the data to nightly failures from the last two weeks with >>> issues since then filtered out manually. >>> >>> Hopefully this should address all concerns. >>> >>> New webrev at http://cr.openjdk.java.net/~miauno/8040748/webrev.02/ >>> >>> Thanks, >>> Mikael >>> >>> On 2014-04-25 08:15, Staffan Larsen wrote: >>>> For test/com/sun/jdi/JdbReadTwiceTest.sh, you list JDK-8002116, but that bug is resolved so should not be reason to quarantine the test. >>>> >>>> For test/com/sun/jdi/RepStep.java you list JDK-6471769 JDK-6766320 but both of those are closed so should not be reason to quarantine the test. >>>> >>>> For test/demo/jvmti/mtrace/TraceJFrame.java you list JDK-8035195 and JDK-8039432, but 8035195 seems to be just an old name for 8039432 (looking it up in JBS takes you to 8039432). So 8035195 should not be listed. >>>> >>>> For test/sun/tools/jinfo/Basic.sh, there are no open bugs against it (except JDK-6542634 which is a timeout from 2007 and I?m not sure it is valid) so I don?t think it should be quarantined. >>>> >>>> /Staffan >>>> >>>> >>>> On 24 apr 2014, at 20:01, Mikael Auno wrote: >>>> >>>>> I've now added the keyword "quarantine" as well as fixed an issue with >>>>> placement of the @ignore tag (it's not allowed to come before @library). >>>>> >>>>> New webrev at http://cr.openjdk.java.net/~miauno/8040748/webrev.01/ >>>>> >>>>> Local testing: >>>>> >>>>>> % jtreg -jdk $JAVA_HOME -k:quarantine -ignore:quiet -verbose:summary /localhome/ws/jdk9-dev/jdk/test/ >>>>>> Test results: no tests selected >>>>>> Report written to /localhome/temp/run/JTreport/html/report.html >>>>>> Results written to /localhome/temp/run/JTwork >>>>> >>>>> Thanks, >>>>> Mikael >>>>> >>>>> On 2014-04-22 17:12, Stefan S?rne wrote: >>>>>> Hi Mikael, >>>>>> >>>>>> I think we should use a key word to group quarantined tests, which can be used to run the tests as a separate batch. Recommend to add this to all tests: >>>>>> @key quarantine >>>>>> >>>>>> Note that you may have to add the key word as a known key word to the TEST.ROOT file as well. >>>>>> >>>>>> Best regards, >>>>>> Stefan >>>>>> >>>>>> -----Original Message----- >>>>>> From: Mikael Auno >>>>>> Sent: den 16 april 2014 19:51 >>>>>> To: serviceability-dev at openjdk.java.net >>>>>> Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests using @ignore >>>>>> >>>>>> Please, review the following fix adding the @ignore tag to a couple of serviceability tests >>>>>> >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8040748 >>>>>> Webrev: http://cr.openjdk.java.net/~miauno/8040748/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Mikael >>>>>> >>>>> >>>> >>> >> > From staffan.larsen at oracle.com Mon May 5 18:24:13 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 5 May 2014 20:24:13 +0200 Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests In-Reply-To: <5367A36C.7080602@oracle.com> References: <534EC2F9.9000305@oracle.com> <9178805f-7014-45ae-9c16-884c282dd045@default> <53595180.40906@oracle.com> <53679188.10005@oracle.com> <0125990A-6485-4249-A9CA-0DB9964ECFE7@oracle.com> <5367A36C.7080602@oracle.com> Message-ID: <0A01E982-7462-406E-8AFE-49312F417654@oracle.com> Mikael, I just the final review for JDK-8031126 so I will be pushing that shortly to jdk9/hs-rt. Would you mind removing that entry from your change (unless you have already pushed it). Thanks, /Staffan On 5 maj 2014, at 16:42, Mikael Auno wrote: > Thanks for spotting it. New webrev at > http://cr.openjdk.java.net/~miauno/8040748/webrev.03/. > > Mikael > > On 2014-05-05 16:18, Staffan Larsen wrote: >> 8039432 is Resolved and should not be listed. >> >> /Staffan >> >> On 5 maj 2014, at 15:26, Mikael Auno wrote: >> >>> I've updated this change to use ProblemList.txt instead of @ignore >>> (since that was only intended for hotspot/test and not jdk/test). I've >>> also updated the data to nightly failures from the last two weeks with >>> issues since then filtered out manually. >>> >>> Hopefully this should address all concerns. >>> >>> New webrev at http://cr.openjdk.java.net/~miauno/8040748/webrev.02/ >>> >>> Thanks, >>> Mikael >>> >>> On 2014-04-25 08:15, Staffan Larsen wrote: >>>> For test/com/sun/jdi/JdbReadTwiceTest.sh, you list JDK-8002116, but that bug is resolved so should not be reason to quarantine the test. >>>> >>>> For test/com/sun/jdi/RepStep.java you list JDK-6471769 JDK-6766320 but both of those are closed so should not be reason to quarantine the test. >>>> >>>> For test/demo/jvmti/mtrace/TraceJFrame.java you list JDK-8035195 and JDK-8039432, but 8035195 seems to be just an old name for 8039432 (looking it up in JBS takes you to 8039432). So 8035195 should not be listed. >>>> >>>> For test/sun/tools/jinfo/Basic.sh, there are no open bugs against it (except JDK-6542634 which is a timeout from 2007 and I?m not sure it is valid) so I don?t think it should be quarantined. >>>> >>>> /Staffan >>>> >>>> >>>> On 24 apr 2014, at 20:01, Mikael Auno wrote: >>>> >>>>> I've now added the keyword "quarantine" as well as fixed an issue with >>>>> placement of the @ignore tag (it's not allowed to come before @library). >>>>> >>>>> New webrev at http://cr.openjdk.java.net/~miauno/8040748/webrev.01/ >>>>> >>>>> Local testing: >>>>> >>>>>> % jtreg -jdk $JAVA_HOME -k:quarantine -ignore:quiet -verbose:summary /localhome/ws/jdk9-dev/jdk/test/ >>>>>> Test results: no tests selected >>>>>> Report written to /localhome/temp/run/JTreport/html/report.html >>>>>> Results written to /localhome/temp/run/JTwork >>>>> >>>>> Thanks, >>>>> Mikael >>>>> >>>>> On 2014-04-22 17:12, Stefan S?rne wrote: >>>>>> Hi Mikael, >>>>>> >>>>>> I think we should use a key word to group quarantined tests, which can be used to run the tests as a separate batch. Recommend to add this to all tests: >>>>>> @key quarantine >>>>>> >>>>>> Note that you may have to add the key word as a known key word to the TEST.ROOT file as well. >>>>>> >>>>>> Best regards, >>>>>> Stefan >>>>>> >>>>>> -----Original Message----- >>>>>> From: Mikael Auno >>>>>> Sent: den 16 april 2014 19:51 >>>>>> To: serviceability-dev at openjdk.java.net >>>>>> Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests using @ignore >>>>>> >>>>>> Please, review the following fix adding the @ignore tag to a couple of serviceability tests >>>>>> >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8040748 >>>>>> Webrev: http://cr.openjdk.java.net/~miauno/8040748/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Mikael >>>>>> >>>>> >>>> >>> >> > From mikael.auno at oracle.com Tue May 6 09:01:48 2014 From: mikael.auno at oracle.com (Mikael Auno) Date: Tue, 06 May 2014 11:01:48 +0200 Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests In-Reply-To: <0A01E982-7462-406E-8AFE-49312F417654@oracle.com> References: <534EC2F9.9000305@oracle.com> <9178805f-7014-45ae-9c16-884c282dd045@default> <53595180.40906@oracle.com> <53679188.10005@oracle.com> <0125990A-6485-4249-A9CA-0DB9964ECFE7@oracle.com> <5367A36C.7080602@oracle.com> <0A01E982-7462-406E-8AFE-49312F417654@oracle.com> Message-ID: <5368A4FC.3010802@oracle.com> Done, and thanks for the reviews. Mikael On 2014-05-05 20:24, Staffan Larsen wrote: > Mikael, > > I just the final review for JDK-8031126 so I will be pushing that shortly to jdk9/hs-rt. Would you mind removing that entry from your change (unless you have already pushed it). > > Thanks, > /Staffan > > On 5 maj 2014, at 16:42, Mikael Auno wrote: > >> Thanks for spotting it. New webrev at >> http://cr.openjdk.java.net/~miauno/8040748/webrev.03/. >> >> Mikael >> >> On 2014-05-05 16:18, Staffan Larsen wrote: >>> 8039432 is Resolved and should not be listed. >>> >>> /Staffan >>> >>> On 5 maj 2014, at 15:26, Mikael Auno wrote: >>> >>>> I've updated this change to use ProblemList.txt instead of @ignore >>>> (since that was only intended for hotspot/test and not jdk/test). I've >>>> also updated the data to nightly failures from the last two weeks with >>>> issues since then filtered out manually. >>>> >>>> Hopefully this should address all concerns. >>>> >>>> New webrev at http://cr.openjdk.java.net/~miauno/8040748/webrev.02/ >>>> >>>> Thanks, >>>> Mikael >>>> >>>> On 2014-04-25 08:15, Staffan Larsen wrote: >>>>> For test/com/sun/jdi/JdbReadTwiceTest.sh, you list JDK-8002116, but that bug is resolved so should not be reason to quarantine the test. >>>>> >>>>> For test/com/sun/jdi/RepStep.java you list JDK-6471769 JDK-6766320 but both of those are closed so should not be reason to quarantine the test. >>>>> >>>>> For test/demo/jvmti/mtrace/TraceJFrame.java you list JDK-8035195 and JDK-8039432, but 8035195 seems to be just an old name for 8039432 (looking it up in JBS takes you to 8039432). So 8035195 should not be listed. >>>>> >>>>> For test/sun/tools/jinfo/Basic.sh, there are no open bugs against it (except JDK-6542634 which is a timeout from 2007 and I?m not sure it is valid) so I don?t think it should be quarantined. >>>>> >>>>> /Staffan >>>>> >>>>> >>>>> On 24 apr 2014, at 20:01, Mikael Auno wrote: >>>>> >>>>>> I've now added the keyword "quarantine" as well as fixed an issue with >>>>>> placement of the @ignore tag (it's not allowed to come before @library). >>>>>> >>>>>> New webrev at http://cr.openjdk.java.net/~miauno/8040748/webrev.01/ >>>>>> >>>>>> Local testing: >>>>>> >>>>>>> % jtreg -jdk $JAVA_HOME -k:quarantine -ignore:quiet -verbose:summary /localhome/ws/jdk9-dev/jdk/test/ >>>>>>> Test results: no tests selected >>>>>>> Report written to /localhome/temp/run/JTreport/html/report.html >>>>>>> Results written to /localhome/temp/run/JTwork >>>>>> >>>>>> Thanks, >>>>>> Mikael >>>>>> >>>>>> On 2014-04-22 17:12, Stefan S?rne wrote: >>>>>>> Hi Mikael, >>>>>>> >>>>>>> I think we should use a key word to group quarantined tests, which can be used to run the tests as a separate batch. Recommend to add this to all tests: >>>>>>> @key quarantine >>>>>>> >>>>>>> Note that you may have to add the key word as a known key word to the TEST.ROOT file as well. >>>>>>> >>>>>>> Best regards, >>>>>>> Stefan >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Mikael Auno >>>>>>> Sent: den 16 april 2014 19:51 >>>>>>> To: serviceability-dev at openjdk.java.net >>>>>>> Subject: RFR 8040748: [TESTBUG] Exclude failing (serviceability) jtreg tests using @ignore >>>>>>> >>>>>>> Please, review the following fix adding the @ignore tag to a couple of serviceability tests >>>>>>> >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8040748 >>>>>>> Webrev: http://cr.openjdk.java.net/~miauno/8040748/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> Mikael >>>>>>> >>>>>> >>>>> >>>> >>> >> > From staffan.larsen at oracle.com Thu May 8 06:06:54 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 8 May 2014 08:06:54 +0200 Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync Message-ID: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com> All, This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct. When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert. The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms. Kudos to Rickard for helping me write the code. webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8041934 The fix has been verified by running the failing test in JPRT with -Xcomp. Thanks, /Staffan From mikael.auno at oracle.com Thu May 8 09:56:29 2014 From: mikael.auno at oracle.com (Mikael Auno) Date: Thu, 08 May 2014 11:56:29 +0200 Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync In-Reply-To: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com> References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com> Message-ID: <536B54CD.4090605@oracle.com> Note that RepStep was just added to ProblemList due to this issue and will have to be removed from there when the fix is integrated. Mikael On 2014-05-08 08:06, Staffan Larsen wrote: > All, > > This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct. > > When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert. > > The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms. > > Kudos to Rickard for helping me write the code. > > webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8041934 > > The fix has been verified by running the failing test in JPRT with -Xcomp. > > Thanks, > /Staffan > From Alan.Bateman at oracle.com Thu May 8 15:40:54 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 08 May 2014 16:40:54 +0100 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework In-Reply-To: <71C097AB-E539-45C3-AD05-5E046751B7A9@oracle.com> References: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> <534BFC27.6000206@oracle.com> <942D9C10-0E80-4B76-9F4F-71DDFCAB3EFB@oracle.com> <535FA77C.6050303@oracle.com> <71C097AB-E539-45C3-AD05-5E046751B7A9@oracle.com> Message-ID: <536BA586.5060608@oracle.com> On 29/04/2014 15:08, Staffan Larsen wrote: > Thanks for the comments. I have updated the review with both. > > webrev: http://cr.openjdk.java.net/~sla/8039173/webrev.05/ > > I do not actually have any Reviewers for this change. Anyone willing to take it on is much appreciated. > Sorry for the delay, I've been busy with other things. I've looked through the rest of the webrev and it looks good to me. -Alan. From staffan.larsen at oracle.com Thu May 8 15:47:18 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 8 May 2014 17:47:18 +0200 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework In-Reply-To: <536BA586.5060608@oracle.com> References: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> <534BFC27.6000206@oracle.com> <942D9C10-0E80-4B76-9F4F-71DDFCAB3EFB@oracle.com> <535FA77C.6050303@oracle.com> <71C097AB-E539-45C3-AD05-5E046751B7A9@oracle.com> <536BA586.5060608@oracle.com> Message-ID: <382A499A-F17D-49F4-BB7F-D3A0FFAC4C23@oracle.com> Thank you, Alan! On 8 maj 2014, at 17:40, Alan Bateman wrote: > On 29/04/2014 15:08, Staffan Larsen wrote: >> Thanks for the comments. I have updated the review with both. >> >> webrev: http://cr.openjdk.java.net/~sla/8039173/webrev.05/ >> >> I do not actually have any Reviewers for this change. Anyone willing to take it on is much appreciated. >> > Sorry for the delay, I've been busy with other things. > > I've looked through the rest of the webrev and it looks good to me. > > -Alan. > From dmitry.samersoff at oracle.com Thu May 8 16:04:39 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 08 May 2014 20:04:39 +0400 Subject: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework In-Reply-To: <71C097AB-E539-45C3-AD05-5E046751B7A9@oracle.com> References: <94B0E3B9-A874-414C-AC09-60E7D9FE23BC@oracle.com> <534BFC27.6000206@oracle.com> <942D9C10-0E80-4B76-9F4F-71DDFCAB3EFB@oracle.com> <535FA77C.6050303@oracle.com> <71C097AB-E539-45C3-AD05-5E046751B7A9@oracle.com> Message-ID: <536BAB17.3080407@oracle.com> Staffan, Looks good for me. Could you comment in bug report that this changeset also fixes incorrect usage of off parameter in *VirtualMachine_read functions. -Dmitry On 2014-04-29 18:08, Staffan Larsen wrote: > Thanks for the comments. I have updated the review with both. > > webrev: http://cr.openjdk.java.net/~sla/8039173/webrev.05/ > > I do not actually have any Reviewers for this change. Anyone willing to take it on is much appreciated. > > Thanks, > /Staffan > > > On 29 apr 2014, at 15:22, Alan Bateman wrote: > >> On 16/04/2014 10:21, Staffan Larsen wrote: >>> On 14 apr 2014, at 17:17, Alan Bateman wrote: >>> >>>> : >>>> For someone looking at the Virtualmachine API then I don't think the javadoc is clear enough to understand when one might get the specific AttachOperationFailedException vs. the more general IOException. I think it means that there was communication with the target VM but that the operation failed for some reason but I don't think this will be obvious to the reader. >>> I have tried to clarify the wording in the javadoc. Suggestions for improvements are welcome. >> Sorry for the delay, I was on away for a few days and just catching up with this again. >> >> The updated descriptions looks much better. For IOException then it might be better to have a bit of wriggle room to allow for other I/O errors that might not be communication related. So maybe something like "If an I/O error occurs, a communication error for example, that cannot be identified as an error to indicate that the operation failed in the target VM". >> >>> : >>>> For the new exception then it would be good to add @since and also a copyright header. >>> Fixed. >>> >> Thanks, a formatting nit at L42, I assume that the "{" will fit at the end of line 41. >> >> I don't have cycles at the moment to go through the implementation changes but I think you have other reviewers for that. >> >> -Alan. >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.daugherty at oracle.com Thu May 8 17:05:29 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 08 May 2014 11:05:29 -0600 Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync In-Reply-To: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com> References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com> Message-ID: <536BB959.7060706@oracle.com> > webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ src/share/vm/runtime/sharedRuntime.hpp No comments. src/share/vm/runtime/sharedRuntime.cpp line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit( I'm not sure that JRT_LEAF is right. I would think that JvmtiExport::post_method_exit() would have to grab one or more locks with all the state checks it has to make... For reference, InterpreterRuntime::post_method_exit() is a wrapper around JvmtiExport::post_method_exit() and it is IRT_ENTRY instead of IRT_LEAF. src/cpu/sparc/vm/sharedRuntime_sparc.cpp No comments. src/cpu/x86/vm/sharedRuntime_x86_32.cpp No comments. src/cpu/x86/vm/sharedRuntime_x86_64.cpp No comments. I'm guessing that PPC has the same issue, but I'm presuming that someone else (Vladimir?) will handle that... Dan On 5/8/14 12:06 AM, Staffan Larsen wrote: > All, > > This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct. > > When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert. > > The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms. > > Kudos to Rickard for helping me write the code. > > webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8041934 > > The fix has been verified by running the failing test in JPRT with -Xcomp. > > Thanks, > /Staffan From jeremymanson at google.com Thu May 8 18:56:50 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Thu, 8 May 2014 11:56:50 -0700 Subject: RFR: 8042778: Getting all visible methods in ReferenceTypeImpl is slow Message-ID: I'm testing out my newly acquired OpenJDK authorship with something simple. If I did this wrong, I apologize. Basically, the debugger becomes very slow if there are a lot of methods in a class. This can happen (O(thousands)) if you are using a code generation tool. http://cr.openjdk.java.net/~jmanson/8042778/webrev.00/ Reviews from reviewers and committing from committers would be appreciated. Thanks! Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri May 9 03:17:05 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 09 May 2014 13:17:05 +1000 Subject: RFR: 8042778: Getting all visible methods in ReferenceTypeImpl is slow In-Reply-To: References: Message-ID: <536C48B1.7070408@oracle.com> Hi Jeremy, On 9/05/2014 4:56 AM, Jeremy Manson wrote: > I'm testing out my newly acquired OpenJDK authorship with something > simple. If I did this wrong, I apologize. > > Basically, the debugger becomes very slow if there are a lot of methods > in a class. This can happen (O(thousands)) if you are using a code > generation tool. > > http://cr.openjdk.java.net/~jmanson/8042778/webrev.00/ I find it counter-intuitive that this makes things faster: - list.retainAll(map.values()); + list.retainAll(new HashSet(map.values())); Can you explain why introducing the intermediate HashSet improves things? A comment in the code would also be good. Thanks, David > Reviews from reviewers and committing from committers would be > appreciated. Thanks! > > Jeremy From yekaterina.kantserova at oracle.com Fri May 9 10:43:39 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 09 May 2014 12:43:39 +0200 Subject: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <920D97EC-4782-46BC-BFE9-6B3800DB6C27@oracle.com> References: <5331718B.2020909@oracle.com> <920D97EC-4782-46BC-BFE9-6B3800DB6C27@oracle.com> Message-ID: <536CB15B.8070908@oracle.com> Hi, The version b09 of JTreg which contains https://bugs.openjdk.java.net/browse/CODETOOLS-7900178 has been promoted. So it seems to be time to push the fix for JDK-8034960. I've made a new webrev to be sure the changes fit in in the latest jdk9 source. The webrev can be found here: cr.openjdk.java.net/~ykantser/8034960/webrev.01. Thanks, Katja On 03/25/2014 01:14 PM, Staffan Larsen wrote: > I?ve looked at a random sample of these changes and they look ok. > > Since some of the changes are in non-serviceability code I have also added core-libs to the review thread. > > I?m sure you know this, but for the record: please don?t push this until jtreg with the fix has been promoted. > > Thanks, > /Staffan > > On 25 mar 2014, at 13:07, Yekaterina Kantserova wrote: > >> Hi, >> >> Could I please have a review of this fix. >> >> webrev: http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8034960 >> >> When using @library in a JTreg test even @build need to be specify for all library files used by the test. If @build is not specified it can lead to intermittent failures when running tests concurrently, since javac implicit compilation and @library and -concurrency don't play well together. >> >> Verified locally since no JTreg with fix has been promoted yet. >> >> >> Thanks, >> Katja From staffan.larsen at oracle.com Fri May 9 10:47:23 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 9 May 2014 12:47:23 +0200 Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync In-Reply-To: <536BB959.7060706@oracle.com> References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com> <536BB959.7060706@oracle.com> Message-ID: <2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com> On 8 maj 2014, at 19:05, Daniel D. Daugherty wrote: > > webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ > > src/share/vm/runtime/sharedRuntime.hpp > No comments. > > src/share/vm/runtime/sharedRuntime.cpp > line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit( > I'm not sure that JRT_LEAF is right. I would think that > JvmtiExport::post_method_exit() would have to grab one or > more locks with all the state checks it has to make... > > For reference, InterpreterRuntime::post_method_exit() > is a wrapper around JvmtiExport::post_method_exit() > and it is IRT_ENTRY instead of IRT_LEAF. Good catch! > > src/cpu/sparc/vm/sharedRuntime_sparc.cpp > No comments. > > src/cpu/x86/vm/sharedRuntime_x86_32.cpp > No comments. > > src/cpu/x86/vm/sharedRuntime_x86_64.cpp > No comments. > > I'm guessing that PPC has the same issue, but I'm presuming > that someone else (Vladimir?) will handle that? Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix. Updated review: http://cr.openjdk.java.net/~sla/8041934/webrev.01/ Thanks, /Staffan > > Dan > > > On 5/8/14 12:06 AM, Staffan Larsen wrote: >> All, >> >> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct. >> >> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert. >> >> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms. >> >> Kudos to Rickard for helping me write the code. >> >> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8041934 >> >> The fix has been verified by running the failing test in JPRT with -Xcomp. >> >> Thanks, >> /Staffan > From staffan.larsen at oracle.com Fri May 9 10:48:56 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 9 May 2014 12:48:56 +0200 Subject: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <536CB15B.8070908@oracle.com> References: <5331718B.2020909@oracle.com> <920D97EC-4782-46BC-BFE9-6B3800DB6C27@oracle.com> <536CB15B.8070908@oracle.com> Message-ID: Looks good! Thanks, /Staffan On 9 maj 2014, at 12:43, Yekaterina Kantserova wrote: > Hi, > > The version b09 of JTreg which contains https://bugs.openjdk.java.net/browse/CODETOOLS-7900178 has been promoted. So it seems to be time to push the fix for JDK-8034960. I've made a new webrev to be sure the changes fit in in the latest jdk9 source. The webrev can be found here: cr.openjdk.java.net/~ykantser/8034960/webrev.01. > > Thanks, > Katja > > > > On 03/25/2014 01:14 PM, Staffan Larsen wrote: >> I?ve looked at a random sample of these changes and they look ok. >> >> Since some of the changes are in non-serviceability code I have also added core-libs to the review thread. >> >> I?m sure you know this, but for the record: please don?t push this until jtreg with the fix has been promoted. >> >> Thanks, >> /Staffan >> >> On 25 mar 2014, at 13:07, Yekaterina Kantserova wrote: >> >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> webrev: http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8034960 >>> >>> When using @library in a JTreg test even @build need to be specify for all library files used by the test. If @build is not specified it can lead to intermittent failures when running tests concurrently, since javac implicit compilation and @library and -concurrency don't play well together. >>> >>> Verified locally since no JTreg with fix has been promoted yet. >>> >>> >>> Thanks, >>> Katja > From Alan.Bateman at oracle.com Fri May 9 11:07:20 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 09 May 2014 12:07:20 +0100 Subject: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <536CB15B.8070908@oracle.com> References: <5331718B.2020909@oracle.com> <920D97EC-4782-46BC-BFE9-6B3800DB6C27@oracle.com> <536CB15B.8070908@oracle.com> Message-ID: <536CB6E8.4070607@oracle.com> On 09/05/2014 11:43, Yekaterina Kantserova wrote: > Hi, > > The version b09 of JTreg which contains > https://bugs.openjdk.java.net/browse/CODETOOLS-7900178 has been > promoted. So it seems to be time to push the fix for JDK-8034960. I've > made a new webrev to be sure the changes fit in in the latest jdk9 > source. The webrev can be found here: > cr.openjdk.java.net/~ykantser/8034960/webrev.01. Thanks for doing this, it should make concurrent test runs a lot more stable. I've skimmed over the changes and they look good to me too. -Alan From yekaterina.kantserova at oracle.com Fri May 9 11:32:08 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 09 May 2014 13:32:08 +0200 Subject: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <536CB6E8.4070607@oracle.com> References: <5331718B.2020909@oracle.com> <920D97EC-4782-46BC-BFE9-6B3800DB6C27@oracle.com> <536CB15B.8070908@oracle.com> <536CB6E8.4070607@oracle.com> Message-ID: <536CBCB8.4030804@oracle.com> Staffan, Alan, thanks for reviews! I will wait with pushing it until Monday to make sure no one has objections. // Katja On 05/09/2014 01:07 PM, Alan Bateman wrote: > On 09/05/2014 11:43, Yekaterina Kantserova wrote: >> Hi, >> >> The version b09 of JTreg which contains >> https://bugs.openjdk.java.net/browse/CODETOOLS-7900178 has been >> promoted. So it seems to be time to push the fix for JDK-8034960. >> I've made a new webrev to be sure the changes fit in in the latest >> jdk9 source. The webrev can be found here: >> cr.openjdk.java.net/~ykantser/8034960/webrev.01. > Thanks for doing this, it should make concurrent test runs a lot more > stable. I've skimmed over the changes and they look good to me too. > > -Alan From daniel.daugherty at oracle.com Fri May 9 14:01:20 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 09 May 2014 08:01:20 -0600 Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync In-Reply-To: <2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com> References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com> <536BB959.7060706@oracle.com> <2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com> Message-ID: <536CDFB0.2000309@oracle.com> > Updated review: http://cr.openjdk.java.net/~sla/8041934/webrev.01/ Thumbs up! src/share/vm/runtime/sharedRuntime.hpp No comments. src/share/vm/runtime/sharedRuntime.cpp Thanks for fixing the entry type. src/cpu/sparc/vm/sharedRuntime_sparc.cpp No comments. src/cpu/x86/vm/sharedRuntime_x86_32.cpp No comments. src/cpu/x86/vm/sharedRuntime_x86_64.cpp No comments. Dan On 5/9/14 4:47 AM, Staffan Larsen wrote: > On 8 maj 2014, at 19:05, Daniel D. Daugherty wrote: > >>> webrev:http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >> src/share/vm/runtime/sharedRuntime.hpp >> No comments. >> >> src/share/vm/runtime/sharedRuntime.cpp >> line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit( >> I'm not sure that JRT_LEAF is right. I would think that >> JvmtiExport::post_method_exit() would have to grab one or >> more locks with all the state checks it has to make... >> >> For reference, InterpreterRuntime::post_method_exit() >> is a wrapper around JvmtiExport::post_method_exit() >> and it is IRT_ENTRY instead of IRT_LEAF. > Good catch! > >> src/cpu/sparc/vm/sharedRuntime_sparc.cpp >> No comments. >> >> src/cpu/x86/vm/sharedRuntime_x86_32.cpp >> No comments. >> >> src/cpu/x86/vm/sharedRuntime_x86_64.cpp >> No comments. >> >> I'm guessing that PPC has the same issue, but I'm presuming >> that someone else (Vladimir?) will handle that? > Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix. > > Updated review:http://cr.openjdk.java.net/~sla/8041934/webrev.01/ > > Thanks, > /Staffan > >> Dan >> >> >> On 5/8/14 12:06 AM, Staffan Larsen wrote: >>> All, >>> >>> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct. >>> >>> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert. >>> >>> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms. >>> >>> Kudos to Rickard for helping me write the code. >>> >>> webrev:http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >>> bug:https://bugs.openjdk.java.net/browse/JDK-8041934 >>> >>> The fix has been verified by running the failing test in JPRT with -Xcomp. >>> >>> Thanks, >>> /Staffan From staffan.larsen at oracle.com Fri May 9 14:30:15 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 9 May 2014 16:30:15 +0200 Subject: RFR: 8041923 Command line output is missing from jinfo Message-ID: Before the fix of JDK-8036599 the jinfo -flags output contained: Non-default VM flags: -XX:InitialHeapSize=31457280 -XX:MaxHeapSize=31457280 -XX:MaxNewSize=10485760 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=1572864 -XX:OldSize=20971520 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC Command line: -Xmx30m After the fix it says only: VM Flags: -XX:CICompilerCount=3 -XX:InitialHeapSize=31457280 -XX:MaxHeapSize=31457280 -XX:MaxNewSize=10485760 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=10485760 -XX:OldSize=20971520 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC To restore the old output sun.tools.jinfo.JInfo has been modified to include output from vm.executeJCmd("VM.command_line"); as well: VM Flags: -XX:CICompilerCount=3 -XX:InitialHeapSize=31457280 -XX:MaxHeapSize=31457280 -XX:MaxNewSize=10485760 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=10485760 -XX:OldSize=20971520 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC VM Arguments: jvm_args: -Xmx30m java_command: Sleeper 10000 java_class_path (initial): /Users/staffan/dev Launcher Type: SUN_STANDARD webrev: http://cr.openjdk.java.net/~sla/8041923/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8041923 Thanks, /Staffan From jeremymanson at google.com Fri May 9 16:32:42 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Fri, 9 May 2014 09:32:42 -0700 Subject: RFR: 8042778: Getting all visible methods in ReferenceTypeImpl is slow In-Reply-To: <536C48B1.7070408@oracle.com> References: <536C48B1.7070408@oracle.com> Message-ID: Hi David, Hm. This was done several years ago in response to a user request, and he claimed it cleared up the problem, but you're right - contains() on the collection returned by map.values() should have been an O(1) operation, both then and now. So I'll check into it and get back on this next week. Jeremy On Thu, May 8, 2014 at 8:17 PM, David Holmes wrote: > Hi Jeremy, > > > On 9/05/2014 4:56 AM, Jeremy Manson wrote: > >> I'm testing out my newly acquired OpenJDK authorship with something >> simple. If I did this wrong, I apologize. >> >> Basically, the debugger becomes very slow if there are a lot of methods >> in a class. This can happen (O(thousands)) if you are using a code >> generation tool. >> >> http://cr.openjdk.java.net/~jmanson/8042778/webrev.00/ >> > > I find it counter-intuitive that this makes things faster: > > - list.retainAll(map.values()); > + list.retainAll(new HashSet(map.values())); > > Can you explain why introducing the intermediate HashSet improves things? > A comment in the code would also be good. > > Thanks, > David > > > > > Reviews from reviewers and committing from committers would be >> appreciated. Thanks! >> >> Jeremy >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri May 9 18:18:04 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 09 May 2014 11:18:04 -0700 Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync In-Reply-To: <2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com> References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com> <536BB959.7060706@oracle.com> <2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com> Message-ID: <536D1BDC.7000908@oracle.com> Staffan, This is important discovery, thanks! The fix looks good to me. One question below. Thanks, Serguei On 5/9/14 3:47 AM, Staffan Larsen wrote: > On 8 maj 2014, at 19:05, Daniel D. Daugherty wrote: > >>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >> src/share/vm/runtime/sharedRuntime.hpp >> No comments. >> >> src/share/vm/runtime/sharedRuntime.cpp >> line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit( >> I'm not sure that JRT_LEAF is right. I would think that >> JvmtiExport::post_method_exit() would have to grab one or >> more locks with all the state checks it has to make... >> >> For reference, InterpreterRuntime::post_method_exit() >> is a wrapper around JvmtiExport::post_method_exit() >> and it is IRT_ENTRY instead of IRT_LEAF. > Good catch! Q: Is correct to use call_VM_leaf (vs call_VM ) in the sharedRuntime_.cpp ? + __ call_VM_leaf( + CAST_FROM_FN_PTR(address, SharedRuntime::jvmti_method_exit), + thread, rax); > >> src/cpu/sparc/vm/sharedRuntime_sparc.cpp >> No comments. >> >> src/cpu/x86/vm/sharedRuntime_x86_32.cpp >> No comments. >> >> src/cpu/x86/vm/sharedRuntime_x86_64.cpp >> No comments. >> >> I'm guessing that PPC has the same issue, but I'm presuming >> that someone else (Vladimir?) will handle that? > Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix. > > Updated review: http://cr.openjdk.java.net/~sla/8041934/webrev.01/ > > Thanks, > /Staffan > >> Dan >> >> >> On 5/8/14 12:06 AM, Staffan Larsen wrote: >>> All, >>> >>> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct. >>> >>> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert. >>> >>> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms. >>> >>> Kudos to Rickard for helping me write the code. >>> >>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8041934 >>> >>> The fix has been verified by running the failing test in JPRT with -Xcomp. >>> >>> Thanks, >>> /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri May 9 18:20:58 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 09 May 2014 11:20:58 -0700 Subject: RFR (S) 8042796: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found Message-ID: <536D1C8A.4080503@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8042796 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8042796-JVMTI-OLD.1 Summary: This is a Nightly Stabilization issue that was caused by a combination of two problems: - A regression introduced by the fix of: https://bugs.openjdk.java.net/browse/JDK-7182152 - An SQE testbase infra regression: https://bugs.openjdk.java.net/browse/INTJDK-7611018 A number of the vm.mlvm tests hits this guarantee taht was added by 7182152 (must be relaxed). The issue is with the deleted static private methods that are still present in the CP cache. The fix is to mark the deleted methods with the flag JVM_ACC_IS_DELETED and then use it to relax the guarantee condition. Testing: Running the failing tests: vm.mlvm.indy.func.jvmti In progress: nsk.jvmti, nsk.jdi, java.lang.instrument test runs on sparcv9 and amd64. Thanks, Serguei From yekaterina.kantserova at oracle.com Mon May 12 08:28:19 2014 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 12 May 2014 10:28:19 +0200 Subject: Fwd: Re: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: References: Message-ID: <53708623.60006@oracle.com> Staffan, could you please be my sponsor and push this fix? I have discovered three more tests that should bechanged: sun/management/jmxremote/bootstrap/CustomLauncherTest.java java/lang/management/MemoryMXBean/CollectionUsageThreshold.java java/lang/management/MemoryMXBean/LowMemoryTest.java The webrev that includes them can be found here: http://cr.openjdk.java.net/~ykantser/8034960/webrev.02/ Thanks, Katja -------- Original Message -------- Subject: Re: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError Date: Fri, 9 May 2014 12:48:56 +0200 From: Staffan Larsen To: Yekaterina Kantserova CC: Alan Bateman , "serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net" , core-libs-dev Libs Looks good! Thanks, /Staffan On 9 maj 2014, at 12:43, Yekaterina Kantserova wrote: > Hi, > > The version b09 of JTreg which containshttps://bugs.openjdk.java.net/browse/CODETOOLS-7900178 has been promoted. So it seems to be time to push the fix for JDK-8034960. I've made a new webrev to be sure the changes fit in in the latest jdk9 source. The webrev can be found here: cr.openjdk.java.net/~ykantser/8034960/webrev.01. > > Thanks, > Katja > > > > On 03/25/2014 01:14 PM, Staffan Larsen wrote: >> I?ve looked at a random sample of these changes and they look ok. >> >> Since some of the changes are in non-serviceability code I have also added core-libs to the review thread. >> >> I?m sure you know this, but for the record: please don?t push this until jtreg with the fix has been promoted. >> >> Thanks, >> /Staffan >> >> On 25 mar 2014, at 13:07, Yekaterina Kantserova wrote: >> >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> webrev:http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/ >>> bug:https://bugs.openjdk.java.net/browse/JDK-8034960 >>> >>> When using @library in a JTreg test even @build need to be specify for all library files used by the test. If @build is not specified it can lead to intermittent failures when running tests concurrently, since javac implicit compilation and @library and -concurrency don't play well together. >>> >>> Verified locally since no JTreg with fix has been promoted yet. >>> >>> >>> Thanks, >>> Katja > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 8034960.open.patch Type: text/x-patch Size: 9519 bytes Desc: not available URL: From staffan.larsen at oracle.com Mon May 12 08:38:55 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 12 May 2014 10:38:55 +0200 Subject: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError In-Reply-To: <53708623.60006@oracle.com> References: <53708623.60006@oracle.com> Message-ID: Pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/05e9c9216e26 Thanks, /Staffan On 12 maj 2014, at 10:28, Yekaterina Kantserova wrote: > Staffan, > > could you please be my sponsor and push this fix? > > I have discovered three more tests that should be changed: > sun/management/jmxremote/bootstrap/CustomLauncherTest.java > java/lang/management/MemoryMXBean/CollectionUsageThreshold.java > java/lang/management/MemoryMXBean/LowMemoryTest.java > > The webrev that includes them can be found here: http://cr.openjdk.java.net/~ykantser/8034960/webrev.02/ > > Thanks, > Katja > > > > -------- Original Message -------- > Subject: Re: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError > Date: Fri, 9 May 2014 12:48:56 +0200 > From: Staffan Larsen > To: Yekaterina Kantserova > CC: Alan Bateman , "serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net" , core-libs-dev Libs > > Looks good! > > Thanks, > /Staffan > > On 9 maj 2014, at 12:43, Yekaterina Kantserova wrote: > > > Hi, > > > > The version b09 of JTreg which contains https://bugs.openjdk.java.net/browse/CODETOOLS-7900178 has been promoted. So it seems to be time to push the fix for JDK-8034960. I've made a new webrev to be sure the changes fit in in the latest jdk9 source. The webrev can be found here: cr.openjdk.java.net/~ykantser/8034960/webrev.01. > > > > Thanks, > > Katja > > > > > > > > On 03/25/2014 01:14 PM, Staffan Larsen wrote: > >> I?ve looked at a random sample of these changes and they look ok. > >> > >> Since some of the changes are in non-serviceability code I have also added core-libs to the review thread. > >> > >> I?m sure you know this, but for the record: please don?t push this until jtreg with the fix has been promoted. > >> > >> Thanks, > >> /Staffan > >> > >> On 25 mar 2014, at 13:07, Yekaterina Kantserova wrote: > >> > >>> Hi, > >>> > >>> Could I please have a review of this fix. > >>> > >>> webrev: http://cr.openjdk.java.net/~ykantser/8034960/webrev.00/ > >>> bug: https://bugs.openjdk.java.net/browse/JDK-8034960 > >>> > >>> When using @library in a JTreg test even @build need to be specify for all library files used by the test. If @build is not specified it can lead to intermittent failures when running tests concurrently, since javac implicit compilation and @library and -concurrency don't play well together. > >>> > >>> Verified locally since no JTreg with fix has been promoted yet. > >>> > >>> > >>> Thanks, > >>> Katja > > > > > > <8034960.open.patch> -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Mon May 12 10:03:03 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 May 2014 12:03:03 +0200 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK Message-ID: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Hi, This is a request for review of Otavio's patch replacing StringBuffer with StringBuilder within OpenJDK. (I also need to review it.) It covers many areas and i have grouped the patches into such areas to aid reviewing. When commenting please including core-libs. Jtreg tests showed no regressions, but when reviewing we need to be mindful of the context e.g. if the buffer escapes and can cross thread boundaries. This is also an experiment to see if we can review the whole thing under one bug :-) if things prove problematic and slow we can split it out. Many files are touched but there are not many changes to each file and changes are very formulaic. I have also included ASM related changes, but i suspect we may have to leave those alone since such changes will make it more difficult to pull in ASM from upstream. - Otavio, for the record can you reply to this thread posting your single ("uber") patch as textual attachment? (IIUC such attachments should now be supported by the email server). Paul. - core http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/ - io http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/ - management http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/ - rmi http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/ - security http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ - tools http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/ - graphics/media http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ - asm http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ivan.gerasimov at oracle.com Mon May 12 10:37:08 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 12 May 2014 14:37:08 +0400 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Message-ID: <5370A454.2080402@oracle.com> Wouldn't it be a little bit more efficient to replace a string concatenation with yet another StringBuilder operation? src/share/classes/com/sun/java/util/jar/pack/BandStructure.java 631 StringBuilder sb = new StringBuilder(); ... 636 Utils.log.fine(" meta-coding "+sb); => 631 StringBuilder sb = new StringBuilder(" meta-coding "); ... 636 Utils.log.fine(sb); and 759 StringBuilder sb = new StringBuilder(); ... 764 ps.print(" //header: "+sb); => 759 StringBuilder sb = new StringBuilder(" //header: "); ... 764 ps.print(sb); Sincerely yours, Ivan On 12.05.2014 14:03, Paul Sandoz wrote: > Hi, > > This is a request for review of Otavio's patch replacing StringBuffer with StringBuilder within OpenJDK. (I also need to review it.) > > It covers many areas and i have grouped the patches into such areas to aid reviewing. When commenting please including core-libs. > > Jtreg tests showed no regressions, but when reviewing we need to be mindful of the context e.g. if the buffer escapes and can cross thread boundaries. > > This is also an experiment to see if we can review the whole thing under one bug :-) if things prove problematic and slow we can split it out. Many files are touched but there are not many changes to each file and changes are very formulaic. > > I have also included ASM related changes, but i suspect we may have to leave those alone since such changes will make it more difficult to pull in ASM from upstream. > > - > > Otavio, for the record can you reply to this thread posting your single ("uber") patch as textual attachment? (IIUC such attachments should now be supported by the email server). > > Paul. > > - core > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/ > > - io > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/ > > - management > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/ > > - rmi > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/ > > - security > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ > > > - tools > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/ > > > - graphics/media > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ > > > - asm > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon May 12 10:42:54 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 May 2014 11:42:54 +0100 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Message-ID: <5370A5AE.4080909@oracle.com> On 12/05/2014 11:03, Paul Sandoz wrote: > > It covers many areas and i have grouped the patches into such areas to > aid reviewing. When commenting please including core-libs. The groupings are a bit odd but I looked through the -core, -io, -management and -rmi patches and don't see any issues. Nothing jumped out to suggest that the StringBuffer could be leaked to other threads. There are a few cases where additional work could be done but I assume you want to focus on s/StringBuffer/StringBuilder/g. You might want to hear from Remi or Kumar before including asm. I mention it because there might be preference to get changes to ASM done upstream to avoid the copy in OpenJDK from diverging. As a general point then I don't see any reason why this can't be one change-set. Periodically it makes sense to do a coarse grain split, say core + client but shouldn't be necessary here, unless of course there is some major refactoring or other big changes in, or coming soon to, jdk9/client. A coarse grain split just reduced the need for merging when sync'ing up integration forests. One minor comment is that refactoring where you change the name of the local can sometimes impact the alignment of statement that span several lines. VMID.toString is the only one that I noticed here and it's no big deal. -Alan. From paul.sandoz at oracle.com Mon May 12 10:55:13 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 May 2014 12:55:13 +0200 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <5370A5AE.4080909@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5370A5AE.4080909@oracle.com> Message-ID: <424F5797-258F-4DD8-A0FD-BFE5DFA6FC74@oracle.com> On May 12, 2014, at 12:42 PM, Alan Bateman wrote: > On 12/05/2014 11:03, Paul Sandoz wrote: >> >> It covers many areas and i have grouped the patches into such areas to aid reviewing. When commenting please including core-libs. > The groupings are a bit odd Yeah, definitely idiosyncratic, i tried to lump 'em in terms of areas where people could focus their expertise without creating too few or too many webrevs. > but I looked through the -core, -io, -management and -rmi patches and don't see any issues. Thanks! > Nothing jumped out to suggest that the StringBuffer could be leaked to other threads. There are a few cases where additional work could be done but I assume you want to focus on s/StringBuffer/StringBuilder/g. > It might be worth fixing those if they are not too disruptive. > You might want to hear from Remi or Kumar before including asm. I mention it because there might be preference to get changes to ASM done upstream to avoid the copy in OpenJDK from diverging. > Yes. > As a general point then I don't see any reason why this can't be one change-set. Periodically it makes sense to do a coarse grain split, say core + client but shouldn't be necessary here, unless of course there is some major refactoring or other big changes in, or coming soon to, jdk9/client. A coarse grain split just reduced the need for merging when sync'ing up integration forests. > Ok. > One minor comment is that refactoring where you change the name of the local can sometimes impact the alignment of statement that span several lines. VMID.toString is the only one that I noticed here and it's no big deal. > I fixed that. Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ivan.gerasimov at oracle.com Mon May 12 11:00:04 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 12 May 2014 15:00:04 +0400 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Message-ID: <5370A9B4.80809@oracle.com> src/share/classes/sun/misc/UUDecoder.java 126 StringBuilder x = new StringBuilder(); Is only filled, but doesn't seem to be used anyhow. Maybe just delete it? Sincerely yours, Ivan On 12.05.2014 14:03, Paul Sandoz wrote: > Hi, > > This is a request for review of Otavio's patch replacing StringBuffer > with StringBuilder within OpenJDK. (I also need to review it.) > > It covers many areas and i have grouped the patches into such areas to > aid reviewing. When commenting please including core-libs. > > Jtreg tests showed no regressions, but when reviewing we need to be > mindful of the context e.g. if the buffer escapes and can cross thread > boundaries. > > This is also an experiment to see if we can review the whole thing > under one bug :-) if things prove problematic and slow we can split it > out. Many files are touched but there are not many changes to each > file and changes are very formulaic. > > I have also included ASM related changes, but i suspect we may have to > leave those alone since such changes will make it more difficult to > pull in ASM from upstream. > - > > Otavio, for the record can you reply to this thread posting your > single ("uber") patch as textual attachment? (IIUC such attachments > should now be supported by the email server). > > Paul. > > - core > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/ > > > - io > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/ > > > - management > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/ > > > - rmi > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/ > > > - security > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ > > > > - tools > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/ > > > > - graphics/media > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ > > > > - asm > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Mon May 12 11:17:43 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 12 May 2014 19:17:43 +0800 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Message-ID: <5370ADD7.4070208@oracle.com> > - security > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ Looks fine to me. Thanks for making this update. Xuelei On 5/12/2014 6:03 PM, Paul Sandoz wrote: > Hi, > > This is a request for review of Otavio's patch replacing StringBuffer > with StringBuilder within OpenJDK. (I also need to review it.) > > It covers many areas and i have grouped the patches into such areas to > aid reviewing. When commenting please including core-libs. > > Jtreg tests showed no regressions, but when reviewing we need to be > mindful of the context e.g. if the buffer escapes and can cross thread > boundaries. > > This is also an experiment to see if we can review the whole thing under > one bug :-) if things prove problematic and slow we can split it > out. Many files are touched but there are not many changes to each file > and changes are very formulaic. > > I have also included ASM related changes, but i suspect we may have to > leave those alone since such changes will make it more difficult to pull > in ASM from upstream. > > - > > Otavio, for the record can you reply to this thread posting your single > ("uber") patch as textual attachment? (IIUC such attachments should now > be supported by the email server). > > Paul. > > - core > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/ > > - io > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/ > > - management > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/ > > - rmi > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/ > > - security > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ > > > - tools > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/ > > > - graphics/media > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ > > > - asm > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/ From daniel.fuchs at oracle.com Mon May 12 14:07:57 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 12 May 2014 16:07:57 +0200 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Message-ID: <5370D5BD.4030503@oracle.com> Hi Paul, I looked at -management and the changes there look good. There is just some two spaces vs four space formatting in line 99. best regards, -- daniel On 5/12/14 12:03 PM, Paul Sandoz wrote: > Hi, > > This is a request for review of Otavio's patch replacing StringBuffer > with StringBuilder within OpenJDK. (I also need to review it.) > > It covers many areas and i have grouped the patches into such areas to > aid reviewing. When commenting please including core-libs. > > Jtreg tests showed no regressions, but when reviewing we need to be > mindful of the context e.g. if the buffer escapes and can cross thread > boundaries. > > This is also an experiment to see if we can review the whole thing under > one bug :-) if things prove problematic and slow we can split it > out. Many files are touched but there are not many changes to each file > and changes are very formulaic. > > I have also included ASM related changes, but i suspect we may have to > leave those alone since such changes will make it more difficult to pull > in ASM from upstream. > - > > Otavio, for the record can you reply to this thread posting your single > ("uber") patch as textual attachment? (IIUC such attachments should now > be supported by the email server). > > Paul. > > - core > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/ > > - io > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/ > > - management > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/ > > - rmi > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/ > > - security > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ > > > - tools > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/ > > > - graphics/media > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ > > > - asm > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/ From kevin.walls at oracle.com Mon May 12 15:02:03 2014 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 12 May 2014 16:02:03 +0100 Subject: RFR: 8039995: Test serviceability/sa/jmap-hashcode/Test8028623.java fails on some Linux/Mac machines. Message-ID: <5370E26B.3030509@oracle.com> Hi, I'd like to get a review of this test change. It assumed that jmap would have permission to run on a process that the test itself created, but this is not necessarily the case. Here I'm considering it OK to skip (pass) the test where jmap fails to attach. The test itself was not platform-specific and as long as we have other platforms where jmap step will work, we are testing for this problem. bug: https://bugs.openjdk.java.net/browse/JDK-8039995 webrev: http://cr.openjdk.java.net/~kevinw/8039995/webrev.00/ Thanks Kevin From forax at univ-mlv.fr Mon May 12 16:43:05 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 12 May 2014 18:43:05 +0200 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <5370A5AE.4080909@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5370A5AE.4080909@oracle.com> Message-ID: <5370FA19.9090107@univ-mlv.fr> On 05/12/2014 12:42 PM, Alan Bateman wrote: > On 12/05/2014 11:03, Paul Sandoz wrote: >> >> It covers many areas and i have grouped the patches into such areas >> to aid reviewing. When commenting please including core-libs. > The groupings are a bit odd but I looked through the -core, -io, > -management and -rmi patches and don't see any issues. Nothing jumped > out to suggest that the StringBuffer could be leaked to other threads. > There are a few cases where additional work could be done but I assume > you want to focus on s/StringBuffer/StringBuilder/g. > > You might want to hear from Remi or Kumar before including asm. I > mention it because there might be preference to get changes to ASM > done upstream to avoid the copy in OpenJDK from diverging. Hi all, I've applied the changes to the ASM trunk so Kumar can sync when he wants, the current revision of the trunk is 1745 cheers, R?mi From paul.sandoz at oracle.com Tue May 13 08:32:43 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 13 May 2014 10:32:43 +0200 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <5370A9B4.80809@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5370A9B4.80809@oracle.com> Message-ID: On May 12, 2014, at 1:00 PM, Ivan Gerasimov wrote: > src/share/classes/sun/misc/UUDecoder.java > 126 StringBuilder x = new StringBuilder(); > Is only filled, but doesn't seem to be used anyhow. > Maybe just delete it? > Thanks, i will take a look at this and your other change once s/StringBuffer/StringBuilder/g is out of the way. Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From paul.sandoz at oracle.com Tue May 13 08:35:18 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 13 May 2014 10:35:18 +0200 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <5370D5BD.4030503@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5370D5BD.4030503@oracle.com> Message-ID: On May 12, 2014, at 4:07 PM, Daniel Fuchs wrote: > Hi Paul, > > I looked at -management and the changes there look good. > > There is just some two spaces vs four space formatting in > > line 99. > Thanks, updated. Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Alan.Bateman at oracle.com Tue May 13 08:45:34 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 May 2014 09:45:34 +0100 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <424F5797-258F-4DD8-A0FD-BFE5DFA6FC74@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5370A5AE.4080909@oracle.com> <424F5797-258F-4DD8-A0FD-BFE5DFA6FC74@oracle.com> Message-ID: <5371DBAE.8010109@oracle.com> On 12/05/2014 11:55, Paul Sandoz wrote: > On May 12, 2014, at 12:42 PM, Alan Bateman wrote: > >> On 12/05/2014 11:03, Paul Sandoz wrote: >>> It covers many areas and i have grouped the patches into such areas to aid reviewing. When commenting please including core-libs. >> The groupings are a bit odd > Yeah, definitely idiosyncratic, i tried to lump 'em in terms of areas where people could focus their expertise without creating too few or too many webrevs. > I looked through the -tools and don't see anything escaping so looks good to me. Minor alignment issues in ExpressionParser and TokenMgrError. I also didn't see any takers for -media so I looked through those changes too. A lot of toString methods and I don't see anything obviously leaking to other threads. The s/retBuffer/sb/ in TreeModelEvent.toString is another multi-line statement, no big deal of course. Minor alignment issue in DefaultTreeSelectionModel and StandardTextSource. -Alan. From staffan.larsen at oracle.com Tue May 13 09:20:41 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 13 May 2014 11:20:41 +0200 Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync In-Reply-To: <536D1BDC.7000908@oracle.com> References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com> <536BB959.7060706@oracle.com> <2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com> <536D1BDC.7000908@oracle.com> Message-ID: On 9 maj 2014, at 20:18, serguei.spitsyn at oracle.com wrote: > Staffan, > > This is important discovery, thanks! > The fix looks good to me. > One question below. > > Thanks, > Serguei > > > On 5/9/14 3:47 AM, Staffan Larsen wrote: >> On 8 maj 2014, at 19:05, Daniel D. Daugherty wrote: >> >>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >>> src/share/vm/runtime/sharedRuntime.hpp >>> No comments. >>> >>> src/share/vm/runtime/sharedRuntime.cpp >>> line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit( >>> I'm not sure that JRT_LEAF is right. I would think that >>> JvmtiExport::post_method_exit() would have to grab one or >>> more locks with all the state checks it has to make... >>> >>> For reference, InterpreterRuntime::post_method_exit() >>> is a wrapper around JvmtiExport::post_method_exit() >>> and it is IRT_ENTRY instead of IRT_LEAF. >> Good catch! > > Q: Is correct to use call_VM_leaf (vs call_VM ) in the sharedRuntime_.cpp ? > > + __ call_VM_leaf( > + CAST_FROM_FN_PTR(address, SharedRuntime::jvmti_method_exit), > + thread, rax); That is another good catch! It should probably be call_VM as you note. The reason for all these leaf references is because we used the dtrace probe as a template - obviously without fully understanding what we did :-/ I have changed to code to use call_VM instead. This also required a change from jccb to jcc for the jump (which is now longer than an 8-bit offset). new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/ Thanks, /Staffan > >>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp >>> No comments. >>> >>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp >>> No comments. >>> >>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp >>> No comments. >>> >>> I'm guessing that PPC has the same issue, but I'm presuming >>> that someone else (Vladimir?) will handle that? >> Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix. >> >> Updated review: http://cr.openjdk.java.net/~sla/8041934/webrev.01/ >> >> Thanks, >> /Staffan >> >>> Dan >>> >>> >>> On 5/8/14 12:06 AM, Staffan Larsen wrote: >>>> All, >>>> >>>> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct. >>>> >>>> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert. >>>> >>>> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms. >>>> >>>> Kudos to Rickard for helping me write the code. >>>> >>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041934 >>>> >>>> The fix has been verified by running the failing test in JPRT with -Xcomp. >>>> >>>> Thanks, >>>> /Staffan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue May 13 10:57:39 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 May 2014 11:57:39 +0100 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <5371F7EA.1030300@oracle.com> References: <5371F7EA.1030300@oracle.com> Message-ID: <5371FAA3.3040006@oracle.com> This is debugger's shared memory transport so cc'ing serviceability-dev as that is there this code is maintained. Is there a test case or any outline of the conditions that cause this? I think that would be useful to understand the issue further. -Alan On 13/05/2014 11:46, Aleksej Efimov wrote: > Hi, > > Can I have a review for 8032901 bug [1] fix [2]. There is a possible > case when 'WaitForMultipleObjects' function can return the > WAIT_ABANDONED_0 [3] error value. > In such case it's better to release the mutex and return error value. > This will prevent other threads to be blocked on abandoned mutex. > > Thank you, > Aleksej > > [1] https://bugs.openjdk.java.net/browse/JDK-8032901 > [2] http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.00/ > [3] > http://msdn.microsoft.com/en-gb/library/windows/desktop/ms687025(v=vs.85).aspx > From aleksej.efimov at oracle.com Tue May 13 11:43:29 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 13 May 2014 15:43:29 +0400 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <5371FAA3.3040006@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> Message-ID: <53720561.9080600@oracle.com> Alan, There is no test case for this issue and also the attempt to outline the conditions ended with no result. The report is based only on 'WaitForMultipleObjects' code analysis and this fix is an attempt to make the code looks a little more correct. -Aleksej On 05/13/2014 02:57 PM, Alan Bateman wrote: > > This is debugger's shared memory transport so cc'ing > serviceability-dev as that is there this code is maintained. > > Is there a test case or any outline of the conditions that cause this? > I think that would be useful to understand the issue further. > > -Alan > > On 13/05/2014 11:46, Aleksej Efimov wrote: >> Hi, >> >> Can I have a review for 8032901 bug [1] fix [2]. There is a possible >> case when 'WaitForMultipleObjects' function can return the >> WAIT_ABANDONED_0 [3] error value. >> In such case it's better to release the mutex and return error value. >> This will prevent other threads to be blocked on abandoned mutex. >> >> Thank you, >> Aleksej >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8032901 >> [2] http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.00/ >> [3] >> http://msdn.microsoft.com/en-gb/library/windows/desktop/ms687025(v=vs.85).aspx >> > From david.holmes at oracle.com Tue May 13 12:00:12 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 May 2014 22:00:12 +1000 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <5371FAA3.3040006@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> Message-ID: <5372094C.5070407@oracle.com> I don't understand this one at all. What is an "abandoned mutex"? For that matter why does the code wait on a mutex and an event? Do we already own the mutex? If so what does it mean to wait on it? If not then how can we release it? ??? Thanks, David On 13/05/2014 8:57 PM, Alan Bateman wrote: > > This is debugger's shared memory transport so cc'ing serviceability-dev > as that is there this code is maintained. > > Is there a test case or any outline of the conditions that cause this? I > think that would be useful to understand the issue further. > > -Alan > > On 13/05/2014 11:46, Aleksej Efimov wrote: >> Hi, >> >> Can I have a review for 8032901 bug [1] fix [2]. There is a possible >> case when 'WaitForMultipleObjects' function can return the >> WAIT_ABANDONED_0 [3] error value. >> In such case it's better to release the mutex and return error value. >> This will prevent other threads to be blocked on abandoned mutex. >> >> Thank you, >> Aleksej >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8032901 >> [2] http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.00/ >> [3] >> http://msdn.microsoft.com/en-gb/library/windows/desktop/ms687025(v=vs.85).aspx >> > From aleksej.efimov at oracle.com Tue May 13 13:19:07 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Tue, 13 May 2014 17:19:07 +0400 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <5372094C.5070407@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> Message-ID: <53721BCB.4060200@oracle.com> David, The Windows has a different terminology for mutex objects (much differs from the POSIX one). This one link gave me some understanding of it [1]. Here is the MSDN [1] description of what "abandoned mutex" is: " If a thread terminates without releasing its ownership of a mutex object, the mutex object is considered to be abandoned. A waiting thread can acquire ownership of an abandoned mutex object, but the wait function will return*WAIT_ABANDONED*to indicate that the mutex object is abandoned. An abandoned mutex object indicates that an error has occurred and that any shared resource being protected by the mutex object is in an undefined state. If the thread proceeds as though the mutex object had not been abandoned, it is no longer considered abandoned after the thread releases its ownership. This restores normal behavior if a handle to the mutex object is subsequently specified in a wait function." What does it mean to wait on mutex and ownership of the mutex object: "Any thread with a handle to a mutex object can use one of thewait functions to request ownership of the mutex object. If the mutex object is owned by another thread, the wait function blocks the requesting thread until the owning thread releases the mutex object using the*ReleaseMutex* function." How we can release mutex and wait on already owned mutex: " After a thread obtains ownership of a mutex, it can specify the same mutex in repeated calls to the wait-functions without blocking its execution. This prevents a thread from deadlocking itself while waiting for a mutex that it already owns. To release its ownership under such circumstances, the thread must call*ReleaseMutex* once for each time that the mutex satisfied the conditions of a wait function." [1] http://msdn.microsoft.com/en-gb/library/windows/desktop/ms684266(v=vs.85).aspx -Aleksej On 05/13/2014 04:00 PM, David Holmes wrote: > I don't understand this one at all. What is an "abandoned mutex"? For > that matter why does the code wait on a mutex and an event? Do we > already own the mutex? If so what does it mean to wait on it? If not > then how can we release it? > > ??? > > Thanks, > David > > > On 13/05/2014 8:57 PM, Alan Bateman wrote: >> >> This is debugger's shared memory transport so cc'ing serviceability-dev >> as that is there this code is maintained. >> >> Is there a test case or any outline of the conditions that cause this? I >> think that would be useful to understand the issue further. >> >> -Alan >> >> On 13/05/2014 11:46, Aleksej Efimov wrote: >>> Hi, >>> >>> Can I have a review for 8032901 bug [1] fix [2]. There is a possible >>> case when 'WaitForMultipleObjects' function can return the >>> WAIT_ABANDONED_0 [3] error value. >>> In such case it's better to release the mutex and return error value. >>> This will prevent other threads to be blocked on abandoned mutex. >>> >>> Thank you, >>> Aleksej >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8032901 >>> [2] http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.00/ >>> [3] >>> http://msdn.microsoft.com/en-gb/library/windows/desktop/ms687025(v=vs.85).aspx >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Tue May 13 16:53:43 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 13 May 2014 10:53:43 -0600 Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync In-Reply-To: References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com> <536BB959.7060706@oracle.com> <2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com> <536D1BDC.7000908@oracle.com> Message-ID: <53724E17.2080406@oracle.com> > new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/ src/share/vm/runtime/sharedRuntime.hpp No comments. src/share/vm/runtime/sharedRuntime.cpp No comments. src/cpu/sparc/vm/sharedRuntime_sparc.cpp No comments. src/cpu/x86/vm/sharedRuntime_x86_32.cpp No comments. src/cpu/x86/vm/sharedRuntime_x86_64.cpp No comments. On the switch from call_VM_leaf() -> call_VM(), I looked through all the mentions of the string call_VM in the three src/cpu files. Your change adds the first call_VM() use in all three files and the other places that mention the string "call_VM" seem to have gone through a great deal of trouble not to use call_VM() directly. I have no specific thing I think is wrong, but I find this data worrisome... Thumbs up! Dan On 5/13/14 3:20 AM, Staffan Larsen wrote: > > On 9 maj 2014, at 20:18, serguei.spitsyn at oracle.com > wrote: > >> Staffan, >> >> This is important discovery, thanks! >> The fix looks good to me. >> One question below. >> >> Thanks, >> Serguei >> >> >> On 5/9/14 3:47 AM, Staffan Larsen wrote: >>> On 8 maj 2014, at 19:05, Daniel D. Daugherty wrote: >>> >>>>> webrev:http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >>>> src/share/vm/runtime/sharedRuntime.hpp >>>> No comments. >>>> >>>> src/share/vm/runtime/sharedRuntime.cpp >>>> line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit( >>>> I'm not sure that JRT_LEAF is right. I would think that >>>> JvmtiExport::post_method_exit() would have to grab one or >>>> more locks with all the state checks it has to make... >>>> >>>> For reference, InterpreterRuntime::post_method_exit() >>>> is a wrapper around JvmtiExport::post_method_exit() >>>> and it is IRT_ENTRY instead of IRT_LEAF. >>> Good catch! >> >> Q: Is correct to use call_VM_leaf (vs call_VM ) in the >> sharedRuntime_.cpp ? >> >> + __ call_VM_leaf( >> + CAST_FROM_FN_PTR(address, SharedRuntime::jvmti_method_exit), >> + thread, rax); > > That is another good catch! It should probably be call_VM as you note. > The reason for all these leaf references is because we used the dtrace > probe as a template - obviously without fully understanding what we > did :-/ > > I have changed to code to use call_VM instead. This also required a > change from jccb to jcc for the jump (which is now longer than an > 8-bit offset). > > new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/ > > > Thanks, > /Staffan > > >> >>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp >>>> No comments. >>>> >>>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp >>>> No comments. >>>> >>>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp >>>> No comments. >>>> >>>> I'm guessing that PPC has the same issue, but I'm presuming >>>> that someone else (Vladimir?) will handle that? >>> Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix. >>> >>> Updated review:http://cr.openjdk.java.net/~sla/8041934/webrev.01/ >>> >>> Thanks, >>> /Staffan >>> >>>> Dan >>>> >>>> >>>> On 5/8/14 12:06 AM, Staffan Larsen wrote: >>>>> All, >>>>> >>>>> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct. >>>>> >>>>> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert. >>>>> >>>>> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms. >>>>> >>>>> Kudos to Rickard for helping me write the code. >>>>> >>>>> webrev:http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8041934 >>>>> >>>>> The fix has been verified by running the failing test in JPRT with -Xcomp. >>>>> >>>>> Thanks, >>>>> /Staffan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Tue May 13 17:42:56 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 13 May 2014 11:42:56 -0600 Subject: RFR (S) 8042796: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <536D1C8A.4080503@oracle.com> References: <536D1C8A.4080503@oracle.com> Message-ID: <537259A0.10005@oracle.com> > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8042796-JVMTI-OLD.1 src/share/vm/oops/method.hpp No comments. src/share/vm/utilities/accessFlags.hpp line 57: JVM_ACC_ON_STACK = 0x00080000, // RedefinedClasses() is used on the stack Typos: 'RedefinedClasses() is' -> 'RedefineClasses() was' Not your typos, but would you mind fixing them? src/share/vm/oops/cpCache.cpp line 501: (!f1_as_method()->is_old() && !f1_as_method()->is_obsolete() || line 502 f1_as_method()->is_deleted())); Perhaps this would a little more clear (added parens and reformatted): line 501: ((!f1_as_method()->is_old() && !f1_as_method()->is_obsolete()) || line 502 f1_as_method()->is_deleted())); Or this one: line 501: (f1_as_method()->is_deleted() || line 502: (!f1_as_method()->is_old() && !f1_as_method()->is_obsolete()))); src/share/vm/prims/jvmtiRedefineClasses.cpp No comments Thumbs up even if you don't want to juggle the logic in cpCache.cpp... Minor clarification: > - A regression introduced by the fix of: > https://bugs.openjdk.java.net/browse/JDK-7182152 The above fix modified the existing VM_RedefineClasses::check_class() code to use guarantee() instead of assert() and also modified the logic to catch "obsolete" in addition to "old" entries. I strongly suspect that the code before JDK-7182152 would still have fired an assert in the presence of deleted methods so the regression is probably older than JDK-7182152. Don't know if it is worth fixing that far back though... Dan On 5/9/14 12:20 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8042796 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8042796-JVMTI-OLD.1 > > > Summary: > > This is a Nightly Stabilization issue that was caused by a > combination of two problems: > - A regression introduced by the fix of: > https://bugs.openjdk.java.net/browse/JDK-7182152 > - An SQE testbase infra regression: > https://bugs.openjdk.java.net/browse/INTJDK-7611018 > > A number of the vm.mlvm tests hits this guarantee taht was added by > 7182152 (must be relaxed). > The issue is with the deleted static private methods that are still > present in the CP cache. > The fix is to mark the deleted methods with the flag > JVM_ACC_IS_DELETED and > then use it to relax the guarantee condition. > > > Testing: > Running the failing tests: vm.mlvm.indy.func.jvmti > In progress: nsk.jvmti, nsk.jdi, java.lang.instrument test runs on > sparcv9 and amd64. > > > Thanks, > Serguei From staffan.larsen at oracle.com Tue May 13 18:30:33 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 13 May 2014 20:30:33 +0200 Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync In-Reply-To: <53724E17.2080406@oracle.com> References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com> <536BB959.7060706@oracle.com> <2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com> <536D1BDC.7000908@oracle.com> <53724E17.2080406@oracle.com> Message-ID: <5B0A0E2F-FD3C-47D1-85C5-0B4470FC4F9D@oracle.com> On 13 maj 2014, at 18:53, Daniel D. Daugherty wrote: > > new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/ > > src/share/vm/runtime/sharedRuntime.hpp > No comments. > > src/share/vm/runtime/sharedRuntime.cpp > No comments. > > src/cpu/sparc/vm/sharedRuntime_sparc.cpp > No comments. > > src/cpu/x86/vm/sharedRuntime_x86_32.cpp > No comments. > > src/cpu/x86/vm/sharedRuntime_x86_64.cpp > No comments. > > On the switch from call_VM_leaf() -> call_VM(), I looked through all > the mentions of the string call_VM in the three src/cpu files. Your > change adds the first call_VM() use in all three files and the other > places that mention the string "call_VM" seem to have gone through > a great deal of trouble not to use call_VM() directly. I have no > specific thing I think is wrong, but I find this data worrisome? Yes, it would be great if someone from the compiler team could review this, too. Thanks, /Staffan > > Thumbs up! > > Dan > > > On 5/13/14 3:20 AM, Staffan Larsen wrote: >> >> On 9 maj 2014, at 20:18, serguei.spitsyn at oracle.com wrote: >> >>> Staffan, >>> >>> This is important discovery, thanks! >>> The fix looks good to me. >>> One question below. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 5/9/14 3:47 AM, Staffan Larsen wrote: >>>> On 8 maj 2014, at 19:05, Daniel D. Daugherty wrote: >>>> >>>>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >>>>> src/share/vm/runtime/sharedRuntime.hpp >>>>> No comments. >>>>> >>>>> src/share/vm/runtime/sharedRuntime.cpp >>>>> line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit( >>>>> I'm not sure that JRT_LEAF is right. I would think that >>>>> JvmtiExport::post_method_exit() would have to grab one or >>>>> more locks with all the state checks it has to make... >>>>> >>>>> For reference, InterpreterRuntime::post_method_exit() >>>>> is a wrapper around JvmtiExport::post_method_exit() >>>>> and it is IRT_ENTRY instead of IRT_LEAF. >>>> Good catch! >>> >>> Q: Is correct to use call_VM_leaf (vs call_VM ) in the sharedRuntime_.cpp ? >>> >>> + __ call_VM_leaf( >>> + CAST_FROM_FN_PTR(address, SharedRuntime::jvmti_method_exit), >>> + thread, rax); >> >> That is another good catch! It should probably be call_VM as you note. The reason for all these leaf references is because we used the dtrace probe as a template - obviously without fully understanding what we did :-/ >> >> I have changed to code to use call_VM instead. This also required a change from jccb to jcc for the jump (which is now longer than an 8-bit offset). >> >> new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/ >> >> Thanks, >> /Staffan >> >> >>> >>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp >>>>> No comments. >>>>> >>>>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp >>>>> No comments. >>>>> >>>>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp >>>>> No comments. >>>>> >>>>> I'm guessing that PPC has the same issue, but I'm presuming >>>>> that someone else (Vladimir?) will handle that? >>>> Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix. >>>> >>>> Updated review: http://cr.openjdk.java.net/~sla/8041934/webrev.01/ >>>> >>>> Thanks, >>>> /Staffan >>>> >>>>> Dan >>>>> >>>>> >>>>> On 5/8/14 12:06 AM, Staffan Larsen wrote: >>>>>> All, >>>>>> >>>>>> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct. >>>>>> >>>>>> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert. >>>>>> >>>>>> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms. >>>>>> >>>>>> Kudos to Rickard for helping me write the code. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041934 >>>>>> >>>>>> The fix has been verified by running the failing test in JPRT with -Xcomp. >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue May 13 20:03:47 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 13 May 2014 13:03:47 -0700 Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync In-Reply-To: References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com> <536BB959.7060706@oracle.com> <2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com> <536D1BDC.7000908@oracle.com> Message-ID: <53727AA3.8070500@oracle.com> On 5/13/14 2:20 AM, Staffan Larsen wrote: > > On 9 maj 2014, at 20:18, serguei.spitsyn at oracle.com > wrote: > >> Staffan, >> >> This is important discovery, thanks! >> The fix looks good to me. >> One question below. >> >> Thanks, >> Serguei >> >> >> On 5/9/14 3:47 AM, Staffan Larsen wrote: >>> On 8 maj 2014, at 19:05, Daniel D. Daugherty wrote: >>> >>>>> webrev:http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >>>> src/share/vm/runtime/sharedRuntime.hpp >>>> No comments. >>>> >>>> src/share/vm/runtime/sharedRuntime.cpp >>>> line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit( >>>> I'm not sure that JRT_LEAF is right. I would think that >>>> JvmtiExport::post_method_exit() would have to grab one or >>>> more locks with all the state checks it has to make... >>>> >>>> For reference, InterpreterRuntime::post_method_exit() >>>> is a wrapper around JvmtiExport::post_method_exit() >>>> and it is IRT_ENTRY instead of IRT_LEAF. >>> Good catch! >> >> Q: Is correct to use call_VM_leaf (vs call_VM ) in the >> sharedRuntime_.cpp ? >> >> + __ call_VM_leaf( >> + CAST_FROM_FN_PTR(address, SharedRuntime::jvmti_method_exit), >> + thread, rax); > > That is another good catch! It should probably be call_VM as you note. > The reason for all these leaf references is because we used the dtrace > probe as a template - obviously without fully understanding what we > did :-/ > > I have changed to code to use call_VM instead. This also required a > change from jccb to jcc for the jump (which is now longer than an > 8-bit offset). > > new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/ > > > Thanks, > /Staffan > > >> >>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp >>>> No comments. >>>> >>>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp >>>> No comments. >>>> >>>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp >>>> No comments. >>>> >>>> I'm guessing that PPC has the same issue, but I'm presuming >>>> that someone else (Vladimir?) will handle that? >>> Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix. >>> >>> Updated review:http://cr.openjdk.java.net/~sla/8041934/webrev.01/ Looks good to me. Thanks, Serguei >>> >>> Thanks, >>> /Staffan >>> >>>> Dan >>>> >>>> >>>> On 5/8/14 12:06 AM, Staffan Larsen wrote: >>>>> All, >>>>> >>>>> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct. >>>>> >>>>> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert. >>>>> >>>>> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms. >>>>> >>>>> Kudos to Rickard for helping me write the code. >>>>> >>>>> webrev:http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8041934 >>>>> >>>>> The fix has been verified by running the failing test in JPRT with -Xcomp. >>>>> >>>>> Thanks, >>>>> /Staffan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue May 13 20:19:16 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 13 May 2014 13:19:16 -0700 Subject: RFR (S) 8042796: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <537259A0.10005@oracle.com> References: <536D1C8A.4080503@oracle.com> <537259A0.10005@oracle.com> Message-ID: <53727E44.4010308@oracle.com> Dan, Thank you a lot for reviewing! On 5/13/14 10:42 AM, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8042796-JVMTI-OLD.1 > > > src/share/vm/oops/method.hpp > No comments. > > src/share/vm/utilities/accessFlags.hpp > line 57: JVM_ACC_ON_STACK = 0x00080000, // > RedefinedClasses() is used on the stack > Typos: 'RedefinedClasses() is' -> 'RedefineClasses() was' > Not your typos, but would you mind fixing them? Thanks, I'll fix it. > > src/share/vm/oops/cpCache.cpp > line 501: (!f1_as_method()->is_old() && > !f1_as_method()->is_obsolete() || > line 502 f1_as_method()->is_deleted())); > > Perhaps this would a little more clear (added parens and > reformatted): > > line 501: ((!f1_as_method()->is_old() && > !f1_as_method()->is_obsolete()) || > line 502 f1_as_method()->is_deleted())); > > Or this one: > > line 501: (f1_as_method()->is_deleted() || > line 502: (!f1_as_method()->is_old() && > !f1_as_method()->is_obsolete()))); I agree and will fix it as you suggested. > > src/share/vm/prims/jvmtiRedefineClasses.cpp > No comments > > Thumbs up even if you don't want to juggle the logic > in cpCache.cpp... > > Minor clarification: > > > - A regression introduced by the fix of: > > https://bugs.openjdk.java.net/browse/JDK-7182152 > > The above fix modified the existing VM_RedefineClasses::check_class() > code to use guarantee() instead of assert() and also modified the > logic to catch "obsolete" in addition to "old" entries. I strongly > suspect that the code before JDK-7182152 would still have fired an > assert in the presence of deleted methods so the regression is > probably older than JDK-7182152. Don't know if it is worth fixing > that far back though... Most likely, you are right. In fact, it is not that easy to track it back in time so far. :) Thanks, Serguei > > Dan > > > On 5/9/14 12:20 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8042796 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8042796-JVMTI-OLD.1 >> >> >> Summary: >> >> This is a Nightly Stabilization issue that was caused by a >> combination of two problems: >> - A regression introduced by the fix of: >> https://bugs.openjdk.java.net/browse/JDK-7182152 >> - An SQE testbase infra regression: >> https://bugs.openjdk.java.net/browse/INTJDK-7611018 >> >> A number of the vm.mlvm tests hits this guarantee taht was added by >> 7182152 (must be relaxed). >> The issue is with the deleted static private methods that are still >> present in the CP cache. >> The fix is to mark the deleted methods with the flag >> JVM_ACC_IS_DELETED and >> then use it to relax the guarantee condition. >> >> >> Testing: >> Running the failing tests: vm.mlvm.indy.func.jvmti >> In progress: nsk.jvmti, nsk.jdi, java.lang.instrument test runs on >> sparcv9 and amd64. >> >> >> Thanks, >> Serguei > From christian.thalinger at oracle.com Tue May 13 22:21:56 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 13 May 2014 15:21:56 -0700 Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync In-Reply-To: <5B0A0E2F-FD3C-47D1-85C5-0B4470FC4F9D@oracle.com> References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com> <536BB959.7060706@oracle.com> <2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com> <536D1BDC.7000908@oracle.com> <53724E17.2080406@oracle.com> <5B0A0E2F-FD3C-47D1-85C5-0B4470FC4F9D@oracle.com> Message-ID: Since: int _interp_only_mode; is an int field I would prefer to actually read the value as an int instead of just a byte on x86: + __ cmpb(Address(r15_thread, JavaThread::interp_only_mode_offset()), 0); Otherwise this looks good. On May 13, 2014, at 11:30 AM, Staffan Larsen wrote: > > On 13 maj 2014, at 18:53, Daniel D. Daugherty wrote: > >> > new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/ >> >> src/share/vm/runtime/sharedRuntime.hpp >> No comments. >> >> src/share/vm/runtime/sharedRuntime.cpp >> No comments. >> >> src/cpu/sparc/vm/sharedRuntime_sparc.cpp >> No comments. >> >> src/cpu/x86/vm/sharedRuntime_x86_32.cpp >> No comments. >> >> src/cpu/x86/vm/sharedRuntime_x86_64.cpp >> No comments. >> >> On the switch from call_VM_leaf() -> call_VM(), I looked through all >> the mentions of the string call_VM in the three src/cpu files. Your >> change adds the first call_VM() use in all three files and the other >> places that mention the string "call_VM" seem to have gone through >> a great deal of trouble not to use call_VM() directly. I have no >> specific thing I think is wrong, but I find this data worrisome? > > Yes, it would be great if someone from the compiler team could review this, too. > > Thanks, > /Staffan > >> >> Thumbs up! >> >> Dan >> >> >> On 5/13/14 3:20 AM, Staffan Larsen wrote: >>> >>> On 9 maj 2014, at 20:18, serguei.spitsyn at oracle.com wrote: >>> >>>> Staffan, >>>> >>>> This is important discovery, thanks! >>>> The fix looks good to me. >>>> One question below. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 5/9/14 3:47 AM, Staffan Larsen wrote: >>>>> On 8 maj 2014, at 19:05, Daniel D. Daugherty wrote: >>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >>>>>> src/share/vm/runtime/sharedRuntime.hpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/runtime/sharedRuntime.cpp >>>>>> line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit( >>>>>> I'm not sure that JRT_LEAF is right. I would think that >>>>>> JvmtiExport::post_method_exit() would have to grab one or >>>>>> more locks with all the state checks it has to make... >>>>>> >>>>>> For reference, InterpreterRuntime::post_method_exit() >>>>>> is a wrapper around JvmtiExport::post_method_exit() >>>>>> and it is IRT_ENTRY instead of IRT_LEAF. >>>>> Good catch! >>>> >>>> Q: Is correct to use call_VM_leaf (vs call_VM ) in the sharedRuntime_.cpp ? >>>> >>>> + __ call_VM_leaf( >>>> + CAST_FROM_FN_PTR(address, SharedRuntime::jvmti_method_exit), >>>> + thread, rax); >>> >>> That is another good catch! It should probably be call_VM as you note. The reason for all these leaf references is because we used the dtrace probe as a template - obviously without fully understanding what we did :-/ >>> >>> I have changed to code to use call_VM instead. This also required a change from jccb to jcc for the jump (which is now longer than an 8-bit offset). >>> >>> new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/ >>> >>> Thanks, >>> /Staffan >>> >>> >>>> >>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp >>>>>> No comments. >>>>>> >>>>>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp >>>>>> No comments. >>>>>> >>>>>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp >>>>>> No comments. >>>>>> >>>>>> I'm guessing that PPC has the same issue, but I'm presuming >>>>>> that someone else (Vladimir?) will handle that? >>>>> Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix. >>>>> >>>>> Updated review: http://cr.openjdk.java.net/~sla/8041934/webrev.01/ >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> On 5/8/14 12:06 AM, Staffan Larsen wrote: >>>>>>> All, >>>>>>> >>>>>>> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct. >>>>>>> >>>>>>> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert. >>>>>>> >>>>>>> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms. >>>>>>> >>>>>>> Kudos to Rickard for helping me write the code. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041934 >>>>>>> >>>>>>> The fix has been verified by running the failing test in JPRT with -Xcomp. >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue May 13 22:46:19 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 May 2014 08:46:19 +1000 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <53721BCB.4060200@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> Message-ID: <5372A0BB.1040704@oracle.com> Hi Aleksej, Thanks for the doc references regarding abandonment. Let me rephrase my question. What is this logic trying to achieve by waiting on both a mutex and an event? Do we already own the mutex when this function is called? David On 13/05/2014 11:19 PM, Aleksej Efimov wrote: > David, > > The Windows has a different terminology for mutex objects (much differs > from the POSIX one). This one link gave me some understanding of it [1]. > > Here is the MSDN [1] description of what "abandoned mutex" is: > " If a thread terminates without releasing its ownership of a mutex > object, the mutex object is considered to be abandoned. A waiting thread > can acquire ownership of an abandoned mutex object, but the wait > function will return*WAIT_ABANDONED*to indicate that the mutex object is > abandoned. An abandoned mutex object indicates that an error has > occurred and that any shared resource being protected by the mutex > object is in an undefined state. If the thread proceeds as though the > mutex object had not been abandoned, it is no longer considered > abandoned after the thread releases its ownership. This restores normal > behavior if a handle to the mutex object is subsequently specified in a > wait function." > > > What does it mean to wait on mutex and ownership of the mutex object: > "Any thread with a handle to a mutex object can use one of thewait > functions > to > request ownership of the mutex object. If the mutex object is owned by > another thread, the wait function blocks the requesting thread until the > owning thread releases the mutex object using the*ReleaseMutex* > function." > > How we can release mutex and wait on already owned mutex: > " After a thread obtains ownership of a mutex, it can specify the same > mutex in repeated calls to the wait-functions > without > blocking its execution. This prevents a thread from deadlocking itself > while waiting for a mutex that it already owns. To release its ownership > under such circumstances, the thread must call*ReleaseMutex* > once > for each time that the mutex satisfied the conditions of a wait function." > > [1] > http://msdn.microsoft.com/en-gb/library/windows/desktop/ms684266(v=vs.85).aspx > > -Aleksej > > On 05/13/2014 04:00 PM, David Holmes wrote: >> I don't understand this one at all. What is an "abandoned mutex"? For >> that matter why does the code wait on a mutex and an event? Do we >> already own the mutex? If so what does it mean to wait on it? If not >> then how can we release it? >> >> ??? >> >> Thanks, >> David >> >> >> On 13/05/2014 8:57 PM, Alan Bateman wrote: >>> >>> This is debugger's shared memory transport so cc'ing serviceability-dev >>> as that is there this code is maintained. >>> >>> Is there a test case or any outline of the conditions that cause this? I >>> think that would be useful to understand the issue further. >>> >>> -Alan >>> >>> On 13/05/2014 11:46, Aleksej Efimov wrote: >>>> Hi, >>>> >>>> Can I have a review for 8032901 bug [1] fix [2]. There is a possible >>>> case when 'WaitForMultipleObjects' function can return the >>>> WAIT_ABANDONED_0 [3] error value. >>>> In such case it's better to release the mutex and return error value. >>>> This will prevent other threads to be blocked on abandoned mutex. >>>> >>>> Thank you, >>>> Aleksej >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8032901 >>>> [2] http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.00/ >>>> [3] >>>> http://msdn.microsoft.com/en-gb/library/windows/desktop/ms687025(v=vs.85).aspx >>>> >>>> >>> > From staffan.larsen at oracle.com Wed May 14 06:58:13 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 14 May 2014 08:58:13 +0200 Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync In-Reply-To: References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com> <536BB959.7060706@oracle.com> <2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com> <536D1BDC.7000908@oracle.com> <53724E17.2080406@oracle.com> <5B0A0E2F-FD3C-47D1-85C5-0B4470FC4F9D@oracle.com> Message-ID: <3B477FDF-002F-429D-92CF-314F9A42C22A@oracle.com> Thanks Christian, I will make the change below before I push. /Staffan diff --git a/src/cpu/x86/vm/sharedRuntime_x86_32.cpp b/src/cpu/x86/vm/sharedRuntime_x86_32.cpp --- a/src/cpu/x86/vm/sharedRuntime_x86_32.cpp +++ b/src/cpu/x86/vm/sharedRuntime_x86_32.cpp @@ -2248,7 +2248,7 @@ // if we are now in interp_only_mode and in that case we do the jvmti // callback. Label skip_jvmti_method_exit; - __ cmpb(Address(thread, JavaThread::interp_only_mode_offset()), 0); + __ cmpl(Address(thread, JavaThread::interp_only_mode_offset()), 0); __ jcc(Assembler::zero, skip_jvmti_method_exit, true); save_native_result(masm, ret_type, stack_slots); diff --git a/src/cpu/x86/vm/sharedRuntime_x86_64.cpp b/src/cpu/x86/vm/sharedRuntime_x86_64.cpp --- a/src/cpu/x86/vm/sharedRuntime_x86_64.cpp +++ b/src/cpu/x86/vm/sharedRuntime_x86_64.cpp @@ -2495,7 +2495,7 @@ // if we are now in interp_only_mode and in that case we do the jvmti // callback. Label skip_jvmti_method_exit; - __ cmpb(Address(r15_thread, JavaThread::interp_only_mode_offset()), 0); + __ cmpl(Address(r15_thread, JavaThread::interp_only_mode_offset()), 0); __ jcc(Assembler::zero, skip_jvmti_method_exit, true); save_native_result(masm, ret_type, stack_slots); On 14 maj 2014, at 00:21, Christian Thalinger wrote: > Since: > > int _interp_only_mode; > > is an int field I would prefer to actually read the value as an int instead of just a byte on x86: > + __ cmpb(Address(r15_thread, JavaThread::interp_only_mode_offset()), 0); > Otherwise this looks good. > > On May 13, 2014, at 11:30 AM, Staffan Larsen wrote: > >> >> On 13 maj 2014, at 18:53, Daniel D. Daugherty wrote: >> >>> > new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/ >>> >>> src/share/vm/runtime/sharedRuntime.hpp >>> No comments. >>> >>> src/share/vm/runtime/sharedRuntime.cpp >>> No comments. >>> >>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp >>> No comments. >>> >>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp >>> No comments. >>> >>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp >>> No comments. >>> >>> On the switch from call_VM_leaf() -> call_VM(), I looked through all >>> the mentions of the string call_VM in the three src/cpu files. Your >>> change adds the first call_VM() use in all three files and the other >>> places that mention the string "call_VM" seem to have gone through >>> a great deal of trouble not to use call_VM() directly. I have no >>> specific thing I think is wrong, but I find this data worrisome? >> >> Yes, it would be great if someone from the compiler team could review this, too. >> >> Thanks, >> /Staffan >> >>> >>> Thumbs up! >>> >>> Dan >>> >>> >>> On 5/13/14 3:20 AM, Staffan Larsen wrote: >>>> >>>> On 9 maj 2014, at 20:18, serguei.spitsyn at oracle.com wrote: >>>> >>>>> Staffan, >>>>> >>>>> This is important discovery, thanks! >>>>> The fix looks good to me. >>>>> One question below. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 5/9/14 3:47 AM, Staffan Larsen wrote: >>>>>> On 8 maj 2014, at 19:05, Daniel D. Daugherty wrote: >>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >>>>>>> src/share/vm/runtime/sharedRuntime.hpp >>>>>>> No comments. >>>>>>> >>>>>>> src/share/vm/runtime/sharedRuntime.cpp >>>>>>> line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit( >>>>>>> I'm not sure that JRT_LEAF is right. I would think that >>>>>>> JvmtiExport::post_method_exit() would have to grab one or >>>>>>> more locks with all the state checks it has to make... >>>>>>> >>>>>>> For reference, InterpreterRuntime::post_method_exit() >>>>>>> is a wrapper around JvmtiExport::post_method_exit() >>>>>>> and it is IRT_ENTRY instead of IRT_LEAF. >>>>>> Good catch! >>>>> >>>>> Q: Is correct to use call_VM_leaf (vs call_VM ) in the sharedRuntime_.cpp ? >>>>> >>>>> + __ call_VM_leaf( >>>>> + CAST_FROM_FN_PTR(address, SharedRuntime::jvmti_method_exit), >>>>> + thread, rax); >>>> >>>> That is another good catch! It should probably be call_VM as you note. The reason for all these leaf references is because we used the dtrace probe as a template - obviously without fully understanding what we did :-/ >>>> >>>> I have changed to code to use call_VM instead. This also required a change from jccb to jcc for the jump (which is now longer than an 8-bit offset). >>>> >>>> new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/ >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>>> >>>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp >>>>>>> No comments. >>>>>>> >>>>>>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp >>>>>>> No comments. >>>>>>> >>>>>>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp >>>>>>> No comments. >>>>>>> >>>>>>> I'm guessing that PPC has the same issue, but I'm presuming >>>>>>> that someone else (Vladimir?) will handle that? >>>>>> Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix. >>>>>> >>>>>> Updated review: http://cr.openjdk.java.net/~sla/8041934/webrev.01/ >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> On 5/8/14 12:06 AM, Staffan Larsen wrote: >>>>>>>> All, >>>>>>>> >>>>>>>> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct. >>>>>>>> >>>>>>>> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert. >>>>>>>> >>>>>>>> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms. >>>>>>>> >>>>>>>> Kudos to Rickard for helping me write the code. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041934 >>>>>>>> >>>>>>>> The fix has been verified by running the failing test in JPRT with -Xcomp. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> /Staffan >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed May 14 09:05:11 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 May 2014 19:05:11 +1000 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> <5372A0BB.1040704@oracle.com> Message-ID: <537331C7.8030807@oracle.com> On 14/05/2014 11:06 AM, Vitaly Davidovich wrote: > In windows, you acquire a mutex by waiting on it using one of the wait > functions, one of them employed in the code in question. If > WaitForMultipleObjects succeeds and returns the index of the mutex, > current thread has ownership now. Yes I understand the basic mechanics :) > It's also common to use multi wait functions where the event is a > "cancelation token", e.g. manual reset event; this allows someone to > cancel waiting on mutex acquisition and return from the wait function. > Presumably that's the case here, but I'll let Aleksej confirm; just > wanted to throw this out there in the meantime :). Ah I see - yes cancellable lock acquisition would make sense. Thanks, David > Sent from my phone > > On May 13, 2014 6:46 PM, "David Holmes" > wrote: > > Hi Aleksej, > > Thanks for the doc references regarding abandonment. > > Let me rephrase my question. What is this logic trying to achieve by > waiting on both a mutex and an event? Do we already own the mutex > when this function is called? > > David > > On 13/05/2014 11:19 PM, Aleksej Efimov wrote: > > David, > > The Windows has a different terminology for mutex objects (much > differs > from the POSIX one). This one link gave me some understanding of > it [1]. > > Here is the MSDN [1] description of what "abandoned mutex" is: > " If a thread terminates without releasing its ownership of a mutex > object, the mutex object is considered to be abandoned. A > waiting thread > can acquire ownership of an abandoned mutex object, but the wait > function will return*WAIT_ABANDONED*to indicate that the mutex > object is > abandoned. An abandoned mutex object indicates that an error has > occurred and that any shared resource being protected by the mutex > object is in an undefined state. If the thread proceeds as > though the > mutex object had not been abandoned, it is no longer considered > abandoned after the thread releases its ownership. This restores > normal > behavior if a handle to the mutex object is subsequently > specified in a > wait function." > > > What does it mean to wait on mutex and ownership of the mutex > object: > "Any thread with a handle to a mutex object can use one of thewait > functions > >to > request ownership of the mutex object. If the mutex object is > owned by > another thread, the wait function blocks the requesting thread > until the > owning thread releases the mutex object using the*ReleaseMutex* > >__function." > > How we can release mutex and wait on already owned mutex: > " After a thread obtains ownership of a mutex, it can specify > the same > mutex in repeated calls to the wait-functions > >__without > blocking its execution. This prevents a thread from deadlocking > itself > while waiting for a mutex that it already owns. To release its > ownership > under such circumstances, the thread must call*ReleaseMutex* > >__once > for each time that the mutex satisfied the conditions of a wait > function." > > [1] > http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms684266(v=vs.85).aspx > > > -Aleksej > > On 05/13/2014 04:00 PM, David Holmes wrote: > > I don't understand this one at all. What is an "abandoned > mutex"? For > that matter why does the code wait on a mutex and an event? > Do we > already own the mutex? If so what does it mean to wait on > it? If not > then how can we release it? > > ??? > > Thanks, > David > > > On 13/05/2014 8:57 PM, Alan Bateman wrote: > > > This is debugger's shared memory transport so cc'ing > serviceability-dev > as that is there this code is maintained. > > Is there a test case or any outline of the conditions > that cause this? I > think that would be useful to understand the issue further. > > -Alan > > On 13/05/2014 11:46, Aleksej Efimov wrote: > > Hi, > > Can I have a review for 8032901 bug [1] fix [2]. > There is a possible > case when 'WaitForMultipleObjects' function can > return the > WAIT_ABANDONED_0 [3] error value. > In such case it's better to release the mutex and > return error value. > This will prevent other threads to be blocked on > abandoned mutex. > > Thank you, > Aleksej > > [1] > https://bugs.openjdk.java.net/__browse/JDK-8032901 > > [2] > http://cr.openjdk.java.net/~__aefimov/8032901/9/webrev.00/ > > [3] > http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms687025(v=vs.85).aspx > > > > > From aleksej.efimov at oracle.com Wed May 14 13:18:37 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Wed, 14 May 2014 17:18:37 +0400 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <537331C7.8030807@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> <5372A0BB.1040704@oracle.com> <537331C7.8030807@oracle.com> Message-ID: <53736D2D.7010805@oracle.com> David, Vitaly, I totally agree with Vitaly's explanation (Vitaly - thank you for that) and code in shmemBase.c (the usage of enterMutex() function for sending/receiving bytes through shared memory connection) illustrates on how the connection shutdown event is used as a "cancellation token". Thank you, -Aleksej On 05/14/2014 01:05 PM, David Holmes wrote: > On 14/05/2014 11:06 AM, Vitaly Davidovich wrote: >> In windows, you acquire a mutex by waiting on it using one of the wait >> functions, one of them employed in the code in question. If >> WaitForMultipleObjects succeeds and returns the index of the mutex, >> current thread has ownership now. > > Yes I understand the basic mechanics :) > >> It's also common to use multi wait functions where the event is a >> "cancelation token", e.g. manual reset event; this allows someone to >> cancel waiting on mutex acquisition and return from the wait function. >> Presumably that's the case here, but I'll let Aleksej confirm; just >> wanted to throw this out there in the meantime :). > > Ah I see - yes cancellable lock acquisition would make sense. > > Thanks, > David > >> Sent from my phone >> >> On May 13, 2014 6:46 PM, "David Holmes" > > wrote: >> >> Hi Aleksej, >> >> Thanks for the doc references regarding abandonment. >> >> Let me rephrase my question. What is this logic trying to achieve by >> waiting on both a mutex and an event? Do we already own the mutex >> when this function is called? >> >> David >> >> On 13/05/2014 11:19 PM, Aleksej Efimov wrote: >> >> David, >> >> The Windows has a different terminology for mutex objects (much >> differs >> from the POSIX one). This one link gave me some understanding of >> it [1]. >> >> Here is the MSDN [1] description of what "abandoned mutex" is: >> " If a thread terminates without releasing its ownership of a >> mutex >> object, the mutex object is considered to be abandoned. A >> waiting thread >> can acquire ownership of an abandoned mutex object, but the wait >> function will return*WAIT_ABANDONED*to indicate that the mutex >> object is >> abandoned. An abandoned mutex object indicates that an error has >> occurred and that any shared resource being protected by the >> mutex >> object is in an undefined state. If the thread proceeds as >> though the >> mutex object had not been abandoned, it is no longer considered >> abandoned after the thread releases its ownership. This restores >> normal >> behavior if a handle to the mutex object is subsequently >> specified in a >> wait function." >> >> >> What does it mean to wait on mutex and ownership of the mutex >> object: >> "Any thread with a handle to a mutex object can use one of >> thewait >> functions >> > >to >> request ownership of the mutex object. If the mutex object is >> owned by >> another thread, the wait function blocks the requesting thread >> until the >> owning thread releases the mutex object using the*ReleaseMutex* >> > >__function." >> >> How we can release mutex and wait on already owned mutex: >> " After a thread obtains ownership of a mutex, it can specify >> the same >> mutex in repeated calls to the wait-functions >> > >__without >> blocking its execution. This prevents a thread from deadlocking >> itself >> while waiting for a mutex that it already owns. To release its >> ownership >> under such circumstances, the thread must call*ReleaseMutex* >> > >__once >> for each time that the mutex satisfied the conditions of a wait >> function." >> >> [1] >> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms684266(v=vs.85).aspx >> >> >> -Aleksej >> >> On 05/13/2014 04:00 PM, David Holmes wrote: >> >> I don't understand this one at all. What is an "abandoned >> mutex"? For >> that matter why does the code wait on a mutex and an event? >> Do we >> already own the mutex? If so what does it mean to wait on >> it? If not >> then how can we release it? >> >> ??? >> >> Thanks, >> David >> >> >> On 13/05/2014 8:57 PM, Alan Bateman wrote: >> >> >> This is debugger's shared memory transport so cc'ing >> serviceability-dev >> as that is there this code is maintained. >> >> Is there a test case or any outline of the conditions >> that cause this? I >> think that would be useful to understand the issue >> further. >> >> -Alan >> >> On 13/05/2014 11:46, Aleksej Efimov wrote: >> >> Hi, >> >> Can I have a review for 8032901 bug [1] fix [2]. >> There is a possible >> case when 'WaitForMultipleObjects' function can >> return the >> WAIT_ABANDONED_0 [3] error value. >> In such case it's better to release the mutex and >> return error value. >> This will prevent other threads to be blocked on >> abandoned mutex. >> >> Thank you, >> Aleksej >> >> [1] >> https://bugs.openjdk.java.net/__browse/JDK-8032901 >> >> [2] >> http://cr.openjdk.java.net/~__aefimov/8032901/9/webrev.00/ >> >> [3] >> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms687025(v=vs.85).aspx >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Wed May 14 18:30:54 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 14 May 2014 11:30:54 -0700 Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync In-Reply-To: <3B477FDF-002F-429D-92CF-314F9A42C22A@oracle.com> References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com> <536BB959.7060706@oracle.com> <2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com> <536D1BDC.7000908@oracle.com> <53724E17.2080406@oracle.com> <5B0A0E2F-FD3C-47D1-85C5-0B4470FC4F9D@oracle.com> <3B477FDF-002F-429D-92CF-314F9A42C22A@oracle.com> Message-ID: Looks good. On May 13, 2014, at 11:58 PM, Staffan Larsen wrote: > Thanks Christian, > > I will make the change below before I push. > > /Staffan > > > diff --git a/src/cpu/x86/vm/sharedRuntime_x86_32.cpp b/src/cpu/x86/vm/sharedRuntime_x86_32.cpp > --- a/src/cpu/x86/vm/sharedRuntime_x86_32.cpp > +++ b/src/cpu/x86/vm/sharedRuntime_x86_32.cpp > @@ -2248,7 +2248,7 @@ > // if we are now in interp_only_mode and in that case we do the jvmti > // callback. > Label skip_jvmti_method_exit; > - __ cmpb(Address(thread, JavaThread::interp_only_mode_offset()), 0); > + __ cmpl(Address(thread, JavaThread::interp_only_mode_offset()), 0); > __ jcc(Assembler::zero, skip_jvmti_method_exit, true); > > save_native_result(masm, ret_type, stack_slots); > diff --git a/src/cpu/x86/vm/sharedRuntime_x86_64.cpp b/src/cpu/x86/vm/sharedRuntime_x86_64.cpp > --- a/src/cpu/x86/vm/sharedRuntime_x86_64.cpp > +++ b/src/cpu/x86/vm/sharedRuntime_x86_64.cpp > @@ -2495,7 +2495,7 @@ > // if we are now in interp_only_mode and in that case we do the jvmti > // callback. > Label skip_jvmti_method_exit; > - __ cmpb(Address(r15_thread, JavaThread::interp_only_mode_offset()), 0); > + __ cmpl(Address(r15_thread, JavaThread::interp_only_mode_offset()), 0); > __ jcc(Assembler::zero, skip_jvmti_method_exit, true); > > save_native_result(masm, ret_type, stack_slots); > > > On 14 maj 2014, at 00:21, Christian Thalinger wrote: > >> Since: >> >> int _interp_only_mode; >> >> is an int field I would prefer to actually read the value as an int instead of just a byte on x86: >> + __ cmpb(Address(r15_thread, JavaThread::interp_only_mode_offset()), 0); >> Otherwise this looks good. >> >> On May 13, 2014, at 11:30 AM, Staffan Larsen wrote: >> >>> >>> On 13 maj 2014, at 18:53, Daniel D. Daugherty wrote: >>> >>>> > new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/ >>>> >>>> src/share/vm/runtime/sharedRuntime.hpp >>>> No comments. >>>> >>>> src/share/vm/runtime/sharedRuntime.cpp >>>> No comments. >>>> >>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp >>>> No comments. >>>> >>>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp >>>> No comments. >>>> >>>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp >>>> No comments. >>>> >>>> On the switch from call_VM_leaf() -> call_VM(), I looked through all >>>> the mentions of the string call_VM in the three src/cpu files. Your >>>> change adds the first call_VM() use in all three files and the other >>>> places that mention the string "call_VM" seem to have gone through >>>> a great deal of trouble not to use call_VM() directly. I have no >>>> specific thing I think is wrong, but I find this data worrisome? >>> >>> Yes, it would be great if someone from the compiler team could review this, too. >>> >>> Thanks, >>> /Staffan >>> >>>> >>>> Thumbs up! >>>> >>>> Dan >>>> >>>> >>>> On 5/13/14 3:20 AM, Staffan Larsen wrote: >>>>> >>>>> On 9 maj 2014, at 20:18, serguei.spitsyn at oracle.com wrote: >>>>> >>>>>> Staffan, >>>>>> >>>>>> This is important discovery, thanks! >>>>>> The fix looks good to me. >>>>>> One question below. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 5/9/14 3:47 AM, Staffan Larsen wrote: >>>>>>> On 8 maj 2014, at 19:05, Daniel D. Daugherty wrote: >>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >>>>>>>> src/share/vm/runtime/sharedRuntime.hpp >>>>>>>> No comments. >>>>>>>> >>>>>>>> src/share/vm/runtime/sharedRuntime.cpp >>>>>>>> line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit( >>>>>>>> I'm not sure that JRT_LEAF is right. I would think that >>>>>>>> JvmtiExport::post_method_exit() would have to grab one or >>>>>>>> more locks with all the state checks it has to make... >>>>>>>> >>>>>>>> For reference, InterpreterRuntime::post_method_exit() >>>>>>>> is a wrapper around JvmtiExport::post_method_exit() >>>>>>>> and it is IRT_ENTRY instead of IRT_LEAF. >>>>>>> Good catch! >>>>>> >>>>>> Q: Is correct to use call_VM_leaf (vs call_VM ) in the sharedRuntime_.cpp ? >>>>>> >>>>>> + __ call_VM_leaf( >>>>>> + CAST_FROM_FN_PTR(address, SharedRuntime::jvmti_method_exit), >>>>>> + thread, rax); >>>>> >>>>> That is another good catch! It should probably be call_VM as you note. The reason for all these leaf references is because we used the dtrace probe as a template - obviously without fully understanding what we did :-/ >>>>> >>>>> I have changed to code to use call_VM instead. This also required a change from jccb to jcc for the jump (which is now longer than an 8-bit offset). >>>>> >>>>> new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/ >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> >>>>>> >>>>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp >>>>>>>> No comments. >>>>>>>> >>>>>>>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp >>>>>>>> No comments. >>>>>>>> >>>>>>>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp >>>>>>>> No comments. >>>>>>>> >>>>>>>> I'm guessing that PPC has the same issue, but I'm presuming >>>>>>>> that someone else (Vladimir?) will handle that? >>>>>>> Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix. >>>>>>> >>>>>>> Updated review: http://cr.openjdk.java.net/~sla/8041934/webrev.01/ >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>> On 5/8/14 12:06 AM, Staffan Larsen wrote: >>>>>>>>> All, >>>>>>>>> >>>>>>>>> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct. >>>>>>>>> >>>>>>>>> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert. >>>>>>>>> >>>>>>>>> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms. >>>>>>>>> >>>>>>>>> Kudos to Rickard for helping me write the code. >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/ >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041934 >>>>>>>>> >>>>>>>>> The fix has been verified by running the failing test in JPRT with -Xcomp. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> /Staffan >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu May 15 01:48:25 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 May 2014 11:48:25 +1000 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <53736D2D.7010805@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> <5372A0BB.1040704@oracle.com> <537331C7.8030807@oracle.com> <53736D2D.7010805@oracle.com> Message-ID: <53741CE9.1030807@oracle.com> On 14/05/2014 11:18 PM, Aleksej Efimov wrote: > David, Vitaly, > > I totally agree with Vitaly's explanation (Vitaly - thank you for that) > and code in shmemBase.c (the usage of enterMutex() function for > sending/receiving bytes through shared memory connection) illustrates on > how the connection shutdown event is used as a "cancellation token". Thanks for clarifying that. So if we were to encounter an abandoned mutex the code would presently have acquired the mutex but return an error, thus preventing a subsequent release, and preventing other threads from acquiring (but allowing current thread to recurisevely acquire. So this could both hang and cause data corruption. The new code will still return an error but release the mutex. So no more hangs (other than by conditions caused by data corruption) but more opportunity for data corruption. Obviously it depends on exactly what happens in the critical sections guarded by this mutex, but in general I don't agree with this rationale for making the change: 204 /* If the mutex is abandoned we want to return an error 205 * and also release the mutex so that we don't cause 206 * other threads to be blocked. If a mutex was abandoned 207 * we are in scary state. Data may be corrupted or inconsistent 208 * but it is still better to let other threads run (and possibly 209 * crash) than having them blocked (on the premise that a crash 210 * is always easier to debug than a hang). Considering something has to have gone drastically wrong for the mutex to become abandoned, I'm more inclined to consider this a fatal error and abort. But I'll let the serviceability folk chime in here. Thanks, David > Thank you, > -Aleksej > > > On 05/14/2014 01:05 PM, David Holmes wrote: >> On 14/05/2014 11:06 AM, Vitaly Davidovich wrote: >>> In windows, you acquire a mutex by waiting on it using one of the wait >>> functions, one of them employed in the code in question. If >>> WaitForMultipleObjects succeeds and returns the index of the mutex, >>> current thread has ownership now. >> >> Yes I understand the basic mechanics :) >> >>> It's also common to use multi wait functions where the event is a >>> "cancelation token", e.g. manual reset event; this allows someone to >>> cancel waiting on mutex acquisition and return from the wait function. >>> Presumably that's the case here, but I'll let Aleksej confirm; just >>> wanted to throw this out there in the meantime :). >> >> Ah I see - yes cancellable lock acquisition would make sense. >> >> Thanks, >> David >> >>> Sent from my phone >>> >>> On May 13, 2014 6:46 PM, "David Holmes" >> > wrote: >>> >>> Hi Aleksej, >>> >>> Thanks for the doc references regarding abandonment. >>> >>> Let me rephrase my question. What is this logic trying to achieve by >>> waiting on both a mutex and an event? Do we already own the mutex >>> when this function is called? >>> >>> David >>> >>> On 13/05/2014 11:19 PM, Aleksej Efimov wrote: >>> >>> David, >>> >>> The Windows has a different terminology for mutex objects (much >>> differs >>> from the POSIX one). This one link gave me some understanding of >>> it [1]. >>> >>> Here is the MSDN [1] description of what "abandoned mutex" is: >>> " If a thread terminates without releasing its ownership of a >>> mutex >>> object, the mutex object is considered to be abandoned. A >>> waiting thread >>> can acquire ownership of an abandoned mutex object, but the wait >>> function will return*WAIT_ABANDONED*to indicate that the mutex >>> object is >>> abandoned. An abandoned mutex object indicates that an error has >>> occurred and that any shared resource being protected by the >>> mutex >>> object is in an undefined state. If the thread proceeds as >>> though the >>> mutex object had not been abandoned, it is no longer considered >>> abandoned after the thread releases its ownership. This restores >>> normal >>> behavior if a handle to the mutex object is subsequently >>> specified in a >>> wait function." >>> >>> >>> What does it mean to wait on mutex and ownership of the mutex >>> object: >>> "Any thread with a handle to a mutex object can use one of >>> thewait >>> functions >>> >> >to >>> request ownership of the mutex object. If the mutex object is >>> owned by >>> another thread, the wait function blocks the requesting thread >>> until the >>> owning thread releases the mutex object using the*ReleaseMutex* >>> >> >__function." >>> >>> How we can release mutex and wait on already owned mutex: >>> " After a thread obtains ownership of a mutex, it can specify >>> the same >>> mutex in repeated calls to the wait-functions >>> >> >__without >>> blocking its execution. This prevents a thread from deadlocking >>> itself >>> while waiting for a mutex that it already owns. To release its >>> ownership >>> under such circumstances, the thread must call*ReleaseMutex* >>> >> >__once >>> for each time that the mutex satisfied the conditions of a wait >>> function." >>> >>> [1] >>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms684266(v=vs.85).aspx >>> >>> >>> -Aleksej >>> >>> On 05/13/2014 04:00 PM, David Holmes wrote: >>> >>> I don't understand this one at all. What is an "abandoned >>> mutex"? For >>> that matter why does the code wait on a mutex and an event? >>> Do we >>> already own the mutex? If so what does it mean to wait on >>> it? If not >>> then how can we release it? >>> >>> ??? >>> >>> Thanks, >>> David >>> >>> >>> On 13/05/2014 8:57 PM, Alan Bateman wrote: >>> >>> >>> This is debugger's shared memory transport so cc'ing >>> serviceability-dev >>> as that is there this code is maintained. >>> >>> Is there a test case or any outline of the conditions >>> that cause this? I >>> think that would be useful to understand the issue >>> further. >>> >>> -Alan >>> >>> On 13/05/2014 11:46, Aleksej Efimov wrote: >>> >>> Hi, >>> >>> Can I have a review for 8032901 bug [1] fix [2]. >>> There is a possible >>> case when 'WaitForMultipleObjects' function can >>> return the >>> WAIT_ABANDONED_0 [3] error value. >>> In such case it's better to release the mutex and >>> return error value. >>> This will prevent other threads to be blocked on >>> abandoned mutex. >>> >>> Thank you, >>> Aleksej >>> >>> [1] >>> https://bugs.openjdk.java.net/__browse/JDK-8032901 >>> >>> [2] >>> http://cr.openjdk.java.net/~__aefimov/8032901/9/webrev.00/ >>> >>> [3] >>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms687025(v=vs.85).aspx >>> >>> >>> >>> >>> > From vitalyd at gmail.com Wed May 14 01:06:25 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 13 May 2014 21:06:25 -0400 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <5372A0BB.1040704@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> <5372A0BB.1040704@oracle.com> Message-ID: In windows, you acquire a mutex by waiting on it using one of the wait functions, one of them employed in the code in question. If WaitForMultipleObjects succeeds and returns the index of the mutex, current thread has ownership now. It's also common to use multi wait functions where the event is a "cancelation token", e.g. manual reset event; this allows someone to cancel waiting on mutex acquisition and return from the wait function. Presumably that's the case here, but I'll let Aleksej confirm; just wanted to throw this out there in the meantime :). Sent from my phone On May 13, 2014 6:46 PM, "David Holmes" wrote: > Hi Aleksej, > > Thanks for the doc references regarding abandonment. > > Let me rephrase my question. What is this logic trying to achieve by > waiting on both a mutex and an event? Do we already own the mutex when this > function is called? > > David > > On 13/05/2014 11:19 PM, Aleksej Efimov wrote: > >> David, >> >> The Windows has a different terminology for mutex objects (much differs >> from the POSIX one). This one link gave me some understanding of it [1]. >> >> Here is the MSDN [1] description of what "abandoned mutex" is: >> " If a thread terminates without releasing its ownership of a mutex >> object, the mutex object is considered to be abandoned. A waiting thread >> can acquire ownership of an abandoned mutex object, but the wait >> function will return*WAIT_ABANDONED*to indicate that the mutex object is >> abandoned. An abandoned mutex object indicates that an error has >> occurred and that any shared resource being protected by the mutex >> object is in an undefined state. If the thread proceeds as though the >> mutex object had not been abandoned, it is no longer considered >> abandoned after the thread releases its ownership. This restores normal >> behavior if a handle to the mutex object is subsequently specified in a >> wait function." >> >> >> What does it mean to wait on mutex and ownership of the mutex object: >> "Any thread with a handle to a mutex object can use one of thewait >> functions >> > ms687069%28v=vs.85%29.aspx>to >> request ownership of the mutex object. If the mutex object is owned by >> another thread, the wait function blocks the requesting thread until the >> owning thread releases the mutex object using the*ReleaseMutex* >> > ms685066%28v=vs.85%29.aspx>function." >> >> How we can release mutex and wait on already owned mutex: >> " After a thread obtains ownership of a mutex, it can specify the same >> mutex in repeated calls to the wait-functions >> > ms687069%28v=vs.85%29.aspx>without >> blocking its execution. This prevents a thread from deadlocking itself >> while waiting for a mutex that it already owns. To release its ownership >> under such circumstances, the thread must call*ReleaseMutex* >> > ms685066%28v=vs.85%29.aspx>once >> for each time that the mutex satisfied the conditions of a wait function." >> >> [1] >> http://msdn.microsoft.com/en-gb/library/windows/desktop/ >> ms684266(v=vs.85).aspx >> >> -Aleksej >> >> On 05/13/2014 04:00 PM, David Holmes wrote: >> >>> I don't understand this one at all. What is an "abandoned mutex"? For >>> that matter why does the code wait on a mutex and an event? Do we >>> already own the mutex? If so what does it mean to wait on it? If not >>> then how can we release it? >>> >>> ??? >>> >>> Thanks, >>> David >>> >>> >>> On 13/05/2014 8:57 PM, Alan Bateman wrote: >>> >>>> >>>> This is debugger's shared memory transport so cc'ing serviceability-dev >>>> as that is there this code is maintained. >>>> >>>> Is there a test case or any outline of the conditions that cause this? I >>>> think that would be useful to understand the issue further. >>>> >>>> -Alan >>>> >>>> On 13/05/2014 11:46, Aleksej Efimov wrote: >>>> >>>>> Hi, >>>>> >>>>> Can I have a review for 8032901 bug [1] fix [2]. There is a possible >>>>> case when 'WaitForMultipleObjects' function can return the >>>>> WAIT_ABANDONED_0 [3] error value. >>>>> In such case it's better to release the mutex and return error value. >>>>> This will prevent other threads to be blocked on abandoned mutex. >>>>> >>>>> Thank you, >>>>> Aleksej >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8032901 >>>>> [2] http://cr.openjdk.java.net/~aefimov/8032901/9/webrev.00/ >>>>> [3] >>>>> http://msdn.microsoft.com/en-gb/library/windows/desktop/ >>>>> ms687025(v=vs.85).aspx >>>>> >>>>> >>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu May 15 09:11:05 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 15 May 2014 11:11:05 +0200 Subject: RFR: 8032901: WaitForMultipleObjects() return value not handled appropriately In-Reply-To: <53741CE9.1030807@oracle.com> References: <5371F7EA.1030300@oracle.com> <5371FAA3.3040006@oracle.com> <5372094C.5070407@oracle.com> <53721BCB.4060200@oracle.com> <5372A0BB.1040704@oracle.com> <537331C7.8030807@oracle.com> <53736D2D.7010805@oracle.com> <53741CE9.1030807@oracle.com> Message-ID: <90D75432-E4D0-4B5F-89BB-0BA1F4653482@oracle.com> On 15 maj 2014, at 03:48, David Holmes wrote: > On 14/05/2014 11:18 PM, Aleksej Efimov wrote: >> David, Vitaly, >> >> I totally agree with Vitaly's explanation (Vitaly - thank you for that) >> and code in shmemBase.c (the usage of enterMutex() function for >> sending/receiving bytes through shared memory connection) illustrates on >> how the connection shutdown event is used as a "cancellation token". > > Thanks for clarifying that. > > So if we were to encounter an abandoned mutex the code would presently have acquired the mutex but return an error, thus preventing a subsequent release, and preventing other threads from acquiring (but allowing current thread to recurisevely acquire. So this could both hang and cause data corruption. > > The new code will still return an error but release the mutex. So no more hangs (other than by conditions caused by data corruption) but more opportunity for data corruption. > > Obviously it depends on exactly what happens in the critical sections guarded by this mutex, but in general I don't agree with this rationale for making the change: > > 204 /* If the mutex is abandoned we want to return an error > 205 * and also release the mutex so that we don't cause > 206 * other threads to be blocked. If a mutex was abandoned > 207 * we are in scary state. Data may be corrupted or inconsistent > 208 * but it is still better to let other threads run (and possibly > 209 * crash) than having them blocked (on the premise that a crash > 210 * is always easier to debug than a hang). > > Considering something has to have gone drastically wrong for the mutex to become abandoned, I'm more inclined to consider this a fatal error and abort. > > But I'll let the serviceability folk chime in here. I was involved in fixing this and writing the comment, so obviously I thought it a good solution :-) I do agree that it would probably be a good idea to consider this a fatal error and abort. At that point in the code we don?t have any really nice ways of doing that, though. We could just print an error and call abort(). What we are doing now is returning an error from sysIPMutexEnter() and delegating the error handling to the caller. We have tried to check all call paths to verify that they do ?the right thing? in the face of an error. It is obviously hard to verify, but it looks like they all terminate the connection with some kind of error message. /Staffan > > Thanks, > David > > >> Thank you, >> -Aleksej >> >> >> On 05/14/2014 01:05 PM, David Holmes wrote: >>> On 14/05/2014 11:06 AM, Vitaly Davidovich wrote: >>>> In windows, you acquire a mutex by waiting on it using one of the wait >>>> functions, one of them employed in the code in question. If >>>> WaitForMultipleObjects succeeds and returns the index of the mutex, >>>> current thread has ownership now. >>> >>> Yes I understand the basic mechanics :) >>> >>>> It's also common to use multi wait functions where the event is a >>>> "cancelation token", e.g. manual reset event; this allows someone to >>>> cancel waiting on mutex acquisition and return from the wait function. >>>> Presumably that's the case here, but I'll let Aleksej confirm; just >>>> wanted to throw this out there in the meantime :). >>> >>> Ah I see - yes cancellable lock acquisition would make sense. >>> >>> Thanks, >>> David >>> >>>> Sent from my phone >>>> >>>> On May 13, 2014 6:46 PM, "David Holmes" >>> > wrote: >>>> >>>> Hi Aleksej, >>>> >>>> Thanks for the doc references regarding abandonment. >>>> >>>> Let me rephrase my question. What is this logic trying to achieve by >>>> waiting on both a mutex and an event? Do we already own the mutex >>>> when this function is called? >>>> >>>> David >>>> >>>> On 13/05/2014 11:19 PM, Aleksej Efimov wrote: >>>> >>>> David, >>>> >>>> The Windows has a different terminology for mutex objects (much >>>> differs >>>> from the POSIX one). This one link gave me some understanding of >>>> it [1]. >>>> >>>> Here is the MSDN [1] description of what "abandoned mutex" is: >>>> " If a thread terminates without releasing its ownership of a >>>> mutex >>>> object, the mutex object is considered to be abandoned. A >>>> waiting thread >>>> can acquire ownership of an abandoned mutex object, but the wait >>>> function will return*WAIT_ABANDONED*to indicate that the mutex >>>> object is >>>> abandoned. An abandoned mutex object indicates that an error has >>>> occurred and that any shared resource being protected by the >>>> mutex >>>> object is in an undefined state. If the thread proceeds as >>>> though the >>>> mutex object had not been abandoned, it is no longer considered >>>> abandoned after the thread releases its ownership. This restores >>>> normal >>>> behavior if a handle to the mutex object is subsequently >>>> specified in a >>>> wait function." >>>> >>>> >>>> What does it mean to wait on mutex and ownership of the mutex >>>> object: >>>> "Any thread with a handle to a mutex object can use one of >>>> thewait >>>> functions >>>> >>> >to >>>> request ownership of the mutex object. If the mutex object is >>>> owned by >>>> another thread, the wait function blocks the requesting thread >>>> until the >>>> owning thread releases the mutex object using the*ReleaseMutex* >>>> >>> >__function." >>>> >>>> How we can release mutex and wait on already owned mutex: >>>> " After a thread obtains ownership of a mutex, it can specify >>>> the same >>>> mutex in repeated calls to the wait-functions >>>> >>> >__without >>>> blocking its execution. This prevents a thread from deadlocking >>>> itself >>>> while waiting for a mutex that it already owns. To release its >>>> ownership >>>> under such circumstances, the thread must call*ReleaseMutex* >>>> >>> >__once >>>> for each time that the mutex satisfied the conditions of a wait >>>> function." >>>> >>>> [1] >>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms684266(v=vs.85).aspx >>>> >>>> >>>> -Aleksej >>>> >>>> On 05/13/2014 04:00 PM, David Holmes wrote: >>>> >>>> I don't understand this one at all. What is an "abandoned >>>> mutex"? For >>>> that matter why does the code wait on a mutex and an event? >>>> Do we >>>> already own the mutex? If so what does it mean to wait on >>>> it? If not >>>> then how can we release it? >>>> >>>> ??? >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> On 13/05/2014 8:57 PM, Alan Bateman wrote: >>>> >>>> >>>> This is debugger's shared memory transport so cc'ing >>>> serviceability-dev >>>> as that is there this code is maintained. >>>> >>>> Is there a test case or any outline of the conditions >>>> that cause this? I >>>> think that would be useful to understand the issue >>>> further. >>>> >>>> -Alan >>>> >>>> On 13/05/2014 11:46, Aleksej Efimov wrote: >>>> >>>> Hi, >>>> >>>> Can I have a review for 8032901 bug [1] fix [2]. >>>> There is a possible >>>> case when 'WaitForMultipleObjects' function can >>>> return the >>>> WAIT_ABANDONED_0 [3] error value. >>>> In such case it's better to release the mutex and >>>> return error value. >>>> This will prevent other threads to be blocked on >>>> abandoned mutex. >>>> >>>> Thank you, >>>> Aleksej >>>> >>>> [1] >>>> https://bugs.openjdk.java.net/__browse/JDK-8032901 >>>> >>>> [2] >>>> http://cr.openjdk.java.net/~__aefimov/8032901/9/webrev.00/ >>>> >>>> [3] >>>> http://msdn.microsoft.com/en-__gb/library/windows/desktop/__ms687025(v=vs.85).aspx >>>> >>>> >>>> >>>> >>>> >> From dmitry.samersoff at oracle.com Thu May 15 11:50:01 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 15 May 2014 15:50:01 +0400 Subject: RFR(S): JDK-8041435 Make JDWP socket connector accept only local connections by default Message-ID: <5374A9E9.5060005@oracle.com> Hi Everyone, Please review the fix: http://cr.openjdk.java.net/~dsamersoff/JDK-8041435/webrev.01/ After the fix, JDWP server attempts to guess localhost address and bind to it only if no address is specified in command line but user can explicitly bind server to all of available addresses by using * as an address. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.daugherty at oracle.com Thu May 15 15:58:32 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 15 May 2014 09:58:32 -0600 Subject: RFR(S): JDK-8041435 Make JDWP socket connector accept only local connections by default In-Reply-To: <5374A9E9.5060005@oracle.com> References: <5374A9E9.5060005@oracle.com> Message-ID: <5374E428.6080309@oracle.com> On 5/15/14 5:50 AM, Dmitry Samersoff wrote: > Hi Everyone, > > Please review the fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8041435/webrev.01/ src/share/transport/socket/socketTransport.c line 200: // it lookups "localhost" and return 127.0.0.1 if lookup Typo: "it lookups" -> "it looks up" Typo: "and return 127.0.0.1" -> "and returns 127.0.0.1" line 210: return dbgsysHostToNetworkLong(INADDR_LOOPBACK); nit: indent should be 4-spaces (for this file) line 235: u_short port = (u_short)atoi(address+10); Will this crash on "localhost:"? (colon, but no port number) line 236: sa->sin_port = dbgsysHostToNetworkShort(port); If atoi() on line 235 is passed a non-decimal, what will the value of 'port' be and what will happen here? line 241: u_short port = (u_short)atoi(address+2); line 242: sa->sin_port = dbgsysHostToNetworkShort(port); Same questions about these two lines... old line 440: err = parseAddress(addressString, &sa, 0x7f000001); Is it bad that my brain automatically translated that HEX string into 127.0.0.1? I guess I still remember networking code... I checked out this doc: http://docs.oracle.com/javase/7/docs/technotes/guides/jpda/conninv.html and the help message: $ java -agentlib:jdwp=help Java Debugger JDWP Agent Library -------------------------------- (see http://java.sun.com/products/jpda for more information) jdwp usage: java -agentlib:jdwp=[help]|[