RFR: 8163805: hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java failed with timed out

Hi all, Please review a patch of testbug for debugd server: JBS: https://bugs.openjdk.java.net/browse/JDK-8163805 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8163805/webrev.00/ This issue has been reported since 2016, but it is not fixed yet. Root cause of this problem is `jhsdb` atte

Re: RFR: 8223666: SA: debugd options should follow jhsdb style

Hi all, I pushed: http://hg.openjdk.java.net/jdk/jdk/rev/81852d53e585 Thanks all for helping us! Osamu, if you are working for JDK-8223814, please tell us when you done to create a patch. I can help you. Yasumasa On 2019/05/16 18:04, David Holmes wrote: Just confirming I'm okay with t

Re: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp)

On 17/05/2019 9:14 am, Martin Buchholz wrote: On Thu, May 16, 2019 at 4:05 PM David Holmes > wrote: On 17/05/2019 8:57 am, Martin Buchholz wrote: > Maybe you just need to ask gcc to use a more modern -std=... > It might reasonably be defaulting to gn

Re: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp)

On Thu, May 16, 2019 at 4:05 PM David Holmes wrote: > On 17/05/2019 8:57 am, Martin Buchholz wrote: > > Maybe you just need to ask gcc to use a more modern -std=... > > It might reasonably be defaulting to gnu89 > > > https://stackoverflow.com/questions/14737104/what-is-the-default-c-mode-for-the

Re: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp)

Maybe you just need to ask gcc to use a more modern -std=... It might reasonably be defaulting to gnu89 https://stackoverflow.com/questions/14737104/what-is-the-default-c-mode-for-the-current-gcc-especially-on-ubuntu On Thu, May 16, 2019 at 3:25 PM David Holmes wrote: > On 16/05/2019 11:41 pm, A

Re: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp)

On 17/05/2019 8:57 am, Martin Buchholz wrote: Maybe you just need to ask gcc to use a more modern -std=... It might reasonably be defaulting to gnu89 https://stackoverflow.com/questions/14737104/what-is-the-default-c-mode-for-the-current-gcc-especially-on-ubuntu Yes, but I thought we'd already

RFR (M) 8224079: ExceptionJniWrapper for the Strace test suite

Hi all, I was wanting to continue on deploying the ExceptionJniWrapper and the first on the list was this one C++ file. It is used by various Strace tests and I thought I'd stop at just this one to make it easier for reviewing. Webrev: http://cr.openjdk.java.net/~jcbeyler/8224079/webrev.00/ Bug:

Re: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp)

On 16/05/2019 11:41 pm, Ao Qi wrote: Hi Serguei, I saw your email [1], but I didn't receive it yet. Thanks for your review! I updated: http://cr.openjdk.java.net/~aoqi/8224028/webrev.01/ On Thu, May 16, 2019 at 8:30 PM David Holmes wrote: What compiler was used here? We shouldn't be using a

Withdrawn: RFR: JDK-8221713: JDWP spec - allow option is not described

Sorry, the request is withdrawn. --alex On 05/16/2019 12:17, Alex Menkov wrote: Hi all, Back in JDK10 "allow" option was implemented for dt_socket transport: https://bugs.openjdk.java.net/browse/JDK-8061228 CCC: https://bugs.openjdk.java.net/browse/CCC-8061228 But this option was not reflected

Re: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp)

On 17/05/2019 12:26 am, Jean Christophe Beyler wrote: From my experience, some compiler in Solaris/Windows complain about this (or used to a year ago via the submit repo); Serguei and I had to do this dance when we were getting the heap monitoring tests in. An I think the tests are different

Re: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent

On 17/05/2019 2:40 am, serguei.spit...@oracle.com wrote: Hi David, On 5/16/19 05:33, David Holmes wrote: On 16/05/2019 7:47 pm, serguei.spit...@oracle.com wrote: On 5/16/19 02:25, David Holmes wrote: Hi Serguei, On 16/05/2019 5:22 pm, serguei.spit...@oracle.com wrote: **Note #2* Just real

RFR: JDK-8221713: JDWP spec - allow option is not described

Hi all, Back in JDK10 "allow" option was implemented for dt_socket transport: https://bugs.openjdk.java.net/browse/JDK-8061228 CCC: https://bugs.openjdk.java.net/browse/CCC-8061228 But this option was not reflected in "Connection and Invocation Details" page. JBS: https://bugs.openjdk.java.net

Re: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp)

On Fri, May 17, 2019 at 12:44 AM serguei.spit...@oracle.com wrote: > > Hi Ao Qi, > > Thank you for the update. > It looks good to me. Thanks! > > Do you need a sponsor for integration? Yes:) > > Thanks, > Serguei > > > On 5/16/19 09:38, Alex Menkov wrote: > > > > > > On 05/16/2019 06:41, Ao Qi

Re: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null

Thank you Chris, David, and JC, for reviewing this change! Best regards, Daniil On 5/15/19, 11:33 PM, "David Holmes" wrote: Hi Daniil, That seems fine to me. Thanks, David On 16/05/2019 5:15 am, Daniil Titov wrote: > Hi David, Chris, and JC, > >

Re: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp)

Hi Ao Qi, Thank you for the update. It looks good to me. Do you need a sponsor for integration? Thanks, Serguei On 5/16/19 09:38, Alex Menkov wrote: On 05/16/2019 06:41, Ao Qi wrote: Hi Serguei, I saw your email [1], but I didn't receive it yet. Thanks for your review! I updated: http:/

Re: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent

Hi David, On 5/16/19 05:33, David Holmes wrote: On 16/05/2019 7:47 pm, serguei.spit...@oracle.com wrote: On 5/16/19 02:25, David Holmes wrote: Hi Serguei, On 16/05/2019 5:22 pm, serguei.spit...@oracle.com wrote: **Note #2* Just realized there is an incorrectness in current spec of this ca

Re: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp)

On 05/16/2019 06:41, Ao Qi wrote: Hi Serguei, I saw your email [1], but I didn't receive it yet. Thanks for your review! I updated: http://cr.openjdk.java.net/~aoqi/8224028/webrev.01/ Looks good. --alex On Thu, May 16, 2019 at 8:30 PM David Holmes wrote: What compiler was used here?

Re: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent

On 5/16/19 03:33, Alan Bateman wrote: On 16/05/2019 08:22, serguei.spit...@oracle.com wrote: Not sure, if I understand you correctly because there can be a confusion here. Is it about the IsModifiableModule? : My comment was about how can_redefine_any_class is documented in the Capabiliti

Re: RFR (S) 8224020: AsyncGetCallTrace test should not run on PPC64 or IA64

Hi Jc, from the perspective of the ppc64 and s390 port it is OK to exclude the two platforms from the test. When we will fix AGCT on the two platforms we will update the tests. Thanks, Volker On Thu, May 16, 2019 at 4:57 AM Jean Christophe Beyler wrote: > > Hi both, > > For the linux question,

Re: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent

On 16/05/2019 7:47 pm, serguei.spit...@oracle.com wrote: On 5/16/19 02:25, David Holmes wrote: Hi Serguei, On 16/05/2019 5:22 pm, serguei.spit...@oracle.com wrote: **Note #2* Just realized there is an incorrectness in current spec of this capability an_redefine_any_class. This section http

Re: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp)

What compiler was used here? We shouldn't be using anything that doesn't handle loop variable declarations! Thanks, David On 16/05/2019 7:41 pm, Daniel Fuchs wrote: Hi Ao Qi, I'm adding serviceability-dev, since this is for jdwp. The proposed changes look good to me - but please get someone

Re: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent

On 16/05/2019 08:22, serguei.spit...@oracle.com wrote: Not sure, if I understand you correctly because there can be a confusion here. Is it about the IsModifiableModule? : My comment was about how can_redefine_any_class is documented in the Capabilities table of IsModifiableClass. It curr

Re: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp)

Hi Ao Qi, It looks good to me. Thank you for taking care about it! One minor comment on the fragment: 474 if (mask != NULL) { 475 if (parseAllowedMask(mask, isIPv4, &(_peers[_peers_cnt].netmask)) != JDWPTRANSPORT_ERROR_NONE) {

Re: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent

On 5/16/19 02:25, David Holmes wrote: Hi Serguei, On 16/05/2019 5:22 pm, serguei.spit...@oracle.com wrote: **Note #2* Just realized there is an incorrectness in current spec of this capability an_redefine_any_class. This section https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.htm

Re: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp)

Hi Ao Qi, I'm adding serviceability-dev, since this is for jdwp. The proposed changes look good to me - but please get someone from the serviceability team to review this. best regards, -- daniel On 16/05/2019 08:41, Ao Qi wrote: Hi, I found build is failed on CentOS 7.6, because of loop i

Re: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent

Hi Serguei, On 16/05/2019 5:22 pm, serguei.spit...@oracle.com wrote: **Note #2* Just realized there is an incorrectness in current spec of this capability an_redefine_any_class. This section https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#jvmtiCapabilities.can_redefine_any_cl

Re: RFR: 8223666: SA: debugd options should follow jhsdb style

Just confirming I'm okay with this too. David On 16/05/2019 12:50 pm, serguei.spit...@oracle.com wrote: Hi Osamu, On 5/15/19 19:45, Osamu Sakamoto wrote: Hi Serguei, > I'm Okay with the fix. Thank you for reviewing. I will request Yasumasa to push webrev.00.1 to jdk/jdk when the status of C

Re: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent

On 5/16/19 00:22, serguei.spit...@oracle.com wrote: Hi Alan, Thank you for looking at this CSR. On 5/15/19 00:27, Alan Bateman wrote: On 14/05/2019 21:20, serguei.spit...@oracle.com wrote: :

Re: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent

Hi Alan, Thank you for looking at this CSR. On 5/15/19 00:27, Alan Bateman wrote: On 14/05/2019 21:20, serguei.spit...@oracle.com wrote: : Summary:  The spec of the "can_redefine_any_class" ne