From david.holmes at oracle.com Fri Dec 1 00:16:37 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Dec 2017 10:16:37 +1000 Subject: RFR(XS): 8192840: serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java failing on Windows In-Reply-To: <910a1e62-608f-cd1d-4bdd-598c754d5734@oracle.com> References: <910a1e62-608f-cd1d-4bdd-598c754d5734@oracle.com> Message-ID: <3e146f4c-fcbb-7715-d685-b43a79c37866@oracle.com> Looks good Chris! Thanks, David PS. Sorry for delay but have been OOTO this morning On 1/12/2017 7:50 AM, Chris Plummer wrote: > Hello, > > Please review the changes below. I'll push once I get two reviews since > this is an integration block and would be best if it makes it into > today's nightly build. > > https://bugs.openjdk.java.net/browse/JDK-8192840 > diff --git > a/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java > b/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java > > --- > a/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java > > +++ > b/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java > > @@ -37,7 +37,8 @@ > ???????????? OutputAnalyzer output = null; > > ???????????? output = executor.execute("JVMTI.agent_load " + libpath); > -??????????? output.shouldContain("Agent_OnAttach is not available"); > +??????????? output.shouldContain("Agent_OnAttach"); > +??????????? output.shouldContain("is not available"); > ???????? } catch (Exception e) { > ???????????? throw new RuntimeException(e); > ???????? } > > > I ran the test on Windows-x64, Solaris-sparc, macosx-x64, and and > linux-x64 (both product and fastdebug for all 4 platforms). > > thanks, > > Chris From serguei.spitsyn at oracle.com Fri Dec 1 00:17:09 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 30 Nov 2017 16:17:09 -0800 Subject: RFR(XS): 8192840: serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java failing on Windows In-Reply-To: <910a1e62-608f-cd1d-4bdd-598c754d5734@oracle.com> References: <910a1e62-608f-cd1d-4bdd-598c754d5734@oracle.com> Message-ID: <6d25a4e8-a13d-b3f0-6153-b0c1e3ac7c94@oracle.com> Hi Chris, It looks good. Thanks, Serguei On 11/30/17 13:50, Chris Plummer wrote: > Hello, > > Please review the changes below. I'll push once I get two reviews > since this is an integration block and would be best if it makes it > into today's nightly build. > > https://bugs.openjdk.java.net/browse/JDK-8192840 > diff --git > a/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java > b/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java > > --- > a/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java > +++ > b/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java > @@ -37,7 +37,8 @@ > ???????????? OutputAnalyzer output = null; > > ???????????? output = executor.execute("JVMTI.agent_load " + libpath); > -??????????? output.shouldContain("Agent_OnAttach is not available"); > +??????????? output.shouldContain("Agent_OnAttach"); > +??????????? output.shouldContain("is not available"); > ???????? } catch (Exception e) { > ???????????? throw new RuntimeException(e); > ???????? } > > > I ran the test on Windows-x64, Solaris-sparc, macosx-x64, and and > linux-x64 (both product and fastdebug for all 4 platforms). > > thanks, > > Chris From david.holmes at oracle.com Fri Dec 1 00:48:07 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Dec 2017 10:48:07 +1000 Subject: Unified JVM Logging and diagnostic options LogVMOutput, LogFile, DisplayVMOutput In-Reply-To: References: Message-ID: <92addaa5-e735-db64-0e7a-afe8f5f6c2d4@oracle.com> Hi Man, Adding serviceability as UL is a serviceability feature. On 1/12/2017 10:23 AM, Man Cao wrote: > Hello, > > We (Java Platform Team at Google) found that in JDK9, the file generated by > -XX:+LogVMOutput no longer contains GC log messages, because the unified > JVM logging framework does not use the defaultStream and fileStream classes > and the tty variable. Similarly, related options such as LogFile, > DisplayVMOutput have no effect on the messages printed by the unified > logging framework. > > The main problem for us is that most of our production Java servers use the > options "-XX:+LogVMOutput -XX:-DisplayVMOutput", to save the GC logs and > other VM messages. These flags would no longer work for JDK9's JVM logging > framework. In addition, the file generated by -XX:+LogVMOutput may contain > information that is not printed by the unified logging framework. > > What is worse is that if LogFile and the output of unified logging > framework point to the same file, the file may contain partial or corrupted > messages from the unified logging framework. For example, consider the > following command: > > java -Xlog::file=test.log -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput > -XX:LogFile=test.log > > Then test.log would miss some of the messages that would be printed at the > beginning if you run "java -Xlog". > > So our questions are: > 1. Do you consider this is a bug for the unified logging framework that > should be fixed? Should the unified logging framework respect these > diagnostic options? My understanding is that UL is intended to replace the legacy "logging" flags and works independently of them. So no, UL should not respect these flags. > 2. Is there a plan to deprecate these diagnostic options (LogVMOutput, > LogFile, DisplayVMOutput, etc.)? Will the defaultStream, fileStream classes > and the tty variable eventually removed from HotSpot? I believe that is the general intent - though complete removal is not feasible as UL can't always be used in all contexts. We have migrated various subsystems to UL and all new logging should be using UL. However I don't believe we actually have active RFEs to aggressively complete the switchover. Just my 2c. David > Thanks, > Man > From david.holmes at oracle.com Fri Dec 1 01:11:33 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Dec 2017 11:11:33 +1000 Subject: RFR: 8190837: BasicType and BasicTypeSize should refer to HotSpot values In-Reply-To: References: <210f9c89-e2a6-492a-2f55-c34ad366238c@oracle.com> <3519af22-65de-8005-e307-51b6a479b330@oracle.com> Message-ID: On 29/11/2017 8:04 PM, Yasumasa Suenaga wrote: > Thanks David, > > I will move setType() to after L250. > And I'm waiting for second reviewer and sponsor. I can sponsor, but what platforms have you tested on, and which tests? Thanks, David > > Yasumasa > > > 2017/11/29 ??6:58 "David Holmes" >: > > Hi Yasumasa, > > On 29/11/2017 6:42 PM, Yasumasa Suenaga wrote: > > Hi David, > > That can be fixed using a no-arg > constructor for static initialization and adding a private > setType method > used for the real initialization. > > > I uploaded new webrev. Is it okay? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8190837/webrev.01/ > > > > Minor nit: The private setType method should be defined after: > > ?250? ?//-- Internals only below this point > > but otherwise this looks exactly like I had envisaged. No need to > see updated webrev. > > > I'm not at all clear why we need the tXxx and T_XXX forms? > The former can be > obtained from the latter. > > > I agree with you, but it is difficult. > For example, [1] has a lot of lines which use BasicType. > > I had a lot of compile errors when I removed getTXxx methods > from BasicType... > > > I wasn't suggesting getting rid of the getTXxx methods just the tXxx > fields - as you have done. > > Thanks, > David > > > Thanks, > > Yasumasa > > > [1] > http://hg.openjdk.java.net/jdk/hs/file/5a449dbca6d0/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java#l560 > > > > 2017-11-29 16:01 GMT+09:00 David Holmes >: > > On 29/11/2017 4:19 PM, Jini George wrote: > > > Hi Chris, > > Thank you for raising this. I agree it is disruptive, > but we are trying to > address the issue of frequent SA breakages with hotspot > changes, and the > causes of these breakages. One of the reasons is the > redefinition of > constants, which is extremely error prone. There have > been multiple cases > where the changes get done in hotspot and the > corresponding changes get > inadvertently missed out in SA. And this does not get > caught, sometimes, for > months. I believe that the switch case statements > conversion to if-else > statements is not a heavy price to pay for avoiding > errors like these. > > > > I agree it is good to ensure this always matches the VM. I > also agree it is > unfortunate we lost the ability to keep the switch > statements - so be it. > I'm more concerned that the BasicType static fields are no > longer final > (that may raise parfait warnings!). That can be fixed using > a no-arg > constructor for static initialization and adding a private > setType method > used for the real initialization. > > I'm not at all clear why we need the tXxx and T_XXX forms? > The former can be > obtained from the latter. And with the change to use the > getTXxx() functions > I think we can actually do away with all the tXxx static > fields. The > getTXxx() functions can be implemented as "return > T_XXX.getType(); and the > intToBasicType() function can also examine getType(). The > name could be > stored as a field, set at construction time. Just a thought. :) > > Thanks, > David > > > Thanks! > - Jini. > > On 11/29/2017 7:56 AM, Chris Plummer wrote: > > > On 11/28/17 5:23 PM, Yasumasa Suenaga wrote: > > > Hi Chris, > > I understood the reason for getting rid of > the case statements. I was > just > wondering if you weighed this code > disruption vs. the value of what you > are > fixing. > > > Jini has pointed it as below and I agree with him: > > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-October/021965.html > > ------------- > One point I want to make is that we have the > enum BasicTypeSize redefined in SA as public > static final values, and > this makes it error prone when existing enum > values change, just as in > this case. An ideal solution would be to include > this in vmStructs.cpp > as a declare_constant() macro, and read this in > SA with the > db.lookupIntConstant() method. > ------------- > > > Hi Yasumasa, > > Yes, I had read that and understand the point being > made. What I'm asking > is now that you've implemented it and seen the > disruption to the switch > statements (which I assume you and Jini were not > aware of before embarking > on this), is it still worth doing? It's not really > that big of a deal to me. > I just want to make sure it's been taken into > consideration. > > thanks, > > Chris > > > Thanks, > > Yasumasa > > > 2017-11-29 10:09 GMT+09:00 Chris Plummer > >: > > > On 11/28/17 4:51 PM, Yasumasa Suenaga wrote: > > > Hi Chris, > > 2017-11-29 5:32 GMT+09:00 Chris Plummer > >: > > > Hi Yasumasa, > > This isn't code I know very well, > and I'm not a Reviewer. Just a > couple > of > observations. > > I wonder if the person who > originally suggested this change > realized > the > disruption it would have to existing > switch statements. I'm not > saying > the > change shouldn't be done for this > reason, but it is something to at > least > consider. > > > According to JLS, `case` label need to > have constant expression. > We cannot set `static final` to the > field which is set at > initialize(). > > > https://docs.oracle.com/javase/specs/jls/se9/html/jls-14.html#jls-14.11 > > > > I understood the reason for getting rid of > the case statements. I was > just > wondering if you weighed this code > disruption vs. the value of what you > are > fixing. > > > > > Your coding pattern for the > following differs from the existing 200+ > instances of > VM.registerVMInitializedObserver() > calls already in > place. I > suggest you be consistent with > existing code. > > ? ? ?71? ?static { > ? ? ?72 > ?VM.registerVMInitializedObserver( > ? ? ?73? ? ? ? ?(o, d) -> > initialize(VM.getVM().getTypeDataBase())); > ? ? ?74? ?} > > > This style has been used in > JavaThreadsPanel.java . > > > Ah, I missed that one case, but then it's > one that you added. :) > > > I like it because it is simple. > > I will change it to traditional style if > other reviewer(s) suggest it. > > > I think consistency is important. > > thanks, > > Chris > > > Thanks, > > Yasumasa > > > thanks, > > Chris > > > On 11/27/17 11:49 PM, Yasumasa > Suenaga wrote: > > Hi all, > > Enum values in BasicType and > BasicTypeSize are declared as const > values. However, it makes error > prone when existing enum values > change. > They should refer to HotSpot values > via VMStructs. > > This issue has been pointed by Jini [1]. > > I uploaded webrev for this issue. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8190837/webrev.00/ > > > I cannot access JPRT. So I need a > sponsor. > > > Thanks, > > Yasumasa > > > [1] > > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-October/021965.html > > > > > From yasuenag at gmail.com Fri Dec 1 01:15:13 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 1 Dec 2017 10:15:13 +0900 Subject: RFR: 8190837: BasicType and BasicTypeSize should refer to HotSpot values In-Reply-To: References: <210f9c89-e2a6-492a-2f55-c34ad366238c@oracle.com> <3519af22-65de-8005-e307-51b6a479b330@oracle.com> Message-ID: Hi David, I've tested this change with test/hotspot/jtreg/serviceability/sa on Linux x64. Thanks, Yasumasa 2017-12-01 10:11 GMT+09:00 David Holmes : > On 29/11/2017 8:04 PM, Yasumasa Suenaga wrote: >> >> Thanks David, >> >> I will move setType() to after L250. >> And I'm waiting for second reviewer and sponsor. > > > I can sponsor, but what platforms have you tested on, and which tests? > > Thanks, > David > >> >> Yasumasa >> >> >> 2017/11/29 ??6:58 "David Holmes" > >: >> >> >> Hi Yasumasa, >> >> On 29/11/2017 6:42 PM, Yasumasa Suenaga wrote: >> >> Hi David, >> >> That can be fixed using a no-arg >> constructor for static initialization and adding a private >> setType method >> used for the real initialization. >> >> >> I uploaded new webrev. Is it okay? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8190837/webrev.01/ >> >> >> >> Minor nit: The private setType method should be defined after: >> >> 250 //-- Internals only below this point >> >> but otherwise this looks exactly like I had envisaged. No need to >> see updated webrev. >> >> >> I'm not at all clear why we need the tXxx and T_XXX forms? >> The former can be >> obtained from the latter. >> >> >> I agree with you, but it is difficult. >> For example, [1] has a lot of lines which use BasicType. >> >> I had a lot of compile errors when I removed getTXxx methods >> from BasicType... >> >> >> I wasn't suggesting getting rid of the getTXxx methods just the tXxx >> fields - as you have done. >> >> Thanks, >> David >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] >> >> http://hg.openjdk.java.net/jdk/hs/file/5a449dbca6d0/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java#l560 >> >> >> >> >> 2017-11-29 16:01 GMT+09:00 David Holmes > >: >> >> >> On 29/11/2017 4:19 PM, Jini George wrote: >> >> >> Hi Chris, >> >> Thank you for raising this. I agree it is disruptive, >> but we are trying to >> address the issue of frequent SA breakages with hotspot >> changes, and the >> causes of these breakages. One of the reasons is the >> redefinition of >> constants, which is extremely error prone. There have >> been multiple cases >> where the changes get done in hotspot and the >> corresponding changes get >> inadvertently missed out in SA. And this does not get >> caught, sometimes, for >> months. I believe that the switch case statements >> conversion to if-else >> statements is not a heavy price to pay for avoiding >> errors like these. >> >> >> >> I agree it is good to ensure this always matches the VM. I >> also agree it is >> unfortunate we lost the ability to keep the switch >> statements - so be it. >> I'm more concerned that the BasicType static fields are no >> longer final >> (that may raise parfait warnings!). That can be fixed using >> a no-arg >> constructor for static initialization and adding a private >> setType method >> used for the real initialization. >> >> I'm not at all clear why we need the tXxx and T_XXX forms? >> The former can be >> obtained from the latter. And with the change to use the >> getTXxx() functions >> I think we can actually do away with all the tXxx static >> fields. The >> getTXxx() functions can be implemented as "return >> T_XXX.getType(); and the >> intToBasicType() function can also examine getType(). The >> name could be >> stored as a field, set at construction time. Just a thought. >> :) >> >> Thanks, >> David >> >> >> Thanks! >> - Jini. >> >> On 11/29/2017 7:56 AM, Chris Plummer wrote: >> >> >> On 11/28/17 5:23 PM, Yasumasa Suenaga wrote: >> >> >> Hi Chris, >> >> I understood the reason for getting rid of >> the case statements. I was >> just >> wondering if you weighed this code >> disruption vs. the value of what you >> are >> fixing. >> >> >> Jini has pointed it as below and I agree with him: >> >> >> >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-October/021965.html >> >> >> ------------- >> One point I want to make is that we have the >> enum BasicTypeSize redefined in SA as public >> static final values, and >> this makes it error prone when existing enum >> values change, just as in >> this case. An ideal solution would be to include >> this in vmStructs.cpp >> as a declare_constant() macro, and read this in >> SA with the >> db.lookupIntConstant() method. >> ------------- >> >> >> Hi Yasumasa, >> >> Yes, I had read that and understand the point being >> made. What I'm asking >> is now that you've implemented it and seen the >> disruption to the switch >> statements (which I assume you and Jini were not >> aware of before embarking >> on this), is it still worth doing? It's not really >> that big of a deal to me. >> I just want to make sure it's been taken into >> consideration. >> >> thanks, >> >> Chris >> >> >> Thanks, >> >> Yasumasa >> >> >> 2017-11-29 10:09 GMT+09:00 Chris Plummer >> > >: >> >> >> On 11/28/17 4:51 PM, Yasumasa Suenaga wrote: >> >> >> Hi Chris, >> >> 2017-11-29 5:32 GMT+09:00 Chris Plummer >> > >: >> >> >> >> Hi Yasumasa, >> >> This isn't code I know very well, >> and I'm not a Reviewer. Just a >> couple >> of >> observations. >> >> I wonder if the person who >> originally suggested this change >> realized >> the >> disruption it would have to existing >> switch statements. I'm not >> saying >> the >> change shouldn't be done for this >> reason, but it is something to at >> least >> consider. >> >> >> According to JLS, `case` label need to >> have constant expression. >> We cannot set `static final` to the >> field which is set at >> initialize(). >> >> >> >> https://docs.oracle.com/javase/specs/jls/se9/html/jls-14.html#jls-14.11 >> >> >> >> >> I understood the reason for getting rid of >> the case statements. I was >> just >> wondering if you weighed this code >> disruption vs. the value of what you >> are >> fixing. >> >> >> >> >> Your coding pattern for the >> following differs from the existing >> 200+ >> instances of >> VM.registerVMInitializedObserver() >> calls already in >> place. I >> suggest you be consistent with >> existing code. >> >> 71 static { >> 72 >> VM.registerVMInitializedObserver( >> 73 (o, d) -> >> >> initialize(VM.getVM().getTypeDataBase())); >> 74 } >> >> >> This style has been used in >> JavaThreadsPanel.java . >> >> >> Ah, I missed that one case, but then it's >> one that you added. :) >> >> >> I like it because it is simple. >> >> I will change it to traditional style if >> other reviewer(s) suggest it. >> >> >> I think consistency is important. >> >> thanks, >> >> Chris >> >> >> Thanks, >> >> Yasumasa >> >> >> thanks, >> >> Chris >> >> >> On 11/27/17 11:49 PM, Yasumasa >> Suenaga wrote: >> >> Hi all, >> >> Enum values in BasicType and >> BasicTypeSize are declared as const >> values. However, it makes error >> prone when existing enum values >> change. >> They should refer to HotSpot values >> via VMStructs. >> >> This issue has been pointed by Jini >> [1]. >> >> I uploaded webrev for this issue. >> Could you review it? >> >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8190837/webrev.00/ >> >> >> >> I cannot access JPRT. So I need a >> sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] >> >> >> >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-October/021965.html >> >> >> >> >> >> > From manc at google.com Fri Dec 1 01:15:35 2017 From: manc at google.com (Man Cao) Date: Thu, 30 Nov 2017 17:15:35 -0800 Subject: Unified JVM Logging and diagnostic options LogVMOutput, LogFile, DisplayVMOutput In-Reply-To: <92addaa5-e735-db64-0e7a-afe8f5f6c2d4@oracle.com> References: <92addaa5-e735-db64-0e7a-afe8f5f6c2d4@oracle.com> Message-ID: Thanks David for the quick response! Yes, I understand completely removing defaultStream and tty is probably infeasible. If deprecating the diagnostic options (LogVMOutput, LogFile, DisplayVMOutput) is the intent, could someone create a bug/RFE to track it? They should probably first be added to the special_jvm_flags table in arguments.cpp, so there will be a warning when people use them. The case of conflicting -Xlog::file=test.log and -XX:LogFile=test.log is also a concern, the JVM should at least issue a warning about it. In addition, it would make it easier for us to convince production teams to stop using these options. Thanks, Man On Thu, Nov 30, 2017 at 4:48 PM, David Holmes wrote: > Hi Man, > > Adding serviceability as UL is a serviceability feature. > > > On 1/12/2017 10:23 AM, Man Cao wrote: > >> Hello, >> >> We (Java Platform Team at Google) found that in JDK9, the file generated >> by >> -XX:+LogVMOutput no longer contains GC log messages, because the unified >> JVM logging framework does not use the defaultStream and fileStream >> classes >> and the tty variable. Similarly, related options such as LogFile, >> DisplayVMOutput have no effect on the messages printed by the unified >> logging framework. >> >> The main problem for us is that most of our production Java servers use >> the >> options "-XX:+LogVMOutput -XX:-DisplayVMOutput", to save the GC logs and >> other VM messages. These flags would no longer work for JDK9's JVM logging >> framework. In addition, the file generated by -XX:+LogVMOutput may contain >> information that is not printed by the unified logging framework. >> >> What is worse is that if LogFile and the output of unified logging >> framework point to the same file, the file may contain partial or >> corrupted >> messages from the unified logging framework. For example, consider the >> following command: >> >> java -Xlog::file=test.log -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput >> -XX:LogFile=test.log >> >> Then test.log would miss some of the messages that would be printed at the >> beginning if you run "java -Xlog". >> >> So our questions are: >> 1. Do you consider this is a bug for the unified logging framework that >> should be fixed? Should the unified logging framework respect these >> diagnostic options? >> > > My understanding is that UL is intended to replace the legacy "logging" > flags and works independently of them. So no, UL should not respect these > flags. > > 2. Is there a plan to deprecate these diagnostic options (LogVMOutput, >> LogFile, DisplayVMOutput, etc.)? Will the defaultStream, fileStream >> classes >> and the tty variable eventually removed from HotSpot? >> > > I believe that is the general intent - though complete removal is not > feasible as UL can't always be used in all contexts. We have migrated > various subsystems to UL and all new logging should be using UL. However I > don't believe we actually have active RFEs to aggressively complete the > switchover. > > Just my 2c. > > David > > Thanks, >> Man >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Fri Dec 1 04:37:21 2017 From: jini.george at oracle.com (Jini George) Date: Fri, 1 Dec 2017 10:07:21 +0530 Subject: RFR: JDK-8191914: (XS): New SA test timeout on windows In-Reply-To: <0a32281d-46ea-4cab-735e-24cf9bcbb2cb@oracle.com> References: <6b9f1ad1-1668-a794-7dca-5c5ad2f62329@oracle.com> <0a32281d-46ea-4cab-735e-24cf9bcbb2cb@oracle.com> Message-ID: <422d1f93-6f1b-b066-6691-81cd49a4aa41@oracle.com> Thank you, David, for the review, and for pointing out about the other tests. I went through the other tests and corrected a few more. Would you please take a look at the modified webrev ? http://cr.openjdk.java.net/~jgeorge/8191914/webrev.01/index.html Thanks, Jini. On 11/30/2017 1:27 PM, David Holmes wrote: > Hi Jini, > > Fix looks good. Have you checked the other tests for a similar problem? > > Thanks, > David > > On 30/11/2017 4:34 PM, Jini George wrote: >> Hello, >> >> Requesting reviews for a very small change to avoid the timeout of the >> recently added TestJhsdbJStackLock.java test case on windows. The >> change includes unquarantining this test on windows also. >> >> https://bugs.openjdk.java.net/browse/JDK-8191914 >> Webrev: http://cr.openjdk.java.net/~jgeorge/8191914/webrev.00/ >> >> Thanks, >> Jini. From jini.george at oracle.com Fri Dec 1 04:43:53 2017 From: jini.george at oracle.com (Jini George) Date: Fri, 1 Dec 2017 10:13:53 +0530 Subject: RFR: JDK-8191914: (XS): New SA test timeout on windows In-Reply-To: <422d1f93-6f1b-b066-6691-81cd49a4aa41@oracle.com> References: <6b9f1ad1-1668-a794-7dca-5c5ad2f62329@oracle.com> <0a32281d-46ea-4cab-735e-24cf9bcbb2cb@oracle.com> <422d1f93-6f1b-b066-6691-81cd49a4aa41@oracle.com> Message-ID: <5fadea12-ba08-7252-30b9-a9967b4d2793@oracle.com> This has passed Mach5 testing and jprt is being run currently. Thanks, Jini. On 12/1/2017 10:07 AM, Jini George wrote: > Thank you, David, for the review, and for pointing out about the other > tests. I went through the other tests and corrected a few more. Would > you please take a look at the modified webrev ? > > http://cr.openjdk.java.net/~jgeorge/8191914/webrev.01/index.html > > Thanks, > Jini. > > On 11/30/2017 1:27 PM, David Holmes wrote: >> Hi Jini, >> >> Fix looks good. Have you checked the other tests for a similar problem? >> >> Thanks, >> David >> >> On 30/11/2017 4:34 PM, Jini George wrote: >>> Hello, >>> >>> Requesting reviews for a very small change to avoid the timeout of >>> the recently added TestJhsdbJStackLock.java test case on windows. The >>> change includes unquarantining this test on windows also. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8191914 >>> Webrev: http://cr.openjdk.java.net/~jgeorge/8191914/webrev.00/ >>> >>> Thanks, >>> Jini. From jini.george at oracle.com Fri Dec 1 04:44:26 2017 From: jini.george at oracle.com (Jini George) Date: Fri, 1 Dec 2017 10:14:26 +0530 Subject: RFR: JDK-8191914: (XS): New SA test timeout on windows In-Reply-To: References: <6b9f1ad1-1668-a794-7dca-5c5ad2f62329@oracle.com> Message-ID: <999fb7a7-4246-fbee-a0ee-cfec550b994f@oracle.com> Thank you very much for the review, Sharath! - Jini. On 11/30/2017 9:59 PM, Sharath Ballal wrote: > Hi Jini, > Looks good to me. > > Thanks, > Sharath (Not a Reviewer) > > > -----Original Message----- > From: Jini George > Sent: Thursday, November 30, 2017 12:05 PM > To: serviceability-dev at openjdk.java.net > Subject: RFR: JDK-8191914: (XS): New SA test timeout on windows > > Hello, > > Requesting reviews for a very small change to avoid the timeout of the recently added TestJhsdbJStackLock.java test case on windows. The change includes unquarantining this test on windows also. > > https://bugs.openjdk.java.net/browse/JDK-8191914 > Webrev: http://cr.openjdk.java.net/~jgeorge/8191914/webrev.00/ > > Thanks, > Jini. > From david.holmes at oracle.com Fri Dec 1 04:48:05 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Dec 2017 14:48:05 +1000 Subject: RFR: JDK-8191914: (XS): New SA test timeout on windows In-Reply-To: <422d1f93-6f1b-b066-6691-81cd49a4aa41@oracle.com> References: <6b9f1ad1-1668-a794-7dca-5c5ad2f62329@oracle.com> <0a32281d-46ea-4cab-735e-24cf9bcbb2cb@oracle.com> <422d1f93-6f1b-b066-6691-81cd49a4aa41@oracle.com> Message-ID: <2d7f692b-7cb6-d215-157f-f64c6d020d68@oracle.com> Looks good! Thanks for the additional simplifications using OutputAnalyzer. David On 1/12/2017 2:37 PM, Jini George wrote: > Thank you, David, for the review, and for pointing out about the other > tests. I went through the other tests and corrected a few more. Would > you please take a look at the modified webrev ? > > http://cr.openjdk.java.net/~jgeorge/8191914/webrev.01/index.html > > Thanks, > Jini. > > On 11/30/2017 1:27 PM, David Holmes wrote: >> Hi Jini, >> >> Fix looks good. Have you checked the other tests for a similar problem? >> >> Thanks, >> David >> >> On 30/11/2017 4:34 PM, Jini George wrote: >>> Hello, >>> >>> Requesting reviews for a very small change to avoid the timeout of >>> the recently added TestJhsdbJStackLock.java test case on windows. The >>> change includes unquarantining this test on windows also. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8191914 >>> Webrev: http://cr.openjdk.java.net/~jgeorge/8191914/webrev.00/ >>> >>> Thanks, >>> Jini. From sharath.ballal at oracle.com Fri Dec 1 06:05:19 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 30 Nov 2017 22:05:19 -0800 (PST) Subject: RFR: JDK-8191914: (XS): New SA test timeout on windows In-Reply-To: <2d7f692b-7cb6-d215-157f-f64c6d020d68@oracle.com> References: <6b9f1ad1-1668-a794-7dca-5c5ad2f62329@oracle.com> <0a32281d-46ea-4cab-735e-24cf9bcbb2cb@oracle.com> <422d1f93-6f1b-b066-6691-81cd49a4aa41@oracle.com> <2d7f692b-7cb6-d215-157f-f64c6d020d68@oracle.com> Message-ID: <380c6eef-2ef0-4838-9530-8f86ab207e55@default> Looks Good Jini. Thanks, Sharath -----Original Message----- From: David Holmes Sent: Friday, December 01, 2017 10:18 AM To: Jini George; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8191914: (XS): New SA test timeout on windows Looks good! Thanks for the additional simplifications using OutputAnalyzer. David On 1/12/2017 2:37 PM, Jini George wrote: > Thank you, David, for the review, and for pointing out about the other > tests. I went through the other tests and corrected a few more. Would > you please take a look at the modified webrev ? > > http://cr.openjdk.java.net/~jgeorge/8191914/webrev.01/index.html > > Thanks, > Jini. > > On 11/30/2017 1:27 PM, David Holmes wrote: >> Hi Jini, >> >> Fix looks good. Have you checked the other tests for a similar problem? >> >> Thanks, >> David >> >> On 30/11/2017 4:34 PM, Jini George wrote: >>> Hello, >>> >>> Requesting reviews for a very small change to avoid the timeout of >>> the recently added TestJhsdbJStackLock.java test case on windows. >>> The change includes unquarantining this test on windows also. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8191914 >>> Webrev: http://cr.openjdk.java.net/~jgeorge/8191914/webrev.00/ >>> >>> Thanks, >>> Jini. From sharath.ballal at oracle.com Fri Dec 1 06:53:44 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 30 Nov 2017 22:53:44 -0800 (PST) Subject: RFR: JDK-8192823 - Testcase for 'clhsdb source' command Message-ID: <198096a0-bebb-4bae-a519-a9ae0006c0ee@default> Hello, Pls review changes for the following issue: Bug ID: https://bugs.openjdk.java.net/browse/JDK-8192823 Webrev: http://cr.openjdk.java.net/~sballal/8192823/webrev.00/ Thanks, Sharath -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Fri Dec 1 08:10:26 2017 From: jini.george at oracle.com (Jini George) Date: Fri, 1 Dec 2017 13:40:26 +0530 Subject: RFR: JDK-8191538: SA: tests for clhsdb commands: vmstructsdump, field, symboltable and symbol In-Reply-To: <9c675068-dfd2-4de5-b880-c71b4bed3cb5@default> References: <498c264f-cf5a-56fe-b635-9ddc706b7fd9@oracle.com> <9c675068-dfd2-4de5-b880-c71b4bed3cb5@default> Message-ID: Thank you, Sharath, for the review. The modified webrev is at: http://cr.openjdk.java.net/~jgeorge/8191538/webrev.01/ Could I get one more pair of eyes to take a look at this ? Thanks, Jini. On 11/30/2017 11:35 PM, Sharath Ballal wrote: > Hi Jini, > > http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbField.java.html and > http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbSymbolTable.java.html > > If you are not adding any new vmoption then > > 48 List vmArgs = new ArrayList(); > 49 vmArgs.addAll(Utils.getVmOptions()); > 50 > 51 theApp = new LingeredApp(); > 52 LingeredApp.startApp(vmArgs, theApp); > > Can be replaced by > > theApp = LingeredApp.startApp(); > > Internally LingeredApp.startApp() is adding all the options got from Utils.getVmOptions() > > If you remove that, then following lines are also not required > 27 import java.util.ArrayList; > 30 import jdk.test.lib.Utils; > > > http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbVmStructsDump.java.html > > This line is not required. > 29 import jdk.test.lib.Platform; > > > > Thanks, > Sharath (not a Reviewer) > > > -----Original Message----- > From: Jini George > Sent: Thursday, November 30, 2017 11:11 AM > To: serviceability-dev at openjdk.java.net > Subject: RFR: JDK-8191538: SA: tests for clhsdb commands: vmstructsdump, field, symboltable and symbol > > Hi all, > > Would like to request for reviews for: > > JBS id: https://bugs.openjdk.java.net/browse/JDK-8191538 > Webrev: http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/ > > These are SA jtreg tests to test the following clhsdb commands: > * field > * vmstructsdump > * symboltable > * symbol > > Thanks, > Jini. > > > > From jini.george at oracle.com Fri Dec 1 08:23:31 2017 From: jini.george at oracle.com (Jini George) Date: Fri, 1 Dec 2017 13:53:31 +0530 Subject: RFR: JDK-8191538: SA: tests for clhsdb commands: vmstructsdump, field, symboltable and symbol In-Reply-To: References: <498c264f-cf5a-56fe-b635-9ddc706b7fd9@oracle.com> <9c675068-dfd2-4de5-b880-c71b4bed3cb5@default> Message-ID: <07dc4627-138d-cdb3-e5e8-c0b6c68529f8@oracle.com> Had missed removing the unused line: import jdk.test.lib.Platform; from ClhsdbVmStructsDump.java (Thanks, Sharath, for pointing this out). Revised webrev: http://cr.openjdk.java.net/~jgeorge/8191538/webrev.02/ Thanks, Jini. On 12/1/2017 1:40 PM, Jini George wrote: > Thank you, Sharath, for the review. The modified webrev is at: > > http://cr.openjdk.java.net/~jgeorge/8191538/webrev.01/ > > Could I get one more pair of eyes to take a look at this ? > > Thanks, > Jini. > > > > On 11/30/2017 11:35 PM, Sharath Ballal wrote: >> Hi Jini, >> >> http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbField.java.html >> and >> http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbSymbolTable.java.html >> >> >> If you are not adding any new vmoption then >> >> ?? 48???????????? List vmArgs = new ArrayList(); >> ?? 49???????????? vmArgs.addAll(Utils.getVmOptions()); >> ?? 50 >> ?? 51???????????? theApp = new LingeredApp(); >> ?? 52???????????? LingeredApp.startApp(vmArgs, theApp); >> >> Can be replaced by >> >> ???????????? theApp = LingeredApp.startApp(); >> >> Internally LingeredApp.startApp() is adding all the options got from >> Utils.getVmOptions() >> >> If you remove that, then following lines are also not required >> 27 import java.util.ArrayList; >> ?? 30 import jdk.test.lib.Utils; >> >> >> http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbVmStructsDump.java.html >> >> >> This line is not required. >> 29 import jdk.test.lib.Platform; >> >> >> >> Thanks, >> Sharath (not a Reviewer) >> >> >> -----Original Message----- >> From: Jini George >> Sent: Thursday, November 30, 2017 11:11 AM >> To: serviceability-dev at openjdk.java.net >> Subject: RFR: JDK-8191538: SA: tests for clhsdb commands: >> vmstructsdump, field, symboltable and symbol >> >> Hi all, >> >> Would like to request for reviews for: >> >> JBS id: https://bugs.openjdk.java.net/browse/JDK-8191538 >> Webrev: http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/ >> >> These are SA jtreg tests to test the following clhsdb commands: >> * field >> * vmstructsdump >> * symboltable >> * symbol >> >> Thanks, >> Jini. >> >> >> >> From jini.george at oracle.com Fri Dec 1 09:59:24 2017 From: jini.george at oracle.com (Jini George) Date: Fri, 1 Dec 2017 15:29:24 +0530 Subject: RFR: JDK-8192823 - Testcase for 'clhsdb source' command In-Reply-To: <198096a0-bebb-4bae-a519-a9ae0006c0ee@default> References: <198096a0-bebb-4bae-a519-a9ae0006c0ee@default> Message-ID: <6612c379-1c40-c521-a1d8-68e2be12cb7e@oracle.com> Hi Sharath, I feel it would be good to have at least 2 commands in the commands source file. And it would be good to delete the commands source file once the test has run and passed. Other than these, it looks good to me. Thanks, Jini (Not a Reviewer). On 12/1/2017 12:23 PM, Sharath Ballal wrote: > Hello, > > Pls review changes for the following issue: > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8192823 > > Webrev: http://cr.openjdk.java.net/~sballal/8192823/webrev.00/ > > Thanks, > > Sharath > From serguei.spitsyn at oracle.com Fri Dec 1 10:45:00 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 1 Dec 2017 02:45:00 -0800 Subject: RFR: JDK-8191538: SA: tests for clhsdb commands: vmstructsdump, field, symboltable and symbol In-Reply-To: <07dc4627-138d-cdb3-e5e8-c0b6c68529f8@oracle.com> References: <498c264f-cf5a-56fe-b635-9ddc706b7fd9@oracle.com> <9c675068-dfd2-4de5-b880-c71b4bed3cb5@default> <07dc4627-138d-cdb3-e5e8-c0b6c68529f8@oracle.com> Message-ID: Hi Jini, New tests look Ok to me. Thanks, Serguei On 12/1/17 00:23, Jini George wrote: > Had missed removing the unused line: > > import jdk.test.lib.Platform; > > from ClhsdbVmStructsDump.java (Thanks, Sharath, for pointing this out). > > Revised webrev: > > http://cr.openjdk.java.net/~jgeorge/8191538/webrev.02/ > > Thanks, > Jini. > > On 12/1/2017 1:40 PM, Jini George wrote: >> Thank you, Sharath, for the review. The modified webrev is at: >> >> http://cr.openjdk.java.net/~jgeorge/8191538/webrev.01/ >> >> Could I get one more pair of eyes to take a look at this ? >> >> Thanks, >> Jini. >> >> >> >> On 11/30/2017 11:35 PM, Sharath Ballal wrote: >>> Hi Jini, >>> >>> http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbField.java.html >>> and >>> http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbSymbolTable.java.html >>> >>> >>> If you are not adding any new vmoption then >>> >>> ?? 48???????????? List vmArgs = new ArrayList(); >>> ?? 49???????????? vmArgs.addAll(Utils.getVmOptions()); >>> ?? 50 >>> ?? 51???????????? theApp = new LingeredApp(); >>> ?? 52???????????? LingeredApp.startApp(vmArgs, theApp); >>> >>> Can be replaced by >>> >>> ???????????? theApp = LingeredApp.startApp(); >>> >>> Internally LingeredApp.startApp() is adding all the options got from >>> Utils.getVmOptions() >>> >>> If you remove that, then following lines are also not required >>> 27 import java.util.ArrayList; >>> ?? 30 import jdk.test.lib.Utils; >>> >>> >>> http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbVmStructsDump.java.html >>> >>> >>> This line is not required. >>> 29 import jdk.test.lib.Platform; >>> >>> >>> >>> Thanks, >>> Sharath (not a Reviewer) >>> >>> >>> -----Original Message----- >>> From: Jini George >>> Sent: Thursday, November 30, 2017 11:11 AM >>> To: serviceability-dev at openjdk.java.net >>> Subject: RFR: JDK-8191538: SA: tests for clhsdb commands: >>> vmstructsdump, field, symboltable and symbol >>> >>> Hi all, >>> >>> Would like to request for reviews for: >>> >>> JBS id: https://bugs.openjdk.java.net/browse/JDK-8191538 >>> Webrev: http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/ >>> >>> These are SA jtreg tests to test the following clhsdb commands: >>> * field >>> * vmstructsdump >>> * symboltable >>> * symbol >>> >>> Thanks, >>> Jini. >>> >>> >>> >>> From sharath.ballal at oracle.com Fri Dec 1 10:51:25 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Fri, 1 Dec 2017 02:51:25 -0800 (PST) Subject: RFR: JDK-8192823 - Testcase for 'clhsdb source' command In-Reply-To: <6612c379-1c40-c521-a1d8-68e2be12cb7e@oracle.com> References: <198096a0-bebb-4bae-a519-a9ae0006c0ee@default> <6612c379-1c40-c521-a1d8-68e2be12cb7e@oracle.com> Message-ID: <9cd19516-fde9-4ce6-b830-a93b49741d56@default> Hi Jini, Thanks for the review. I have done the changes. I have left the file undeleted when there is a failure. Update webrev is http://cr.openjdk.java.net/~sballal/8192823/webrev.01/ Earlier the test has passed in JPRT and mach5. I will run them again now. Thanks, Sharath -----Original Message----- From: Jini George Sent: Friday, December 01, 2017 3:29 PM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8192823 - Testcase for 'clhsdb source' command Hi Sharath, I feel it would be good to have at least 2 commands in the commands source file. And it would be good to delete the commands source file once the test has run and passed. Other than these, it looks good to me. Thanks, Jini (Not a Reviewer). On 12/1/2017 12:23 PM, Sharath Ballal wrote: > Hello, > > Pls review changes for the following issue: > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8192823 > > Webrev: http://cr.openjdk.java.net/~sballal/8192823/webrev.00/ > > Thanks, > > Sharath > From sharath.ballal at oracle.com Fri Dec 1 10:56:53 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Fri, 1 Dec 2017 02:56:53 -0800 (PST) Subject: RFR: JDK-8191538: SA: tests for clhsdb commands: vmstructsdump, field, symboltable and symbol In-Reply-To: <07dc4627-138d-cdb3-e5e8-c0b6c68529f8@oracle.com> References: <498c264f-cf5a-56fe-b635-9ddc706b7fd9@oracle.com> <9c675068-dfd2-4de5-b880-c71b4bed3cb5@default> <07dc4627-138d-cdb3-e5e8-c0b6c68529f8@oracle.com> Message-ID: <388b382f-da2b-4a9d-a542-a250c929f6a6@default> Looks good Jini. Thanks, Sharath -----Original Message----- From: Jini George Sent: Friday, December 01, 2017 1:54 PM To: serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8191538: SA: tests for clhsdb commands: vmstructsdump, field, symboltable and symbol Had missed removing the unused line: import jdk.test.lib.Platform; from ClhsdbVmStructsDump.java (Thanks, Sharath, for pointing this out). Revised webrev: http://cr.openjdk.java.net/~jgeorge/8191538/webrev.02/ Thanks, Jini. On 12/1/2017 1:40 PM, Jini George wrote: > Thank you, Sharath, for the review. The modified webrev is at: > > http://cr.openjdk.java.net/~jgeorge/8191538/webrev.01/ > > Could I get one more pair of eyes to take a look at this ? > > Thanks, > Jini. > > > > On 11/30/2017 11:35 PM, Sharath Ballal wrote: >> Hi Jini, >> >> http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbField.java.html >> and >> http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbSymbolTable.java.html >> >> >> If you are not adding any new vmoption then >> >> ?? 48???????????? List vmArgs = new ArrayList(); >> ?? 49???????????? vmArgs.addAll(Utils.getVmOptions()); >> ?? 50 >> ?? 51???????????? theApp = new LingeredApp(); >> ?? 52???????????? LingeredApp.startApp(vmArgs, theApp); >> >> Can be replaced by >> >> ???????????? theApp = LingeredApp.startApp(); >> >> Internally LingeredApp.startApp() is adding all the options got from >> Utils.getVmOptions() >> >> If you remove that, then following lines are also not required >> 27 import java.util.ArrayList; >> ?? 30 import jdk.test.lib.Utils; >> >> >> http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbVmStructsDump.java.html >> >> >> This line is not required. >> 29 import jdk.test.lib.Platform; >> >> >> >> Thanks, >> Sharath (not a Reviewer) >> >> >> -----Original Message----- >> From: Jini George >> Sent: Thursday, November 30, 2017 11:11 AM >> To: serviceability-dev at openjdk.java.net >> Subject: RFR: JDK-8191538: SA: tests for clhsdb commands: >> vmstructsdump, field, symboltable and symbol >> >> Hi all, >> >> Would like to request for reviews for: >> >> JBS id: https://bugs.openjdk.java.net/browse/JDK-8191538 >> Webrev: http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/ >> >> These are SA jtreg tests to test the following clhsdb commands: >> * field >> * vmstructsdump >> * symboltable >> * symbol >> >> Thanks, >> Jini. >> >> >> >> From sharath.ballal at oracle.com Fri Dec 1 11:33:05 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Fri, 1 Dec 2017 03:33:05 -0800 (PST) Subject: RFR: JDK-8192823 - Testcase for 'clhsdb source' command In-Reply-To: <9cd19516-fde9-4ce6-b830-a93b49741d56@default> References: <198096a0-bebb-4bae-a519-a9ae0006c0ee@default> <6612c379-1c40-c521-a1d8-68e2be12cb7e@oracle.com> <9cd19516-fde9-4ce6-b830-a93b49741d56@default> Message-ID: <7d4d5a50-bca7-4ef7-968e-9da1fded1549@default> Can I have one more review please ? Thanks, Sharath -----Original Message----- From: Sharath Ballal Sent: Friday, December 01, 2017 4:21 PM To: Jini Susan George; serviceability-dev at openjdk.java.net Subject: RE: RFR: JDK-8192823 - Testcase for 'clhsdb source' command Hi Jini, Thanks for the review. I have done the changes. I have left the file undeleted when there is a failure. Update webrev is http://cr.openjdk.java.net/~sballal/8192823/webrev.01/ Earlier the test has passed in JPRT and mach5. I will run them again now. Thanks, Sharath -----Original Message----- From: Jini George Sent: Friday, December 01, 2017 3:29 PM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8192823 - Testcase for 'clhsdb source' command Hi Sharath, I feel it would be good to have at least 2 commands in the commands source file. And it would be good to delete the commands source file once the test has run and passed. Other than these, it looks good to me. Thanks, Jini (Not a Reviewer). On 12/1/2017 12:23 PM, Sharath Ballal wrote: > Hello, > > Pls review changes for the following issue: > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8192823 > > Webrev: http://cr.openjdk.java.net/~sballal/8192823/webrev.00/ > > Thanks, > > Sharath > From jini.george at oracle.com Fri Dec 1 12:55:04 2017 From: jini.george at oracle.com (Jini George) Date: Fri, 1 Dec 2017 18:25:04 +0530 Subject: RFR: JDK-8192823 - Testcase for 'clhsdb source' command In-Reply-To: <9cd19516-fde9-4ce6-b830-a93b49741d56@default> References: <198096a0-bebb-4bae-a519-a9ae0006c0ee@default> <6612c379-1c40-c521-a1d8-68e2be12cb7e@oracle.com> <9cd19516-fde9-4ce6-b830-a93b49741d56@default> Message-ID: Looks good. Thanks, Jini. On 12/1/2017 4:21 PM, Sharath Ballal wrote: > Hi Jini, > Thanks for the review. > I have done the changes. I have left the file undeleted when there is a failure. > Update webrev is http://cr.openjdk.java.net/~sballal/8192823/webrev.01/ > > Earlier the test has passed in JPRT and mach5. I will run them again now. > > Thanks, > Sharath > > > -----Original Message----- > From: Jini George > Sent: Friday, December 01, 2017 3:29 PM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8192823 - Testcase for 'clhsdb source' command > > Hi Sharath, > > I feel it would be good to have at least 2 commands in the commands source file. And it would be good to delete the commands source file once the test has run and passed. > > Other than these, it looks good to me. > > Thanks, > Jini (Not a Reviewer). > > On 12/1/2017 12:23 PM, Sharath Ballal wrote: >> Hello, >> >> Pls review changes for the following issue: >> >> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8192823 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8192823/webrev.00/ >> >> Thanks, >> >> Sharath >> From jini.george at oracle.com Fri Dec 1 13:11:46 2017 From: jini.george at oracle.com (Jini George) Date: Fri, 1 Dec 2017 18:41:46 +0530 Subject: RFR: JDK-8191538: SA: tests for clhsdb commands: vmstructsdump, field, symboltable and symbol In-Reply-To: References: <498c264f-cf5a-56fe-b635-9ddc706b7fd9@oracle.com> <9c675068-dfd2-4de5-b880-c71b4bed3cb5@default> <07dc4627-138d-cdb3-e5e8-c0b6c68529f8@oracle.com> Message-ID: <60e04be2-4a9e-5a49-878a-8b49f96c1a53@oracle.com> Thank you, Serguei! - Jini. On 12/1/2017 4:15 PM, serguei.spitsyn at oracle.com wrote: > Hi Jini, > > New tests look Ok to me. > > Thanks, > Serguei > > > On 12/1/17 00:23, Jini George wrote: >> Had missed removing the unused line: >> >> import jdk.test.lib.Platform; >> >> from ClhsdbVmStructsDump.java (Thanks, Sharath, for pointing this out). >> >> Revised webrev: >> >> http://cr.openjdk.java.net/~jgeorge/8191538/webrev.02/ >> >> Thanks, >> Jini. >> >> On 12/1/2017 1:40 PM, Jini George wrote: >>> Thank you, Sharath, for the review. The modified webrev is at: >>> >>> http://cr.openjdk.java.net/~jgeorge/8191538/webrev.01/ >>> >>> Could I get one more pair of eyes to take a look at this ? >>> >>> Thanks, >>> Jini. >>> >>> >>> >>> On 11/30/2017 11:35 PM, Sharath Ballal wrote: >>>> Hi Jini, >>>> >>>> http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbField.java.html >>>> and >>>> http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbSymbolTable.java.html >>>> >>>> >>>> If you are not adding any new vmoption then >>>> >>>> ?? 48???????????? List vmArgs = new ArrayList(); >>>> ?? 49???????????? vmArgs.addAll(Utils.getVmOptions()); >>>> ?? 50 >>>> ?? 51???????????? theApp = new LingeredApp(); >>>> ?? 52???????????? LingeredApp.startApp(vmArgs, theApp); >>>> >>>> Can be replaced by >>>> >>>> ???????????? theApp = LingeredApp.startApp(); >>>> >>>> Internally LingeredApp.startApp() is adding all the options got from >>>> Utils.getVmOptions() >>>> >>>> If you remove that, then following lines are also not required >>>> 27 import java.util.ArrayList; >>>> ?? 30 import jdk.test.lib.Utils; >>>> >>>> >>>> http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbVmStructsDump.java.html >>>> >>>> >>>> This line is not required. >>>> 29 import jdk.test.lib.Platform; >>>> >>>> >>>> >>>> Thanks, >>>> Sharath (not a Reviewer) >>>> >>>> >>>> -----Original Message----- >>>> From: Jini George >>>> Sent: Thursday, November 30, 2017 11:11 AM >>>> To: serviceability-dev at openjdk.java.net >>>> Subject: RFR: JDK-8191538: SA: tests for clhsdb commands: >>>> vmstructsdump, field, symboltable and symbol >>>> >>>> Hi all, >>>> >>>> Would like to request for reviews for: >>>> >>>> JBS id: https://bugs.openjdk.java.net/browse/JDK-8191538 >>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8191538/webrev.00/ >>>> >>>> These are SA jtreg tests to test the following clhsdb commands: >>>> * field >>>> * vmstructsdump >>>> * symboltable >>>> * symbol >>>> >>>> Thanks, >>>> Jini. >>>> >>>> >>>> >>>> > From yasuenag at gmail.com Fri Dec 1 13:56:25 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 1 Dec 2017 22:56:25 +0900 Subject: RFR: 8192897: NPE occurs on clhsdb jstack Message-ID: Hi all, I saw NPE when I run jstack on clhsdb as below: ---------------- hsdb> jstack Deadlock Detection: No deadlocks found. "NonBlockingInputStreamThread" #27 daemon prio=5 tid=0x00007f0924674000 nid=0xf429 in Object.wait() [0x00007f08cf6fd000] java.lang.Thread.State: WAITING (on object monitor) JavaThread state: _thread_blocked - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise) - waiting on Error occurred during stack walking: java.lang.NullPointerException at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getMonitors(CompiledVFrame.java:131) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(JavaVFrame.java:125) at jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:114) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$26.doit(CommandProcessor.java:1073) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1964) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1934) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1814) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:191) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:439) ---------------- It is caused by CompiledVFrame#getScope() returns null. We should consider it at CompiledVFrame#getMonitors(). I uploaded a webrev. Could you review it? I checked this change with hotspot/jtreg/serviceability/sa on Linux x64. http://cr.openjdk.java.net/~ysuenaga/JDK-8192897/webrev.00/ We can reproduce this issue when we run the app with -Xcomp option. So I changed ClhsdbJstack.java to run with it. I cannot access mach5 and JPRT. So I need sponsor. Thanks, Yasumasa From kumar.x.srinivasan at oracle.com Fri Dec 1 14:41:44 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 01 Dec 2017 06:41:44 -0800 Subject: RFR: 8189102: All tools should support -?, -h and --help In-Reply-To: References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> <5A1C4081.2090107@oracle.com> Message-ID: <5A216A28.3030702@oracle.com> Hi, Besides my private comments to you, there are 2-3 internal tests which fail. Have you run all the langtools tests ? There are 4 Windows tests that fail with langtools: jdk/javadoc/doclet/testHelpOption/TestHelpOption.java jdk/javadoc/tool/CheckResourceKeys.java jdk/javadoc/tool/ToolProviderTest.java tools/javap/InvalidOptions.java tools/jdeps/MultiReleaseJar.java This changeset needs to be vetted thoroughly using internal build and test systems. Any Oracle engineer willing to sponsor this ? Kumar On 11/28/2017 3:16 AM, Lindenmaier, Goetz wrote: > Hi, > > I uploaded a new webrev: > http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.04/ > > This includes the changes > - to jshell requested by Robert > - to the test as requested by Kumar. > > See also incremental patch and the test output including all the > help messages referenced in the webrev. > > Best regards, > Goetz. > >> -----Original Message----- >> From: Kumar Srinivasan [mailto:kumar.x.srinivasan at oracle.com] >> Sent: Montag, 27. November 2017 17:43 >> To: Lindenmaier, Goetz >> Cc: core-libs-dev at openjdk.java.net; 'compiler-dev at openjdk.java.net' >> ; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help >> >> Hi, >> >> I looked at some of the components I maintain, and they look good. >> >> Wrt. the test: >> >> 1. The local variables/fields don't comply with the coding conventions, >> we have been >> following in the JDK. >> >> 2. Hmm, someone parked a .ini file in bin directory, later removed, >> perhaps on windows simply check for .exe ? Should a check exist >> to verify if file has executable permissions ?"File.canExecute". >> >> 171 // Returns true if the file is not a tool. >> 172 static boolean notATool(String file) { >> 173 file = file.toLowerCase(); >> 174 if (file.endsWith(".dll") || >> 175 file.endsWith(".map") || >> 176 file.endsWith(".pdb") || >> 177 file.equals("server")) { // server subdir on windows. >> 178 return true; >> 179 } >> 180 return false; >> 181 } >> >> >> 3. Typo in comment >> >> 201 // Check whether 'flag' appears in 'line' as a word of itself. I must not >> >> s/I must/It must/ >> >> >> 4. There is a method to check for isEnglishLocale in TestHelper, perhaps >> use it >> to have the test bale out in non english locales as early as possible ? >> >> 5. Has this been tested on all platforms ? do you need help testing it ? >> >> Kumar >> >> >> On 11/17/2017 3:23 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> please review this change. I also filed a CSR for this: >>> http://cr.openjdk.java.net/~goetz/wr17/8189102- >> helpMessage/webrev.02/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477 >>> >>> See the webrev for a detailed description of the changes. >>> >>> If required, I'll make break-out changes to be reviewed separately. >>> >>> I had posted a RFR before, but improved the change to >>> give a more complete overview of currently supported flags >>> for the CSR: >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017- >> October/028615.html >>> Best regards, >>> Goetz. >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Fri Dec 1 15:16:47 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 1 Dec 2017 15:16:47 +0000 Subject: RFR: 8189102: All tools should support -?, -h and --help In-Reply-To: <5A216A28.3030702@oracle.com> References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> <5A1C4081.2090107@oracle.com> <5A216A28.3030702@oracle.com> Message-ID: <2ac9c1e37d8e493aa5b581d1a69862e8@sap.com> Hi Kumar, I'm already looking at the issues from your other mail. Detailed comments will follow. I'll also check and fix the new tests you report. I think we don't run the langtool tests, i.e. I know we didn't run them before the repos were merged. Obviously we should add them to our testing :) Thanks for further testing and best regards, Goetz. > -----Original Message----- > From: Kumar Srinivasan [mailto:kumar.x.srinivasan at oracle.com] > Sent: Freitag, 1. Dezember 2017 15:42 > To: Lindenmaier, Goetz > Cc: core-libs-dev at openjdk.java.net; 'compiler-dev at openjdk.java.net' > ; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR: 8189102: All tools should support -?, -h and --help > > Hi, > > Besides my private comments to you, there are 2-3 internal tests > which fail. > > Have you run all the langtools tests ? There are 4 Windows tests > that fail with langtools: > > jdk/javadoc/doclet/testHelpOption/TestHelpOption.java > jdk/javadoc/tool/CheckResourceKeys.java > jdk/javadoc/tool/ToolProviderTest.java > tools/javap/InvalidOptions.java > tools/jdeps/MultiReleaseJar.java > > This changeset needs to be vetted thoroughly using internal build and test > systems. > Any Oracle engineer willing to sponsor this ? > > Kumar > > > On 11/28/2017 3:16 AM, Lindenmaier, Goetz wrote: > > > Hi, > > I uploaded a new webrev: > http://cr.openjdk.java.net/~goetz/wr17/8189102- > helpMessage/webrev.04/ > > This includes the changes > - to jshell requested by Robert > - to the test as requested by Kumar. > > See also incremental patch and the test output including all the > help messages referenced in the webrev. > > Best regards, > Goetz. > > > -----Original Message----- > From: Kumar Srinivasan > [mailto:kumar.x.srinivasan at oracle.com] > Sent: Montag, 27. November 2017 17:43 > To: Lindenmaier, Goetz > > Cc: core-libs-dev at openjdk.java.net dev at openjdk.java.net> ; 'compiler-dev at openjdk.java.net > ' > dev at openjdk.java.net> ; serviceability-dev (serviceability- > dev at openjdk.java.net ) > dev at openjdk.java.net> > Subject: Re: RFR: 8189102: All tools should support -?, -h and - > -help > > Hi, > > I looked at some of the components I maintain, and they look > good. > > Wrt. the test: > > 1. The local variables/fields don't comply with the coding > conventions, > we have been > following in the JDK. > > 2. Hmm, someone parked a .ini file in bin directory, later > removed, > perhaps on windows simply check for .exe ? Should a > check exist > to verify if file has executable permissions > ?"File.canExecute". > > 171 // Returns true if the file is not a tool. > 172 static boolean notATool(String file) { > 173 file = file.toLowerCase(); > 174 if (file.endsWith(".dll") || > 175 file.endsWith(".map") || > 176 file.endsWith(".pdb") || > 177 file.equals("server")) { // server subdir on > windows. > 178 return true; > 179 } > 180 return false; > 181 } > > > 3. Typo in comment > > 201 // Check whether 'flag' appears in 'line' as a word of > itself. I must not > > s/I must/It must/ > > > 4. There is a method to check for isEnglishLocale in > TestHelper, perhaps > use it > to have the test bale out in non english locales as early as > possible ? > > 5. Has this been tested on all platforms ? do you need help > testing it ? > > Kumar > > > On 11/17/2017 3:23 AM, Lindenmaier, Goetz wrote: > > Hi, > > please review this change. I also filed a CSR for this: > http://cr.openjdk.java.net/~goetz/wr17/8189102- > > helpMessage/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK- > 8189102 > CSR: https://bugs.openjdk.java.net/browse/JDK- > 8191477 > > See the webrev for a detailed description of the > changes. > > If required, I'll make break-out changes to be > reviewed separately. > > I had posted a RFR before, but improved the change > to > give a more complete overview of currently > supported flags > for the CSR: > http://mail.openjdk.java.net/pipermail/hotspot- > dev/2017- > > October/028615.html > > > Best regards, > Goetz. > > > > From sharath.ballal at oracle.com Fri Dec 1 16:22:14 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Fri, 1 Dec 2017 08:22:14 -0800 (PST) Subject: RFR: 8192897: NPE occurs on clhsdb jstack In-Reply-To: References: Message-ID: Hi Yasumasa, I tried jhsdb with a simple HelloWorld (with -Xcomp) and did not see any exception. Your app does anything else ? Thanks, Sharath -----Original Message----- From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] Sent: Friday, December 01, 2017 7:26 PM To: serviceability-dev at openjdk.java.net Subject: RFR: 8192897: NPE occurs on clhsdb jstack Hi all, I saw NPE when I run jstack on clhsdb as below: ---------------- hsdb> jstack Deadlock Detection: No deadlocks found. "NonBlockingInputStreamThread" #27 daemon prio=5 tid=0x00007f0924674000 nid=0xf429 in Object.wait() [0x00007f08cf6fd000] java.lang.Thread.State: WAITING (on object monitor) JavaThread state: _thread_blocked - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise) - waiting on Error occurred during stack walking: java.lang.NullPointerException at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getMonitors(CompiledVFrame.java:131) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(JavaVFrame.java:125) at jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:114) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$26.doit(CommandProcessor.java:1073) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1964) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1934) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1814) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:191) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:439) ---------------- It is caused by CompiledVFrame#getScope() returns null. We should consider it at CompiledVFrame#getMonitors(). I uploaded a webrev. Could you review it? I checked this change with hotspot/jtreg/serviceability/sa on Linux x64. http://cr.openjdk.java.net/~ysuenaga/JDK-8192897/webrev.00/ We can reproduce this issue when we run the app with -Xcomp option. So I changed ClhsdbJstack.java to run with it. I cannot access mach5 and JPRT. So I need sponsor. Thanks, Yasumasa From serguei.spitsyn at oracle.com Fri Dec 1 20:51:53 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 1 Dec 2017 12:51:53 -0800 Subject: RFR: JDK-8192823 - Testcase for 'clhsdb source' command In-Reply-To: <7d4d5a50-bca7-4ef7-968e-9da1fded1549@default> References: <198096a0-bebb-4bae-a519-a9ae0006c0ee@default> <6612c379-1c40-c521-a1d8-68e2be12cb7e@oracle.com> <9cd19516-fde9-4ce6-b830-a93b49741d56@default> <7d4d5a50-bca7-4ef7-968e-9da1fded1549@default> Message-ID: <0b887ec7-3ccf-232f-de1a-07e8173cd1a6@oracle.com> Hi Sharath, It looks good. Sorry if I'm late. Thanks, Serguei On 12/1/17 03:33, Sharath Ballal wrote: > Can I have one more review please ? > > Thanks, > Sharath > > > -----Original Message----- > From: Sharath Ballal > Sent: Friday, December 01, 2017 4:21 PM > To: Jini Susan George; serviceability-dev at openjdk.java.net > Subject: RE: RFR: JDK-8192823 - Testcase for 'clhsdb source' command > > Hi Jini, > Thanks for the review. > I have done the changes. I have left the file undeleted when there is a failure. > Update webrev is http://cr.openjdk.java.net/~sballal/8192823/webrev.01/ > > Earlier the test has passed in JPRT and mach5. I will run them again now. > > Thanks, > Sharath > > > -----Original Message----- > From: Jini George > Sent: Friday, December 01, 2017 3:29 PM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8192823 - Testcase for 'clhsdb source' command > > Hi Sharath, > > I feel it would be good to have at least 2 commands in the commands source file. And it would be good to delete the commands source file once the test has run and passed. > > Other than these, it looks good to me. > > Thanks, > Jini (Not a Reviewer). > > On 12/1/2017 12:23 PM, Sharath Ballal wrote: >> Hello, >> >> Pls review changes for the following issue: >> >> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8192823 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8192823/webrev.00/ >> >> Thanks, >> >> Sharath >> From yasuenag at gmail.com Fri Dec 1 22:49:13 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 2 Dec 2017 07:49:13 +0900 Subject: RFR: 8192897: NPE occurs on clhsdb jstack In-Reply-To: References: Message-ID: Hi Sharath, I confirmed this issue with jshell and ClhsdbJstack with this change. You need to run the VM in current jdk/hs. Thanks, Yasumasa On 2017/12/02 1:22, Sharath Ballal wrote: > Hi Yasumasa, > I tried jhsdb with a simple HelloWorld (with -Xcomp) and did not see any exception. > Your app does anything else ? > > Thanks, > Sharath > > > -----Original Message----- > From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] > Sent: Friday, December 01, 2017 7:26 PM > To: serviceability-dev at openjdk.java.net > Subject: RFR: 8192897: NPE occurs on clhsdb jstack > > Hi all, > > I saw NPE when I run jstack on clhsdb as below: > > ---------------- > hsdb> jstack > Deadlock Detection: > > No deadlocks found. > > "NonBlockingInputStreamThread" #27 daemon prio=5 tid=0x00007f0924674000 nid=0xf429 in Object.wait() [0x00007f08cf6fd000] > java.lang.Thread.State: WAITING (on object monitor) > JavaThread state: _thread_blocked > - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise) > - waiting on Error occurred during stack walking: > java.lang.NullPointerException > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getMonitors(CompiledVFrame.java:131) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(JavaVFrame.java:125) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:114) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$26.doit(CommandProcessor.java:1073) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1964) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1934) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1814) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:191) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:439) > ---------------- > > It is caused by CompiledVFrame#getScope() returns null. > We should consider it at CompiledVFrame#getMonitors(). > > I uploaded a webrev. Could you review it? > I checked this change with hotspot/jtreg/serviceability/sa on Linux x64. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8192897/webrev.00/ > > We can reproduce this issue when we run the app with -Xcomp option. > So I changed ClhsdbJstack.java to run with it. > > > I cannot access mach5 and JPRT. So I need sponsor. > > > Thanks, > > Yasumasa > From serguei.spitsyn at oracle.com Fri Dec 1 23:43:00 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 1 Dec 2017 15:43:00 -0800 Subject: RFR: 8192897: NPE occurs on clhsdb jstack In-Reply-To: References: Message-ID: <47adaefa-058a-0f48-dea5-79394f9f3e71@oracle.com> An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Fri Dec 1 23:54:13 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 2 Dec 2017 08:54:13 +0900 Subject: RFR: 8192897: NPE occurs on clhsdb jstack In-Reply-To: <47adaefa-058a-0f48-dea5-79394f9f3e71@oracle.com> References: <47adaefa-058a-0f48-dea5-79394f9f3e71@oracle.com> Message-ID: 2017/12/02 8:43 "serguei.spitsyn at oracle.com" : Hi Yasumasa, The fix looks good. Thank you for taking care about this issue. Thanks Serguei! One minor: + throw new RuntimeException("Test ERROR (with -Xcomp=" + withXcomp + ") "+ ex, ex); A space is missed before '+ ex'. No need in new webrev if you fix it. Oh, I will fix it. I'm waiting for second reviewer and sponsor. Thanks, Yasumasa Thanks, Serguei On 12/1/17 05:56, Yasumasa Suenaga wrote: Hi all, I saw NPE when I run jstack on clhsdb as below: ---------------- hsdb> jstack Deadlock Detection: No deadlocks found. "NonBlockingInputStreamThread" #27 daemon prio=5 tid=0x00007f0924674000 nid=0xf429 in Object.wait() [0x00007f08cf6fd000] java.lang.Thread.State: WAITING (on object monitor) JavaThread state: _thread_blocked - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise) - waiting on Error occurred during stack walking: java.lang.NullPointerException at jdk.hotspot.agent/sun.jvm.hotspot.runtime. CompiledVFrame.getMonitors(CompiledVFrame.java:131) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaVFrame. printLockInfo(JavaVFrame.java:125) at jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run( StackTrace.java:114) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$26. doit(CommandProcessor.java:1073) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor. executeCommand(CommandProcessor.java:1964) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor. executeCommand(CommandProcessor.java:1934) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run( CommandProcessor.java:1814) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB( SALauncher.java:191) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:439) ---------------- It is caused by CompiledVFrame#getScope() returns null. We should consider it at CompiledVFrame#getMonitors(). I uploaded a webrev. Could you review it? I checked this change with hotspot/jtreg/serviceability/sa on Linux x64. http://cr.openjdk.java.net/~ysuenaga/JDK-8192897/webrev.00/ We can reproduce this issue when we run the app with -Xcomp option. So I changed ClhsdbJstack.java to run with it. I cannot access mach5 and JPRT. So I need sponsor. Thanks, Yasumasa -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sun Dec 3 20:38:43 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Dec 2017 06:38:43 +1000 Subject: RFR: 8192897: NPE occurs on clhsdb jstack In-Reply-To: References: Message-ID: Hi Yasumasa, On 1/12/2017 11:56 PM, Yasumasa Suenaga wrote: > Hi all, > > I saw NPE when I run jstack on clhsdb as below: > > ---------------- > hsdb> jstack > Deadlock Detection: > > No deadlocks found. > > "NonBlockingInputStreamThread" #27 daemon prio=5 tid=0x00007f0924674000 > nid=0xf429 in Object.wait() [0x00007f08cf6fd000] > ?? java.lang.Thread.State: WAITING (on object monitor) > ?? JavaThread state: _thread_blocked > ?- java.lang.Object.wait(long) @bci=0 (Compiled frame; information may > be imprecise) > ??????? - waiting on > Error occurred during stack walking: > java.lang.NullPointerException > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getMonitors(CompiledVFrame.java:131) > > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(JavaVFrame.java:125) > > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:114) > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$26.doit(CommandProcessor.java:1073) > > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1964) > > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1934) > > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1814) > > ??????? at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) > ??????? at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:191) > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:439) > ---------------- > > It is caused by CompiledVFrame#getScope() returns null. > We should consider it at CompiledVFrame#getMonitors(). > > I uploaded a webrev. Could you review it? > I checked this change with hotspot/jtreg/serviceability/sa on Linux x64. > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8192897/webrev.00/ > > We can reproduce this issue when we run the app with -Xcomp option. > So I changed ClhsdbJstack.java to run with it. How long does the test take to run with Xcomp? We have to watch execution times for the tests in each tier. Thanks, David > > I cannot access mach5 and JPRT. So I need sponsor. > > > Thanks, > > Yasumasa > From yasuenag at gmail.com Mon Dec 4 00:45:22 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 4 Dec 2017 09:45:22 +0900 Subject: RFR: 8192897: NPE occurs on clhsdb jstack In-Reply-To: References: Message-ID: Hi David, I got the result of execution time as below in ClhsdbJstack.jtr: -------------- #-----testresult----- description=file\:/home/ysuenaga/OpenJDK/jdk-hs/test/hotspot/jtreg/serviceability/sa/ClhsdbJstack.java elapsed=24825 0\:00\:24.825 end=Mon Dec 04 09\:41\:41 JST 2017 -------------- Thanks, Yasumasa 2017-12-04 5:38 GMT+09:00 David Holmes : > Hi Yasumasa, > > > On 1/12/2017 11:56 PM, Yasumasa Suenaga wrote: >> >> Hi all, >> >> I saw NPE when I run jstack on clhsdb as below: >> >> ---------------- >> hsdb> jstack >> Deadlock Detection: >> >> No deadlocks found. >> >> "NonBlockingInputStreamThread" #27 daemon prio=5 tid=0x00007f0924674000 >> nid=0xf429 in Object.wait() [0x00007f08cf6fd000] >> java.lang.Thread.State: WAITING (on object monitor) >> JavaThread state: _thread_blocked >> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be >> imprecise) >> - waiting on >> Error occurred during stack walking: >> java.lang.NullPointerException >> at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getMonitors(CompiledVFrame.java:131) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(JavaVFrame.java:125) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:114) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$26.doit(CommandProcessor.java:1073) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1964) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1934) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1814) >> at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) >> at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:191) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:439) >> ---------------- >> >> It is caused by CompiledVFrame#getScope() returns null. >> We should consider it at CompiledVFrame#getMonitors(). >> >> I uploaded a webrev. Could you review it? >> I checked this change with hotspot/jtreg/serviceability/sa on Linux x64. >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8192897/webrev.00/ >> >> We can reproduce this issue when we run the app with -Xcomp option. >> So I changed ClhsdbJstack.java to run with it. > > > How long does the test take to run with Xcomp? We have to watch execution > times for the tests in each tier. > > Thanks, > David > > >> >> I cannot access mach5 and JPRT. So I need sponsor. >> >> >> Thanks, >> >> Yasumasa >> > From david.holmes at oracle.com Mon Dec 4 00:59:53 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Dec 2017 10:59:53 +1000 Subject: RFR: 8192897: NPE occurs on clhsdb jstack In-Reply-To: References: Message-ID: <45a06157-16bf-bafd-9823-93dd86ce6a99@oracle.com> On 4/12/2017 10:45 AM, Yasumasa Suenaga wrote: > Hi David, > > I got the result of execution time as below in ClhsdbJstack.jtr: > > -------------- > #-----testresult----- > description=file\:/home/ysuenaga/OpenJDK/jdk-hs/test/hotspot/jtreg/serviceability/sa/ClhsdbJstack.java > elapsed=24825 0\:00\:24.825 > end=Mon Dec 04 09\:41\:41 JST 2017 > -------------- Thanks - no issue there. David > > Thanks, > > Yasumasa > > > > 2017-12-04 5:38 GMT+09:00 David Holmes : >> Hi Yasumasa, >> >> >> On 1/12/2017 11:56 PM, Yasumasa Suenaga wrote: >>> >>> Hi all, >>> >>> I saw NPE when I run jstack on clhsdb as below: >>> >>> ---------------- >>> hsdb> jstack >>> Deadlock Detection: >>> >>> No deadlocks found. >>> >>> "NonBlockingInputStreamThread" #27 daemon prio=5 tid=0x00007f0924674000 >>> nid=0xf429 in Object.wait() [0x00007f08cf6fd000] >>> java.lang.Thread.State: WAITING (on object monitor) >>> JavaThread state: _thread_blocked >>> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be >>> imprecise) >>> - waiting on >>> Error occurred during stack walking: >>> java.lang.NullPointerException >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getMonitors(CompiledVFrame.java:131) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(JavaVFrame.java:125) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:114) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$26.doit(CommandProcessor.java:1073) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1964) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1934) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1814) >>> at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) >>> at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:191) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:439) >>> ---------------- >>> >>> It is caused by CompiledVFrame#getScope() returns null. >>> We should consider it at CompiledVFrame#getMonitors(). >>> >>> I uploaded a webrev. Could you review it? >>> I checked this change with hotspot/jtreg/serviceability/sa on Linux x64. >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8192897/webrev.00/ >>> >>> We can reproduce this issue when we run the app with -Xcomp option. >>> So I changed ClhsdbJstack.java to run with it. >> >> >> How long does the test take to run with Xcomp? We have to watch execution >> times for the tests in each tier. >> >> Thanks, >> David >> >> >>> >>> I cannot access mach5 and JPRT. So I need sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >> From david.holmes at oracle.com Mon Dec 4 01:43:01 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Dec 2017 11:43:01 +1000 Subject: RFR: 8192897: NPE occurs on clhsdb jstack In-Reply-To: <45a06157-16bf-bafd-9823-93dd86ce6a99@oracle.com> References: <45a06157-16bf-bafd-9823-93dd86ce6a99@oracle.com> Message-ID: <60d12e9d-1fb0-802c-a889-f1b421283d3c@oracle.com> Sorry forgot to clearly say: Reviewed. The fix is consistent with the other NULL checks applied to getScope(). David On 4/12/2017 10:59 AM, David Holmes wrote: > On 4/12/2017 10:45 AM, Yasumasa Suenaga wrote: >> Hi David, >> >> I got the result of execution time as below in ClhsdbJstack.jtr: >> >> -------------- >> #-----testresult----- >> description=file\:/home/ysuenaga/OpenJDK/jdk-hs/test/hotspot/jtreg/serviceability/sa/ClhsdbJstack.java >> >> elapsed=24825 0\:00\:24.825 >> end=Mon Dec 04 09\:41\:41 JST 2017 >> -------------- > > Thanks - no issue there. > > David > >> >> Thanks, >> >> Yasumasa >> >> >> >> 2017-12-04 5:38 GMT+09:00 David Holmes : >>> Hi Yasumasa, >>> >>> >>> On 1/12/2017 11:56 PM, Yasumasa Suenaga wrote: >>>> >>>> Hi all, >>>> >>>> I saw NPE when I run jstack on clhsdb as below: >>>> >>>> ---------------- >>>> hsdb> jstack >>>> Deadlock Detection: >>>> >>>> No deadlocks found. >>>> >>>> "NonBlockingInputStreamThread" #27 daemon prio=5 tid=0x00007f0924674000 >>>> nid=0xf429 in Object.wait() [0x00007f08cf6fd000] >>>> ???? java.lang.Thread.State: WAITING (on object monitor) >>>> ???? JavaThread state: _thread_blocked >>>> ?? - java.lang.Object.wait(long) @bci=0 (Compiled frame; information >>>> may be >>>> imprecise) >>>> ????????? - waiting on >>>> Error occurred during stack walking: >>>> java.lang.NullPointerException >>>> ????????? at >>>> jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getMonitors(CompiledVFrame.java:131) >>>> >>>> ????????? at >>>> jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(JavaVFrame.java:125) >>>> >>>> ????????? at >>>> jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:114) >>>> >>>> ????????? at >>>> jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$26.doit(CommandProcessor.java:1073) >>>> >>>> ????????? at >>>> jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1964) >>>> >>>> ????????? at >>>> jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1934) >>>> >>>> ????????? at >>>> jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1814) >>>> >>>> ????????? at >>>> jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) >>>> ????????? at >>>> jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) >>>> ????????? at >>>> jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:191) >>>> >>>> ????????? at >>>> jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:439) >>>> ---------------- >>>> >>>> It is caused by CompiledVFrame#getScope() returns null. >>>> We should consider it at CompiledVFrame#getMonitors(). >>>> >>>> I uploaded a webrev. Could you review it? >>>> I checked this change with hotspot/jtreg/serviceability/sa on Linux >>>> x64. >>>> >>>> ??? http://cr.openjdk.java.net/~ysuenaga/JDK-8192897/webrev.00/ >>>> >>>> We can reproduce this issue when we run the app with -Xcomp option. >>>> So I changed ClhsdbJstack.java to run with it. >>> >>> >>> How long does the test take to run with Xcomp? We have to watch >>> execution >>> times for the tests in each tier. >>> >>> Thanks, >>> David >>> >>> >>>> >>>> I cannot access mach5 and JPRT. So I need sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>> From jini.george at oracle.com Mon Dec 4 09:00:57 2017 From: jini.george at oracle.com (Jini George) Date: Mon, 4 Dec 2017 14:30:57 +0530 Subject: RFR: 8192897: NPE occurs on clhsdb jstack In-Reply-To: References: Message-ID: <82dbd0b4-42a7-94b1-72fd-291b67a4fcdd@oracle.com> Hi Yasumasa, Thanks for this. Looks good. Thanks, Jini. (Not a Reviewer). On 12/1/2017 7:26 PM, Yasumasa Suenaga wrote: > Hi all, > > I saw NPE when I run jstack on clhsdb as below: > > ---------------- > hsdb> jstack > Deadlock Detection: > > No deadlocks found. > > "NonBlockingInputStreamThread" #27 daemon prio=5 tid=0x00007f0924674000 > nid=0xf429 in Object.wait() [0x00007f08cf6fd000] > ?? java.lang.Thread.State: WAITING (on object monitor) > ?? JavaThread state: _thread_blocked > ?- java.lang.Object.wait(long) @bci=0 (Compiled frame; information may > be imprecise) > ??????? - waiting on > Error occurred during stack walking: > java.lang.NullPointerException > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getMonitors(CompiledVFrame.java:131) > > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(JavaVFrame.java:125) > > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:114) > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$26.doit(CommandProcessor.java:1073) > > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1964) > > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1934) > > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1814) > > ??????? at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) > ??????? at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:191) > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:439) > ---------------- > > It is caused by CompiledVFrame#getScope() returns null. > We should consider it at CompiledVFrame#getMonitors(). > > I uploaded a webrev. Could you review it? > I checked this change with hotspot/jtreg/serviceability/sa on Linux x64. > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8192897/webrev.00/ > > We can reproduce this issue when we run the app with -Xcomp option. > So I changed ClhsdbJstack.java to run with it. > > > I cannot access mach5 and JPRT. So I need sponsor. > > > Thanks, > > Yasumasa > From christoph.langer at sap.com Mon Dec 4 15:44:39 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 4 Dec 2017 15:44:39 +0000 Subject: RFR(S): 8192978: Missing checks and small fixes in jdwp library Message-ID: Hi, I'd like to contribute a few fixes that have been done in our JDK builds that add a few additional checks and cleanups. Can I please get a review. Bug: https://bugs.openjdk.java.net/browse/JDK-8192978 WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8192978.0/ Thanks, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Mon Dec 4 17:37:49 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 4 Dec 2017 09:37:49 -0800 (PST) Subject: RFR: 8192897: NPE occurs on clhsdb jstack In-Reply-To: References: Message-ID: Fix looks good Yasumasa. Thanks, Sharath (Not a Reviewer) -----Original Message----- From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] Sent: Saturday, December 02, 2017 4:19 AM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: 8192897: NPE occurs on clhsdb jstack Hi Sharath, I confirmed this issue with jshell and ClhsdbJstack with this change. You need to run the VM in current jdk/hs. Thanks, Yasumasa On 2017/12/02 1:22, Sharath Ballal wrote: > Hi Yasumasa, > I tried jhsdb with a simple HelloWorld (with -Xcomp) and did not see any exception. > Your app does anything else ? > > Thanks, > Sharath > > > -----Original Message----- > From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] > Sent: Friday, December 01, 2017 7:26 PM > To: serviceability-dev at openjdk.java.net > Subject: RFR: 8192897: NPE occurs on clhsdb jstack > > Hi all, > > I saw NPE when I run jstack on clhsdb as below: > > ---------------- > hsdb> jstack > Deadlock Detection: > > No deadlocks found. > > "NonBlockingInputStreamThread" #27 daemon prio=5 tid=0x00007f0924674000 nid=0xf429 in Object.wait() [0x00007f08cf6fd000] > java.lang.Thread.State: WAITING (on object monitor) > JavaThread state: _thread_blocked > - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise) > - waiting on Error occurred during stack walking: > java.lang.NullPointerException > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getMonitors(CompiledVFrame.java:131) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(JavaVFrame.java:125) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:114) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$26.doit(CommandProcessor.java:1073) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1964) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1934) > at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1814) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:191) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:439) > ---------------- > > It is caused by CompiledVFrame#getScope() returns null. > We should consider it at CompiledVFrame#getMonitors(). > > I uploaded a webrev. Could you review it? > I checked this change with hotspot/jtreg/serviceability/sa on Linux x64. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8192897/webrev.00/ > > We can reproduce this issue when we run the app with -Xcomp option. > So I changed ClhsdbJstack.java to run with it. > > > I cannot access mach5 and JPRT. So I need sponsor. > > > Thanks, > > Yasumasa > From harsha.wardhana.b at oracle.com Mon Dec 4 18:27:38 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 4 Dec 2017 23:57:38 +0530 Subject: [TestBug] RFR : JDK-8192909 - Invalid username or password in HashedPasswordFileTest.java Message-ID: <74e92cde-fef5-8f7f-d58c-4d1019aa8eb3@oracle.com> Hi All, Please review and provide comments for fix for, issue: https://bugs.openjdk.java.net/browse/JDK-8192909 having webrev at, webrev : http://cr.openjdk.java.net/~hb/8192909/webrev.00/ Fix details: The test was failing intermittently because of duplicate entries for role in input password file. The duplicate entries get over-written by JMX agent, but the client was testing with stale entries for duplicated role. Also, the test now uses a single random number generator from test package (Utils.getRandomInstance) instead of two. Regards Harsha From chris.plummer at oracle.com Mon Dec 4 21:32:17 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 4 Dec 2017 13:32:17 -0800 Subject: RFR(S): 8192978: Missing checks and small fixes in jdwp library In-Reply-To: References: Message-ID: <2ebd9977-2f0f-ebc1-99fd-14b5ce3c3c16@oracle.com> An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Tue Dec 5 05:59:00 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 5 Dec 2017 05:59:00 +0000 Subject: [TestBug] RFR : JDK-8192909 - Invalid username or password in HashedPasswordFileTest.java In-Reply-To: <74e92cde-fef5-8f7f-d58c-4d1019aa8eb3@oracle.com> References: <74e92cde-fef5-8f7f-d58c-4d1019aa8eb3@oracle.com> Message-ID: <1261295ea35f465da121e44b7ece3ea4@sap.com> Hi Harsha, this looks good to me. Small finding: Line 366, there could be a space between if and (. Best regards Christoph > -----Original Message----- > From: serviceability-dev [mailto:serviceability-dev- > bounces at openjdk.java.net] On Behalf Of Harsha Wardhana B > Sent: Montag, 4. Dezember 2017 19:28 > To: serviceability-dev at openjdk.java.net > Subject: [TestBug] RFR : JDK-8192909 - Invalid username or password in > HashedPasswordFileTest.java > > Hi All, > > Please review and provide comments for fix for, > > issue: https://bugs.openjdk.java.net/browse/JDK-8192909 > > having webrev at, > > webrev : http://cr.openjdk.java.net/~hb/8192909/webrev.00/ > > Fix details: The test was failing intermittently because of duplicate > entries for role in input password file. The duplicate entries get > over-written by JMX agent, but the client was testing with stale entries > for duplicated role. Also, the test now uses a single random number > generator from test package (Utils.getRandomInstance) instead of two. > > Regards > > Harsha From harsha.wardhana.b at oracle.com Tue Dec 5 07:04:47 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 5 Dec 2017 12:34:47 +0530 Subject: [TestBug] RFR : JDK-8192909 - Invalid username or password in HashedPasswordFileTest.java In-Reply-To: <1261295ea35f465da121e44b7ece3ea4@sap.com> References: <74e92cde-fef5-8f7f-d58c-4d1019aa8eb3@oracle.com> <1261295ea35f465da121e44b7ece3ea4@sap.com> Message-ID: <26fca7fc-d9dc-3d80-9b83-7929a360d3d4@oracle.com> Thanks Christoph for the review. Can I get one more review please? -Harsha On Tuesday 05 December 2017 11:29 AM, Langer, Christoph wrote: > Hi Harsha, > > this looks good to me. > > Small finding: Line 366, there could be a space between if and (. > > Best regards > Christoph > >> -----Original Message----- >> From: serviceability-dev [mailto:serviceability-dev- >> bounces at openjdk.java.net] On Behalf Of Harsha Wardhana B >> Sent: Montag, 4. Dezember 2017 19:28 >> To: serviceability-dev at openjdk.java.net >> Subject: [TestBug] RFR : JDK-8192909 - Invalid username or password in >> HashedPasswordFileTest.java >> >> Hi All, >> >> Please review and provide comments for fix for, >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8192909 >> >> having webrev at, >> >> webrev : http://cr.openjdk.java.net/~hb/8192909/webrev.00/ >> >> Fix details: The test was failing intermittently because of duplicate >> entries for role in input password file. The duplicate entries get >> over-written by JMX agent, but the client was testing with stale entries >> for duplicated role. Also, the test now uses a single random number >> generator from test package (Utils.getRandomInstance) instead of two. >> >> Regards >> >> Harsha From daniel.fuchs at oracle.com Tue Dec 5 10:12:37 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 5 Dec 2017 10:12:37 +0000 Subject: [TestBug] RFR : JDK-8192909 - Invalid username or password in HashedPasswordFileTest.java In-Reply-To: <74e92cde-fef5-8f7f-d58c-4d1019aa8eb3@oracle.com> References: <74e92cde-fef5-8f7f-d58c-4d1019aa8eb3@oracle.com> Message-ID: <4fbda94a-0817-45fc-5b29-8e4a6227c666@oracle.com> Hi Harsha, Looks good. nit: 366 if(random.nextBoolean()) { 367 String[] tokens = line.split("\\s+"); 368 if ((tokens.length == 4 || tokens.length == 3)) { inverting the two if () (testing for the applicability of the line first) would probably give a better chance that an existing password is replaced, unless most lines are applicable. best regards, -- daniel n 04/12/2017 18:27, Harsha Wardhana B wrote: > Hi All, > > Please review and provide comments for fix for, > > issue: https://bugs.openjdk.java.net/browse/JDK-8192909 > > having webrev at, > > webrev : http://cr.openjdk.java.net/~hb/8192909/webrev.00/ > > Fix details: The test was failing intermittently because of duplicate > entries for role in input password file. The duplicate entries get > over-written by JMX agent, but the client was testing with stale entries > for duplicated role. Also, the test now uses a single random number > generator from test package (Utils.getRandomInstance) instead of two. > > Regards > > Harsha > From christoph.langer at sap.com Tue Dec 5 10:52:01 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 5 Dec 2017 10:52:01 +0000 Subject: RFR(S): 8192978: Missing checks and small fixes in jdwp library In-Reply-To: <2ebd9977-2f0f-ebc1-99fd-14b5ce3c3c16@oracle.com> References: <2ebd9977-2f0f-ebc1-99fd-14b5ce3c3c16@oracle.com> Message-ID: <9ee1eeae24f847c9918f4777be2fb271@sap.com> Hi Chris, thanks for looking at this. The main part of the changes are the findings of a code scan tool (coverity). Here are some detailed comments. I also made a small update to the webrev (concerning eventHelper.c): http://cr.openjdk.java.net/~clanger/webrevs/8192978.1/. > shmemBase.c: seems correct, but could use explanation/example of when existing code was failing. This is a coverity finding. The correct size specification as per Microsoft?s doc [1] for jlong (__int64) would be I64. VirtualMachineImpl.c: When/why is pos ever null? This is also a coverity case. For some reason, coverity thinks that pos could be NULL here. But I?m with you ? I also don?t see a path how that could ever happen. Nevertheless, this change would please converity and I don?t see it being performance critical so I would like to leave it. It?s also not wrong. error_messages.c: Is there any reason not to do this fix for all platforms? Do you have a test case for it? This is a Windows only issue. ?vsnprintf? would write the terminating 0. But in jdk.jdwp.agent/windows/native/libjdwp/util_md.h, vsnprintf is redefined to _vsnprintf. And this, by the Mircrosoft documentation [2], doesn?t necessarily write the terminating character. error_messages.h: ok. looks like just whitespace cleanup yes eventHelper.c: Do you have a testcase? Also, is the "bagAdd(eventBag)" message going to be of use to the user? For this one I don?t have the history. Maybe it was also the coverity tool. But there is no testcase. In my update I have updated 2 other places with the null check where bagAdd is called. I guess in case of such a null error occurring, it could help a little. But probably this would be something to be investigated by the developer rather than the debugging user. inStream.c: inStream_init() now uses a magic number of 11. What does it represent? inStream_endOfInput() looks like it used to be completely broken. How was this not noticed? Is this related to the change inStream_init(), which possible was masking this error? Is there a test case for it? I found this fix in our code base. instream_endOfInput() is obviously never used. At least I don?t find any references in the source code scan. Maybe I shall completely remove it? As for the ?magic number of 11?: This is the offset to the payload of a jdwpCmdPacket, see jdk.jdwp.agent/share/native/include/ jdwpTransport.h. (sizeof(jint) /* len*/ + sizeof(jint) /* id */ + sizeof(jbyte) /* flags*/ + sizeof(jbyte) /* cmdSet */ + sizeof(jbyte) /*cmd */ Maybe I should write it down explicitly? With that offset subtracted from the length field, we initialize stream->left with the correct value which makes the checks in readBytes (line 73) more correct. But there is also no test case invoker.c: ok: looks like just whitespace cleanup Yes. log_messages.c: is there any reason not to do this fix for all platforms? Do you have a test case for it? Same goes as for error_messages.c. I?m still hoping to get this change done under the hood of JDK-8192978. I will update the bug with some more details and also add an appropriate noreg label. Best regards, Christoph [1] https://msdn.microsoft.com/en-us/library/tcxf1dw6.aspx [2] https://msdn.microsoft.com/en-us/library/1kt27hek.aspx From: Chris Plummer [mailto:chris.plummer at oracle.com] Sent: Montag, 4. Dezember 2017 22:32 To: Langer, Christoph ; serviceability-dev at openjdk.java.net Subject: Re: RFR(S): 8192978: Missing checks and small fixes in jdwp library Hi Christoph, Some of your changes could use explanations. Can you please elaborate on the problems you are fixing in the CR? Test cases, or at least explaining how to reproduce the issues you are fixing would also be useful. shmemBase.c: seems correct, but could use explanation/example of when existing code was failing. VirtualMachineImpl.c: When/why is pos ever null? error_messages.c: Is there any reason not to do this fix for all platforms? Do you have a test case for it? error_messages.h: ok. looks like just whitespace cleanup eventHelper.c: Do you have a testcase? Also, is the "bagAdd(eventBag)" message going to be of use to the user? inStream.c: inStream_init() now uses a magic number of 11. What does it represent? inStream_endOfInput() looks like it used to be completely broken. How was this not noticed? Is this related to the change inStream_init(), which possible was masking this error? Is there a test case for it? invoker.c: ok: looks like just whitespace cleanup log_messages.c: is there any reason not to do this fix for all platforms? Do you have a test case for it? I think you will need to file separate CRs for each issue. You can lump the whitespace cleanup into one. The rest probably should each be seaprate CRs, but I could see possibly doing just one CR for them if the CR documented each problem being fixed. thanks, Chris On 12/4/17 7:44 AM, Langer, Christoph wrote: Hi, I?d like to contribute a few fixes that have been done in our JDK builds that add a few additional checks and cleanups. Can I please get a review. Bug: https://bugs.openjdk.java.net/browse/JDK-8192978 WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8192978.0/ Thanks, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Tue Dec 5 12:04:41 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 5 Dec 2017 17:34:41 +0530 Subject: [TestBug] RFR : JDK-8192909 - Invalid username or password in HashedPasswordFileTest.java In-Reply-To: <4fbda94a-0817-45fc-5b29-8e4a6227c666@oracle.com> References: <74e92cde-fef5-8f7f-d58c-4d1019aa8eb3@oracle.com> <4fbda94a-0817-45fc-5b29-8e4a6227c666@oracle.com> Message-ID: Hi Daniel, On Tuesday 05 December 2017 03:42 PM, Daniel Fuchs wrote: > Hi Harsha, > > Looks good. Thanks for the review. > > nit: > > ?366???????????????? if(random.nextBoolean()) { > ?367???????????????????? String[] tokens = line.split("\\s+"); > ?368???????????????????? if ((tokens.length == 4 || tokens.length == > 3)) { > > inverting the two if () (testing for the applicability of the line > first) would probably give a better chance that an existing > password is replaced, unless most lines are applicable. All the lines will be applicable. The password file will be hashed before the above lines are executed. An Assert statement at line 353 makes sure of that. Hence no point inverting the two if(). > > best regards, > > -- daniel Regards Harsha > > n 04/12/2017 18:27, Harsha Wardhana B wrote: >> Hi All, >> >> Please review and provide comments for fix for, >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8192909 >> >> having webrev at, >> >> webrev : http://cr.openjdk.java.net/~hb/8192909/webrev.00/ >> >> Fix details: The test was failing intermittently because of duplicate >> entries for role in input password file. The duplicate entries get >> over-written by JMX agent, but the client was testing with stale >> entries for duplicated role. Also, the test now uses a single random >> number generator from test package (Utils.getRandomInstance) instead >> of two. >> >> Regards >> >> Harsha >> > From goetz.lindenmaier at sap.com Tue Dec 5 13:08:15 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 5 Dec 2017 13:08:15 +0000 Subject: RFR(S): 8192978: Missing checks and small fixes in jdwp library In-Reply-To: <9ee1eeae24f847c9918f4777be2fb271@sap.com> References: <2ebd9977-2f0f-ebc1-99fd-14b5ce3c3c16@oracle.com> <9ee1eeae24f847c9918f4777be2fb271@sap.com> Message-ID: <024423b22c484d24a757e64313e8b5ff@sap.com> Hi Christoph, thanks for doing this change. I would appreciate if the coverity findings get into the codebase, at minimum it simplifies repeated runs. I?m not sure about the syntax cleanups, especially invoker.c, this seems too trivial to touch the file. Thanks for explaining inStream.c, I think it would help documenting the number or computing it explicitly as you propose. Best regards, Goetz. From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Langer, Christoph Sent: Dienstag, 5. Dezember 2017 11:52 To: Chris Plummer ; serviceability-dev at openjdk.java.net Subject: RE: RFR(S): 8192978: Missing checks and small fixes in jdwp library Hi Chris, thanks for looking at this. The main part of the changes are the findings of a code scan tool (coverity). Here are some detailed comments. I also made a small update to the webrev (concerning eventHelper.c): http://cr.openjdk.java.net/~clanger/webrevs/8192978.1/. > shmemBase.c: seems correct, but could use explanation/example of when existing code was failing. This is a coverity finding. The correct size specification as per Microsoft?s doc [1] for jlong (__int64) would be I64. VirtualMachineImpl.c: When/why is pos ever null? This is also a coverity case. For some reason, coverity thinks that pos could be NULL here. But I?m with you ? I also don?t see a path how that could ever happen. Nevertheless, this change would please converity and I don?t see it being performance critical so I would like to leave it. It?s also not wrong. error_messages.c: Is there any reason not to do this fix for all platforms? Do you have a test case for it? This is a Windows only issue. ?vsnprintf? would write the terminating 0. But in jdk.jdwp.agent/windows/native/libjdwp/util_md.h, vsnprintf is redefined to _vsnprintf. And this, by the Mircrosoft documentation [2], doesn?t necessarily write the terminating character. error_messages.h: ok. looks like just whitespace cleanup yes eventHelper.c: Do you have a testcase? Also, is the "bagAdd(eventBag)" message going to be of use to the user? For this one I don?t have the history. Maybe it was also the coverity tool. But there is no testcase. In my update I have updated 2 other places with the null check where bagAdd is called. I guess in case of such a null error occurring, it could help a little. But probably this would be something to be investigated by the developer rather than the debugging user. inStream.c: inStream_init() now uses a magic number of 11. What does it represent? inStream_endOfInput() looks like it used to be completely broken. How was this not noticed? Is this related to the change inStream_init(), which possible was masking this error? Is there a test case for it? I found this fix in our code base. instream_endOfInput() is obviously never used. At least I don?t find any references in the source code scan. Maybe I shall completely remove it? As for the ?magic number of 11?: This is the offset to the payload of a jdwpCmdPacket, see jdk.jdwp.agent/share/native/include/ jdwpTransport.h. (sizeof(jint) /* len*/ + sizeof(jint) /* id */ + sizeof(jbyte) /* flags*/ + sizeof(jbyte) /* cmdSet */ + sizeof(jbyte) /*cmd */ Maybe I should write it down explicitly? With that offset subtracted from the length field, we initialize stream->left with the correct value which makes the checks in readBytes (line 73) more correct. But there is also no test case invoker.c: ok: looks like just whitespace cleanup Yes. log_messages.c: is there any reason not to do this fix for all platforms? Do you have a test case for it? Same goes as for error_messages.c. I?m still hoping to get this change done under the hood of JDK-8192978. I will update the bug with some more details and also add an appropriate noreg label. Best regards, Christoph [1] https://msdn.microsoft.com/en-us/library/tcxf1dw6.aspx [2] https://msdn.microsoft.com/en-us/library/1kt27hek.aspx From: Chris Plummer [mailto:chris.plummer at oracle.com] Sent: Montag, 4. Dezember 2017 22:32 To: Langer, Christoph >; serviceability-dev at openjdk.java.net Subject: Re: RFR(S): 8192978: Missing checks and small fixes in jdwp library Hi Christoph, Some of your changes could use explanations. Can you please elaborate on the problems you are fixing in the CR? Test cases, or at least explaining how to reproduce the issues you are fixing would also be useful. shmemBase.c: seems correct, but could use explanation/example of when existing code was failing. VirtualMachineImpl.c: When/why is pos ever null? error_messages.c: Is there any reason not to do this fix for all platforms? Do you have a test case for it? error_messages.h: ok. looks like just whitespace cleanup eventHelper.c: Do you have a testcase? Also, is the "bagAdd(eventBag)" message going to be of use to the user? inStream.c: inStream_init() now uses a magic number of 11. What does it represent? inStream_endOfInput() looks like it used to be completely broken. How was this not noticed? Is this related to the change inStream_init(), which possible was masking this error? Is there a test case for it? invoker.c: ok: looks like just whitespace cleanup log_messages.c: is there any reason not to do this fix for all platforms? Do you have a test case for it? I think you will need to file separate CRs for each issue. You can lump the whitespace cleanup into one. The rest probably should each be seaprate CRs, but I could see possibly doing just one CR for them if the CR documented each problem being fixed. thanks, Chris On 12/4/17 7:44 AM, Langer, Christoph wrote: Hi, I?d like to contribute a few fixes that have been done in our JDK builds that add a few additional checks and cleanups. Can I please get a review. Bug: https://bugs.openjdk.java.net/browse/JDK-8192978 WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8192978.0/ Thanks, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Tue Dec 5 14:41:55 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 5 Dec 2017 14:41:55 +0000 Subject: [TestBug] RFR : JDK-8192909 - Invalid username or password in HashedPasswordFileTest.java In-Reply-To: References: <74e92cde-fef5-8f7f-d58c-4d1019aa8eb3@oracle.com> <4fbda94a-0817-45fc-5b29-8e4a6227c666@oracle.com> Message-ID: +1 -- daniel On 05/12/2017 12:04, Harsha Wardhana B wrote: > Hi Daniel, > > > On Tuesday 05 December 2017 03:42 PM, Daniel Fuchs wrote: >> Hi Harsha, >> >> Looks good. > Thanks for the review. >> >> nit: >> >> ?366???????????????? if(random.nextBoolean()) { >> ?367???????????????????? String[] tokens = line.split("\\s+"); >> ?368???????????????????? if ((tokens.length == 4 || tokens.length == >> 3)) { >> >> inverting the two if () (testing for the applicability of the line >> first) would probably give a better chance that an existing >> password is replaced, unless most lines are applicable. > All the lines will be applicable. The password file will be hashed > before the above lines are executed. An Assert statement at line 353 > makes sure of that. Hence no point inverting the two if(). >> >> best regards, >> >> -- daniel > Regards > Harsha >> >> n 04/12/2017 18:27, Harsha Wardhana B wrote: >>> Hi All, >>> >>> Please review and provide comments for fix for, >>> >>> issue: https://bugs.openjdk.java.net/browse/JDK-8192909 >>> >>> having webrev at, >>> >>> webrev : http://cr.openjdk.java.net/~hb/8192909/webrev.00/ >>> >>> Fix details: The test was failing intermittently because of duplicate >>> entries for role in input password file. The duplicate entries get >>> over-written by JMX agent, but the client was testing with stale >>> entries for duplicated role. Also, the test now uses a single random >>> number generator from test package (Utils.getRandomInstance) instead >>> of two. >>> >>> Regards >>> >>> Harsha >>> >> > From harsha.wardhana.b at oracle.com Tue Dec 5 16:15:27 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 5 Dec 2017 21:45:27 +0530 Subject: [TestBug] RFR : JDK-8192909 - Invalid username or password in HashedPasswordFileTest.java In-Reply-To: References: <74e92cde-fef5-8f7f-d58c-4d1019aa8eb3@oracle.com> <4fbda94a-0817-45fc-5b29-8e4a6227c666@oracle.com> Message-ID: Thanks Daniel and Christoph for review. -Harsha On Tuesday 05 December 2017 08:11 PM, Daniel Fuchs wrote: > +1 > > -- daniel > > On 05/12/2017 12:04, Harsha Wardhana B wrote: >> Hi Daniel, >> >> >> On Tuesday 05 December 2017 03:42 PM, Daniel Fuchs wrote: >>> Hi Harsha, >>> >>> Looks good. >> Thanks for the review. >>> >>> nit: >>> >>> ?366???????????????? if(random.nextBoolean()) { >>> ?367???????????????????? String[] tokens = line.split("\\s+"); >>> ?368???????????????????? if ((tokens.length == 4 || tokens.length == >>> 3)) { >>> >>> inverting the two if () (testing for the applicability of the line >>> first) would probably give a better chance that an existing >>> password is replaced, unless most lines are applicable. >> All the lines will be applicable. The password file will be hashed >> before the above lines are executed. An Assert statement at line 353 >> makes sure of that. Hence no point inverting the two if(). >>> >>> best regards, >>> >>> -- daniel >> Regards >> Harsha >>> >>> n 04/12/2017 18:27, Harsha Wardhana B wrote: >>>> Hi All, >>>> >>>> Please review and provide comments for fix for, >>>> >>>> issue: https://bugs.openjdk.java.net/browse/JDK-8192909 >>>> >>>> having webrev at, >>>> >>>> webrev : http://cr.openjdk.java.net/~hb/8192909/webrev.00/ >>>> >>>> Fix details: The test was failing intermittently because of >>>> duplicate entries for role in input password file. The duplicate >>>> entries get over-written by JMX agent, but the client was testing >>>> with stale entries for duplicated role. Also, the test now uses a >>>> single random number generator from test package >>>> (Utils.getRandomInstance) instead of two. >>>> >>>> Regards >>>> >>>> Harsha >>>> >>> >> > From chris.plummer at oracle.com Tue Dec 5 23:03:15 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 5 Dec 2017 15:03:15 -0800 Subject: RFR(S): 8192978: Missing checks and small fixes in jdwp library In-Reply-To: <9ee1eeae24f847c9918f4777be2fb271@sap.com> References: <2ebd9977-2f0f-ebc1-99fd-14b5ce3c3c16@oracle.com> <9ee1eeae24f847c9918f4777be2fb271@sap.com> Message-ID: <7b6699b2-6105-9f0c-19ed-21b2d9a694b6@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Dec 6 06:33:59 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Dec 2017 16:33:59 +1000 Subject: Unified JVM Logging and diagnostic options LogVMOutput, LogFile, DisplayVMOutput In-Reply-To: References: <92addaa5-e735-db64-0e7a-afe8f5f6c2d4@oracle.com> Message-ID: <19afa6c9-0f35-e108-7027-3d7974c89300@oracle.com> On 1/12/2017 11:15 AM, Man Cao wrote: > Thanks David for the quick response! > > Yes, I understand completely removing defaultStream and tty is probably > infeasible. > > If deprecating the diagnostic options (LogVMOutput, LogFile, > DisplayVMOutput) is the intent, could someone create a bug/RFE to track > it? They should probably first be added to the special_jvm_flags table I think there is too much yet to be done in the conversion process to file such a RFE - to be frank we don't have active RFE's for the remaining conversions, rather they are being tackled case by case when people are working in the area. > in arguments.cpp, so there will be a warning when people use them. The > case of conflicting -Xlog::file=test.log and -XX:LogFile=test.log is > also a concern, the JVM should at least issue a warning about it. In > addition, it would make it easier for us to convince production teams to > stop using these options. I have filed: https://bugs.openjdk.java.net/browse/JDK-8193117 JDK-8193117 Issue a warning if legacy logging and Unified Logging are told to use the same file Cheers, David ----- > Thanks, > Man > > On Thu, Nov 30, 2017 at 4:48 PM, David Holmes > wrote: > > Hi Man, > > Adding serviceability as UL is a serviceability feature. > > > On 1/12/2017 10:23 AM, Man Cao wrote: > > Hello, > > We (Java Platform Team at Google) found that in JDK9, the file > generated by > -XX:+LogVMOutput no longer contains GC log messages, because the > unified > JVM logging framework does not use the defaultStream and > fileStream classes > and the tty variable. Similarly, related options such as LogFile, > DisplayVMOutput have no effect on the messages printed by the > unified > logging framework. > > The main problem for us is that most of our production Java > servers use the > options "-XX:+LogVMOutput -XX:-DisplayVMOutput", to save the GC > logs and > other VM messages. These flags would no longer work for JDK9's > JVM logging > framework. In addition, the file generated by -XX:+LogVMOutput > may contain > information that is not printed by the unified logging framework. > > What is worse is that if LogFile and the output of unified logging > framework point to the same file, the file may contain partial > or corrupted > messages from the unified logging framework. For example, > consider the > following command: > > java -Xlog::file=test.log -XX:+UnlockDiagnosticVMOptions > -XX:+LogVMOutput > -XX:LogFile=test.log > > Then test.log would miss some of the messages that would be > printed at the > beginning if you run "java -Xlog". > > So our questions are: > 1. Do you consider this is a bug for the unified logging > framework that > should be fixed? Should the unified logging framework respect these > diagnostic options? > > > My understanding is that UL is intended to replace the legacy > "logging" flags and works independently of them. So no, UL should > not respect these flags. > > 2. Is there a plan to deprecate these diagnostic options > (LogVMOutput, > LogFile, DisplayVMOutput, etc.)? Will the defaultStream, > fileStream classes > and the tty variable eventually removed from HotSpot? > > > I believe that is the general intent - though complete removal is > not feasible as UL can't always be used in all contexts. We have > migrated various subsystems to UL and all new logging should be > using UL. However I don't believe we actually have active RFEs to > aggressively complete the switchover. > > Just my 2c. > > David > > Thanks, > Man > > From karen.kinnear at oracle.com Wed Dec 6 14:17:47 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 6 Dec 2017 09:17:47 -0500 Subject: Unified JVM Logging and diagnostic options LogVMOutput, LogFile, DisplayVMOutput In-Reply-To: <19afa6c9-0f35-e108-7027-3d7974c89300@oracle.com> References: <92addaa5-e735-db64-0e7a-afe8f5f6c2d4@oracle.com> <19afa6c9-0f35-e108-7027-3d7974c89300@oracle.com> Message-ID: <4B8D1CCD-50DF-4A13-8C04-9B3B4646781F@oracle.com> Just a note - unified logging belongs to runtime. thanks, Karen > On Dec 6, 2017, at 1:33 AM, David Holmes wrote: > > On 1/12/2017 11:15 AM, Man Cao wrote: >> Thanks David for the quick response! >> Yes, I understand completely removing defaultStream and tty is probably infeasible. >> If deprecating the diagnostic options (LogVMOutput, LogFile, DisplayVMOutput) is the intent, could someone create a bug/RFE to track it? They should probably first be added to the special_jvm_flags table > > I think there is too much yet to be done in the conversion process to file such a RFE - to be frank we don't have active RFE's for the remaining conversions, rather they are being tackled case by case when people are working in the area. > >> in arguments.cpp, so there will be a warning when people use them. The case of conflicting -Xlog::file=test.log and -XX:LogFile=test.log is also a concern, the JVM should at least issue a warning about it. In addition, it would make it easier for us to convince production teams to stop using these options. > > I have filed: > > https://bugs.openjdk.java.net/browse/JDK-8193117 > > JDK-8193117 Issue a warning if legacy logging and Unified Logging are told to use the same file > > Cheers, > David > ----- > >> Thanks, >> Man >> On Thu, Nov 30, 2017 at 4:48 PM, David Holmes > wrote: >> Hi Man, >> Adding serviceability as UL is a serviceability feature. >> On 1/12/2017 10:23 AM, Man Cao wrote: >> Hello, >> We (Java Platform Team at Google) found that in JDK9, the file >> generated by >> -XX:+LogVMOutput no longer contains GC log messages, because the >> unified >> JVM logging framework does not use the defaultStream and >> fileStream classes >> and the tty variable. Similarly, related options such as LogFile, >> DisplayVMOutput have no effect on the messages printed by the >> unified >> logging framework. >> The main problem for us is that most of our production Java >> servers use the >> options "-XX:+LogVMOutput -XX:-DisplayVMOutput", to save the GC >> logs and >> other VM messages. These flags would no longer work for JDK9's >> JVM logging >> framework. In addition, the file generated by -XX:+LogVMOutput >> may contain >> information that is not printed by the unified logging framework. >> What is worse is that if LogFile and the output of unified logging >> framework point to the same file, the file may contain partial >> or corrupted >> messages from the unified logging framework. For example, >> consider the >> following command: >> java -Xlog::file=test.log -XX:+UnlockDiagnosticVMOptions >> -XX:+LogVMOutput >> -XX:LogFile=test.log >> Then test.log would miss some of the messages that would be >> printed at the >> beginning if you run "java -Xlog". >> So our questions are: >> 1. Do you consider this is a bug for the unified logging >> framework that >> should be fixed? Should the unified logging framework respect these >> diagnostic options? >> My understanding is that UL is intended to replace the legacy >> "logging" flags and works independently of them. So no, UL should >> not respect these flags. >> 2. Is there a plan to deprecate these diagnostic options >> (LogVMOutput, >> LogFile, DisplayVMOutput, etc.)? Will the defaultStream, >> fileStream classes >> and the tty variable eventually removed from HotSpot? >> I believe that is the general intent - though complete removal is >> not feasible as UL can't always be used in all contexts. We have >> migrated various subsystems to UL and all new logging should be >> using UL. However I don't believe we actually have active RFEs to >> aggressively complete the switchover. >> Just my 2c. >> David >> Thanks, >> Man From christoph.langer at sap.com Wed Dec 6 15:44:58 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 6 Dec 2017 15:44:58 +0000 Subject: RFR(S): 8192978: Missing checks and small fixes in jdwp library In-Reply-To: <7b6699b2-6105-9f0c-19ed-21b2d9a694b6@oracle.com> References: <2ebd9977-2f0f-ebc1-99fd-14b5ce3c3c16@oracle.com> <9ee1eeae24f847c9918f4777be2fb271@sap.com> <7b6699b2-6105-9f0c-19ed-21b2d9a694b6@oracle.com> Message-ID: <7819ccf065ed42399ef2ee3fa6ecc1c4@sap.com> Hi Chris, thanks again for your reply. > shmemBase.c: seems correct, but could use explanation/example of when existing code was failing. This is a coverity finding. The correct size specification as per Microsoft?s doc [1] for jlong (__int64) would be I64. Yes. I was just wondering if using the incorrect format ever produced a test failure. Also, isn't %ld incorrect for 32-bit platforms? But then I doubt this code has ever been compiled for a 32-bit unix target. Also, it looks like PRId64 should work for all platforms. This is what we use in hotspot to print a 64-bit value: #define INT64_FORMAT "%" PRId64 So maybe this fix can be simplified. You are probably right, I?ll address this in my next webrev. VirtualMachineImpl.c: When/why is pos ever null? This is also a coverity case. For some reason, coverity thinks that pos could be NULL here. But I?m with you ? I also don?t see a path how that could ever happen. Nevertheless, this change would please converity and I don?t see it being performance critical so I would like to leave it. It?s also not wrong. I'm actually more concerned about making the code harder to read and misleading the reader into thinking it could actually be NULL. I'm not familiar with coverity, but I thought tools like this either provided a specific call path for these types of errors (in which case the problem might actually be up the call chain), or allowed you to configure the tool not to complain about specific cases that you know can't happen. OK, what I?m gonna do now: I?ve reverted the stuff in our codebase to get a new coverity run. If coverity still complains I?ll check again to first of all get an explanation by coverity what should be wrong and then find a more sensible fix. Or maybe we can tell coverity to shut up? error_messages.c: Is there any reason not to do this fix for all platforms? Do you have a test case for it? This is a Windows only issue. ?vsnprintf? would write the terminating 0. But in jdk.jdwp.agent/windows/native/libjdwp/util_md.h, vsnprintf is redefined to _vsnprintf. And this, by the Mircrosoft documentation [2], doesn?t necessarily write the terminating character. Any idea why we do this redefine of vsnprintf? In any case, it might be best to just unconditionally terminate rather than have WIN32 explicit code. After reading the specs again, I think that windows uses _vsnprintf since this version matches the standard Unix/Linux behavior better which means that the buffer is written up to count and a terminating 0 might not be written. So it?s best to terminate the buffer in any case which will be reflected by my new webrev. eventHelper.c: Do you have a testcase? Also, is the "bagAdd(eventBag)" message going to be of use to the user? For this one I don?t have the history. Maybe it was also the coverity tool. But there is no testcase. In my update I have updated 2 other places with the null check where bagAdd is called. I guess in case of such a null error occurring, it could help a little. But probably this would be something to be investigated by the developer rather than the debugging user. I think you should hold off on this one until you have a better handle on why this was needed, and possible also include a test case. This one is coverity, too. I?m now doing the same approach like I do with VirtualMachineImpl.c. I?m removing the stuff and see if coverity will complain again and then rethink the patch. inStream.c: inStream_init() now uses a magic number of 11. What does it represent? inStream_endOfInput() looks like it used to be completely broken. How was this not noticed? Is this related to the change inStream_init(), which possible was masking this error? Is there a test case for it? I found this fix in our code base. instream_endOfInput() is obviously never used. At least I don?t find any references in the source code scan. Maybe I shall completely remove it? As for the ?magic number of 11?: This is the offset to the payload of a jdwpCmdPacket, see jdk.jdwp.agent/share/native/include/ jdwpTransport.h. (sizeof(jint) /* len*/ + sizeof(jint) /* id */ + sizeof(jbyte) /* flags*/ + sizeof(jbyte) /* cmdSet */ + sizeof(jbyte) /*cmd */ Maybe I should write it down explicitly? Can you use offsetof? Yes, will do in next webrev. I?m still hoping to get this change done under the hood of JDK-8192978. I will update the bug with some more details and also add an appropriate noreg label. I think the coverity fixes can be one bug. The format changes one bug (I assume coverity did not find them). inStream.c should have its own bug. eventHelper.c should have its own bug and more investigation as to why it is needed. I get nervous when the reason for a change has been forgotten. Ok, I will eventually split as suggested. So, I?ll check the coverity results tomorrow and then come up with new webrevs. Best regards, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Wed Dec 6 16:10:23 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Wed, 6 Dec 2017 08:10:23 -0800 (PST) Subject: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands Message-ID: Hello, Pls review changes for the following issue: Bug ID: https://bugs.openjdk.java.net/browse/JDK-8193124 Webrev: http://cr.openjdk.java.net/~sballal/8193124/webrev.00/ The tests have passed in JPRT and Mach5. Thanks, Sharath -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Wed Dec 6 17:10:02 2017 From: jini.george at oracle.com (Jini George) Date: Wed, 6 Dec 2017 22:40:02 +0530 Subject: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands In-Reply-To: References: Message-ID: <3017924b-7aad-16e3-1ccb-43823dd3e91c@oracle.com> Hi Sharath, For ClhsdbFindPC.java, the test case would fail if it gets invoked with -Xcomp. So, it might be better to invoke LingeredApp only with -Xint or only with -Xcomp (and if so, check for the "In code in NMethod" string). Other than this, the rest of it looks good to me. Thanks! Jini. On 12/6/2017 9:40 PM, Sharath Ballal wrote: > Hello, > > Pls review changes for the following issue: > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8193124 > > Webrev: http://cr.openjdk.java.net/~sballal/8193124/webrev.00/ > > The tests have passed in JPRT and Mach5. > > Thanks, > > Sharath > From chris.plummer at oracle.com Wed Dec 6 22:38:43 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 6 Dec 2017 14:38:43 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError Message-ID: Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8191229 http://cr.openjdk.java.net/~cjplummer/8191229/webrev.00/ The test is testing contended monitor support. After registering the callback, it gets an unexpected notification of a contended monitor, which is happening while the finalizer thread is running. In the callback the test does a FindClass to find a test class, but the classloader context is not correct when the finalizer thread is current, so FindClass fails and leaves an exception pending (probably blowing away the finalzer thread) and also (separately) causes the test to fail. It's unknown why this callback is suddenly being triggered, but the callback itself is not a bug, and the test needs to defend against it. The fix is to lookup the test class during test initialization and keep it cached, rather than look it up every time there is a contended monitor callback. thanks, Chris From serguei.spitsyn at oracle.com Wed Dec 6 23:33:12 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 6 Dec 2017 15:33:12 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: References: Message-ID: Hi Chris, It looks good to me. I wonder if we have other similar cases like this in the JVMTI tests. Thanks, Serguei On 12/6/17 14:38, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8191229 > http://cr.openjdk.java.net/~cjplummer/8191229/webrev.00/ > > The test is testing contended monitor support. After registering the > callback, it gets an unexpected notification of a contended monitor, > which is happening while the finalizer thread is running. In the > callback the test does a FindClass to find a test class, but the > classloader context is not correct when the finalizer thread is > current, so FindClass fails and leaves an exception pending (probably > blowing away the finalzer thread) and also (separately) causes the > test to fail. It's unknown why this callback is suddenly being > triggered, but the callback itself is not a bug, and the test needs to > defend against it. > > The fix is to lookup the test class during test initialization and > keep it cached, rather than look it up every time there is a contended > monitor callback. > > thanks, > > Chris From chris.plummer at oracle.com Wed Dec 6 23:55:02 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 6 Dec 2017 15:55:02 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: References: Message-ID: I didn't see any other suspicious uses of FindClass in the jvmti jtreg tests. Chris On 12/6/17 3:33 PM, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > It looks good to me. > I wonder if we have other similar cases like this in the JVMTI tests. > > Thanks, > Serguei > > > On 12/6/17 14:38, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8191229 >> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.00/ >> >> The test is testing contended monitor support. After registering the >> callback, it gets an unexpected notification of a contended monitor, >> which is happening while the finalizer thread is running. In the >> callback the test does a FindClass to find a test class, but the >> classloader context is not correct when the finalizer thread is >> current, so FindClass fails and leaves an exception pending (probably >> blowing away the finalzer thread) and also (separately) causes the >> test to fail. It's unknown why this callback is suddenly being >> triggered, but the callback itself is not a bug, and the test needs >> to defend against it. >> >> The fix is to lookup the test class during test initialization and >> keep it cached, rather than look it up every time there is a >> contended monitor callback. >> >> thanks, >> >> Chris > From serguei.spitsyn at oracle.com Thu Dec 7 00:10:56 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 6 Dec 2017 16:10:56 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: References: Message-ID: On 12/6/17 15:55, Chris Plummer wrote: > I didn't see any other suspicious uses of FindClass in the jvmti jtreg > tests. Good to know. There are not that many jvmti jtreg tests. Interesting part would be the nsk.jvmti tests. There are many uses of the FindClass there. But let's keep it out of this review. Thanks, Serguei > Chris > > On 12/6/17 3:33 PM, serguei.spitsyn at oracle.com wrote: >> Hi Chris, >> >> It looks good to me. >> I wonder if we have other similar cases like this in the JVMTI tests. >> >> Thanks, >> Serguei >> >> >> On 12/6/17 14:38, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8191229 >>> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.00/ >>> >>> The test is testing contended monitor support. After registering the >>> callback, it gets an unexpected notification of a contended monitor, >>> which is happening while the finalizer thread is running. In the >>> callback the test does a FindClass to find a test class, but the >>> classloader context is not correct when the finalizer thread is >>> current, so FindClass fails and leaves an exception pending >>> (probably blowing away the finalzer thread) and also (separately) >>> causes the test to fail. It's unknown why this callback is suddenly >>> being triggered, but the callback itself is not a bug, and the test >>> needs to defend against it. >>> >>> The fix is to lookup the test class during test initialization and >>> keep it cached, rather than look it up every time there is a >>> contended monitor callback. >>> >>> thanks, >>> >>> Chris >> > From chris.plummer at oracle.com Thu Dec 7 00:14:00 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 6 Dec 2017 16:14:00 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: References: Message-ID: On 12/6/17 4:10 PM, serguei.spitsyn at oracle.com wrote: > > On 12/6/17 15:55, Chris Plummer wrote: >> I didn't see any other suspicious uses of FindClass in the jvmti >> jtreg tests. > > Good to know. > There are not that many jvmti jtreg tests. > Interesting part would be the nsk.jvmti tests. > There are many uses of the FindClass there. > But let's keep it out of this review. Yes, I did check there and noticed too many calls to go through. We'll just need to keep an eye out for new failures since this failure seems to have been triggered by recent JDK or VM changes resulting in a contended monitor that we did not see in past. Chris > > Thanks, > Serguei > > >> Chris >> >> On 12/6/17 3:33 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Chris, >>> >>> It looks good to me. >>> I wonder if we have other similar cases like this in the JVMTI tests. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 12/6/17 14:38, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review the following: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8191229 >>>> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.00/ >>>> >>>> The test is testing contended monitor support. After registering >>>> the callback, it gets an unexpected notification of a contended >>>> monitor, which is happening while the finalizer thread is running. >>>> In the callback the test does a FindClass to find a test class, but >>>> the classloader context is not correct when the finalizer thread is >>>> current, so FindClass fails and leaves an exception pending >>>> (probably blowing away the finalzer thread) and also (separately) >>>> causes the test to fail. It's unknown why this callback is suddenly >>>> being triggered, but the callback itself is not a bug, and the test >>>> needs to defend against it. >>>> >>>> The fix is to lookup the test class during test initialization and >>>> keep it cached, rather than look it up every time there is a >>>> contended monitor callback. >>>> >>>> thanks, >>>> >>>> Chris >>> >> > From alexey.menkov at oracle.com Thu Dec 7 00:48:51 2017 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 6 Dec 2017 16:48:51 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: References: Message-ID: <98e5033f-3caf-0817-7b35-dae95f06b8d5@oracle.com> +1 Chris, while you are there could you please fix a minor issue with the native part of the test - Agent_Initialize doesn't zero callbacks struct (only sets MonitorContendedEnter/MonitorContendedEntered): - jvmtiEventCallbacks callbacks; + jvmtiEventCallbacks callbacks = {0}; --alex On 12/06/2017 15:33, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > It looks good to me. > I wonder if we have other similar cases like this in the JVMTI tests. > > Thanks, > Serguei > > > On 12/6/17 14:38, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8191229 >> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.00/ >> >> The test is testing contended monitor support. After registering the >> callback, it gets an unexpected notification of a contended monitor, >> which is happening while the finalizer thread is running. In the >> callback the test does a FindClass to find a test class, but the >> classloader context is not correct when the finalizer thread is >> current, so FindClass fails and leaves an exception pending (probably >> blowing away the finalzer thread) and also (separately) causes the >> test to fail. It's unknown why this callback is suddenly being >> triggered, but the callback itself is not a bug, and the test needs to >> defend against it. >> >> The fix is to lookup the test class during test initialization and >> keep it cached, rather than look it up every time there is a contended >> monitor callback. >> >> thanks, >> >> Chris > From chris.plummer at oracle.com Thu Dec 7 01:27:43 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 6 Dec 2017 17:27:43 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: <98e5033f-3caf-0817-7b35-dae95f06b8d5@oracle.com> References: <98e5033f-3caf-0817-7b35-dae95f06b8d5@oracle.com> Message-ID: Hi Alex, Good catch. I guess it doesn't blow up because we only enable the two callbacks we setup. It looks like we usually zero it out with: ??? memset(&callbacks, 0, sizeof(callbacks)); So I'll go with that fix. thanks, Chris On 12/6/17 4:48 PM, Alex Menkov wrote: > +1 > > Chris, while you are there could you please fix a minor issue with the > native part of the test - Agent_Initialize doesn't zero callbacks > struct (only sets MonitorContendedEnter/MonitorContendedEntered): > > -??? jvmtiEventCallbacks callbacks; > +??? jvmtiEventCallbacks callbacks = {0}; > > --alex > > On 12/06/2017 15:33, serguei.spitsyn at oracle.com wrote: >> Hi Chris, >> >> It looks good to me. >> I wonder if we have other similar cases like this in the JVMTI tests. >> >> Thanks, >> Serguei >> >> >> On 12/6/17 14:38, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8191229 >>> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.00/ >>> >>> The test is testing contended monitor support. After registering the >>> callback, it gets an unexpected notification of a contended monitor, >>> which is happening while the finalizer thread is running. In the >>> callback the test does a FindClass to find a test class, but the >>> classloader context is not correct when the finalizer thread is >>> current, so FindClass fails and leaves an exception pending >>> (probably blowing away the finalzer thread) and also (separately) >>> causes the test to fail. It's unknown why this callback is suddenly >>> being triggered, but the callback itself is not a bug, and the test >>> needs to defend against it. >>> >>> The fix is to lookup the test class during test initialization and >>> keep it cached, rather than look it up every time there is a >>> contended monitor callback. >>> >>> thanks, >>> >>> Chris >> From david.holmes at oracle.com Thu Dec 7 02:47:51 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Dec 2017 12:47:51 +1000 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: References: Message-ID: Hi Chris, On 7/12/2017 8:38 AM, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8191229 > http://cr.openjdk.java.net/~cjplummer/8191229/webrev.00/ I expected to see the initialization done in JNI_OnLoad, not in a new init() method. David ----- > The test is testing contended monitor support. After registering the > callback, it gets an unexpected notification of a contended monitor, > which is happening while the finalizer thread is running. In the > callback the test does a FindClass to find a test class, but the > classloader context is not correct when the finalizer thread is current, > so FindClass fails and leaves an exception pending (probably blowing > away the finalzer thread) and also (separately) causes the test to fail. > It's unknown why this callback is suddenly being triggered, but the > callback itself is not a bug, and the test needs to defend against it. > > The fix is to lookup the test class during test initialization and keep > it cached, rather than look it up every time there is a contended > monitor callback. > > thanks, > > Chris From chris.plummer at oracle.com Thu Dec 7 03:08:16 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 6 Dec 2017 19:08:16 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: References: Message-ID: On 12/6/17 6:47 PM, David Holmes wrote: > Hi Chris, > > On 7/12/2017 8:38 AM, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8191229 >> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.00/ > > I expected to see the initialization done in JNI_OnLoad, not in a new > init() method. I was worried it wouldn't work because of JDK-8188052, but I guess that only impacts JNI_OnUnload. I can change it to init from JNI_OnLoad(). Chris > > David > ----- > >> The test is testing contended monitor support. After registering the >> callback, it gets an unexpected notification of a contended monitor, >> which is happening while the finalizer thread is running. In the >> callback the test does a FindClass to find a test class, but the >> classloader context is not correct when the finalizer thread is >> current, so FindClass fails and leaves an exception pending (probably >> blowing away the finalzer thread) and also (separately) causes the >> test to fail. It's unknown why this callback is suddenly being >> triggered, but the callback itself is not a bug, and the test needs >> to defend against it. >> >> The fix is to lookup the test class during test initialization and >> keep it cached, rather than look it up every time there is a >> contended monitor callback. >> >> thanks, >> >> Chris From david.holmes at oracle.com Thu Dec 7 03:38:30 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Dec 2017 13:38:30 +1000 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: References: Message-ID: <721a9b28-5d3b-bd35-4d6d-5aa9d693c778@oracle.com> On 7/12/2017 1:08 PM, Chris Plummer wrote: > On 12/6/17 6:47 PM, David Holmes wrote: >> Hi Chris, >> >> On 7/12/2017 8:38 AM, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8191229 >>> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.00/ >> >> I expected to see the initialization done in JNI_OnLoad, not in a new >> init() method. > I was worried it wouldn't work because of JDK-8188052, but I guess that > only impacts JNI_OnUnload. I can change it to init from JNI_OnLoad(). Yes please use JNI_OnLoad. Thanks, David > > Chris >> >> David >> ----- >> >>> The test is testing contended monitor support. After registering the >>> callback, it gets an unexpected notification of a contended monitor, >>> which is happening while the finalizer thread is running. In the >>> callback the test does a FindClass to find a test class, but the >>> classloader context is not correct when the finalizer thread is >>> current, so FindClass fails and leaves an exception pending (probably >>> blowing away the finalzer thread) and also (separately) causes the >>> test to fail. It's unknown why this callback is suddenly being >>> triggered, but the callback itself is not a bug, and the test needs >>> to defend against it. >>> >>> The fix is to lookup the test class during test initialization and >>> keep it cached, rather than look it up every time there is a >>> contended monitor callback. >>> >>> thanks, >>> >>> Chris > > From chris.plummer at oracle.com Thu Dec 7 04:04:59 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 6 Dec 2017 20:04:59 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: <721a9b28-5d3b-bd35-4d6d-5aa9d693c778@oracle.com> References: <721a9b28-5d3b-bd35-4d6d-5aa9d693c778@oracle.com> Message-ID: <2fbe6bf9-afd6-2fa8-3d70-edf83278fe43@oracle.com> On 12/6/17 7:38 PM, David Holmes wrote: > On 7/12/2017 1:08 PM, Chris Plummer wrote: >> On 12/6/17 6:47 PM, David Holmes wrote: >>> Hi Chris, >>> >>> On 7/12/2017 8:38 AM, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review the following: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8191229 >>>> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.00/ >>> >>> I expected to see the initialization done in JNI_OnLoad, not in a >>> new init() method. >> I was worried it wouldn't work because of JDK-8188052, but I guess >> that only impacts JNI_OnUnload. I can change it to init from >> JNI_OnLoad(). > > Yes please use JNI_OnLoad. Having issues with that. The IsInstanceOf() done during the jvmti callback is crashing in JNIHandles::resolve_non_null(). Something is messed up about the testclass handle, but I can't figure out what. I'm initializing it the same way, except in OnLoad() rather than in init(). JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *jvm, void *reserved) { ??? jint res; ??? JNIEnv *env; ??? res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) &env), ?????????????????????????????????? JVMTI_VERSION_1); ??? testClass = (*env)->FindClass(env, TEST_CLASS); ??? if (testClass != NULL) { ????? testClass = (*env)->NewGlobalRef(env, testClass); ??? } ??? return JNI_VERSION_1_8; } Very strange. Chris > > Thanks, > David >> >> Chris >>> >>> David >>> ----- >>> >>>> The test is testing contended monitor support. After registering >>>> the callback, it gets an unexpected notification of a contended >>>> monitor, which is happening while the finalizer thread is running. >>>> In the callback the test does a FindClass to find a test class, but >>>> the classloader context is not correct when the finalizer thread is >>>> current, so FindClass fails and leaves an exception pending >>>> (probably blowing away the finalzer thread) and also (separately) >>>> causes the test to fail. It's unknown why this callback is suddenly >>>> being triggered, but the callback itself is not a bug, and the test >>>> needs to defend against it. >>>> >>>> The fix is to lookup the test class during test initialization and >>>> keep it cached, rather than look it up every time there is a >>>> contended monitor callback. >>>> >>>> thanks, >>>> >>>> Chris >> >> From chris.plummer at oracle.com Thu Dec 7 04:47:39 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 6 Dec 2017 20:47:39 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: <2fbe6bf9-afd6-2fa8-3d70-edf83278fe43@oracle.com> References: <721a9b28-5d3b-bd35-4d6d-5aa9d693c778@oracle.com> <2fbe6bf9-afd6-2fa8-3d70-edf83278fe43@oracle.com> Message-ID: <09479812-7023-7567-4016-539111001ea7@oracle.com> On 12/6/17 8:04 PM, Chris Plummer wrote: > On 12/6/17 7:38 PM, David Holmes wrote: >> On 7/12/2017 1:08 PM, Chris Plummer wrote: >>> On 12/6/17 6:47 PM, David Holmes wrote: >>>> Hi Chris, >>>> >>>> On 7/12/2017 8:38 AM, Chris Plummer wrote: >>>>> Hello, >>>>> >>>>> Please review the following: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8191229 >>>>> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.00/ >>>> >>>> I expected to see the initialization done in JNI_OnLoad, not in a >>>> new init() method. >>> I was worried it wouldn't work because of JDK-8188052, but I guess >>> that only impacts JNI_OnUnload. I can change it to init from >>> JNI_OnLoad(). >> >> Yes please use JNI_OnLoad. > Having issues with that. The IsInstanceOf() done during the jvmti > callback is crashing in JNIHandles::resolve_non_null(). Something is > messed up about the testclass handle, but I can't figure out what. I'm > initializing it the same way, except in OnLoad() rather than in init(). > > JNIEXPORT jint JNICALL > JNI_OnLoad(JavaVM *jvm, void *reserved) { > ??? jint res; > ??? JNIEnv *env; > > ??? res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) &env), > ?????????????????????????????????? JVMTI_VERSION_1); > ??? testClass = (*env)->FindClass(env, TEST_CLASS); > ??? if (testClass != NULL) { > ????? testClass = (*env)->NewGlobalRef(env, testClass); > ??? } > ??? return JNI_VERSION_1_8; > } > > Very strange. Interesting. The problem was passing JVMTI_VERSION_1 into GetEnv() instead of JNI_VERSION_1_8. I'm not sure why that was problematic, but changing it to JNI_VERSION_1_8 fixed the problem. I had copied this GetEnv() code from Agent_Initialize(), but there it was used to get the jvmtiEnv*, and seemed to be working ok, at least for the use of the jvmtiEnv* in that function. The other jvmti tests are using JVMTI_VERSION_9, but I think most of them are new in 9. I don't know when GetOwnedMonitorInfo was introduced, but maybe it should also be updated to specify JVMTI_VERSION_9. Chris > > Chris >> >> Thanks, >> David >>> >>> Chris >>>> >>>> David >>>> ----- >>>> >>>>> The test is testing contended monitor support. After registering >>>>> the callback, it gets an unexpected notification of a contended >>>>> monitor, which is happening while the finalizer thread is running. >>>>> In the callback the test does a FindClass to find a test class, >>>>> but the classloader context is not correct when the finalizer >>>>> thread is current, so FindClass fails and leaves an exception >>>>> pending (probably blowing away the finalzer thread) and also >>>>> (separately) causes the test to fail. It's unknown why this >>>>> callback is suddenly being triggered, but the callback itself is >>>>> not a bug, and the test needs to defend against it. >>>>> >>>>> The fix is to lookup the test class during test initialization and >>>>> keep it cached, rather than look it up every time there is a >>>>> contended monitor callback. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>> >>> > > From chris.plummer at oracle.com Thu Dec 7 07:44:05 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 6 Dec 2017 23:44:05 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: <09479812-7023-7567-4016-539111001ea7@oracle.com> References: <721a9b28-5d3b-bd35-4d6d-5aa9d693c778@oracle.com> <2fbe6bf9-afd6-2fa8-3d70-edf83278fe43@oracle.com> <09479812-7023-7567-4016-539111001ea7@oracle.com> Message-ID: <181e26de-de69-273b-ae14-68aebc546411@oracle.com> New webrev: https://bugs.openjdk.java.net/browse/JDK-8191229 http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/ testClass now initialized from JNI_OnLoad(), and use memset to clear callbacks. Also updated to use JVMTI_VERSION_9 when calling GetEnv(). thanks, Chris From serguei.spitsyn at oracle.com Thu Dec 7 07:57:09 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 6 Dec 2017 23:57:09 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: References: Message-ID: Hi David, On 12/6/17 18:47, David Holmes wrote: > Hi Chris, > > On 7/12/2017 8:38 AM, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8191229 >> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.00/ > > I expected to see the initialization done in JNI_OnLoad, not in a new > init() method. I see no point to initialize it specifically in the JNI_OnLoad except for a simplicity. We just need the testClass set before the locks in the test class are used. But I see no problem in either case. :) Thanks, Serguei > David > ----- > >> The test is testing contended monitor support. After registering the >> callback, it gets an unexpected notification of a contended monitor, >> which is happening while the finalizer thread is running. In the >> callback the test does a FindClass to find a test class, but the >> classloader context is not correct when the finalizer thread is >> current, so FindClass fails and leaves an exception pending (probably >> blowing away the finalzer thread) and also (separately) causes the >> test to fail. It's unknown why this callback is suddenly being >> triggered, but the callback itself is not a bug, and the test needs >> to defend against it. >> >> The fix is to lookup the test class during test initialization and >> keep it cached, rather than look it up every time there is a >> contended monitor callback. >> >> thanks, >> >> Chris From serguei.spitsyn at oracle.com Thu Dec 7 08:02:08 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 7 Dec 2017 00:02:08 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: <181e26de-de69-273b-ae14-68aebc546411@oracle.com> References: <721a9b28-5d3b-bd35-4d6d-5aa9d693c778@oracle.com> <2fbe6bf9-afd6-2fa8-3d70-edf83278fe43@oracle.com> <09479812-7023-7567-4016-539111001ea7@oracle.com> <181e26de-de69-273b-ae14-68aebc546411@oracle.com> Message-ID: Hi Chris, This variant is not that simple as one would expect but it looks Ok to me. Thanks, Serguei On 12/6/17 23:44, Chris Plummer wrote: > New webrev: > > https://bugs.openjdk.java.net/browse/JDK-8191229 > http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/ > > testClass now initialized from JNI_OnLoad(), and use memset to clear > callbacks. Also updated to use JVMTI_VERSION_9 when calling GetEnv(). > > thanks, > > Chris From chris.plummer at oracle.com Thu Dec 7 08:11:43 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 7 Dec 2017 00:11:43 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: References: <721a9b28-5d3b-bd35-4d6d-5aa9d693c778@oracle.com> <2fbe6bf9-afd6-2fa8-3d70-edf83278fe43@oracle.com> <09479812-7023-7567-4016-539111001ea7@oracle.com> <181e26de-de69-273b-ae14-68aebc546411@oracle.com> Message-ID: <9129c982-895f-027c-8dbd-b863025802c2@oracle.com> I could put it in Agent_Initialize(). It would be a little simpler since I would not need to call and error check GetEnv() again. I initially had done it there, but ran into the crash due to handle issues, so I moved it to JNI_OnLoad. But ended up having the same problem there, and it was due to specifying JVMTI_VERSION_1 on the GetEnv() call. I think possibly the dispatch table is different and it was not doing the NewGlobalRef() call properly. So Agent_Initialize() might work now that I'm specifying JVMTI_VERSION_9. thanks, Chris On 12/7/17 12:02 AM, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > This variant is not that simple as one would expect but it looks Ok to > me. > > Thanks, > Serguei > > > On 12/6/17 23:44, Chris Plummer wrote: >> New webrev: >> >> https://bugs.openjdk.java.net/browse/JDK-8191229 >> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/ >> >> testClass now initialized from JNI_OnLoad(), and use memset to clear >> callbacks. Also updated to use JVMTI_VERSION_9 when calling GetEnv(). >> >> thanks, >> >> Chris > From sharath.ballal at oracle.com Thu Dec 7 08:55:08 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 7 Dec 2017 00:55:08 -0800 (PST) Subject: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands In-Reply-To: <3017924b-7aad-16e3-1ccb-43823dd3e91c@oracle.com> References: <3017924b-7aad-16e3-1ccb-43823dd3e91c@oracle.com> Message-ID: Thanks Jini. I have changed the testcase to run with both -Xint and -Xcomp. Updated webrev is http://cr.openjdk.java.net/~sballal/8193124/webrev.01/ Thanks, Sharath -----Original Message----- From: Jini George Sent: Wednesday, December 06, 2017 10:40 PM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands Hi Sharath, For ClhsdbFindPC.java, the test case would fail if it gets invoked with -Xcomp. So, it might be better to invoke LingeredApp only with -Xint or only with -Xcomp (and if so, check for the "In code in NMethod" string). Other than this, the rest of it looks good to me. Thanks! Jini. On 12/6/2017 9:40 PM, Sharath Ballal wrote: > Hello, > > Pls review changes for the following issue: > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8193124 > > Webrev: http://cr.openjdk.java.net/~sballal/8193124/webrev.00/ > > The tests have passed in JPRT and Mach5. > > Thanks, > > Sharath > From david.holmes at oracle.com Thu Dec 7 10:41:59 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Dec 2017 20:41:59 +1000 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: <181e26de-de69-273b-ae14-68aebc546411@oracle.com> References: <721a9b28-5d3b-bd35-4d6d-5aa9d693c778@oracle.com> <2fbe6bf9-afd6-2fa8-3d70-edf83278fe43@oracle.com> <09479812-7023-7567-4016-539111001ea7@oracle.com> <181e26de-de69-273b-ae14-68aebc546411@oracle.com> Message-ID: <836bf838-409c-17c8-c3aa-04065a41c5fb@oracle.com> Hi Chris, On 7/12/2017 5:44 PM, Chris Plummer wrote: > New webrev: > > https://bugs.openjdk.java.net/browse/JDK-8191229 > http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/ > > testClass now initialized from JNI_OnLoad(), and use memset to clear > callbacks. Also updated to use JVMTI_VERSION_9 when calling GetEnv(). 71 // JNI_OnLoad has not been called yet, so can't possibly be an instance of TEST_CLASS. You can't be executing this method before JNI_OnLoad has executed. If JNI_Onload has executed then you can't execute this method and find NULL as that means JNI_Onload failed and hence library loading fails and so you can't be executing this method. So this method reduces to a simple instanceof check, which can go straight into the calling method. 183 if (testClass == NULL) { That can just be "else {" - but as I said it can't be NULL anyway. Thanks, David > thanks, > > Chris From goetz.lindenmaier at sap.com Thu Dec 7 11:20:40 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 7 Dec 2017 11:20:40 +0000 Subject: FW: RFR(M): 8189102: All tools should support -?, -h and --help In-Reply-To: <8aa25976d496465fac00a4ae3628e533@sap.com> References: <8aa25976d496465fac00a4ae3628e533@sap.com> Message-ID: <456c694ec25a42658af1b8600aaa136d@sap.com> Hi, ... missed some lists in my first post ... I prepared a fifth webrev for this change. Please review. It incorporates the changes requested by the CSR reviewers (not to remove docuemtation of '-help' where is was documented before) and the changes proposed by Kumar: http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.05/ See also the information in the webrev itself, there are also patch files with the incremental builds. This change contains fixes for some langtool tests. I ran the following test suites on it: hotspot, jdk, langtools, nashorn, jaxp, most of them on all the platforms we build. Best regards, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Mittwoch, 11. Oktober 2017 22:07 > To: hotspot-dev developers > Subject: RFR(M): 8189102: All tools should support -?, -h and --help > > Hi > > The tools in jdk should all show the same behavior wrt. help flags. > This change normalizes the help flags of a row of the tools in the jdk. > Java accepts -?, -h and --help, thus I changed the tools to support > these, too. Some tools exited with '1' after displaying the help message, > I turned this to '0'. > > Maybe this is not the right mailing list for this, please advise. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.01/ > > In detail, this fixes the help message of the following tools: > jar -? -h --help; added -?. > jarsigner -? -h --help; added --help. -help accepted but not documented. > javac -? --help; added -?. Removed -help. -h is taken for other purpose > javadoc -? -h --help; added -h -?. Removed -help > javap -? -h --help; added -h. -help accepted but no more documented. > jcmd -? -h --help; added -? --help. -help accepted but no more > documented. Changed return value to '0' > jdb -? -h --help; added -? -h --help. -help accepted but no more > documented. > jdeprscan -? -h --help; added -? > jinfo -? -h --help; added -? --help. -help accepted but no more > documented. > jjs -h --help; Replaced -help by --help. Adding more not straight > forward. > jps -? -h --help; added -? --help. -help accepted but no more > documented. > jshell -? -h --help; added -? > jstat -? -h --help; added -h --help. -help accepted but no more > documented. > > Best regards, > Goetz. From yasuenag at gmail.com Thu Dec 7 14:14:33 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 7 Dec 2017 23:14:33 +0900 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: <181e26de-de69-273b-ae14-68aebc546411@oracle.com> References: <721a9b28-5d3b-bd35-4d6d-5aa9d693c778@oracle.com> <2fbe6bf9-afd6-2fa8-3d70-edf83278fe43@oracle.com> <09479812-7023-7567-4016-539111001ea7@oracle.com> <181e26de-de69-273b-ae14-68aebc546411@oracle.com> Message-ID: <1fcf0aa0-49b6-3c8d-8794-6cbdc7ccd24d@gmail.com> Hi Chris, I added testcase of GetOwnedMonitorInfo in JDK-8185164. I have concern your change to cache the result of FindClass(). According to [1], FindClass() calls find_class_from_class_loader(), it returns JNI local value. Is it safe to cache? So I called FindClass each time in original commit. Thanks, Yasumasa [1] http://hg.openjdk.java.net/jdk/hs/file/32fd4be602d5/src/hotspot/share/prims/jvm.cpp#l3450 On 2017/12/07 16:44, Chris Plummer wrote: > New webrev: > > https://bugs.openjdk.java.net/browse/JDK-8191229 > http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/ > > testClass now initialized from JNI_OnLoad(), and use memset to clear > callbacks. Also updated to use JVMTI_VERSION_9 when calling GetEnv(). > > thanks, > > Chris > From christoph.langer at sap.com Thu Dec 7 15:21:00 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 7 Dec 2017 15:21:00 +0000 Subject: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c Message-ID: Hi, please review the first extracted patch from 8192978. This one is about correcting the jlong format string in src/jdk.jdi/share/native/libdt_shmem/shmemBase.c. Bug: https://bugs.openjdk.java.net/browse/JDK-8193183 WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8193183.0/ I believe the libdt_shmem is only built on windows. Thanks, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Thu Dec 7 16:38:47 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Dec 2017 11:38:47 -0500 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment Message-ID: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> Greetings, I have a small fix for a very intermittent ServerSocket related test failure: ??? JDK-8182307: Error during JRMP connection establishment ??? https://bugs.openjdk.java.net/browse/JDK-8182307 The fix is copied from Jerry's work on the following bugs: ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris ??? https://bugs.openjdk.java.net/browse/JDK-8182757 ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception ??? https://bugs.openjdk.java.net/browse/JDK-8178676 For the gory details of the reasons for this fix please see Jerry's bugs. Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ I observed this test failure one time in my Thread-SMR work and have been including this fix in months of Thread-SMR stress testing. It was also included in both JPRT and Mach5 tier[1-5] testing of the Thread-SMR changes. Thanks, in advance, for any comments, suggestions or questions. Dan From chris.plummer at oracle.com Thu Dec 7 16:49:37 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 7 Dec 2017 08:49:37 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: <836bf838-409c-17c8-c3aa-04065a41c5fb@oracle.com> References: <721a9b28-5d3b-bd35-4d6d-5aa9d693c778@oracle.com> <2fbe6bf9-afd6-2fa8-3d70-edf83278fe43@oracle.com> <09479812-7023-7567-4016-539111001ea7@oracle.com> <181e26de-de69-273b-ae14-68aebc546411@oracle.com> <836bf838-409c-17c8-c3aa-04065a41c5fb@oracle.com> Message-ID: <896a74dd-3b4f-19b7-adea-d0d74e04267a@oracle.com> On 12/7/17 2:41 AM, David Holmes wrote: > Hi Chris, > > On 7/12/2017 5:44 PM, Chris Plummer wrote: >> New webrev: >> >> https://bugs.openjdk.java.net/browse/JDK-8191229 >> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/ >> >> testClass now initialized from JNI_OnLoad(), and use memset to clear >> callbacks. Also updated to use JVMTI_VERSION_9 when calling GetEnv(). > > ? 71???????? // JNI_OnLoad has not been called yet, so can't possibly > be an instance of TEST_CLASS. > > You can't be executing this method before JNI_OnLoad has executed. If > JNI_Onload has executed then you can't execute this method and find > NULL as that means JNI_Onload failed and hence library loading fails > and so you can't be executing this method. So this method reduces to a > simple instanceof check, which can go straight into the calling method. That's what I thought, but it was crashing because testClass was NULL. I think Agent_OnLoad() is being called before JNI_OnLoad. I'll add traces and see for sure. Chris > > ?183???? if (testClass == NULL) { > > That can just be "else {" - but as I said it can't be NULL anyway. > > Thanks, > David > >> thanks, >> >> Chris From chris.plummer at oracle.com Thu Dec 7 16:51:45 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 7 Dec 2017 08:51:45 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: <1fcf0aa0-49b6-3c8d-8794-6cbdc7ccd24d@gmail.com> References: <721a9b28-5d3b-bd35-4d6d-5aa9d693c778@oracle.com> <2fbe6bf9-afd6-2fa8-3d70-edf83278fe43@oracle.com> <09479812-7023-7567-4016-539111001ea7@oracle.com> <181e26de-de69-273b-ae14-68aebc546411@oracle.com> <1fcf0aa0-49b6-3c8d-8794-6cbdc7ccd24d@gmail.com> Message-ID: <97f62dcd-a564-be69-c378-fc0342788274@oracle.com> Hi Yasumasa, It is safe in my version because I move it to a global ref. See the NewGlobalRef() call in my webrev. thanks, Chris On 12/7/17 6:14 AM, Yasumasa Suenaga wrote: > Hi Chris, > > I added testcase of GetOwnedMonitorInfo in JDK-8185164. > I have concern your change to cache the result of FindClass(). > > According to [1], FindClass() calls find_class_from_class_loader(), it > returns JNI local value. > Is it safe to cache? > > So I called FindClass each time in original commit. > > > Thanks, > > Yasumasa > > > [1] > http://hg.openjdk.java.net/jdk/hs/file/32fd4be602d5/src/hotspot/share/prims/jvm.cpp#l3450 > > > On 2017/12/07 16:44, Chris Plummer wrote: >> New webrev: >> >> https://bugs.openjdk.java.net/browse/JDK-8191229 >> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/ >> >> testClass now initialized from JNI_OnLoad(), and use memset to clear >> callbacks. Also updated to use JVMTI_VERSION_9 when calling GetEnv(). >> >> thanks, >> >> Chris >> From daniel.daugherty at oracle.com Thu Dec 7 16:55:57 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Dec 2017 11:55:57 -0500 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> Message-ID: <0a36c975-8bca-c618-9133-66348f145436@oracle.com> Adding core-libs-dev at ... since this is RMI code. Thanks Alan! Folks, this review spans three OpenJDK aliases so Thunderbird's reply-to-list feature won't get it right. This is one of the few times that reply-to-all is the right thing to do... Dan On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: > Greetings, > > I have a small fix for a very intermittent ServerSocket related test > failure: > > ??? JDK-8182307: Error during JRMP connection establishment > ??? https://bugs.openjdk.java.net/browse/JDK-8182307 > > The fix is copied from Jerry's work on the following bugs: > > ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris > ??? https://bugs.openjdk.java.net/browse/JDK-8182757 > > ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception > ??? https://bugs.openjdk.java.net/browse/JDK-8178676 > > For the gory details of the reasons for this fix please see > Jerry's bugs. > > Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ > > > I observed this test failure one time in my Thread-SMR work and have > been including this fix in months of Thread-SMR stress testing. It was > also included in both JPRT and Mach5 tier[1-5] testing of the Thread-SMR > changes. > > Thanks, in advance, for any comments, suggestions or questions. > > Dan > From gerald.thornbrugh at oracle.com Thu Dec 7 17:00:43 2017 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Thu, 7 Dec 2017 10:00:43 -0700 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: <0a36c975-8bca-c618-9133-66348f145436@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <0a36c975-8bca-c618-9133-66348f145436@oracle.com> Message-ID: Hi Dan, Your fix looks good. Jerry > Adding core-libs-dev at ... since this is RMI code. Thanks Alan! > > Folks, this review spans three OpenJDK aliases so Thunderbird's > reply-to-list feature won't get it right. This is one of the > few times that reply-to-all is the right thing to do... > > Dan > > On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a small fix for a very intermittent ServerSocket related test >> failure: >> >> ??? JDK-8182307: Error during JRMP connection establishment >> ??? https://bugs.openjdk.java.net/browse/JDK-8182307 >> >> The fix is copied from Jerry's work on the following bugs: >> >> ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >> ??? https://bugs.openjdk.java.net/browse/JDK-8182757 >> >> ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception >> ??? https://bugs.openjdk.java.net/browse/JDK-8178676 >> >> For the gory details of the reasons for this fix please see >> Jerry's bugs. >> >> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >> >> >> I observed this test failure one time in my Thread-SMR work and have >> been including this fix in months of Thread-SMR stress testing. It was >> also included in both JPRT and Mach5 tier[1-5] testing of the Thread-SMR >> changes. >> >> Thanks, in advance, for any comments, suggestions or questions. >> >> Dan >> > From daniel.daugherty at oracle.com Thu Dec 7 17:05:52 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Dec 2017 12:05:52 -0500 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <0a36c975-8bca-c618-9133-66348f145436@oracle.com> Message-ID: <3c719cde-b764-5582-67c9-33ff7cf95661@oracle.com> Jerry, Thanks for the review! Dan On 12/7/17 12:00 PM, Gerald Thornbrugh wrote: > Hi Dan, > > Your fix looks good. > > Jerry > >> Adding core-libs-dev at ... since this is RMI code. Thanks Alan! >> >> Folks, this review spans three OpenJDK aliases so Thunderbird's >> reply-to-list feature won't get it right. This is one of the >> few times that reply-to-all is the right thing to do... >> >> Dan >> >> On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a small fix for a very intermittent ServerSocket related test >>> failure: >>> >>> ??? JDK-8182307: Error during JRMP connection establishment >>> ??? https://bugs.openjdk.java.net/browse/JDK-8182307 >>> >>> The fix is copied from Jerry's work on the following bugs: >>> >>> ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >>> ??? https://bugs.openjdk.java.net/browse/JDK-8182757 >>> >>> ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception >>> ??? https://bugs.openjdk.java.net/browse/JDK-8178676 >>> >>> For the gory details of the reasons for this fix please see >>> Jerry's bugs. >>> >>> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>> >>> >>> I observed this test failure one time in my Thread-SMR work and have >>> been including this fix in months of Thread-SMR stress testing. It was >>> also included in both JPRT and Mach5 tier[1-5] testing of the >>> Thread-SMR >>> changes. >>> >>> Thanks, in advance, for any comments, suggestions or questions. >>> >>> Dan >>> >> > From Roger.Riggs at Oracle.com Thu Dec 7 17:07:13 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 7 Dec 2017 12:07:13 -0500 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <0a36c975-8bca-c618-9133-66348f145436@oracle.com> Message-ID: +1 On 12/7/2017 12:00 PM, Gerald Thornbrugh wrote: > Hi Dan, > > Your fix looks good. > > Jerry > >> Adding core-libs-dev at ... since this is RMI code. Thanks Alan! >> >> Folks, this review spans three OpenJDK aliases so Thunderbird's >> reply-to-list feature won't get it right. This is one of the >> few times that reply-to-all is the right thing to do... >> >> Dan >> >> On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a small fix for a very intermittent ServerSocket related test >>> failure: >>> >>> ??? JDK-8182307: Error during JRMP connection establishment >>> ??? https://bugs.openjdk.java.net/browse/JDK-8182307 >>> >>> The fix is copied from Jerry's work on the following bugs: >>> >>> ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >>> ??? https://bugs.openjdk.java.net/browse/JDK-8182757 >>> >>> ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception >>> ??? https://bugs.openjdk.java.net/browse/JDK-8178676 >>> >>> For the gory details of the reasons for this fix please see >>> Jerry's bugs. >>> >>> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>> >>> >>> I observed this test failure one time in my Thread-SMR work and have >>> been including this fix in months of Thread-SMR stress testing. It was >>> also included in both JPRT and Mach5 tier[1-5] testing of the >>> Thread-SMR >>> changes. >>> >>> Thanks, in advance, for any comments, suggestions or questions. >>> >>> Dan >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Thu Dec 7 17:09:19 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Dec 2017 12:09:19 -0500 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <0a36c975-8bca-c618-9133-66348f145436@oracle.com> Message-ID: <35163e84-b100-1b85-3179-a58699163fc5@oracle.com> Roger, Thanks for the review! Dan P.S. I'm planning to push this fix to jdk/hs since the only sightings have been in jdk/hs testing or in projects that are parented to jdk/hs repos... Hope that's okay... On 12/7/17 12:07 PM, Roger Riggs wrote: > +1 > > On 12/7/2017 12:00 PM, Gerald Thornbrugh wrote: >> Hi Dan, >> >> Your fix looks good. >> >> Jerry >> >>> Adding core-libs-dev at ... since this is RMI code. Thanks Alan! >>> >>> Folks, this review spans three OpenJDK aliases so Thunderbird's >>> reply-to-list feature won't get it right. This is one of the >>> few times that reply-to-all is the right thing to do... >>> >>> Dan >>> >>> On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have a small fix for a very intermittent ServerSocket related test >>>> failure: >>>> >>>> ??? JDK-8182307: Error during JRMP connection establishment >>>> https://bugs.openjdk.java.net/browse/JDK-8182307 >>>> >>>> The fix is copied from Jerry's work on the following bugs: >>>> >>>> ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >>>> https://bugs.openjdk.java.net/browse/JDK-8182757 >>>> >>>> ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with >>>> Exception >>>> https://bugs.openjdk.java.net/browse/JDK-8178676 >>>> >>>> For the gory details of the reasons for this fix please see >>>> Jerry's bugs. >>>> >>>> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>>> >>>> >>>> I observed this test failure one time in my Thread-SMR work and have >>>> been including this fix in months of Thread-SMR stress testing. It was >>>> also included in both JPRT and Mach5 tier[1-5] testing of the >>>> Thread-SMR >>>> changes. >>>> >>>> Thanks, in advance, for any comments, suggestions or questions. >>>> >>>> Dan >>>> >>> >> > From chris.plummer at oracle.com Thu Dec 7 17:27:53 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 7 Dec 2017 09:27:53 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: <896a74dd-3b4f-19b7-adea-d0d74e04267a@oracle.com> References: <721a9b28-5d3b-bd35-4d6d-5aa9d693c778@oracle.com> <2fbe6bf9-afd6-2fa8-3d70-edf83278fe43@oracle.com> <09479812-7023-7567-4016-539111001ea7@oracle.com> <181e26de-de69-273b-ae14-68aebc546411@oracle.com> <836bf838-409c-17c8-c3aa-04065a41c5fb@oracle.com> <896a74dd-3b4f-19b7-adea-d0d74e04267a@oracle.com> Message-ID: <634a4f5d-5102-5f75-3f8f-1581510f0644@oracle.com> On 12/7/17 8:49 AM, Chris Plummer wrote: > On 12/7/17 2:41 AM, David Holmes wrote: >> Hi Chris, >> >> On 7/12/2017 5:44 PM, Chris Plummer wrote: >>> New webrev: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8191229 >>> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/ >>> >>> testClass now initialized from JNI_OnLoad(), and use memset to clear >>> callbacks. Also updated to use JVMTI_VERSION_9 when calling GetEnv(). >> >> ? 71???????? // JNI_OnLoad has not been called yet, so can't possibly >> be an instance of TEST_CLASS. >> >> You can't be executing this method before JNI_OnLoad has executed. If >> JNI_Onload has executed then you can't execute this method and find >> NULL as that means JNI_Onload failed and hence library loading fails >> and so you can't be executing this method. So this method reduces to >> a simple instanceof check, which can go straight into the calling >> method. > That's what I thought, but it was crashing because testClass was NULL. > I think Agent_OnLoad() is being called before JNI_OnLoad. I'll add > traces and see for sure. Printfs confirm that (at least in the one run I just did) Agent_OnLoad() was called before JNI_OnLoad(). However, I'm not certain that is always the case, because before I put the NULL check in, it only crashed 12 out of 50 times. 2 of those were on a linux-x64 product build and the rest were on the macosx debug build. Debug builds on Windows, solaris, and linux were fine. I'm not certain of the call environment for either of these functions, but I can at least see that Agent_OnLoad() is called on a different thread than JNI_OnLoad(), which is called on the test's main thread. So a race is seems possible. Chris > > Chris >> >> ?183???? if (testClass == NULL) { >> >> That can just be "else {" - but as I said it can't be NULL anyway. >> >> Thanks, >> David >> >>> thanks, >>> >>> Chris > > > From serguei.spitsyn at oracle.com Thu Dec 7 18:08:07 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 7 Dec 2017 10:08:07 -0800 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: <35163e84-b100-1b85-3179-a58699163fc5@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <0a36c975-8bca-c618-9133-66348f145436@oracle.com> <35163e84-b100-1b85-3179-a58699163fc5@oracle.com> Message-ID: Hi Dan, The fix looks good to me. Nice, you have caught it. Do you want this fixed in 10 or 11? I thought that the jdk/hs is for 11 now. Is it correct? Thanks, Serguei On 12/7/17 09:09, Daniel D. Daugherty wrote: > Roger, > > Thanks for the review! > > Dan > > P.S. > I'm planning to push this fix to jdk/hs since the only sightings > have been in jdk/hs testing or in projects that are parented to > jdk/hs repos... Hope that's okay... > > > On 12/7/17 12:07 PM, Roger Riggs wrote: >> +1 >> >> On 12/7/2017 12:00 PM, Gerald Thornbrugh wrote: >>> Hi Dan, >>> >>> Your fix looks good. >>> >>> Jerry >>> >>>> Adding core-libs-dev at ... since this is RMI code. Thanks Alan! >>>> >>>> Folks, this review spans three OpenJDK aliases so Thunderbird's >>>> reply-to-list feature won't get it right. This is one of the >>>> few times that reply-to-all is the right thing to do... >>>> >>>> Dan >>>> >>>> On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I have a small fix for a very intermittent ServerSocket related test >>>>> failure: >>>>> >>>>> ??? JDK-8182307: Error during JRMP connection establishment >>>>> https://bugs.openjdk.java.net/browse/JDK-8182307 >>>>> >>>>> The fix is copied from Jerry's work on the following bugs: >>>>> >>>>> ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >>>>> https://bugs.openjdk.java.net/browse/JDK-8182757 >>>>> >>>>> ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with >>>>> Exception >>>>> https://bugs.openjdk.java.net/browse/JDK-8178676 >>>>> >>>>> For the gory details of the reasons for this fix please see >>>>> Jerry's bugs. >>>>> >>>>> Webrev URL: >>>>> http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>>>> >>>>> >>>>> I observed this test failure one time in my Thread-SMR work and have >>>>> been including this fix in months of Thread-SMR stress testing. It >>>>> was >>>>> also included in both JPRT and Mach5 tier[1-5] testing of the >>>>> Thread-SMR >>>>> changes. >>>>> >>>>> Thanks, in advance, for any comments, suggestions or questions. >>>>> >>>>> Dan >>>>> >>>> >>> >> > From chris.plummer at oracle.com Thu Dec 7 18:13:31 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 7 Dec 2017 10:13:31 -0800 Subject: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c In-Reply-To: References: Message-ID: <3dc667ae-52c6-3253-ad1d-5276500b6a02@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Dec 7 18:32:31 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 7 Dec 2017 10:32:31 -0800 Subject: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c In-Reply-To: <3dc667ae-52c6-3253-ad1d-5276500b6a02@oracle.com> References: <3dc667ae-52c6-3253-ad1d-5276500b6a02@oracle.com> Message-ID: <45d8bb8f-797a-5954-d9b4-d2a3d18ebea7@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Dec 7 18:36:35 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 7 Dec 2017 10:36:35 -0800 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <0a36c975-8bca-c618-9133-66348f145436@oracle.com> <35163e84-b100-1b85-3179-a58699163fc5@oracle.com> Message-ID: <968040bb-0923-a930-cab6-fce3e6d718a7@oracle.com> On 12/7/17 10:08, serguei.spitsyn at oracle.com wrote: > Hi Dan, > > The fix looks good to me. > Nice, you have caught it. > > Do you want this fixed in 10 or 11? > I thought that the jdk/hs is for 11 now. > Is it correct? Never mind. I've just found a message from Jesper the jdk/hs is used for 10 pushes for one more week. Thanks, Serguei > > Thanks, > Serguei > > > On 12/7/17 09:09, Daniel D. Daugherty wrote: >> Roger, >> >> Thanks for the review! >> >> Dan >> >> P.S. >> I'm planning to push this fix to jdk/hs since the only sightings >> have been in jdk/hs testing or in projects that are parented to >> jdk/hs repos... Hope that's okay... >> >> >> On 12/7/17 12:07 PM, Roger Riggs wrote: >>> +1 >>> >>> On 12/7/2017 12:00 PM, Gerald Thornbrugh wrote: >>>> Hi Dan, >>>> >>>> Your fix looks good. >>>> >>>> Jerry >>>> >>>>> Adding core-libs-dev at ... since this is RMI code. Thanks Alan! >>>>> >>>>> Folks, this review spans three OpenJDK aliases so Thunderbird's >>>>> reply-to-list feature won't get it right. This is one of the >>>>> few times that reply-to-all is the right thing to do... >>>>> >>>>> Dan >>>>> >>>>> On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I have a small fix for a very intermittent ServerSocket related test >>>>>> failure: >>>>>> >>>>>> ??? JDK-8182307: Error during JRMP connection establishment >>>>>> https://bugs.openjdk.java.net/browse/JDK-8182307 >>>>>> >>>>>> The fix is copied from Jerry's work on the following bugs: >>>>>> >>>>>> ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >>>>>> https://bugs.openjdk.java.net/browse/JDK-8182757 >>>>>> >>>>>> ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with >>>>>> Exception >>>>>> https://bugs.openjdk.java.net/browse/JDK-8178676 >>>>>> >>>>>> For the gory details of the reasons for this fix please see >>>>>> Jerry's bugs. >>>>>> >>>>>> Webrev URL: >>>>>> http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>>>>> >>>>>> >>>>>> I observed this test failure one time in my Thread-SMR work and have >>>>>> been including this fix in months of Thread-SMR stress testing. >>>>>> It was >>>>>> also included in both JPRT and Mach5 tier[1-5] testing of the >>>>>> Thread-SMR >>>>>> changes. >>>>>> >>>>>> Thanks, in advance, for any comments, suggestions or questions. >>>>>> >>>>>> Dan >>>>>> >>>>> >>>> >>> >> > From daniel.daugherty at oracle.com Thu Dec 7 18:46:27 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Dec 2017 13:46:27 -0500 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <0a36c975-8bca-c618-9133-66348f145436@oracle.com> <35163e84-b100-1b85-3179-a58699163fc5@oracle.com> Message-ID: On 12/7/17 1:08 PM, serguei.spitsyn at oracle.com wrote: > Hi Dan, > > The fix looks good to me. > Nice, you have caught it. Thanks for the review! > Do you want this fixed in 10 or 11? > I thought that the jdk/hs is for 11 now. > Is it correct? Please see Mark R's e-mail with the subject line of "JDK 10 enters Rampdown Phase One in one week". In short, the RDP1 deadline applies to jdk/jdk, jdk/hs and jdk/client all at the same time. Dan > > Thanks, > Serguei > > > On 12/7/17 09:09, Daniel D. Daugherty wrote: >> Roger, >> >> Thanks for the review! >> >> Dan >> >> P.S. >> I'm planning to push this fix to jdk/hs since the only sightings >> have been in jdk/hs testing or in projects that are parented to >> jdk/hs repos... Hope that's okay... >> >> >> On 12/7/17 12:07 PM, Roger Riggs wrote: >>> +1 >>> >>> On 12/7/2017 12:00 PM, Gerald Thornbrugh wrote: >>>> Hi Dan, >>>> >>>> Your fix looks good. >>>> >>>> Jerry >>>> >>>>> Adding core-libs-dev at ... since this is RMI code. Thanks Alan! >>>>> >>>>> Folks, this review spans three OpenJDK aliases so Thunderbird's >>>>> reply-to-list feature won't get it right. This is one of the >>>>> few times that reply-to-all is the right thing to do... >>>>> >>>>> Dan >>>>> >>>>> On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I have a small fix for a very intermittent ServerSocket related test >>>>>> failure: >>>>>> >>>>>> ??? JDK-8182307: Error during JRMP connection establishment >>>>>> https://bugs.openjdk.java.net/browse/JDK-8182307 >>>>>> >>>>>> The fix is copied from Jerry's work on the following bugs: >>>>>> >>>>>> ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >>>>>> https://bugs.openjdk.java.net/browse/JDK-8182757 >>>>>> >>>>>> ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with >>>>>> Exception >>>>>> https://bugs.openjdk.java.net/browse/JDK-8178676 >>>>>> >>>>>> For the gory details of the reasons for this fix please see >>>>>> Jerry's bugs. >>>>>> >>>>>> Webrev URL: >>>>>> http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>>>>> >>>>>> >>>>>> I observed this test failure one time in my Thread-SMR work and have >>>>>> been including this fix in months of Thread-SMR stress testing. >>>>>> It was >>>>>> also included in both JPRT and Mach5 tier[1-5] testing of the >>>>>> Thread-SMR >>>>>> changes. >>>>>> >>>>>> Thanks, in advance, for any comments, suggestions or questions. >>>>>> >>>>>> Dan >>>>>> >>>>> >>>> >>> >> > From alexey.menkov at oracle.com Thu Dec 7 18:50:47 2017 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 7 Dec 2017 10:50:47 -0800 Subject: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c In-Reply-To: References: Message-ID: <17f57253-bd8c-6e1d-385e-1d6e12a049da@oracle.com> Looks like we already have definitions to workaround Visual Studio issues (including absence of PRId64) in open/src/hotspot/share/utilities/globalDefinitions_visCPP.hpp It would be better to reuse it (to have all workarounds in a single place) I suppose to utilize it you need #include "utilities/globalDefinitions.hpp" It includes corresponding "globalDefinitions_*.hpp" depending on the compiler used. --alex On 12/07/2017 07:21, Langer, Christoph wrote: > Hi, > > please review the first extracted patch from 8192978. This one is about > correcting the jlong format string in > src/jdk.jdi/share/native/libdt_shmem/shmemBase.c. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193183 > > WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8193183.0/ > > I believe the libdt_shmem is only built on windows. > > Thanks, > > Christoph > From chris.plummer at oracle.com Thu Dec 7 18:51:41 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 7 Dec 2017 10:51:41 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: <634a4f5d-5102-5f75-3f8f-1581510f0644@oracle.com> References: <721a9b28-5d3b-bd35-4d6d-5aa9d693c778@oracle.com> <2fbe6bf9-afd6-2fa8-3d70-edf83278fe43@oracle.com> <09479812-7023-7567-4016-539111001ea7@oracle.com> <181e26de-de69-273b-ae14-68aebc546411@oracle.com> <836bf838-409c-17c8-c3aa-04065a41c5fb@oracle.com> <896a74dd-3b4f-19b7-adea-d0d74e04267a@oracle.com> <634a4f5d-5102-5f75-3f8f-1581510f0644@oracle.com> Message-ID: <3a9f9374-2498-c9b7-f5f4-fa0a5de3a1bb@oracle.com> On 12/7/17 9:27 AM, Chris Plummer wrote: > On 12/7/17 8:49 AM, Chris Plummer wrote: >> On 12/7/17 2:41 AM, David Holmes wrote: >>> Hi Chris, >>> >>> On 7/12/2017 5:44 PM, Chris Plummer wrote: >>>> New webrev: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8191229 >>>> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/ >>>> >>>> testClass now initialized from JNI_OnLoad(), and use memset to >>>> clear callbacks. Also updated to use JVMTI_VERSION_9 when calling >>>> GetEnv(). >>> >>> ? 71???????? // JNI_OnLoad has not been called yet, so can't >>> possibly be an instance of TEST_CLASS. >>> >>> You can't be executing this method before JNI_OnLoad has executed. >>> If JNI_Onload has executed then you can't execute this method and >>> find NULL as that means JNI_Onload failed and hence library loading >>> fails and so you can't be executing this method. So this method >>> reduces to a simple instanceof check, which can go straight into the >>> calling method. >> That's what I thought, but it was crashing because testClass was >> NULL. I think Agent_OnLoad() is being called before JNI_OnLoad. I'll >> add traces and see for sure. > Printfs confirm that (at least in the one run I just did) > Agent_OnLoad() was called before JNI_OnLoad(). However, I'm not > certain that is always the case, because before I put the NULL check > in, it only crashed 12 out of 50 times. 2 of those were on a linux-x64 > product build and the rest were on the macosx debug build. Debug > builds on Windows, solaris, and linux were fine. I'm not certain of > the call environment for either of these functions, but I can at least > see that Agent_OnLoad() is called on a different thread than > JNI_OnLoad(), which is called on the test's main thread. So a race is > seems possible. I think Agent_OnLoad() is always called before JNI_OnLoad(), but the reason is it only sometimes crashes without the NULL check is the same as the reason this bug exists in the first place. It requires an unexpected contended monitor callback, and that doesn't always happen before JNI_OnLoad is called. I think this might be another good reason to move the FindClass code to Agent_Initialize(), which is called by Agent_Onload(). It will guarantee that testClass is set before we setup the contended monitor callbacks. Chris > > Chris >> >> Chris >>> >>> ?183???? if (testClass == NULL) { >>> >>> That can just be "else {" - but as I said it can't be NULL anyway. >>> >>> Thanks, >>> David >>> >>>> thanks, >>>> >>>> Chris >> >> >> > > From christoph.langer at sap.com Thu Dec 7 19:02:34 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 7 Dec 2017 19:02:34 +0000 Subject: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c In-Reply-To: <3dc667ae-52c6-3253-ad1d-5276500b6a02@oracle.com> References: <3dc667ae-52c6-3253-ad1d-5276500b6a02@oracle.com> Message-ID: <80d026308d3c4975b5c4955c097eba75@sap.com> Thanks Chris and Serguei for reviewing. I can do the push myself as it isn?t hotspot. I?ll send out other webrevs tomorrow for the other stuff. Best regards Christoph From: Chris Plummer [mailto:chris.plummer at oracle.com] Sent: Donnerstag, 7. Dezember 2017 19:14 To: Langer, Christoph ; serviceability-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: Re: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c Looks good to me. I can sponsor the push for you. thanks, Chris On 12/7/17 7:21 AM, Langer, Christoph wrote: Hi, please review the first extracted patch from 8192978. This one is about correcting the jlong format string in src/jdk.jdi/share/native/libdt_shmem/shmemBase.c. Bug: https://bugs.openjdk.java.net/browse/JDK-8193183 WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8193183.0/ I believe the libdt_shmem is only built on windows. Thanks, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Dec 7 19:19:00 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 7 Dec 2017 11:19:00 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: <3a9f9374-2498-c9b7-f5f4-fa0a5de3a1bb@oracle.com> References: <721a9b28-5d3b-bd35-4d6d-5aa9d693c778@oracle.com> <2fbe6bf9-afd6-2fa8-3d70-edf83278fe43@oracle.com> <09479812-7023-7567-4016-539111001ea7@oracle.com> <181e26de-de69-273b-ae14-68aebc546411@oracle.com> <836bf838-409c-17c8-c3aa-04065a41c5fb@oracle.com> <896a74dd-3b4f-19b7-adea-d0d74e04267a@oracle.com> <634a4f5d-5102-5f75-3f8f-1581510f0644@oracle.com> <3a9f9374-2498-c9b7-f5f4-fa0a5de3a1bb@oracle.com> Message-ID: On 12/7/17 10:51 AM, Chris Plummer wrote: > On 12/7/17 9:27 AM, Chris Plummer wrote: >> On 12/7/17 8:49 AM, Chris Plummer wrote: >>> On 12/7/17 2:41 AM, David Holmes wrote: >>>> Hi Chris, >>>> >>>> On 7/12/2017 5:44 PM, Chris Plummer wrote: >>>>> New webrev: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8191229 >>>>> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/ >>>>> >>>>> testClass now initialized from JNI_OnLoad(), and use memset to >>>>> clear callbacks. Also updated to use JVMTI_VERSION_9 when calling >>>>> GetEnv(). >>>> >>>> ? 71???????? // JNI_OnLoad has not been called yet, so can't >>>> possibly be an instance of TEST_CLASS. >>>> >>>> You can't be executing this method before JNI_OnLoad has executed. >>>> If JNI_Onload has executed then you can't execute this method and >>>> find NULL as that means JNI_Onload failed and hence library loading >>>> fails and so you can't be executing this method. So this method >>>> reduces to a simple instanceof check, which can go straight into >>>> the calling method. >>> That's what I thought, but it was crashing because testClass was >>> NULL. I think Agent_OnLoad() is being called before JNI_OnLoad. I'll >>> add traces and see for sure. >> Printfs confirm that (at least in the one run I just did) >> Agent_OnLoad() was called before JNI_OnLoad(). However, I'm not >> certain that is always the case, because before I put the NULL check >> in, it only crashed 12 out of 50 times. 2 of those were on a >> linux-x64 product build and the rest were on the macosx debug build. >> Debug builds on Windows, solaris, and linux were fine. I'm not >> certain of the call environment for either of these functions, but I >> can at least see that Agent_OnLoad() is called on a different thread >> than JNI_OnLoad(), which is called on the test's main thread. So a >> race is seems possible. > I think Agent_OnLoad() is always called before JNI_OnLoad(), but the > reason is it only sometimes crashes without the NULL check is the same > as the reason this bug exists in the first place. It requires an > unexpected contended monitor callback, and that doesn't always happen > before JNI_OnLoad is called. > > I think this might be another good reason to move the FindClass code > to Agent_Initialize(), which is called by Agent_Onload(). It will > guarantee that testClass is set before we setup the contended monitor > callbacks. Well, that won't work. GetEnv() for a JNIEnv returns JNI_EDETACHED when called from Agent_OnLoad(). So I think that means I'm sticking with the last webrev and leaving the NULL check of testClass in place. Chris > > Chris >> >> Chris >>> >>> Chris >>>> >>>> ?183???? if (testClass == NULL) { >>>> >>>> That can just be "else {" - but as I said it can't be NULL anyway. >>>> >>>> Thanks, >>>> David >>>> >>>>> thanks, >>>>> >>>>> Chris >>> >>> >>> >> >> > > From chris.plummer at oracle.com Thu Dec 7 19:25:00 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 7 Dec 2017 11:25:00 -0800 Subject: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c In-Reply-To: <17f57253-bd8c-6e1d-385e-1d6e12a049da@oracle.com> References: <17f57253-bd8c-6e1d-385e-1d6e12a049da@oracle.com> Message-ID: <6e5f6093-80a9-5671-d0b9-556f67383505@oracle.com> I had noticed that when I first looked at these changes, but figured that JDI code cannot leverage globalDefinitions.hpp. However, I'm not certain of that. Chris On 12/7/17 10:50 AM, Alex Menkov wrote: > Looks like we already have definitions to workaround Visual Studio > issues (including absence of PRId64) in > open/src/hotspot/share/utilities/globalDefinitions_visCPP.hpp > It would be better to reuse it (to have all workarounds in a single > place) > > I suppose to utilize it you need > #include "utilities/globalDefinitions.hpp" > It includes corresponding "globalDefinitions_*.hpp" depending on the > compiler used. > > --alex > > On 12/07/2017 07:21, Langer, Christoph wrote: >> Hi, >> >> please review the first extracted patch from 8192978. This one is >> about correcting the jlong format string in >> src/jdk.jdi/share/native/libdt_shmem/shmemBase.c. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8193183 >> >> WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8193183.0/ >> >> I believe the libdt_shmem is only built on windows. >> >> Thanks, >> >> Christoph >> From chris.plummer at oracle.com Thu Dec 7 19:26:25 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 7 Dec 2017 11:26:25 -0800 Subject: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c In-Reply-To: <80d026308d3c4975b5c4955c097eba75@sap.com> References: <3dc667ae-52c6-3253-ad1d-5276500b6a02@oracle.com> <80d026308d3c4975b5c4955c097eba75@sap.com> Message-ID: An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Dec 7 19:27:22 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 7 Dec 2017 11:27:22 -0800 Subject: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c In-Reply-To: References: <3dc667ae-52c6-3253-ad1d-5276500b6a02@oracle.com> <80d026308d3c4975b5c4955c097eba75@sap.com> Message-ID: <64da2314-c060-a8b9-e026-63a77dcfb111@oracle.com> An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Thu Dec 7 20:16:10 2017 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 7 Dec 2017 12:16:10 -0800 Subject: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c In-Reply-To: <6e5f6093-80a9-5671-d0b9-556f67383505@oracle.com> References: <17f57253-bd8c-6e1d-385e-1d6e12a049da@oracle.com> <6e5f6093-80a9-5671-d0b9-556f67383505@oracle.com> Message-ID: <90607de6-2be9-e8ee-ef26-069b1d8d5f7f@oracle.com> well, maybe code duplication is lesser evil in the case :) --alex On 12/07/2017 11:25, Chris Plummer wrote: > I had noticed that when I first looked at these changes, but figured > that JDI code cannot leverage globalDefinitions.hpp. However, I'm not > certain of that. > > Chris > > On 12/7/17 10:50 AM, Alex Menkov wrote: >> Looks like we already have definitions to workaround Visual Studio >> issues (including absence of PRId64) in >> open/src/hotspot/share/utilities/globalDefinitions_visCPP.hpp >> It would be better to reuse it (to have all workarounds in a single >> place) >> >> I suppose to utilize it you need >> #include "utilities/globalDefinitions.hpp" >> It includes corresponding "globalDefinitions_*.hpp" depending on the >> compiler used. >> >> --alex >> >> On 12/07/2017 07:21, Langer, Christoph wrote: >>> Hi, >>> >>> please review the first extracted patch from 8192978. This one is >>> about correcting the jlong format string in >>> src/jdk.jdi/share/native/libdt_shmem/shmemBase.c. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193183 >>> >>> WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8193183.0/ >>> >>> I believe the libdt_shmem is only built on windows. >>> >>> Thanks, >>> >>> Christoph >>> > From christoph.langer at sap.com Thu Dec 7 21:28:36 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 7 Dec 2017 21:28:36 +0000 Subject: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c In-Reply-To: References: <3dc667ae-52c6-3253-ad1d-5276500b6a02@oracle.com> <80d026308d3c4975b5c4955c097eba75@sap.com> Message-ID: <7a449df5e4814191b83e074bc53e0a0e@sap.com> Hi Chris, ok, I understand. Then please let me know when you're done or ...in that case you might as well do the push.:) Thanks Christoph From: Chris Plummer [mailto:chris.plummer at oracle.com] Sent: Donnerstag, 7. Dezember 2017 20:26 To: Langer, Christoph ; serviceability-dev at openjdk.java.net; serguei.spitsyn at oracle.com Cc: Lindenmaier, Goetz Subject: Re: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c Hi Christoph, You can do the push, but please let me do some internal testing first. I want to make sure all our platforms are covered, and our closed tests are turn. thanks, Chris On 12/7/17 11:02 AM, Langer, Christoph wrote: Thanks Chris and Serguei for reviewing. I can do the push myself as it isn't hotspot. I'll send out other webrevs tomorrow for the other stuff. Best regards Christoph From: Chris Plummer [mailto:chris.plummer at oracle.com] Sent: Donnerstag, 7. Dezember 2017 19:14 To: Langer, Christoph ; serviceability-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: Re: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c Looks good to me. I can sponsor the push for you. thanks, Chris On 12/7/17 7:21 AM, Langer, Christoph wrote: Hi, please review the first extracted patch from 8192978. This one is about correcting the jlong format string in src/jdk.jdi/share/native/libdt_shmem/shmemBase.c. Bug: https://bugs.openjdk.java.net/browse/JDK-8193183 WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8193183.0/ I believe the libdt_shmem is only built on windows. Thanks, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Fri Dec 8 00:45:32 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Dec 2017 19:45:32 -0500 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> Message-ID: <5f349300-a8a6-1df5-fb8e-11be4b8b625b@oracle.com> Greetings, My fix for the following bug: ??? JDK-8182307: Error during JRMP connection establishment ??? https://bugs.openjdk.java.net/browse/JDK-8182307 broke two hs-tier3 tests. I'm backing out the fix via: ??? JDK-8193225 [BACKOUT] fix for 8182307 Error during JRMP connection establishment ??? https://bugs.openjdk.java.net/browse/JDK-8193225 Here's the webrev: ??? http://cr.openjdk.java.net/~dcubed/8193225-webrev/jdk10-0/ This is a simple "hg backout". I need a single (R)eviewer. Thanks! Dan On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: > Greetings, > > I have a small fix for a very intermittent ServerSocket related test > failure: > > ??? JDK-8182307: Error during JRMP connection establishment > ??? https://bugs.openjdk.java.net/browse/JDK-8182307 > > The fix is copied from Jerry's work on the following bugs: > > ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris > ??? https://bugs.openjdk.java.net/browse/JDK-8182757 > > ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception > ??? https://bugs.openjdk.java.net/browse/JDK-8178676 > > For the gory details of the reasons for this fix please see > Jerry's bugs. > > Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ > > > I observed this test failure one time in my Thread-SMR work and have > been including this fix in months of Thread-SMR stress testing. It was > also included in both JPRT and Mach5 tier[1-5] testing of the Thread-SMR > changes. > > Thanks, in advance, for any comments, suggestions or questions. > > Dan > From daniel.daugherty at oracle.com Fri Dec 8 00:46:29 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Dec 2017 19:46:29 -0500 Subject: URGENT RFR(XXS): 8193225 - [BACKOUT] fix for 8182307 Error during JRMP connection In-Reply-To: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> Message-ID: <75b321b3-c844-3ec7-352c-32d2817d67a3@oracle.com> Resending with the correct subject line! Greetings, My fix for the following bug: ??? JDK-8182307: Error during JRMP connection establishment ??? https://bugs.openjdk.java.net/browse/JDK-8182307 broke two hs-tier3 tests. I'm backing out the fix via: ??? JDK-8193225 [BACKOUT] fix for 8182307 Error during JRMP connection establishment ??? https://bugs.openjdk.java.net/browse/JDK-8193225 Here's the webrev: ??? http://cr.openjdk.java.net/~dcubed/8193225-webrev/jdk10-0/ This is a simple "hg backout". I need a single (R)eviewer. Thanks! Dan On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: > Greetings, > > I have a small fix for a very intermittent ServerSocket related test > failure: > > ??? JDK-8182307: Error during JRMP connection establishment > ??? https://bugs.openjdk.java.net/browse/JDK-8182307 > > The fix is copied from Jerry's work on the following bugs: > > ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris > ??? https://bugs.openjdk.java.net/browse/JDK-8182757 > > ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception > ??? https://bugs.openjdk.java.net/browse/JDK-8178676 > > For the gory details of the reasons for this fix please see > Jerry's bugs. > > Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ > > > I observed this test failure one time in my Thread-SMR work and have > been including this fix in months of Thread-SMR stress testing. It was > also included in both JPRT and Mach5 tier[1-5] testing of the Thread-SMR > changes. > > Thanks, in advance, for any comments, suggestions or questions. > > Dan > From igor.ignatyev at oracle.com Fri Dec 8 00:57:31 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 7 Dec 2017 16:57:31 -0800 Subject: URGENT RFR(XXS): 8193225 - [BACKOUT] fix for 8182307 Error during JRMP connection In-Reply-To: <75b321b3-c844-3ec7-352c-32d2817d67a3@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <75b321b3-c844-3ec7-352c-32d2817d67a3@oracle.com> Message-ID: <9A41D422-55E0-4AFE-B7CC-469815E5928C@oracle.com> Reviewed. -- Igor > On Dec 7, 2017, at 4:46 PM, Daniel D. Daugherty wrote: > > Resending with the correct subject line! > > > Greetings, > > My fix for the following bug: > > JDK-8182307: Error during JRMP connection establishment > https://bugs.openjdk.java.net/browse/JDK-8182307 > > broke two hs-tier3 tests. I'm backing out the fix via: > > JDK-8193225 [BACKOUT] fix for 8182307 Error during JRMP connection establishment > https://bugs.openjdk.java.net/browse/JDK-8193225 > > Here's the webrev: > > http://cr.openjdk.java.net/~dcubed/8193225-webrev/jdk10-0/ > > This is a simple "hg backout". I need a single (R)eviewer. Thanks! > > Dan > > > > On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a small fix for a very intermittent ServerSocket related test >> failure: >> >> JDK-8182307: Error during JRMP connection establishment >> https://bugs.openjdk.java.net/browse/JDK-8182307 >> >> The fix is copied from Jerry's work on the following bugs: >> >> JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >> https://bugs.openjdk.java.net/browse/JDK-8182757 >> >> JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception >> https://bugs.openjdk.java.net/browse/JDK-8178676 >> >> For the gory details of the reasons for this fix please see >> Jerry's bugs. >> >> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >> >> >> I observed this test failure one time in my Thread-SMR work and have >> been including this fix in months of Thread-SMR stress testing. It was >> also included in both JPRT and Mach5 tier[1-5] testing of the Thread-SMR >> changes. >> >> Thanks, in advance, for any comments, suggestions or questions. >> >> Dan >> > From daniel.daugherty at oracle.com Fri Dec 8 01:06:11 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Dec 2017 20:06:11 -0500 Subject: URGENT RFR(XXS): 8193225 - [BACKOUT] fix for 8182307 Error during JRMP connection In-Reply-To: <9A41D422-55E0-4AFE-B7CC-469815E5928C@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <75b321b3-c844-3ec7-352c-32d2817d67a3@oracle.com> <9A41D422-55E0-4AFE-B7CC-469815E5928C@oracle.com> Message-ID: <2cf54ae8-db16-6c88-ff49-6f4fb82d9064@oracle.com> Thanks Igor! Dan On 12/7/17 7:57 PM, Igor Ignatyev wrote: > Reviewed. > > -- Igor > >> On Dec 7, 2017, at 4:46 PM, Daniel D. Daugherty wrote: >> >> Resending with the correct subject line! >> >> >> Greetings, >> >> My fix for the following bug: >> >> JDK-8182307: Error during JRMP connection establishment >> https://bugs.openjdk.java.net/browse/JDK-8182307 >> >> broke two hs-tier3 tests. I'm backing out the fix via: >> >> JDK-8193225 [BACKOUT] fix for 8182307 Error during JRMP connection establishment >> https://bugs.openjdk.java.net/browse/JDK-8193225 >> >> Here's the webrev: >> >> http://cr.openjdk.java.net/~dcubed/8193225-webrev/jdk10-0/ >> >> This is a simple "hg backout". I need a single (R)eviewer. Thanks! >> >> Dan >> >> >> >> On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a small fix for a very intermittent ServerSocket related test >>> failure: >>> >>> JDK-8182307: Error during JRMP connection establishment >>> https://bugs.openjdk.java.net/browse/JDK-8182307 >>> >>> The fix is copied from Jerry's work on the following bugs: >>> >>> JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >>> https://bugs.openjdk.java.net/browse/JDK-8182757 >>> >>> JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception >>> https://bugs.openjdk.java.net/browse/JDK-8178676 >>> >>> For the gory details of the reasons for this fix please see >>> Jerry's bugs. >>> >>> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>> >>> >>> I observed this test failure one time in my Thread-SMR work and have >>> been including this fix in months of Thread-SMR stress testing. It was >>> also included in both JPRT and Mach5 tier[1-5] testing of the Thread-SMR >>> changes. >>> >>> Thanks, in advance, for any comments, suggestions or questions. >>> >>> Dan >>> From yasuenag at gmail.com Fri Dec 8 01:13:40 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 8 Dec 2017 10:13:40 +0900 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: <97f62dcd-a564-be69-c378-fc0342788274@oracle.com> References: <721a9b28-5d3b-bd35-4d6d-5aa9d693c778@oracle.com> <2fbe6bf9-afd6-2fa8-3d70-edf83278fe43@oracle.com> <09479812-7023-7567-4016-539111001ea7@oracle.com> <181e26de-de69-273b-ae14-68aebc546411@oracle.com> <1fcf0aa0-49b6-3c8d-8794-6cbdc7ccd24d@gmail.com> <97f62dcd-a564-be69-c378-fc0342788274@oracle.com> Message-ID: Hi Chris, Thanks! I did not see that. IMHO, you can move SetEventNotificationMode() to JNI_OnLoad(). If so, we ensure that CheckLockObject() is called after all initialization is completed. We can keep jvmtiEnv instance. Yasumasa 2017-12-08 1:51 GMT+09:00 Chris Plummer : > Hi Yasumasa, > > It is safe in my version because I move it to a global ref. See the > NewGlobalRef() call in my webrev. > > thanks, > > Chris > > > On 12/7/17 6:14 AM, Yasumasa Suenaga wrote: >> >> Hi Chris, >> >> I added testcase of GetOwnedMonitorInfo in JDK-8185164. >> I have concern your change to cache the result of FindClass(). >> >> According to [1], FindClass() calls find_class_from_class_loader(), it >> returns JNI local value. >> Is it safe to cache? >> >> So I called FindClass each time in original commit. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] >> http://hg.openjdk.java.net/jdk/hs/file/32fd4be602d5/src/hotspot/share/prims/jvm.cpp#l3450 >> >> >> On 2017/12/07 16:44, Chris Plummer wrote: >>> >>> New webrev: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8191229 >>> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/ >>> >>> testClass now initialized from JNI_OnLoad(), and use memset to clear >>> callbacks. Also updated to use JVMTI_VERSION_9 when calling GetEnv(). >>> >>> thanks, >>> >>> Chris >>> > From serguei.spitsyn at oracle.com Fri Dec 8 01:26:03 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 7 Dec 2017 17:26:03 -0800 Subject: URGENT RFR(XXS): 8193225 - [BACKOUT] fix for 8182307 Error during JRMP connection In-Reply-To: <9A41D422-55E0-4AFE-B7CC-469815E5928C@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <75b321b3-c844-3ec7-352c-32d2817d67a3@oracle.com> <9A41D422-55E0-4AFE-B7CC-469815E5928C@oracle.com> Message-ID: +1 Sorry, your fix broke two hs-tier3 tests. I've decided to always run all hs-tier's before any of my integrations. :( Thanks, Serguei On 12/7/17 16:57, Igor Ignatyev wrote: > Reviewed. > > -- Igor > >> On Dec 7, 2017, at 4:46 PM, Daniel D. Daugherty wrote: >> >> Resending with the correct subject line! >> >> >> Greetings, >> >> My fix for the following bug: >> >> JDK-8182307: Error during JRMP connection establishment >> https://bugs.openjdk.java.net/browse/JDK-8182307 >> >> broke two hs-tier3 tests. I'm backing out the fix via: >> >> JDK-8193225 [BACKOUT] fix for 8182307 Error during JRMP connection establishment >> https://bugs.openjdk.java.net/browse/JDK-8193225 >> >> Here's the webrev: >> >> http://cr.openjdk.java.net/~dcubed/8193225-webrev/jdk10-0/ >> >> This is a simple "hg backout". I need a single (R)eviewer. Thanks! >> >> Dan >> >> >> >> On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a small fix for a very intermittent ServerSocket related test >>> failure: >>> >>> JDK-8182307: Error during JRMP connection establishment >>> https://bugs.openjdk.java.net/browse/JDK-8182307 >>> >>> The fix is copied from Jerry's work on the following bugs: >>> >>> JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >>> https://bugs.openjdk.java.net/browse/JDK-8182757 >>> >>> JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception >>> https://bugs.openjdk.java.net/browse/JDK-8178676 >>> >>> For the gory details of the reasons for this fix please see >>> Jerry's bugs. >>> >>> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>> >>> >>> I observed this test failure one time in my Thread-SMR work and have >>> been including this fix in months of Thread-SMR stress testing. It was >>> also included in both JPRT and Mach5 tier[1-5] testing of the Thread-SMR >>> changes. >>> >>> Thanks, in advance, for any comments, suggestions or questions. >>> >>> Dan >>> From daniel.daugherty at oracle.com Fri Dec 8 01:31:26 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Dec 2017 20:31:26 -0500 Subject: URGENT RFR(XXS): 8193225 - [BACKOUT] fix for 8182307 Error during JRMP connection In-Reply-To: References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <75b321b3-c844-3ec7-352c-32d2817d67a3@oracle.com> <9A41D422-55E0-4AFE-B7CC-469815E5928C@oracle.com> Message-ID: On 12/7/17 8:26 PM, serguei.spitsyn at oracle.com wrote: > +1 > > Sorry, your fix broke two hs-tier3 tests. Me too! > I've decided to always run all hs-tier's before any of my > integrations. :( My last test run with the fix for 8182307 by itself was a Mach5 tier[1-5] job on 11.22... There were no RMI test failures... I cannot explain what happened (yet)... Dan > > Thanks, > Serguei > > > On 12/7/17 16:57, Igor Ignatyev wrote: >> Reviewed. >> >> -- Igor >> >>> On Dec 7, 2017, at 4:46 PM, Daniel D. Daugherty >>> wrote: >>> >>> Resending with the correct subject line! >>> >>> >>> Greetings, >>> >>> My fix for the following bug: >>> >>> ???? JDK-8182307: Error during JRMP connection establishment >>> ???? https://bugs.openjdk.java.net/browse/JDK-8182307 >>> >>> broke two hs-tier3 tests. I'm backing out the fix via: >>> >>> ???? JDK-8193225 [BACKOUT] fix for 8182307 Error during JRMP >>> connection establishment >>> ???? https://bugs.openjdk.java.net/browse/JDK-8193225 >>> >>> Here's the webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8193225-webrev/jdk10-0/ >>> >>> This is a simple "hg backout". I need a single (R)eviewer. Thanks! >>> >>> Dan >>> >>> >>> >>> On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have a small fix for a very intermittent ServerSocket related test >>>> failure: >>>> >>>> ???? JDK-8182307: Error during JRMP connection establishment >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8182307 >>>> >>>> The fix is copied from Jerry's work on the following bugs: >>>> >>>> ???? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8182757 >>>> >>>> ???? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with >>>> Exception >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8178676 >>>> >>>> For the gory details of the reasons for this fix please see >>>> Jerry's bugs. >>>> >>>> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>>> >>>> >>>> I observed this test failure one time in my Thread-SMR work and have >>>> been including this fix in months of Thread-SMR stress testing. It was >>>> also included in both JPRT and Mach5 tier[1-5] testing of the >>>> Thread-SMR >>>> changes. >>>> >>>> Thanks, in advance, for any comments, suggestions or questions. >>>> >>>> Dan >>>> > From chris.plummer at oracle.com Fri Dec 8 01:38:56 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 7 Dec 2017 17:38:56 -0800 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: References: <721a9b28-5d3b-bd35-4d6d-5aa9d693c778@oracle.com> <2fbe6bf9-afd6-2fa8-3d70-edf83278fe43@oracle.com> <09479812-7023-7567-4016-539111001ea7@oracle.com> <181e26de-de69-273b-ae14-68aebc546411@oracle.com> <1fcf0aa0-49b6-3c8d-8794-6cbdc7ccd24d@gmail.com> <97f62dcd-a564-be69-c378-fc0342788274@oracle.com> Message-ID: <0a83dcb9-9289-c210-6fff-2fc1a5df371d@oracle.com> Hi Yasumasa, That would work, but let me see what David and Serguei think. I believe normally we enable events in Agent_Initialize(), so don't want to switch around something that's working if it's not what we really want. thanks, Chris On 12/7/17 5:13 PM, Yasumasa Suenaga wrote: > Hi Chris, > > Thanks! I did not see that. > > IMHO, you can move SetEventNotificationMode() to JNI_OnLoad(). If so, > we ensure that CheckLockObject() is called after all initialization is > completed. > We can keep jvmtiEnv instance. > > > Yasumasa > > > > 2017-12-08 1:51 GMT+09:00 Chris Plummer : >> Hi Yasumasa, >> >> It is safe in my version because I move it to a global ref. See the >> NewGlobalRef() call in my webrev. >> >> thanks, >> >> Chris >> >> >> On 12/7/17 6:14 AM, Yasumasa Suenaga wrote: >>> Hi Chris, >>> >>> I added testcase of GetOwnedMonitorInfo in JDK-8185164. >>> I have concern your change to cache the result of FindClass(). >>> >>> According to [1], FindClass() calls find_class_from_class_loader(), it >>> returns JNI local value. >>> Is it safe to cache? >>> >>> So I called FindClass each time in original commit. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> http://hg.openjdk.java.net/jdk/hs/file/32fd4be602d5/src/hotspot/share/prims/jvm.cpp#l3450 >>> >>> >>> On 2017/12/07 16:44, Chris Plummer wrote: >>>> New webrev: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8191229 >>>> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/ >>>> >>>> testClass now initialized from JNI_OnLoad(), and use memset to clear >>>> callbacks. Also updated to use JVMTI_VERSION_9 when calling GetEnv(). >>>> >>>> thanks, >>>> >>>> Chris >>>> From daniel.daugherty at oracle.com Fri Dec 8 01:40:19 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Dec 2017 20:40:19 -0500 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: <0a83dcb9-9289-c210-6fff-2fc1a5df371d@oracle.com> References: <721a9b28-5d3b-bd35-4d6d-5aa9d693c778@oracle.com> <2fbe6bf9-afd6-2fa8-3d70-edf83278fe43@oracle.com> <09479812-7023-7567-4016-539111001ea7@oracle.com> <181e26de-de69-273b-ae14-68aebc546411@oracle.com> <1fcf0aa0-49b6-3c8d-8794-6cbdc7ccd24d@gmail.com> <97f62dcd-a564-be69-c378-fc0342788274@oracle.com> <0a83dcb9-9289-c210-6fff-2fc1a5df371d@oracle.com> Message-ID: <7beda3fc-5d9e-ddbd-4d13-a066f64c2aa8@oracle.com> I would not do the JVM/TI SetEventNotificationMode() call i JNI_OnLoad(). Dan On 12/7/17 8:38 PM, Chris Plummer wrote: > Hi Yasumasa, > > That would work, but let me see what David and Serguei think. I > believe normally we enable events in Agent_Initialize(), so don't want > to switch around something that's working if it's not what we really > want. > > thanks, > > Chris > > On 12/7/17 5:13 PM, Yasumasa Suenaga wrote: >> Hi Chris, >> >> Thanks! I did not see that. >> >> IMHO, you can move SetEventNotificationMode() to JNI_OnLoad(). If so, >> we ensure that CheckLockObject() is called after all initialization is >> completed. >> We can keep jvmtiEnv instance. >> >> >> Yasumasa >> >> >> >> 2017-12-08 1:51 GMT+09:00 Chris Plummer : >>> Hi Yasumasa, >>> >>> It is safe in my version because I move it to a global ref. See the >>> NewGlobalRef() call in my webrev. >>> >>> thanks, >>> >>> Chris >>> >>> >>> On 12/7/17 6:14 AM, Yasumasa Suenaga wrote: >>>> Hi Chris, >>>> >>>> I added testcase of GetOwnedMonitorInfo in JDK-8185164. >>>> I have concern your change to cache the result of FindClass(). >>>> >>>> According to [1], FindClass() calls find_class_from_class_loader(), it >>>> returns JNI local value. >>>> Is it safe to cache? >>>> >>>> So I called FindClass each time in original commit. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://hg.openjdk.java.net/jdk/hs/file/32fd4be602d5/src/hotspot/share/prims/jvm.cpp#l3450 >>>> >>>> >>>> >>>> On 2017/12/07 16:44, Chris Plummer wrote: >>>>> New webrev: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8191229 >>>>> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/ >>>>> >>>>> testClass now initialized from JNI_OnLoad(), and use memset to clear >>>>> callbacks. Also updated to use JVMTI_VERSION_9 when calling GetEnv(). >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> > From david.holmes at oracle.com Fri Dec 8 03:46:04 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Dec 2017 13:46:04 +1000 Subject: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c In-Reply-To: References: Message-ID: <5e9a9a8d-3254-d704-5037-7d086e31c495@oracle.com> On 8/12/2017 1:21 AM, Langer, Christoph wrote: > Hi, > > please review the first extracted patch from 8192978. This one is about > correcting the jlong format string in > src/jdk.jdi/share/native/libdt_shmem/shmemBase.c. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193183 > > WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8193183.0/ > > I believe the libdt_shmem is only built on windows. Okay ... in that case why do you need the + #if defined(_WIN32) ? As there is no definition of PRId64 for non-Windows any attempt to build on non-Windows will fail. If you don't use the ifdef and simply use %I64d then any attempt to build on non-windows will also fail. Or we can continue the illusion this might be built on non-Windows and add a definition that works in all cases - like hotspot's INT64_FORMAT. Cheers, David > Thanks, > > Christoph > From david.holmes at oracle.com Fri Dec 8 03:51:01 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Dec 2017 13:51:01 +1000 Subject: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError In-Reply-To: <7beda3fc-5d9e-ddbd-4d13-a066f64c2aa8@oracle.com> References: <721a9b28-5d3b-bd35-4d6d-5aa9d693c778@oracle.com> <2fbe6bf9-afd6-2fa8-3d70-edf83278fe43@oracle.com> <09479812-7023-7567-4016-539111001ea7@oracle.com> <181e26de-de69-273b-ae14-68aebc546411@oracle.com> <1fcf0aa0-49b6-3c8d-8794-6cbdc7ccd24d@gmail.com> <97f62dcd-a564-be69-c378-fc0342788274@oracle.com> <0a83dcb9-9289-c210-6fff-2fc1a5df371d@oracle.com> <7beda3fc-5d9e-ddbd-4d13-a066f64c2aa8@oracle.com> Message-ID: <8ff5daee-3ca8-6130-3fc1-ca0ef5190654@oracle.com> On 8/12/2017 11:40 AM, Daniel D. Daugherty wrote: > I would not do the JVM/TI SetEventNotificationMode() call i JNI_OnLoad(). I agree. I had not really considered the dual use of this one library as both a JNI lib and a JVM TI agent lib. In that regard the NULL check is fine. Thanks, David > Dan > > > On 12/7/17 8:38 PM, Chris Plummer wrote: >> Hi Yasumasa, >> >> That would work, but let me see what David and Serguei think. I >> believe normally we enable events in Agent_Initialize(), so don't want >> to switch around something that's working if it's not what we really >> want. >> >> thanks, >> >> Chris >> >> On 12/7/17 5:13 PM, Yasumasa Suenaga wrote: >>> Hi Chris, >>> >>> Thanks! I did not see that. >>> >>> IMHO, you can move SetEventNotificationMode() to JNI_OnLoad(). If so, >>> we ensure that CheckLockObject() is called after all initialization is >>> completed. >>> We can keep jvmtiEnv instance. >>> >>> >>> Yasumasa >>> >>> >>> >>> 2017-12-08 1:51 GMT+09:00 Chris Plummer : >>>> Hi Yasumasa, >>>> >>>> It is safe in my version because I move it to a global ref. See the >>>> NewGlobalRef() call in my webrev. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> >>>> On 12/7/17 6:14 AM, Yasumasa Suenaga wrote: >>>>> Hi Chris, >>>>> >>>>> I added testcase of GetOwnedMonitorInfo in JDK-8185164. >>>>> I have concern your change to cache the result of FindClass(). >>>>> >>>>> According to [1], FindClass() calls find_class_from_class_loader(), it >>>>> returns JNI local value. >>>>> Is it safe to cache? >>>>> >>>>> So I called FindClass each time in original commit. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/jdk/hs/file/32fd4be602d5/src/hotspot/share/prims/jvm.cpp#l3450 >>>>> >>>>> >>>>> >>>>> On 2017/12/07 16:44, Chris Plummer wrote: >>>>>> New webrev: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8191229 >>>>>> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/ >>>>>> >>>>>> testClass now initialized from JNI_OnLoad(), and use memset to clear >>>>>> callbacks. Also updated to use JVMTI_VERSION_9 when calling GetEnv(). >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >> > From chris.plummer at oracle.com Fri Dec 8 04:16:42 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 7 Dec 2017 20:16:42 -0800 Subject: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c In-Reply-To: <5e9a9a8d-3254-d704-5037-7d086e31c495@oracle.com> References: <5e9a9a8d-3254-d704-5037-7d086e31c495@oracle.com> Message-ID: On 12/7/17 7:46 PM, David Holmes wrote: > On 8/12/2017 1:21 AM, Langer, Christoph wrote: >> Hi, >> >> please review the first extracted patch from 8192978. This one is >> about correcting the jlong format string in >> src/jdk.jdi/share/native/libdt_shmem/shmemBase.c. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8193183 >> >> WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8193183.0/ >> >> I believe the libdt_shmem is only built on windows. > > Okay ... in that case why do you need the > > + #if defined(_WIN32) > > ? As there is no definition of PRId64 for non-Windows any attempt to > build on non-Windows will fail. If you don't use the ifdef and simply > use %I64d then any attempt to build on non-windows will also fail. > > Or we can continue the illusion this might be built on non-Windows and > add a definition that works in all cases - like hotspot's INT64_FORMAT. INT64_FORMAT uses PRId64. Chris > > Cheers, > David > >> Thanks, >> >> Christoph >> From david.holmes at oracle.com Fri Dec 8 04:50:52 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Dec 2017 14:50:52 +1000 Subject: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c In-Reply-To: References: <5e9a9a8d-3254-d704-5037-7d086e31c495@oracle.com> Message-ID: <1329b7bc-9431-f9d5-ea21-412bfa5ab0b9@oracle.com> On 8/12/2017 2:16 PM, Chris Plummer wrote: > On 12/7/17 7:46 PM, David Holmes wrote: >> On 8/12/2017 1:21 AM, Langer, Christoph wrote: >>> Hi, >>> >>> please review the first extracted patch from 8192978. This one is >>> about correcting the jlong format string in >>> src/jdk.jdi/share/native/libdt_shmem/shmemBase.c. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193183 >>> >>> WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8193183.0/ >>> >>> I believe the libdt_shmem is only built on windows. >> >> Okay ... in that case why do you need the >> >> + #if defined(_WIN32) >> >> ? As there is no definition of PRId64 for non-Windows any attempt to >> build on non-Windows will fail. If you don't use the ifdef and simply >> use %I64d then any attempt to build on non-windows will also fail. >> >> Or we can continue the illusion this might be built on non-Windows and >> add a definition that works in all cases - like hotspot's INT64_FORMAT. > INT64_FORMAT uses PRId64. Apologies - I hadn't realized that PRId64 is the standard name. David > Chris >> >> Cheers, >> David >> >>> Thanks, >>> >>> Christoph >>> > From sharath.ballal at oracle.com Fri Dec 8 05:04:47 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 7 Dec 2017 21:04:47 -0800 (PST) Subject: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands In-Reply-To: References: <3017924b-7aad-16e3-1ccb-43823dd3e91c@oracle.com> Message-ID: <9f9fdd65-87b2-427f-95a5-26832381a662@default> Can I get one more review pls ? Thanks, Sharath -----Original Message----- From: Sharath Ballal Sent: Thursday, December 07, 2017 2:25 PM To: Jini Susan George; serviceability-dev at openjdk.java.net Subject: RE: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands Thanks Jini. I have changed the testcase to run with both -Xint and -Xcomp. Updated webrev is http://cr.openjdk.java.net/~sballal/8193124/webrev.01/ Thanks, Sharath -----Original Message----- From: Jini George Sent: Wednesday, December 06, 2017 10:40 PM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands Hi Sharath, For ClhsdbFindPC.java, the test case would fail if it gets invoked with -Xcomp. So, it might be better to invoke LingeredApp only with -Xint or only with -Xcomp (and if so, check for the "In code in NMethod" string). Other than this, the rest of it looks good to me. Thanks! Jini. On 12/6/2017 9:40 PM, Sharath Ballal wrote: > Hello, > > Pls review changes for the following issue: > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8193124 > > Webrev: http://cr.openjdk.java.net/~sballal/8193124/webrev.00/ > > The tests have passed in JPRT and Mach5. > > Thanks, > > Sharath > From chris.plummer at oracle.com Fri Dec 8 05:43:36 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 7 Dec 2017 21:43:36 -0800 Subject: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands In-Reply-To: <9f9fdd65-87b2-427f-95a5-26832381a662@default> References: <3017924b-7aad-16e3-1ccb-43823dd3e91c@oracle.com> <9f9fdd65-87b2-427f-95a5-26832381a662@default> Message-ID: <87236cb1-53aa-807b-308d-bd6c44280761@oracle.com> Hi Sharath, Overall looks good. I actually ran ClhsdbFindPC so I could look at the output and better understand how it works. One thing I noticed is that ClhsdbLauncher echoes the hsdb prompt and the output of the command, but not the command itself. I tinkered with it a bit to see if this could be fixed, but couldn't figure out how to inject the command into the output stream at the right point. I think maybe you need to dump the process output before each command is executed (this will print any previous command's output, and then the prompt), followed by printing the command itself. If this is possible, maybe consider this for an RFE. FYI, you still need a "R"eviewer. thanks, Chris On 12/7/17 9:04 PM, Sharath Ballal wrote: > Can I get one more review pls ? > > Thanks, > Sharath > > > -----Original Message----- > From: Sharath Ballal > Sent: Thursday, December 07, 2017 2:25 PM > To: Jini Susan George; serviceability-dev at openjdk.java.net > Subject: RE: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands > > Thanks Jini. I have changed the testcase to run with both -Xint and -Xcomp. > Updated webrev is http://cr.openjdk.java.net/~sballal/8193124/webrev.01/ > > > Thanks, > Sharath > > > -----Original Message----- > From: Jini George > Sent: Wednesday, December 06, 2017 10:40 PM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands > > Hi Sharath, > > For ClhsdbFindPC.java, the test case would fail if it gets invoked with -Xcomp. So, it might be better to invoke LingeredApp only with -Xint or only with -Xcomp (and if so, check for the "In code in NMethod" string). > > Other than this, the rest of it looks good to me. > > Thanks! > Jini. > > > On 12/6/2017 9:40 PM, Sharath Ballal wrote: >> Hello, >> >> Pls review changes for the following issue: >> >> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8193124 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8193124/webrev.00/ >> >> The tests have passed in JPRT and Mach5. >> >> Thanks, >> >> Sharath >> From chris.plummer at oracle.com Fri Dec 8 05:47:42 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 7 Dec 2017 21:47:42 -0800 Subject: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c In-Reply-To: <7a449df5e4814191b83e074bc53e0a0e@sap.com> References: <3dc667ae-52c6-3253-ad1d-5276500b6a02@oracle.com> <80d026308d3c4975b5c4955c097eba75@sap.com> <7a449df5e4814191b83e074bc53e0a0e@sap.com> Message-ID: <35cd0c8d-b9b2-d5ab-61d9-4dfe06317ae5@oracle.com> An HTML attachment was scrubbed... URL: From sundararajan.athijegannathan at oracle.com Fri Dec 8 05:55:35 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 08 Dec 2017 11:25:35 +0530 Subject: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands In-Reply-To: <87236cb1-53aa-807b-308d-bd6c44280761@oracle.com> References: <3017924b-7aad-16e3-1ccb-43823dd3e91c@oracle.com> <9f9fdd65-87b2-427f-95a5-26832381a662@default> <87236cb1-53aa-807b-308d-bd6c44280761@oracle.com> Message-ID: <5A2A2957.50208@oracle.com> Looks good -Sundar On 08/12/17, 11:13 AM, Chris Plummer wrote: > Hi Sharath, > > Overall looks good. I actually ran ClhsdbFindPC so I could look at the > output and better understand how it works. One thing I noticed is that > ClhsdbLauncher echoes the hsdb prompt and the output of the command, > but not the command itself. I tinkered with it a bit to see if this > could be fixed, but couldn't figure out how to inject the command into > the output stream at the right point. I think maybe you need to dump > the process output before each command is executed (this will print > any previous command's output, and then the prompt), followed by > printing the command itself. If this is possible, maybe consider this > for an RFE. > > FYI, you still need a "R"eviewer. > > thanks, > > Chris > > On 12/7/17 9:04 PM, Sharath Ballal wrote: >> Can I get one more review pls ? >> >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: Sharath Ballal >> Sent: Thursday, December 07, 2017 2:25 PM >> To: Jini Susan George; serviceability-dev at openjdk.java.net >> Subject: RE: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and >> findpc commands >> >> Thanks Jini. I have changed the testcase to run with both -Xint and >> -Xcomp. >> Updated webrev is http://cr.openjdk.java.net/~sballal/8193124/webrev.01/ >> >> >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: Jini George >> Sent: Wednesday, December 06, 2017 10:40 PM >> To: Sharath Ballal; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and >> findpc commands >> >> Hi Sharath, >> >> For ClhsdbFindPC.java, the test case would fail if it gets invoked >> with -Xcomp. So, it might be better to invoke LingeredApp only with >> -Xint or only with -Xcomp (and if so, check for the "In code in >> NMethod" string). >> >> Other than this, the rest of it looks good to me. >> >> Thanks! >> Jini. >> >> >> On 12/6/2017 9:40 PM, Sharath Ballal wrote: >>> Hello, >>> >>> Pls review changes for the following issue: >>> >>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8193124 >>> >>> Webrev: http://cr.openjdk.java.net/~sballal/8193124/webrev.00/ >>> >>> The tests have passed in JPRT and Mach5. >>> >>> Thanks, >>> >>> Sharath >>> > From sharath.ballal at oracle.com Fri Dec 8 05:48:13 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 7 Dec 2017 21:48:13 -0800 (PST) Subject: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands In-Reply-To: <87236cb1-53aa-807b-308d-bd6c44280761@oracle.com> References: <3017924b-7aad-16e3-1ccb-43823dd3e91c@oracle.com> <9f9fdd65-87b2-427f-95a5-26832381a662@default> <87236cb1-53aa-807b-308d-bd6c44280761@oracle.com> Message-ID: <0333b77f-bab2-413b-b3bb-a51a62d1816c@default> Thanks Chris for the inputs. I think this can be done. There is an echo command which works as shown below. The command will be shown as '+ ' I guess this should be good enough right ? hsdb> echo echo is false hsdb> echo true hsdb> universe + universe Heap Parameters: garbage-first heap [0x0000000083200000, 0x0000000100000000] region size 1024K hsdb> echo + echo echo is true hsdb> Thanks, Sharath -----Original Message----- From: Chris Plummer Sent: Friday, December 08, 2017 11:14 AM To: Sharath Ballal; Jini Susan George; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands Hi Sharath, Overall looks good. I actually ran ClhsdbFindPC so I could look at the output and better understand how it works. One thing I noticed is that ClhsdbLauncher echoes the hsdb prompt and the output of the command, but not the command itself. I tinkered with it a bit to see if this could be fixed, but couldn't figure out how to inject the command into the output stream at the right point. I think maybe you need to dump the process output before each command is executed (this will print any previous command's output, and then the prompt), followed by printing the command itself. If this is possible, maybe consider this for an RFE. FYI, you still need a "R"eviewer. thanks, Chris On 12/7/17 9:04 PM, Sharath Ballal wrote: > Can I get one more review pls ? > > Thanks, > Sharath > > > -----Original Message----- > From: Sharath Ballal > Sent: Thursday, December 07, 2017 2:25 PM > To: Jini Susan George; serviceability-dev at openjdk.java.net > Subject: RE: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and > findpc commands > > Thanks Jini. I have changed the testcase to run with both -Xint and -Xcomp. > Updated webrev is > http://cr.openjdk.java.net/~sballal/8193124/webrev.01/ > > > Thanks, > Sharath > > > -----Original Message----- > From: Jini George > Sent: Wednesday, December 06, 2017 10:40 PM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and > findpc commands > > Hi Sharath, > > For ClhsdbFindPC.java, the test case would fail if it gets invoked with -Xcomp. So, it might be better to invoke LingeredApp only with -Xint or only with -Xcomp (and if so, check for the "In code in NMethod" string). > > Other than this, the rest of it looks good to me. > > Thanks! > Jini. > > > On 12/6/2017 9:40 PM, Sharath Ballal wrote: >> Hello, >> >> Pls review changes for the following issue: >> >> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8193124 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8193124/webrev.00/ >> >> The tests have passed in JPRT and Mach5. >> >> Thanks, >> >> Sharath >> From chris.plummer at oracle.com Fri Dec 8 06:52:29 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 7 Dec 2017 22:52:29 -0800 Subject: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands In-Reply-To: <0333b77f-bab2-413b-b3bb-a51a62d1816c@default> References: <3017924b-7aad-16e3-1ccb-43823dd3e91c@oracle.com> <9f9fdd65-87b2-427f-95a5-26832381a662@default> <87236cb1-53aa-807b-308d-bd6c44280761@oracle.com> <0333b77f-bab2-413b-b3bb-a51a62d1816c@default> Message-ID: <9f2a1921-51ab-a63a-f386-305814f53fb9@oracle.com> That works for me. thanks, Chris On 12/7/17 9:48 PM, Sharath Ballal wrote: > Thanks Chris for the inputs. > > I think this can be done. There is an echo command which works as shown below. > The command will be shown as '+ ' > I guess this should be good enough right ? > > hsdb> echo > echo is false > hsdb> echo true > hsdb> universe > + universe > Heap Parameters: > garbage-first heap [0x0000000083200000, 0x0000000100000000] region size 1024K > hsdb> echo > + echo > echo is true > hsdb> > > Thanks, > Sharath > > > -----Original Message----- > From: Chris Plummer > Sent: Friday, December 08, 2017 11:14 AM > To: Sharath Ballal; Jini Susan George; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands > > Hi Sharath, > > Overall looks good. I actually ran ClhsdbFindPC so I could look at the output and better understand how it works. One thing I noticed is that ClhsdbLauncher echoes the hsdb prompt and the output of the command, but not the command itself. I tinkered with it a bit to see if this could be fixed, but couldn't figure out how to inject the command into the output stream at the right point. I think maybe you need to dump the process output before each command is executed (this will print any previous command's output, and then the prompt), followed by printing the command itself. If this is possible, maybe consider this for an RFE. > > FYI, you still need a "R"eviewer. > > thanks, > > Chris > > On 12/7/17 9:04 PM, Sharath Ballal wrote: >> Can I get one more review pls ? >> >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: Sharath Ballal >> Sent: Thursday, December 07, 2017 2:25 PM >> To: Jini Susan George; serviceability-dev at openjdk.java.net >> Subject: RE: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and >> findpc commands >> >> Thanks Jini. I have changed the testcase to run with both -Xint and -Xcomp. >> Updated webrev is >> http://cr.openjdk.java.net/~sballal/8193124/webrev.01/ >> >> >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: Jini George >> Sent: Wednesday, December 06, 2017 10:40 PM >> To: Sharath Ballal; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and >> findpc commands >> >> Hi Sharath, >> >> For ClhsdbFindPC.java, the test case would fail if it gets invoked with -Xcomp. So, it might be better to invoke LingeredApp only with -Xint or only with -Xcomp (and if so, check for the "In code in NMethod" string). >> >> Other than this, the rest of it looks good to me. >> >> Thanks! >> Jini. >> >> >> On 12/6/2017 9:40 PM, Sharath Ballal wrote: >>> Hello, >>> >>> Pls review changes for the following issue: >>> >>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8193124 >>> >>> Webrev: http://cr.openjdk.java.net/~sballal/8193124/webrev.00/ >>> >>> The tests have passed in JPRT and Mach5. >>> >>> Thanks, >>> >>> Sharath >>> From jini.george at oracle.com Fri Dec 8 07:03:18 2017 From: jini.george at oracle.com (Jini George) Date: Fri, 8 Dec 2017 12:33:18 +0530 Subject: RFR: JDK-8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands Message-ID: Hello, Requesting reviews for: JBS Id: https://bugs.openjdk.java.net/browse/JDK-8192985 Webrev: http://cr.openjdk.java.net/~jgeorge/8192985/webrev.00/ These are the new test cases for the following clhsdb commands: 1. inspect 2. scanoops 3. printas These tests have been verified through the Mach5 and jprt systems. Thanks, Jini. From sharath.ballal at oracle.com Fri Dec 8 07:25:25 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 7 Dec 2017 23:25:25 -0800 (PST) Subject: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands In-Reply-To: <5A2A2957.50208@oracle.com> References: <3017924b-7aad-16e3-1ccb-43823dd3e91c@oracle.com> <9f9fdd65-87b2-427f-95a5-26832381a662@default> <87236cb1-53aa-807b-308d-bd6c44280761@oracle.com> <5A2A2957.50208@oracle.com> Message-ID: <3c7b499a-1c66-4e09-9b43-a2d59b90f444@default> Thanks for the review Sundar. Thanks, Sharath -----Original Message----- From: Sundararajan Athijegannathan Sent: Friday, December 08, 2017 11:26 AM To: serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands Looks good -Sundar On 08/12/17, 11:13 AM, Chris Plummer wrote: > Hi Sharath, > > Overall looks good. I actually ran ClhsdbFindPC so I could look at the > output and better understand how it works. One thing I noticed is that > ClhsdbLauncher echoes the hsdb prompt and the output of the command, > but not the command itself. I tinkered with it a bit to see if this > could be fixed, but couldn't figure out how to inject the command into > the output stream at the right point. I think maybe you need to dump > the process output before each command is executed (this will print > any previous command's output, and then the prompt), followed by > printing the command itself. If this is possible, maybe consider this > for an RFE. > > FYI, you still need a "R"eviewer. > > thanks, > > Chris > > On 12/7/17 9:04 PM, Sharath Ballal wrote: >> Can I get one more review pls ? >> >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: Sharath Ballal >> Sent: Thursday, December 07, 2017 2:25 PM >> To: Jini Susan George; serviceability-dev at openjdk.java.net >> Subject: RE: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and >> findpc commands >> >> Thanks Jini. I have changed the testcase to run with both -Xint and >> -Xcomp. >> Updated webrev is >> http://cr.openjdk.java.net/~sballal/8193124/webrev.01/ >> >> >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: Jini George >> Sent: Wednesday, December 06, 2017 10:40 PM >> To: Sharath Ballal; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and >> findpc commands >> >> Hi Sharath, >> >> For ClhsdbFindPC.java, the test case would fail if it gets invoked >> with -Xcomp. So, it might be better to invoke LingeredApp only with >> -Xint or only with -Xcomp (and if so, check for the "In code in >> NMethod" string). >> >> Other than this, the rest of it looks good to me. >> >> Thanks! >> Jini. >> >> >> On 12/6/2017 9:40 PM, Sharath Ballal wrote: >>> Hello, >>> >>> Pls review changes for the following issue: >>> >>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8193124 >>> >>> Webrev: http://cr.openjdk.java.net/~sballal/8193124/webrev.00/ >>> >>> The tests have passed in JPRT and Mach5. >>> >>> Thanks, >>> >>> Sharath >>> > From sharath.ballal at oracle.com Fri Dec 8 07:42:18 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 7 Dec 2017 23:42:18 -0800 (PST) Subject: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands In-Reply-To: <9f2a1921-51ab-a63a-f386-305814f53fb9@oracle.com> References: <3017924b-7aad-16e3-1ccb-43823dd3e91c@oracle.com> <9f9fdd65-87b2-427f-95a5-26832381a662@default> <87236cb1-53aa-807b-308d-bd6c44280761@oracle.com> <0333b77f-bab2-413b-b3bb-a51a62d1816c@default> <9f2a1921-51ab-a63a-f386-305814f53fb9@oracle.com> Message-ID: <4d36fede-45c0-4b66-ad6f-1a0fa705855d@default> Thanks Chris. I opened https://bugs.openjdk.java.net/browse/JDK-8193237 for the same. Thanks, Sharath -----Original Message----- From: Chris Plummer Sent: Friday, December 08, 2017 12:22 PM To: Sharath Ballal; Jini Susan George; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands That works for me. thanks, Chris On 12/7/17 9:48 PM, Sharath Ballal wrote: > Thanks Chris for the inputs. > > I think this can be done. There is an echo command which works as shown below. > The command will be shown as '+ ' > I guess this should be good enough right ? > > hsdb> echo > echo is false > hsdb> echo true > hsdb> universe > + universe > Heap Parameters: > garbage-first heap [0x0000000083200000, 0x0000000100000000] region > size 1024K > hsdb> echo > + echo > echo is true > hsdb> > > Thanks, > Sharath > > > -----Original Message----- > From: Chris Plummer > Sent: Friday, December 08, 2017 11:14 AM > To: Sharath Ballal; Jini Susan George; > serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and > findpc commands > > Hi Sharath, > > Overall looks good. I actually ran ClhsdbFindPC so I could look at the output and better understand how it works. One thing I noticed is that ClhsdbLauncher echoes the hsdb prompt and the output of the command, but not the command itself. I tinkered with it a bit to see if this could be fixed, but couldn't figure out how to inject the command into the output stream at the right point. I think maybe you need to dump the process output before each command is executed (this will print any previous command's output, and then the prompt), followed by printing the command itself. If this is possible, maybe consider this for an RFE. > > FYI, you still need a "R"eviewer. > > thanks, > > Chris > > On 12/7/17 9:04 PM, Sharath Ballal wrote: >> Can I get one more review pls ? >> >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: Sharath Ballal >> Sent: Thursday, December 07, 2017 2:25 PM >> To: Jini Susan George; serviceability-dev at openjdk.java.net >> Subject: RE: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and >> findpc commands >> >> Thanks Jini. I have changed the testcase to run with both -Xint and -Xcomp. >> Updated webrev is >> http://cr.openjdk.java.net/~sballal/8193124/webrev.01/ >> >> >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: Jini George >> Sent: Wednesday, December 06, 2017 10:40 PM >> To: Sharath Ballal; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and >> findpc commands >> >> Hi Sharath, >> >> For ClhsdbFindPC.java, the test case would fail if it gets invoked with -Xcomp. So, it might be better to invoke LingeredApp only with -Xint or only with -Xcomp (and if so, check for the "In code in NMethod" string). >> >> Other than this, the rest of it looks good to me. >> >> Thanks! >> Jini. >> >> >> On 12/6/2017 9:40 PM, Sharath Ballal wrote: >>> Hello, >>> >>> Pls review changes for the following issue: >>> >>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8193124 >>> >>> Webrev: http://cr.openjdk.java.net/~sballal/8193124/webrev.00/ >>> >>> The tests have passed in JPRT and Mach5. >>> >>> Thanks, >>> >>> Sharath >>> From christoph.langer at sap.com Fri Dec 8 08:34:37 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 8 Dec 2017 08:34:37 +0000 Subject: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c In-Reply-To: <90607de6-2be9-e8ee-ef26-069b1d8d5f7f@oracle.com> References: <17f57253-bd8c-6e1d-385e-1d6e12a049da@oracle.com> <6e5f6093-80a9-5671-d0b9-556f67383505@oracle.com> <90607de6-2be9-e8ee-ef26-069b1d8d5f7f@oracle.com> Message-ID: Hi Alex, as far as I know, it's not possible to include hotspot headers in the JDK, so we have to leave it local. Best regards Christoph -----Original Message----- From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Alex Menkov Sent: Donnerstag, 7. Dezember 2017 21:16 To: Chris Plummer ; serviceability-dev at openjdk.java.net Subject: Re: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c well, maybe code duplication is lesser evil in the case :) --alex On 12/07/2017 11:25, Chris Plummer wrote: > I had noticed that when I first looked at these changes, but figured > that JDI code cannot leverage globalDefinitions.hpp. However, I'm not > certain of that. > > Chris > > On 12/7/17 10:50 AM, Alex Menkov wrote: >> Looks like we already have definitions to workaround Visual Studio >> issues (including absence of PRId64) in >> open/src/hotspot/share/utilities/globalDefinitions_visCPP.hpp >> It would be better to reuse it (to have all workarounds in a single >> place) >> >> I suppose to utilize it you need >> #include "utilities/globalDefinitions.hpp" >> It includes corresponding "globalDefinitions_*.hpp" depending on the >> compiler used. >> >> --alex >> >> On 12/07/2017 07:21, Langer, Christoph wrote: >>> Hi, >>> >>> please review the first extracted patch from 8192978. This one is >>> about correcting the jlong format string in >>> src/jdk.jdi/share/native/libdt_shmem/shmemBase.c. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193183 >>> >>> WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8193183.0/ >>> >>> I believe the libdt_shmem is only built on windows. >>> >>> Thanks, >>> >>> Christoph >>> > From christoph.langer at sap.com Fri Dec 8 08:57:40 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 8 Dec 2017 08:57:40 +0000 Subject: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c In-Reply-To: <35cd0c8d-b9b2-d5ab-61d9-4dfe06317ae5@oracle.com> References: <3dc667ae-52c6-3253-ad1d-5276500b6a02@oracle.com> <80d026308d3c4975b5c4955c097eba75@sap.com> <7a449df5e4814191b83e074bc53e0a0e@sap.com> <35cd0c8d-b9b2-d5ab-61d9-4dfe06317ae5@oracle.com> Message-ID: Done: http://hg.openjdk.java.net/jdk/jdk/rev/8ad12da0cbc7 Thanks Christoph From: Chris Plummer [mailto:chris.plummer at oracle.com] Sent: Freitag, 8. Dezember 2017 06:48 To: Langer, Christoph ; serviceability-dev at openjdk.java.net; serguei.spitsyn at oracle.com Cc: Lindenmaier, Goetz Subject: Re: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c Hi Christoph, Testing is done. All clear to push. I'll let you have the honors. :) Chris On 12/7/17 1:28 PM, Langer, Christoph wrote: Hi Chris, ok, I understand. Then please let me know when you?re done or ?in that case you might as well do the push.:) Thanks Christoph From: Chris Plummer [mailto:chris.plummer at oracle.com] Sent: Donnerstag, 7. Dezember 2017 20:26 To: Langer, Christoph ; serviceability-dev at openjdk.java.net; serguei.spitsyn at oracle.com Cc: Lindenmaier, Goetz Subject: Re: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c Hi Christoph, You can do the push, but please let me do some internal testing first. I want to make sure all our platforms are covered, and our closed tests are turn. thanks, Chris On 12/7/17 11:02 AM, Langer, Christoph wrote: Thanks Chris and Serguei for reviewing. I can do the push myself as it isn?t hotspot. I?ll send out other webrevs tomorrow for the other stuff. Best regards Christoph From: Chris Plummer [mailto:chris.plummer at oracle.com] Sent: Donnerstag, 7. Dezember 2017 19:14 To: Langer, Christoph ; serviceability-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: Re: RFR (XS): 8193183: Fix format string in libdt_shmem/shmemBase.c Looks good to me. I can sponsor the push for you. thanks, Chris On 12/7/17 7:21 AM, Langer, Christoph wrote: Hi, please review the first extracted patch from 8192978. This one is about correcting the jlong format string in src/jdk.jdi/share/native/libdt_shmem/shmemBase.c. Bug: https://bugs.openjdk.java.net/browse/JDK-8193183 WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8193183.0/ I believe the libdt_shmem is only built on windows. Thanks, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Fri Dec 8 09:11:43 2017 From: jini.george at oracle.com (Jini George) Date: Fri, 8 Dec 2017 14:41:43 +0530 Subject: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands In-Reply-To: References: <3017924b-7aad-16e3-1ccb-43823dd3e91c@oracle.com> Message-ID: <4206022d-0cc0-7767-8f9b-dfe471c1db0e@oracle.com> Looks good. Thanks, Jini On 12/7/2017 2:25 PM, Sharath Ballal wrote: > Thanks Jini. I have changed the testcase to run with both -Xint and -Xcomp. > Updated webrev is http://cr.openjdk.java.net/~sballal/8193124/webrev.01/ > > > Thanks, > Sharath > > > -----Original Message----- > From: Jini George > Sent: Wednesday, December 06, 2017 10:40 PM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands > > Hi Sharath, > > For ClhsdbFindPC.java, the test case would fail if it gets invoked with -Xcomp. So, it might be better to invoke LingeredApp only with -Xint or only with -Xcomp (and if so, check for the "In code in NMethod" string). > > Other than this, the rest of it looks good to me. > > Thanks! > Jini. > > > On 12/6/2017 9:40 PM, Sharath Ballal wrote: >> Hello, >> >> Pls review changes for the following issue: >> >> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8193124 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8193124/webrev.00/ >> >> The tests have passed in JPRT and Mach5. >> >> Thanks, >> >> Sharath >> From sharath.ballal at oracle.com Fri Dec 8 09:21:05 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Fri, 8 Dec 2017 01:21:05 -0800 (PST) Subject: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands In-Reply-To: <4206022d-0cc0-7767-8f9b-dfe471c1db0e@oracle.com> References: <3017924b-7aad-16e3-1ccb-43823dd3e91c@oracle.com> <4206022d-0cc0-7767-8f9b-dfe471c1db0e@oracle.com> Message-ID: Thanks for the review Jini. Thanks, Sharath -----Original Message----- From: Jini George Sent: Friday, December 08, 2017 2:42 PM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands Looks good. Thanks, Jini On 12/7/2017 2:25 PM, Sharath Ballal wrote: > Thanks Jini. I have changed the testcase to run with both -Xint and -Xcomp. > Updated webrev is http://cr.openjdk.java.net/~sballal/8193124/webrev.01/ > > > Thanks, > Sharath > > > -----Original Message----- > From: Jini George > Sent: Wednesday, December 06, 2017 10:40 PM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8193124 - SA: Testcases for clhsdb jdis and findpc commands > > Hi Sharath, > > For ClhsdbFindPC.java, the test case would fail if it gets invoked with -Xcomp. So, it might be better to invoke LingeredApp only with -Xint or only with -Xcomp (and if so, check for the "In code in NMethod" string). > > Other than this, the rest of it looks good to me. > > Thanks! > Jini. > > > On 12/6/2017 9:40 PM, Sharath Ballal wrote: >> Hello, >> >> Pls review changes for the following issue: >> >> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8193124 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8193124/webrev.00/ >> >> The tests have passed in JPRT and Mach5. >> >> Thanks, >> >> Sharath >> From Alan.Bateman at oracle.com Fri Dec 8 09:28:01 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 8 Dec 2017 09:28:01 +0000 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: <0a36c975-8bca-c618-9133-66348f145436@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <0a36c975-8bca-c618-9133-66348f145436@oracle.com> Message-ID: <6cadd346-f826-55ce-0276-cfd2f7bef7f4@oracle.com> On 07/12/2017 16:55, Daniel D. Daugherty wrote: > : >> Greetings, >> >> I have a small fix for a very intermittent ServerSocket related test >> failure: >> >> ??? JDK-8182307: Error during JRMP connection establishment >> ??? https://bugs.openjdk.java.net/browse/JDK-8182307 >> >> : >> >> For the gory details of the reasons for this fix please see >> Jerry's bugs. >> >> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >> It's not clear to me how this change solves the issue.? It's a "read timeout" so this means the connection has been established. The client will not care if the server has enabled SO_REUSEADDR or whether it initially bound to a fixed or ephemeral port. Is this issue Solaris only? I ask because there is an awkward issue on Solaris where the kernel will accept a pending connection when the process is at its file descriptor limit. We've seen this periodically, esp. with tests that leave connections or files open. An unsuspecting tests runs later, establishes a connection but gets timeouts as there isn't no code at the application level has accepted the connection. -Alan From christoph.langer at sap.com Fri Dec 8 13:48:37 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 8 Dec 2017 13:48:37 +0000 Subject: RFR(S): 8192978: Missing checks and small fixes in jdwp library Message-ID: Hi, this is a new webrev for 8192978. This change now only contains the coverity fixes. In detail: src/jdk.jdwp.agent/share/native/libjdwp/VirtualMachineImpl.c, static void writePaths(PacketOutputStream *out, char *string): strchr could be called with NULL argument because of assignment pos = psPos; in line 856 (last line of for loop). Proposal: check pos for NULL in head of for loop src/jdk.jdwp.agent/share/native/libjdwp/error_messages.c, static void vprint_message(FILE *fp, const char *prefix, const char *suffix, const char *format, va_list ap): potentially unterminated vsnprintf call. Proposal: terminate src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c, static jboolean synthesizeUnloadEvent(void *signatureVoid, void *envVoid): checking eventBag for NULL and then calling JDI_ASSERT only in that case is a bit dubious. It leads the coverity code scan tool to think that eventBag might be NULL when eventHelper_recordClassUnload is called which would eventually try to dereference a NULL eventbag and hence crash. Proposal: remove the NULL check but unconditionally assert. This is the real fix for the changes in eventHelper.c in my former webrev. src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c, void log_message_end(const char *format, ...): potentially unterminated vsnprintf call. Proposal: terminate Furthermore I have 2 whitespace changes which I'd like to see because they would help me reducing the diff to our codebase and, furthermore, make the code looking nicer... a little ;-) Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8192978.2/ Bug: https://bugs.openjdk.java.net/browse/JDK-8192978 I'm doing builds on the main platform and running jtreg tests. Thanks in advance & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Fri Dec 8 14:36:59 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 8 Dec 2017 09:36:59 -0500 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: <6cadd346-f826-55ce-0276-cfd2f7bef7f4@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <0a36c975-8bca-c618-9133-66348f145436@oracle.com> <6cadd346-f826-55ce-0276-cfd2f7bef7f4@oracle.com> Message-ID: <56b505b7-4294-69e0-b501-708ea2c7a81d@oracle.com> On 12/8/17 4:28 AM, Alan Bateman wrote: > On 07/12/2017 16:55, Daniel D. Daugherty wrote: >> : >>> Greetings, >>> >>> I have a small fix for a very intermittent ServerSocket related test >>> failure: >>> >>> ??? JDK-8182307: Error during JRMP connection establishment >>> ??? https://bugs.openjdk.java.net/browse/JDK-8182307 >>> >>> : >>> >>> For the gory details of the reasons for this fix please see >>> Jerry's bugs. >>> >>> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>> > It's not clear to me how this change solves the issue.? It's a "read > timeout" so this means the connection has been established. Yes, the connection has been established, but it has been established to the wrong ServerSocket. The ServerSocket port that was picked by the test with its "return new ServerSocket(port)" call was also picked by another "interloper" process. It's the SO_REUSEADDR attribute that allows these two processes to both think that they have the same random port. We have only observed proven sightings of this bug on Solaris SPARC and Solaris X64 machines. So the interloper and the server side of the test both did accept() calls on the same port. The interloper won the race in this case so it is matched up with the test's client side connect(). The test's client side starts doing its protocol reads, but the interloper does not send what the test's client side expects so the test's client side times out in read(). Here's Jerry's eval note from https://bugs.openjdk.java.net/browse/JDK-8182757: > gthornbr Gerald Thornbrugh > > added a comment - 2017-07-27 11:33 > If a socket is being setup without a fixed port using the SO_REUSEADDR > flag can lead to other processes interfering with the poll/receive > process of a debugger/debuggee configuring a socket for communication. > When SO_REUSEADDR is used other processes can attempt a listen() on > the same port and receive a connect from the debuggee. This causes the > debugger to stay in poll() waiting for a connect and the debuggee > stays in recv() waiting to receive data from the "rogue" process that > will never send it. > > This can also lead to connections being terminated early on the > debuggee side when the "rogue" process terminates the connection > because it does not receive what it expected from the client process > (i.e. the debuggee). > > The fix is to not use the SO_REUSEADDR flag for non-fixed port > sockets. This keeps "rogue" processes from reusing the port address > and from stealing the connects sent by from the debuggee. In the hunt for JDK-8182757 we were fortunate that the tests were configured for the server side accept() call to _not_ timeout. That allowed us to capture stacks from both the debuggee and debugger sides. We were also able to capture debug info from different points in the protocol stack in various repro attemps. The only thing we didn't do was add debugging info in the kernel to try and chase the race enabled by SO_REUSEADDR to ground. This bug's (JDK-8182307) failure mode is more like the other failure that Jerry fixed: https://bugs.openjdk.java.net/browse/JDK-8178676 The server side accept() is configured to timeout so we don't have a stack from the server side hang point to prove that the JDK-8178676 failure is the same as the JDK-8182757. With the fixes for JDK-8182757 and JDK-8178676 in place, we have not seen these failure modes reproduce. The fix for JDK-8182757 was pushed on 2017-08-03 and the fix for JDK-8178676 was pushed on 2017-08-14. It is not proof, but it is a strong indicator that these instances of this failure mode are fixed. > The client will not care if the server has enabled SO_REUSEADDR or > whether it initially bound to a fixed or ephemeral port. True, but the client has been connected to the interloper process which is why the read() times out. It is the SO_REUSEADDR attribute that allows the interloper to accept() the test's server side port and that does break the client side of the test. > Is this issue Solaris only? I ask because there is an awkward issue on > Solaris where the kernel will accept a pending connection when the > process is at its file descriptor limit. We've seen this periodically, > esp. with tests that leave connections or files open. An unsuspecting > tests runs later, establishes a connection but gets timeouts as there > isn't no code at the application level has accepted the connection. We have only seen provable sightings of this failure mode on Solaris SPARC and Solaris X64 machines. Folks have added sightings on other platforms to the older bug that was tracking the original issue: ??? JDK-6303969 JDWP: Socket Transport handshake fails rarely on InstancesTest.java ??? https://bugs.openjdk.java.net/browse/JDK-6303969 but Jerry and I were never able to prove a sighting on anything other than Solaris. This "file descriptor limit" issue is new to me. Do you have a pointer to it? It's entirely possible that there is more than one bug at play here... Dan > > -Alan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Fri Dec 8 15:07:57 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 8 Dec 2017 15:07:57 +0000 Subject: RFR (S): 8193258: Better usage of JDWP HEADER SIZE Message-ID: Hi, Here's a proposal to clean up the usage of the JDWP header size within the source code of libjdwp. Bug: https://bugs.openjdk.java.net/browse/JDK-8193258 WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8193258.0/ As for inStream.c, I'm wondering wether inStream_endOfInput shall be removed? It seems to be unused... Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Dec 8 20:18:48 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 8 Dec 2017 12:18:48 -0800 Subject: RFR (S): 8193258: Better usage of JDWP HEADER SIZE In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Dec 8 20:12:29 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 8 Dec 2017 12:12:29 -0800 Subject: RFR (S): 8193258: Better usage of JDWP HEADER SIZE In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Dec 8 20:51:50 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 8 Dec 2017 12:51:50 -0800 Subject: RFR(S): 8192978: Missing checks and small fixes in jdwp library In-Reply-To: References: Message-ID: <9080870b-800b-888d-52df-a55b5e3381e4@oracle.com> An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Fri Dec 8 21:07:06 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 8 Dec 2017 21:07:06 +0000 Subject: RFR (S): 8193258: Better usage of JDWP HEADER SIZE In-Reply-To: References: Message-ID: <3acbaa87f2ab4df69dbddc277d2ea673@sap.com> Hi Serguei, I did only run hotspot/jtreg/serviceability/jdwp, didn?t find a lot more in that area. I?m hoping/waiting for Chris? tests then. I agree, I will then remove inStream_endOfInput. If something like that is needed for future developments, it can easily be added again. Best regards Christoph From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Freitag, 8. Dezember 2017 21:12 To: Langer, Christoph ; serviceability-dev at openjdk.java.net; Chris Plummer Subject: Re: RFR (S): 8193258: Better usage of JDWP HEADER SIZE Hi Christoph, The fix looks good to me. What tests did you run? On 12/8/17 07:07, Langer, Christoph wrote: Hi, Here?s a proposal to clean up the usage of the JDWP header size within the source code of libjdwp. Bug: https://bugs.openjdk.java.net/browse/JDK-8193258 WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8193258.0/ As for inStream.c, I?m wondering wether inStream_endOfInput shall be removed? It seems to be unused? I'm inclined to remove it. Otherwise, it must be: 417 return (stream->left <= 0); Thanks, Serguei Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Fri Dec 8 21:07:55 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 8 Dec 2017 21:07:55 +0000 Subject: RFR(S): 8192978: Missing checks and small fixes in jdwp library In-Reply-To: <9080870b-800b-888d-52df-a55b5e3381e4@oracle.com> References: <9080870b-800b-888d-52df-a55b5e3381e4@oracle.com> Message-ID: <37515ee093d749caba716b520bcae927@sap.com> Thanks in advance, Chris, for testing. Please let me know the outcome when you are done. Best regards Christoph From: Chris Plummer [mailto:chris.plummer at oracle.com] Sent: Freitag, 8. Dezember 2017 21:52 To: Langer, Christoph ; serviceability-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: Re: RFR(S): 8192978: Missing checks and small fixes in jdwp library Hi Christoph, On 12/8/17 5:48 AM, Langer, Christoph wrote: Hi, this is a new webrev for 8192978. This change now only contains the coverity fixes. In detail: src/jdk.jdwp.agent/share/native/libjdwp/VirtualMachineImpl.c, static void writePaths(PacketOutputStream *out, char *string): strchr could be called with NULL argument because of assignment pos = psPos; in line 856 (last line of for loop). Proposal: check pos for NULL in head of for loop If I understand correctly how the code currently works, pos/psPos will be NULL on the last iteration of the loop, but we'll exit anyway since "i == npaths" by that point. So the NULL pos will never be referenced. I guess coverity is cluing in on the following section: 846 psPos = strchr(pos, ps[0]); 847 if ( psPos == NULL ) { 848 plen = (int)strlen(pos); 849 } else { 850 plen = (int)(psPos-pos); 851 psPos++; 852 } We admit in line 847 that psPos can be NULL, but coverity can't read into the loop logic deep enough to recognize we'll also exit when this happens. I guess your fix is fine, although technically unnecessary. src/jdk.jdwp.agent/share/native/libjdwp/error_messages.c, static void vprint_message(FILE *fp, const char *prefix, const char *suffix, const char *format, va_list ap): potentially unterminated vsnprintf call. Proposal: terminate Ok. src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c, static jboolean synthesizeUnloadEvent(void *signatureVoid, void *envVoid): checking eventBag for NULL and then calling JDI_ASSERT only in that case is a bit dubious. It leads the coverity code scan tool to think that eventBag might be NULL when eventHelper_recordClassUnload is called which would eventually try to dereference a NULL eventbag and hence crash. Proposal: remove the NULL check but unconditionally assert. This is the real fix for the changes in eventHelper.c in my former webrev. Looks good. Thanks for looking deeper into this one. src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c, void log_message_end(const char *format, ...): potentially unterminated vsnprintf call. Proposal: terminate Ok. Furthermore I have 2 whitespace changes which I?d like to see because they would help me reducing the diff to our codebase and, furthermore, make the code looking nicer? a little ;-) Please list the files with just whitespace changes in the CR. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8192978.2/ Bug: https://bugs.openjdk.java.net/browse/JDK-8192978 I?m doing builds on the main platform and running jtreg tests. I'm doing a pretty comprehensive round of serviceability testing myself with these changes and also 8193258. I'll let you know if there are any issues. thanks, Chris Thanks in advance & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Sat Dec 9 00:17:36 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 8 Dec 2017 16:17:36 -0800 Subject: RFR(S): 8192978: Missing checks and small fixes in jdwp library In-Reply-To: <37515ee093d749caba716b520bcae927@sap.com> References: <9080870b-800b-888d-52df-a55b5e3381e4@oracle.com> <37515ee093d749caba716b520bcae927@sap.com> Message-ID: <025a61b2-13cd-ed5d-0017-dbdbe49f0951@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sat Dec 9 05:26:56 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 8 Dec 2017 21:26:56 -0800 Subject: RFR (S): 8193258: Better usage of JDWP HEADER SIZE In-Reply-To: <3acbaa87f2ab4df69dbddc277d2ea673@sap.com> References: <3acbaa87f2ab4df69dbddc277d2ea673@sap.com> Message-ID: <7cc996bb-b8ec-b147-5dea-e2f21e7ff9e5@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sat Dec 9 05:41:39 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 8 Dec 2017 21:41:39 -0800 Subject: RFR(S): 8192978: Missing checks and small fixes in jdwp library In-Reply-To: References: Message-ID: <5130dfbb-11f4-5f3e-434d-58217510f284@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sat Dec 9 05:56:12 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 8 Dec 2017 21:56:12 -0800 Subject: RFR (S): 8193258: Better usage of JDWP HEADER SIZE In-Reply-To: <27fcd2f3-233b-f54e-be8a-f594dfbc0a66@oracle.com> References: <3acbaa87f2ab4df69dbddc277d2ea673@sap.com> <7cc996bb-b8ec-b147-5dea-e2f21e7ff9e5@oracle.com> <27fcd2f3-233b-f54e-be8a-f594dfbc0a66@oracle.com> Message-ID: <74080274-6be6-a031-b0e7-ceecda1ff180@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Sat Dec 9 05:46:02 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 8 Dec 2017 21:46:02 -0800 Subject: RFR (S): 8193258: Better usage of JDWP HEADER SIZE In-Reply-To: <7cc996bb-b8ec-b147-5dea-e2f21e7ff9e5@oracle.com> References: <3acbaa87f2ab4df69dbddc277d2ea673@sap.com> <7cc996bb-b8ec-b147-5dea-e2f21e7ff9e5@oracle.com> Message-ID: <27fcd2f3-233b-f54e-be8a-f594dfbc0a66@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Sat Dec 9 06:14:08 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 8 Dec 2017 22:14:08 -0800 Subject: RFR (S): 8193258: Better usage of JDWP HEADER SIZE In-Reply-To: <74080274-6be6-a031-b0e7-ceecda1ff180@oracle.com> References: <3acbaa87f2ab4df69dbddc277d2ea673@sap.com> <7cc996bb-b8ec-b147-5dea-e2f21e7ff9e5@oracle.com> <27fcd2f3-233b-f54e-be8a-f594dfbc0a66@oracle.com> <74080274-6be6-a031-b0e7-ceecda1ff180@oracle.com> Message-ID: <970b0044-e47e-031d-4912-f07a0087f5a7@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sat Dec 9 06:15:44 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 8 Dec 2017 22:15:44 -0800 Subject: RFR (S): 8193258: Better usage of JDWP HEADER SIZE In-Reply-To: <970b0044-e47e-031d-4912-f07a0087f5a7@oracle.com> References: <3acbaa87f2ab4df69dbddc277d2ea673@sap.com> <7cc996bb-b8ec-b147-5dea-e2f21e7ff9e5@oracle.com> <27fcd2f3-233b-f54e-be8a-f594dfbc0a66@oracle.com> <74080274-6be6-a031-b0e7-ceecda1ff180@oracle.com> <970b0044-e47e-031d-4912-f07a0087f5a7@oracle.com> Message-ID: <8527da89-0006-bfd6-fcaa-a6fdebac8532@oracle.com> An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Sat Dec 9 17:07:35 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 9 Dec 2017 17:07:35 +0000 Subject: RFR(S): 8192978: Missing checks and small fixes in jdwp library In-Reply-To: <025a61b2-13cd-ed5d-0017-dbdbe49f0951@oracle.com> References: <9080870b-800b-888d-52df-a55b5e3381e4@oracle.com> <37515ee093d749caba716b520bcae927@sap.com> <025a61b2-13cd-ed5d-0017-dbdbe49f0951@oracle.com> Message-ID: <5c4391cb4a84449ea706b43ab669448b@sap.com> Hi Chris, thanks for testing. I added the files with whitespace changes to the bug. I?ll push this on Monday. Best regards Christoph From: Chris Plummer [mailto:chris.plummer at oracle.com] Sent: Samstag, 9. Dezember 2017 01:18 To: Langer, Christoph ; serviceability-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: Re: RFR(S): 8192978: Missing checks and small fixes in jdwp library All testing passed. thanks, Chris On 12/8/17 1:07 PM, Langer, Christoph wrote: Thanks in advance, Chris, for testing. Please let me know the outcome when you are done. Best regards Christoph From: Chris Plummer [mailto:chris.plummer at oracle.com] Sent: Freitag, 8. Dezember 2017 21:52 To: Langer, Christoph ; serviceability-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: Re: RFR(S): 8192978: Missing checks and small fixes in jdwp library Hi Christoph, On 12/8/17 5:48 AM, Langer, Christoph wrote: Hi, this is a new webrev for 8192978. This change now only contains the coverity fixes. In detail: src/jdk.jdwp.agent/share/native/libjdwp/VirtualMachineImpl.c, static void writePaths(PacketOutputStream *out, char *string): strchr could be called with NULL argument because of assignment pos = psPos; in line 856 (last line of for loop). Proposal: check pos for NULL in head of for loop If I understand correctly how the code currently works, pos/psPos will be NULL on the last iteration of the loop, but we'll exit anyway since "i == npaths" by that point. So the NULL pos will never be referenced. I guess coverity is cluing in on the following section: 846 psPos = strchr(pos, ps[0]); 847 if ( psPos == NULL ) { 848 plen = (int)strlen(pos); 849 } else { 850 plen = (int)(psPos-pos); 851 psPos++; 852 } We admit in line 847 that psPos can be NULL, but coverity can't read into the loop logic deep enough to recognize we'll also exit when this happens. I guess your fix is fine, although technically unnecessary. src/jdk.jdwp.agent/share/native/libjdwp/error_messages.c, static void vprint_message(FILE *fp, const char *prefix, const char *suffix, const char *format, va_list ap): potentially unterminated vsnprintf call. Proposal: terminate Ok. src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c, static jboolean synthesizeUnloadEvent(void *signatureVoid, void *envVoid): checking eventBag for NULL and then calling JDI_ASSERT only in that case is a bit dubious. It leads the coverity code scan tool to think that eventBag might be NULL when eventHelper_recordClassUnload is called which would eventually try to dereference a NULL eventbag and hence crash. Proposal: remove the NULL check but unconditionally assert. This is the real fix for the changes in eventHelper.c in my former webrev. Looks good. Thanks for looking deeper into this one. src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c, void log_message_end(const char *format, ...): potentially unterminated vsnprintf call. Proposal: terminate Ok. Furthermore I have 2 whitespace changes which I?d like to see because they would help me reducing the diff to our codebase and, furthermore, make the code looking nicer? a little ;-) Please list the files with just whitespace changes in the CR. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8192978.2/ Bug: https://bugs.openjdk.java.net/browse/JDK-8192978 I?m doing builds on the main platform and running jtreg tests. I'm doing a pretty comprehensive round of serviceability testing myself with these changes and also 8193258. I'll let you know if there are any issues. thanks, Chris Thanks in advance & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Sun Dec 10 09:51:52 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 10 Dec 2017 09:51:52 +0000 Subject: RFR (S): 8193258: Better usage of JDWP HEADER SIZE In-Reply-To: <7cc996bb-b8ec-b147-5dea-e2f21e7ff9e5@oracle.com> References: <3acbaa87f2ab4df69dbddc277d2ea673@sap.com> <7cc996bb-b8ec-b147-5dea-e2f21e7ff9e5@oracle.com> Message-ID: <414830ddd74f46e988afb14a146616e0@sap.com> Hi Serguei, I wasn?t aware that the jdk/com/sun/jdi tests would test libjdwp, I just found hotspot/jtreg/serviceability/jdwp when searching for jdwp in the tests. But thanks to your hints I know better now. In fact I ran the jdi tests when testing my change for 8193183. I made a new webrev which includes the removal of inStream_endOfInput: http://cr.openjdk.java.net/~clanger/webrevs/8193258.1/. Can you please approve this. This time I ran the jdi tests without issues and also did builds on Windows, linux x86, AIX, Solaris and Mac. ? Best regards Christoph From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Samstag, 9. Dezember 2017 06:27 To: Langer, Christoph ; serviceability-dev at openjdk.java.net; Chris Plummer Subject: Re: RFR (S): 8193258: Better usage of JDWP HEADER SIZE Hi Christoph, You need to run at least the jdk/com/sun/jdi tests. Thanks, Serguei On 12/8/17 13:07, Langer, Christoph wrote: Hi Serguei, I did only run hotspot/jtreg/serviceability/jdwp, didn?t find a lot more in that area. I?m hoping/waiting for Chris? tests then. I agree, I will then remove inStream_endOfInput. If something like that is needed for future developments, it can easily be added again. Best regards Christoph From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Freitag, 8. Dezember 2017 21:12 To: Langer, Christoph ; serviceability-dev at openjdk.java.net; Chris Plummer Subject: Re: RFR (S): 8193258: Better usage of JDWP HEADER SIZE Hi Christoph, The fix looks good to me. What tests did you run? On 12/8/17 07:07, Langer, Christoph wrote: Hi, Here?s a proposal to clean up the usage of the JDWP header size within the source code of libjdwp. Bug: https://bugs.openjdk.java.net/browse/JDK-8193258 WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8193258.0/ As for inStream.c, I?m wondering wether inStream_endOfInput shall be removed? It seems to be unused? I'm inclined to remove it. Otherwise, it must be: 417 return (stream->left <= 0); Thanks, Serguei Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Mon Dec 11 04:02:10 2017 From: jini.george at oracle.com (Jini George) Date: Mon, 11 Dec 2017 09:32:10 +0530 Subject: RFR: JDK-8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands In-Reply-To: References: Message-ID: <2b0f120f-689d-64c6-e3a4-78010a3b9158@oracle.com> Gentle Reminder. Thank you. Jini. On 12/8/2017 12:33 PM, Jini George wrote: > Hello, > > Requesting reviews for: > > JBS Id: https://bugs.openjdk.java.net/browse/JDK-8192985 > Webrev: http://cr.openjdk.java.net/~jgeorge/8192985/webrev.00/ > > These are the new test cases for the following clhsdb commands: > 1. inspect > 2. scanoops > 3. printas > > These tests have been verified through the Mach5 and jprt systems. > > Thanks, > Jini. > From christoph.langer at sap.com Mon Dec 11 07:39:38 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 11 Dec 2017 07:39:38 +0000 Subject: RFR(S): 8192978: Missing checks and small fixes in jdwp library In-Reply-To: <5c4391cb4a84449ea706b43ab669448b@sap.com> References: <9080870b-800b-888d-52df-a55b5e3381e4@oracle.com> <37515ee093d749caba716b520bcae927@sap.com> <025a61b2-13cd-ed5d-0017-dbdbe49f0951@oracle.com> <5c4391cb4a84449ea706b43ab669448b@sap.com> Message-ID: <40fa44d716f74a72b21a83dc341697f2@sap.com> Hi guys, I just pushed this: http://hg.openjdk.java.net/jdk/jdk/rev/8db54e2c453b However, for some reason somebody set my original bug to Fix version 11 which I kinda ignored and now the system created a backport bug for 10 (https://bugs.openjdk.java.net/browse/JDK-8193305). Probably I should have corrected the fix version before I pushed. Now, shall I set the original bug https://bugs.openjdk.java.net/browse/JDK-8192978 to ?Resolved? manually or wait for the system to do it? Any hints on that one? Thanks Christoph From: Langer, Christoph Sent: Samstag, 9. Dezember 2017 18:08 To: 'Chris Plummer' ; serviceability-dev at openjdk.java.net Cc: 'serguei.spitsyn at oracle.com' Subject: RE: RFR(S): 8192978: Missing checks and small fixes in jdwp library Hi Chris, thanks for testing. I added the files with whitespace changes to the bug. I?ll push this on Monday. Best regards Christoph From: Chris Plummer [mailto:chris.plummer at oracle.com] Sent: Samstag, 9. Dezember 2017 01:18 To: Langer, Christoph >; serviceability-dev at openjdk.java.net Cc: Lindenmaier, Goetz > Subject: Re: RFR(S): 8192978: Missing checks and small fixes in jdwp library All testing passed. thanks, Chris On 12/8/17 1:07 PM, Langer, Christoph wrote: Thanks in advance, Chris, for testing. Please let me know the outcome when you are done. Best regards Christoph From: Chris Plummer [mailto:chris.plummer at oracle.com] Sent: Freitag, 8. Dezember 2017 21:52 To: Langer, Christoph ; serviceability-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: Re: RFR(S): 8192978: Missing checks and small fixes in jdwp library Hi Christoph, On 12/8/17 5:48 AM, Langer, Christoph wrote: Hi, this is a new webrev for 8192978. This change now only contains the coverity fixes. In detail: src/jdk.jdwp.agent/share/native/libjdwp/VirtualMachineImpl.c, static void writePaths(PacketOutputStream *out, char *string): strchr could be called with NULL argument because of assignment pos = psPos; in line 856 (last line of for loop). Proposal: check pos for NULL in head of for loop If I understand correctly how the code currently works, pos/psPos will be NULL on the last iteration of the loop, but we'll exit anyway since "i == npaths" by that point. So the NULL pos will never be referenced. I guess coverity is cluing in on the following section: 846 psPos = strchr(pos, ps[0]); 847 if ( psPos == NULL ) { 848 plen = (int)strlen(pos); 849 } else { 850 plen = (int)(psPos-pos); 851 psPos++; 852 } We admit in line 847 that psPos can be NULL, but coverity can't read into the loop logic deep enough to recognize we'll also exit when this happens. I guess your fix is fine, although technically unnecessary. src/jdk.jdwp.agent/share/native/libjdwp/error_messages.c, static void vprint_message(FILE *fp, const char *prefix, const char *suffix, const char *format, va_list ap): potentially unterminated vsnprintf call. Proposal: terminate Ok. src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c, static jboolean synthesizeUnloadEvent(void *signatureVoid, void *envVoid): checking eventBag for NULL and then calling JDI_ASSERT only in that case is a bit dubious. It leads the coverity code scan tool to think that eventBag might be NULL when eventHelper_recordClassUnload is called which would eventually try to dereference a NULL eventbag and hence crash. Proposal: remove the NULL check but unconditionally assert. This is the real fix for the changes in eventHelper.c in my former webrev. Looks good. Thanks for looking deeper into this one. src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c, void log_message_end(const char *format, ...): potentially unterminated vsnprintf call. Proposal: terminate Ok. Furthermore I have 2 whitespace changes which I?d like to see because they would help me reducing the diff to our codebase and, furthermore, make the code looking nicer? a little ;-) Please list the files with just whitespace changes in the CR. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8192978.2/ Bug: https://bugs.openjdk.java.net/browse/JDK-8192978 I?m doing builds on the main platform and running jtreg tests. I'm doing a pretty comprehensive round of serviceability testing myself with these changes and also 8193258. I'll let you know if there are any issues. thanks, Chris Thanks in advance & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From amit.sapre at oracle.com Mon Dec 11 09:36:30 2017 From: amit.sapre at oracle.com (Amit Sapre) Date: Mon, 11 Dec 2017 01:36:30 -0800 (PST) Subject: RFR : Test bug : JDK-8179700 - Exceptions thrown in StartManagementAgent.java Message-ID: <70e51ad6-b8dd-4b82-95a4-2b7821e27ce0@default> Hello, Please review this trival fix for removing test case from ProblemList.txt file. The Test case got updated from other changeset http://hg.openjdk.java.net/jdk/hs/rev/bc1cffa26561 But was not removed from ProblemList.txt. Bug id : https://bugs.openjdk.java.net/browse/JDK-8179700 Webrev : http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8179700/webrev.00/ Thanks, Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at ORACLE.COM Mon Dec 11 07:53:06 2017 From: chris.plummer at ORACLE.COM (Chris Plummer) Date: Sun, 10 Dec 2017 23:53:06 -0800 Subject: RFR(S): 8192978: Missing checks and small fixes in jdwp library In-Reply-To: <40fa44d716f74a72b21a83dc341697f2@sap.com> References: <9080870b-800b-888d-52df-a55b5e3381e4@oracle.com> <37515ee093d749caba716b520bcae927@sap.com> <025a61b2-13cd-ed5d-0017-dbdbe49f0951@oracle.com> <5c4391cb4a84449ea706b43ab669448b@sap.com> <40fa44d716f74a72b21a83dc341697f2@sap.com> Message-ID: <842a6b05-db48-70d6-99e2-963aec793621@oracle.com> An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Mon Dec 11 10:11:10 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 11 Dec 2017 02:11:10 -0800 (PST) Subject: RFR: JDK-8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands In-Reply-To: References: Message-ID: Hi Jini, Looks Good. Some nits: http://cr.openjdk.java.net/~jgeorge/8192985/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java.html Since you are not passing any new VM options, the following lines 28 import jdk.test.lib.Utils; 47 List vmArgs = new ArrayList(); 48 vmArgs.addAll(Utils.getVmOptions()); 49 50 theApp = new LingeredAppWithLock(); 51 LingeredApp.startApp(vmArgs, theApp); Can be replaced by theApp = new LingeredAppWithLock(); LingeredApp.startApp(null, theApp); http://cr.openjdk.java.net/~jgeorge/8192985/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java.html 41 public static void testWithGcType If you are not planning on this method being called from elsewhere, you can make it private. Thanks, Sharath -----Original Message----- From: Jini George Sent: Friday, December 08, 2017 12:33 PM To: serviceability-dev at openjdk.java.net Subject: RFR: JDK-8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands Hello, Requesting reviews for: JBS Id: https://bugs.openjdk.java.net/browse/JDK-8192985 Webrev: http://cr.openjdk.java.net/~jgeorge/8192985/webrev.00/ These are the new test cases for the following clhsdb commands: 1. inspect 2. scanoops 3. printas These tests have been verified through the Mach5 and jprt systems. Thanks, Jini. From shafi.s.ahmad at oracle.com Mon Dec 11 10:31:43 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Mon, 11 Dec 2017 02:31:43 -0800 (PST) Subject: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code [internal] In-Reply-To: <84a40b32-51aa-445d-b325-8b751a7e9516@default> References: <84a40b32-51aa-445d-b325-8b751a7e9516@default> Message-ID: <7a69f608-9271-42ef-8048-faeddc7b0b8a@default> Hi, Could you please review the fix for JDK-8170299: Debugger does not stop inside the low memory notifications code. With the current implementation 'debugger does not stop inside the low memory *notifications* code' This is expected as the notification code is getting executed with the service thread, which is a hidden thread. shafi at shafi-ahmad:~/Java/jdk8/jdk8u-dev$ jdb -Xmx32m MemoryWarningSystem Initializing jdb ... > stop at MemoryWarningSystem$1:25 Deferring breakpoint MemoryWarningSystem$1:25. It will be set after the class is loaded. > run run MemoryWarningSystem Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > . . . > quit Breakpoint not hit. With the attached webrev, jdb stop at breakpoint inside notification code. shshahma at slc12kkg:/scratch/shshahma/Java/jdk-dev$ jdb -Xmx128m MemoryWarningSystem Initializing jdb ... > stop at MemoryWarningSystem$1:25 Deferring breakpoint MemoryWarningSystem$1:25. It will be set after the class is loaded. > run run MemoryWarningSystem Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > VM Started: Set deferred breakpoint MemoryWarningSystem$1:25 Breakpoint hit: "thread=Debugger", MemoryWarningSystem$1.memoryUsageLow(), line=25 bci=0 25 System.out.println("Memory usage low!!!"); Debugger[1] where [1] MemoryWarningSystem$1.memoryUsageLow (MemoryWarningSystem.java:25) [2] MemoryWarningSystem$2.handleNotification (MemoryWarningSystem.java:48) [3] javax.management.NotificationBroadcasterSupport.handleNotification (NotificationBroadcasterSupport.java:284) [4] javax.management.NotificationBroadcasterSupport$SendNotifJob.run (NotificationBroadcasterSupport.java:361) [5] java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1,135) [6] java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:635) [7] java.lang.Thread.run (Thread.java:844) [8] jdk.internal.misc.InnocuousThread.run (InnocuousThread.java:134) Debugger[1] list 21 22 MemoryWarningSystem mws = new MemoryWarningSystem(); 23 mws.addListener(new MemoryWarningSystem.Listener() { 24 public void memoryUsageLow(long usedMemory, long maxMemory) { 25 => System.out.println("Memory usage low!!!"); 26 double percentageUsed = ((double) usedMemory) / maxMemory; 27 System.out.println("percentageUsed = " + percentageUsed); 28 MemoryWarningSystem.setPercentageUsageThreshold(0.8); 29 } 30 }); Debugger[1] threads Group system: (java.lang.ref.Reference$ReferenceHandler)0x362 Reference Handler running (java.lang.ref.Finalizer$FinalizerThread)0x361 Finalizer cond. waiting (java.lang.Thread)0x360 Signal Dispatcher running Group main: (java.lang.Thread)0x1 main running Group InnocuousThreadGroup: (jdk.internal.misc.InnocuousThread)0x35f Common-Cleaner cond. waiting (jdk.internal.misc.InnocuousThread)0x4f1 Debugger running (at breakpoint) Debugger[1] step > Memory usage low!!! Step completed: "thread=Debugger", MemoryWarningSystem$1.memoryUsageLow(), line=26 bci=8 26 double percentageUsed = ((double) usedMemory) / maxMemory; Please see the newly created thread " (jdk.internal.misc.InnocuousThread)0x4f1 Debugger running (at breakpoint)". In the change, the class 'MemoryImpl' is derived from class 'NotificationBroadcasterSupport' instead of class 'NotificationEmitterSupport' NotificationBroadcastSupport takes an Executor, in the constructor of MemoryImpl we are calling super() with an executor, which is a visible thread. The method hasListeners() is referenced inside MemoryImpl.java and defined in NotificationEmitterSupport. This method is not present in NotificationBroadcasterSupport so I added it to NotificationBroadcasterSupport. Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8170299 Webrev link: http://cr.openjdk.java.net/~shshahma/8170299/webrev.02/ Testing: jprt -testset core, rbt --test nsk.jvmti.testlist,nsk.jdi.testlist. Regards, Shafi -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Dec 11 12:40:00 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Dec 2017 22:40:00 +1000 Subject: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code [internal] In-Reply-To: <7a69f608-9271-42ef-8048-faeddc7b0b8a@default> References: <84a40b32-51aa-445d-b325-8b751a7e9516@default> <7a69f608-9271-42ef-8048-faeddc7b0b8a@default> Message-ID: <688138a6-2f71-91bf-6da4-7baa5b2195c2@oracle.com> Hi Shafi, I'm not at all sure about the approach you've taken with this ... On 11/12/2017 8:31 PM, Shafi Ahmad wrote: > Hi, > > Could you please review the fix for JDK-8170299: Debugger does not stop > inside the low memory notifications code. > > With the current implementation ?debugger does not stop inside the low > memory *notifications* code? > > This is expected as the notification code is getting executed with the > service thread, which is a hidden thread. Okay. I recall some discussion on this problem - the main question being "why is the service thread executing user-defined Java code?". I'm assuming now this is an implementation artifact, not part of the main design of the management framework? But it is unclear. Attempting to introduce a new thread to execute the code may be reasonable, but raises whole range of questions about concurrency, synchronization and possibly deadlock with this code! > shafi at shafi-ahmad:~/Java/jdk8/jdk8u-dev$ jdb -Xmx32m MemoryWarningSystem > > Initializing jdb ... > > > stop at MemoryWarningSystem$1:25 > > Deferring breakpoint MemoryWarningSystem$1:25. > > It will be set after the class is loaded. > > > run > > run MemoryWarningSystem > > Set uncaught java.lang.Throwable > > Set deferred uncaught java.lang.Throwable > > > > > . . . > > > quit > > Breakpoint not hit. > > With the attached webrev, jdb stop ?at breakpoint inside notification code. > > shshahma at slc12kkg:/scratch/shshahma/Java/jdk-dev$ jdb -Xmx128m > MemoryWarningSystem > > Initializing jdb ... > > > stop at MemoryWarningSystem$1:25 > > Deferring breakpoint MemoryWarningSystem$1:25. > > It will be set after the class is loaded. > > > run > > run MemoryWarningSystem > > Set uncaught java.lang.Throwable > > Set deferred uncaught java.lang.Throwable > > > > > VM Started: Set deferred breakpoint MemoryWarningSystem$1:25 > > Breakpoint hit: "thread=Debugger", > MemoryWarningSystem$1.memoryUsageLow(), line=25 bci=0 > > 25 ???????????System.out.println("Memory usage low!!!"); > > Debugger[1] where > > ? [1] MemoryWarningSystem$1.memoryUsageLow (MemoryWarningSystem.java:25) > > ? [2] MemoryWarningSystem$2.handleNotification > (MemoryWarningSystem.java:48) > > ? [3] > javax.management.NotificationBroadcasterSupport.handleNotification > (NotificationBroadcasterSupport.java:284) > > ? [4] javax.management.NotificationBroadcasterSupport$SendNotifJob.run > (NotificationBroadcasterSupport.java:361) > > ? [5] java.util.concurrent.ThreadPoolExecutor.runWorker > (ThreadPoolExecutor.java:1,135) > > ? [6] java.util.concurrent.ThreadPoolExecutor$Worker.run > (ThreadPoolExecutor.java:635) > > ? [7] java.lang.Thread.run (Thread.java:844) > > ? [8] jdk.internal.misc.InnocuousThread.run (InnocuousThread.java:134) > > Debugger[1] list > > 21 > > 22??????? MemoryWarningSystem mws = new MemoryWarningSystem(); > > 23??????? mws.addListener(new MemoryWarningSystem.Listener() { > > 24????????? public void memoryUsageLow(long usedMemory, long maxMemory) { > > 25 =>???????? System.out.println("Memory usage low!!!"); > > 26??????????? double percentageUsed = ((double) usedMemory) / maxMemory; > > 27??????????? System.out.println("percentageUsed = " + percentageUsed); > > 28??????????? MemoryWarningSystem.setPercentageUsageThreshold(0.8); > > 29????????? } > > 30??????? }); > > Debugger[1] threads > > Group system: > > ? (java.lang.ref.Reference$ReferenceHandler)0x362 Reference Handler running > > ? (java.lang.ref.Finalizer$FinalizerThread)0x361? Finalizer > cond. waiting > > ? (java.lang.Thread)0x360???????????????????????? Signal Dispatcher running > > Group main: > > ? (java.lang.Thread)0x1?????????????????????????? main????????????? running > > Group InnocuousThreadGroup: > > ? (jdk.internal.misc.InnocuousThread)0x35f??????? Common-Cleaner > cond. waiting > > ? (jdk.internal.misc.InnocuousThread)0x4f1??????? Debugger > ???????running (at breakpoint) > > Debugger[1] step > > > Memory usage low!!! > > Step completed: "thread=Debugger", > MemoryWarningSystem$1.memoryUsageLow(), line=26 bci=8 > > 26??????????? double percentageUsed = ((double) usedMemory) / maxMemory; > > Please see the newly created thread ? > (jdk.internal.misc.InnocuousThread)0x4f1??????? Debugger > ???????running (at breakpoint)?. > > In the change, the class ?MemoryImpl? is derived from class > ?NotificationBroadcasterSupport? instead of class > ?NotificationEmitterSupport? That's quite a significant change and the implications of it are not at all obvious. The sun.management.NotificationEmitterSupport class utilises synchronization for thread-safety. The NotificationBroadcasterSupport class utilises a CopyOnWriteArraylist and will have quite different concurrency properties. Throw into the mix the fact you've now added a new thread and we really have no clear idea how this will all behave. > NotificationBroadcastSupport takes an Executor, in the constructor of > MemoryImpl we are calling super() with an executor, which is a visible > thread. > > The method hasListeners() is referenced ?inside MemoryImpl.java and > defined in ?NotificationEmitterSupport. > > This method is not present in ?NotificationBroadcasterSupport so I added > it to NotificationBroadcasterSupport. You will need to file a CSR request first to add a public method to a public class. But it's not all clear to me this is a method that should be added to this API. I see what you are trying to do, but the impact of these changes seem quite far reaching and hard to determine. > Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8170299 You should note that the bug is not publicly visible. Thanks, David > Webrev link: http://cr.openjdk.java.net/~shshahma/8170299/webrev.02/ > > Testing: jprt -testset core, rbt --test nsk.jvmti.testlist,nsk.jdi.testlist. > > Regards, > > Shafi > From daniel.daugherty at oracle.com Mon Dec 11 13:09:33 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 11 Dec 2017 08:09:33 -0500 Subject: RFR(S): 8192978: Missing checks and small fixes in jdwp library In-Reply-To: <842a6b05-db48-70d6-99e2-963aec793621@oracle.com> References: <9080870b-800b-888d-52df-a55b5e3381e4@oracle.com> <37515ee093d749caba716b520bcae927@sap.com> <025a61b2-13cd-ed5d-0017-dbdbe49f0951@oracle.com> <5c4391cb4a84449ea706b43ab669448b@sap.com> <40fa44d716f74a72b21a83dc341697f2@sap.com> <842a6b05-db48-70d6-99e2-963aec793621@oracle.com> Message-ID: <94237a8e-fec9-4cbc-b2d1-3da68e2fafab@oracle.com> Fixed. Dan On 12/11/17 2:53 AM, Chris Plummer wrote: > Hi Christoph, > > I was just guilty of the same thing on Friday. Dan cleaned it up for > me. See JDK-8191229. I believe the process is to change the Fix > Version in the backport from 10 to 11, re-open it, and then close as > resolved "No an issue" (with a comment as to why this was done). For > the main CR, change the Fix Version from 11 to 10, copy the HG Updater > info from the backport, close as resolved "Fixed". I think you also > need to set "Resolved In Build" to "team". > > Chris > > On 12/10/17 11:39 PM, Langer, Christoph wrote: >> >> Hi guys, >> >> I just pushed this: http://hg.openjdk.java.net/jdk/jdk/rev/8db54e2c453b >> >> However, for some reason somebody set my original bug to Fix version >> 11 which I kinda ignored and now the system created a backport bug >> for 10 (https://bugs.openjdk.java.net/browse/JDK-8193305). Probably I >> should have corrected the fix version before I pushed. Now, shall I >> set the original bug https://bugs.openjdk.java.net/browse/JDK-8192978 >> to ?Resolved? manually or wait for the system to do it? Any hints on >> that one? >> >> Thanks >> >> Christoph >> >> *From:*Langer, Christoph >> *Sent:* Samstag, 9. Dezember 2017 18:08 >> *To:* 'Chris Plummer' ; >> serviceability-dev at openjdk.java.net >> *Cc:* 'serguei.spitsyn at oracle.com' >> *Subject:* RE: RFR(S): 8192978: Missing checks and small fixes in >> jdwp library >> >> Hi Chris, >> >> thanks for testing. I added the files with whitespace changes to the >> bug. I?ll push this on Monday. >> >> Best regards >> >> Christoph >> >> *From:*Chris Plummer [mailto:chris.plummer at oracle.com] >> *Sent:* Samstag, 9. Dezember 2017 01:18 >> *To:* Langer, Christoph > >; >> serviceability-dev at openjdk.java.net >> >> *Cc:* Lindenmaier, Goetz > > >> *Subject:* Re: RFR(S): 8192978: Missing checks and small fixes in >> jdwp library >> >> All testing passed. >> >> thanks, >> >> Chris >> >> On 12/8/17 1:07 PM, Langer, Christoph wrote: >> >> Thanks in advance, Chris, for testing. >> >> Please let me know the outcome when you are done. >> >> Best regards >> >> Christoph >> >> *From:*Chris Plummer [mailto:chris.plummer at oracle.com] >> *Sent:* Freitag, 8. Dezember 2017 21:52 >> *To:* Langer, Christoph >> ; >> serviceability-dev at openjdk.java.net >> >> *Cc:* Lindenmaier, Goetz >> >> *Subject:* Re: RFR(S): 8192978: Missing checks and small fixes in >> jdwp library >> >> Hi Christoph, >> >> On 12/8/17 5:48 AM, Langer, Christoph wrote: >> >> Hi, >> >> this is a new webrev for 8192978. This change now only >> contains the coverity fixes. >> >> In detail: >> src/jdk.jdwp.agent/share/native/libjdwp/VirtualMachineImpl.c, >> static void writePaths(PacketOutputStream *out, char *string): >> ????strchr could be called with NULL argument because of >> assignment pos = psPos; in line 856 (last line of for loop). >> Proposal: check pos for NULL in head of for loop >> >> If I understand correctly how the code currently works, pos/psPos >> will be NULL on the last iteration of the loop, but we'll exit >> anyway since "i == npaths" by that point. So the NULL pos will >> never be referenced. I guess coverity is cluing in on the >> following section: >> >> ?846???????? psPos = strchr(pos, ps[0]); >> ?847???????? if ( psPos == NULL ) { >> ?848???????????? plen = (int)strlen(pos); >> ?849???????? } else { >> ?850???????????? plen = (int)(psPos-pos); >> ?851???????????? psPos++; >> ?852???????? } >> >> We admit in line 847 that psPos can be NULL, but coverity can't >> read into the loop logic deep enough to recognize we'll also exit >> when this happens. >> >> I guess your fix is fine, although technically unnecessary. >> >> >> >> >> ?src/jdk.jdwp.agent/share/native/libjdwp/error_messages.c, >> static void vprint_message(FILE *fp, const char *prefix, >> const char *suffix, const char *format, va_list ap): >> ????potentially unterminated vsnprintf call. Proposal: terminate >> >> Ok. >> >> >> >> src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c, >> static jboolean synthesizeUnloadEvent(void *signatureVoid, >> void *envVoid): >> ????checking eventBag for NULL and then calling JDI_ASSERT >> only in that case is a bit dubious. >> >> ??? It leads the coverity code scan tool to think that >> eventBag might be NULL when eventHelper_recordClassUnload is >> called >> >> ??? which would eventually try to dereference a NULL eventbag >> and hence crash. >> >> ??? Proposal: remove the NULL check but unconditionally assert. >> >> ??? This is the real fix for the changes in eventHelper.c in >> my former webrev. >> >> Looks good. Thanks for looking deeper into this one. >> >> >> src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c, void >> log_message_end(const char *format, ...): >> ????potentially unterminated vsnprintf call. Proposal: terminate >> >> Ok. >> >> Furthermore I have 2 whitespace changes which I?d like to see >> because they would help me reducing the diff to our codebase >> and, furthermore, make the code looking nicer? a little ;-) >> >> Please list the files with just whitespace changes in the CR. >> >> >> Webrev: >> http://cr.openjdk.java.net/~clanger/webrevs/8192978.2/ >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8192978 >> >> >> I?m doing builds on the main platform and running jtreg tests. >> >> I'm doing a pretty comprehensive round of serviceability testing >> myself with these changes and also 8193258. I'll let you know if >> there are any issues. >> >> thanks, >> >> Chris >> >> Thanks in advance & Best regards >> >> Christoph >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon Dec 11 15:39:30 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 11 Dec 2017 15:39:30 +0000 Subject: RFR(S): 8192978: Missing checks and small fixes in jdwp library In-Reply-To: <94237a8e-fec9-4cbc-b2d1-3da68e2fafab@oracle.com> References: <9080870b-800b-888d-52df-a55b5e3381e4@oracle.com> <37515ee093d749caba716b520bcae927@sap.com> <025a61b2-13cd-ed5d-0017-dbdbe49f0951@oracle.com> <5c4391cb4a84449ea706b43ab669448b@sap.com> <40fa44d716f74a72b21a83dc341697f2@sap.com> <842a6b05-db48-70d6-99e2-963aec793621@oracle.com> <94237a8e-fec9-4cbc-b2d1-3da68e2fafab@oracle.com> Message-ID: <99777f515c2747d783130dd122fd35de@sap.com> Hi Dan, thanks for your help. I'll be more wary next time... Best regards Christoph From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] Sent: Montag, 11. Dezember 2017 14:10 To: Chris Plummer ; Langer, Christoph ; serguei.spitsyn at oracle.com; serviceability-dev at openjdk.java.net Subject: Re: RFR(S): 8192978: Missing checks and small fixes in jdwp library Fixed. Dan On 12/11/17 2:53 AM, Chris Plummer wrote: Hi Christoph, I was just guilty of the same thing on Friday. Dan cleaned it up for me. See JDK-8191229. I believe the process is to change the Fix Version in the backport from 10 to 11, re-open it, and then close as resolved "No an issue" (with a comment as to why this was done). For the main CR, change the Fix Version from 11 to 10, copy the HG Updater info from the backport, close as resolved "Fixed". I think you also need to set "Resolved In Build" to "team". Chris On 12/10/17 11:39 PM, Langer, Christoph wrote: Hi guys, I just pushed this: http://hg.openjdk.java.net/jdk/jdk/rev/8db54e2c453b However, for some reason somebody set my original bug to Fix version 11 which I kinda ignored and now the system created a backport bug for 10 (https://bugs.openjdk.java.net/browse/JDK-8193305). Probably I should have corrected the fix version before I pushed. Now, shall I set the original bug https://bugs.openjdk.java.net/browse/JDK-8192978 to "Resolved" manually or wait for the system to do it? Any hints on that one? Thanks Christoph From: Langer, Christoph Sent: Samstag, 9. Dezember 2017 18:08 To: 'Chris Plummer' ; serviceability-dev at openjdk.java.net Cc: 'serguei.spitsyn at oracle.com' Subject: RE: RFR(S): 8192978: Missing checks and small fixes in jdwp library Hi Chris, thanks for testing. I added the files with whitespace changes to the bug. I'll push this on Monday. Best regards Christoph From: Chris Plummer [mailto:chris.plummer at oracle.com] Sent: Samstag, 9. Dezember 2017 01:18 To: Langer, Christoph >; serviceability-dev at openjdk.java.net Cc: Lindenmaier, Goetz > Subject: Re: RFR(S): 8192978: Missing checks and small fixes in jdwp library All testing passed. thanks, Chris On 12/8/17 1:07 PM, Langer, Christoph wrote: Thanks in advance, Chris, for testing. Please let me know the outcome when you are done. Best regards Christoph From: Chris Plummer [mailto:chris.plummer at oracle.com] Sent: Freitag, 8. Dezember 2017 21:52 To: Langer, Christoph ; serviceability-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: Re: RFR(S): 8192978: Missing checks and small fixes in jdwp library Hi Christoph, On 12/8/17 5:48 AM, Langer, Christoph wrote: Hi, this is a new webrev for 8192978. This change now only contains the coverity fixes. In detail: src/jdk.jdwp.agent/share/native/libjdwp/VirtualMachineImpl.c, static void writePaths(PacketOutputStream *out, char *string): strchr could be called with NULL argument because of assignment pos = psPos; in line 856 (last line of for loop). Proposal: check pos for NULL in head of for loop If I understand correctly how the code currently works, pos/psPos will be NULL on the last iteration of the loop, but we'll exit anyway since "i == npaths" by that point. So the NULL pos will never be referenced. I guess coverity is cluing in on the following section: 846 psPos = strchr(pos, ps[0]); 847 if ( psPos == NULL ) { 848 plen = (int)strlen(pos); 849 } else { 850 plen = (int)(psPos-pos); 851 psPos++; 852 } We admit in line 847 that psPos can be NULL, but coverity can't read into the loop logic deep enough to recognize we'll also exit when this happens. I guess your fix is fine, although technically unnecessary. src/jdk.jdwp.agent/share/native/libjdwp/error_messages.c, static void vprint_message(FILE *fp, const char *prefix, const char *suffix, const char *format, va_list ap): potentially unterminated vsnprintf call. Proposal: terminate Ok. src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c, static jboolean synthesizeUnloadEvent(void *signatureVoid, void *envVoid): checking eventBag for NULL and then calling JDI_ASSERT only in that case is a bit dubious. It leads the coverity code scan tool to think that eventBag might be NULL when eventHelper_recordClassUnload is called which would eventually try to dereference a NULL eventbag and hence crash. Proposal: remove the NULL check but unconditionally assert. This is the real fix for the changes in eventHelper.c in my former webrev. Looks good. Thanks for looking deeper into this one. src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c, void log_message_end(const char *format, ...): potentially unterminated vsnprintf call. Proposal: terminate Ok. Furthermore I have 2 whitespace changes which I'd like to see because they would help me reducing the diff to our codebase and, furthermore, make the code looking nicer... a little ;-) Please list the files with just whitespace changes in the CR. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8192978.2/ Bug: https://bugs.openjdk.java.net/browse/JDK-8192978 I'm doing builds on the main platform and running jtreg tests. I'm doing a pretty comprehensive round of serviceability testing myself with these changes and also 8193258. I'll let you know if there are any issues. thanks, Chris Thanks in advance & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon Dec 11 15:43:36 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 11 Dec 2017 15:43:36 +0000 Subject: RFR (S): 8193258: Better usage of JDWP HEADER SIZE In-Reply-To: <414830ddd74f46e988afb14a146616e0@sap.com> References: <3acbaa87f2ab4df69dbddc277d2ea673@sap.com> <7cc996bb-b8ec-b147-5dea-e2f21e7ff9e5@oracle.com> <414830ddd74f46e988afb14a146616e0@sap.com> Message-ID: <18402b3adaac40318233487eedd5e9e7@sap.com> Hi Serguei, Chris, please look at this webrev: http://cr.openjdk.java.net/~clanger/webrevs/8193258.2/ I spotted a few other locations in libdt_shmem where JDWP HEADER SIZE should be used. Builds and tests running? Best regards Christoph From: Langer, Christoph Sent: Sonntag, 10. Dezember 2017 10:52 To: 'serguei.spitsyn at oracle.com' ; serviceability-dev at openjdk.java.net Cc: Chris Plummer Subject: RE: RFR (S): 8193258: Better usage of JDWP HEADER SIZE Hi Serguei, I wasn?t aware that the jdk/com/sun/jdi tests would test libjdwp, I just found hotspot/jtreg/serviceability/jdwp when searching for jdwp in the tests. But thanks to your hints I know better now. In fact I ran the jdi tests when testing my change for 8193183. I made a new webrev which includes the removal of inStream_endOfInput: http://cr.openjdk.java.net/~clanger/webrevs/8193258.1/. Can you please approve this. This time I ran the jdi tests without issues and also did builds on Windows, linux x86, AIX, Solaris and Mac. ? Best regards Christoph From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Samstag, 9. Dezember 2017 06:27 To: Langer, Christoph >; serviceability-dev at openjdk.java.net; Chris Plummer > Subject: Re: RFR (S): 8193258: Better usage of JDWP HEADER SIZE Hi Christoph, You need to run at least the jdk/com/sun/jdi tests. Thanks, Serguei On 12/8/17 13:07, Langer, Christoph wrote: Hi Serguei, I did only run hotspot/jtreg/serviceability/jdwp, didn?t find a lot more in that area. I?m hoping/waiting for Chris? tests then. I agree, I will then remove inStream_endOfInput. If something like that is needed for future developments, it can easily be added again. Best regards Christoph From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Freitag, 8. Dezember 2017 21:12 To: Langer, Christoph ; serviceability-dev at openjdk.java.net; Chris Plummer Subject: Re: RFR (S): 8193258: Better usage of JDWP HEADER SIZE Hi Christoph, The fix looks good to me. What tests did you run? On 12/8/17 07:07, Langer, Christoph wrote: Hi, Here?s a proposal to clean up the usage of the JDWP header size within the source code of libjdwp. Bug: https://bugs.openjdk.java.net/browse/JDK-8193258 WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8193258.0/ As for inStream.c, I?m wondering wether inStream_endOfInput shall be removed? It seems to be unused? I'm inclined to remove it. Otherwise, it must be: 417 return (stream->left <= 0); Thanks, Serguei Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Dec 11 16:52:38 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Dec 2017 16:52:38 +0000 Subject: FW: RFR(M): 8189102: All tools should support -?, -h and --help In-Reply-To: <456c694ec25a42658af1b8600aaa136d@sap.com> References: <8aa25976d496465fac00a4ae3628e533@sap.com> <456c694ec25a42658af1b8600aaa136d@sap.com> Message-ID: <6d7d895f-9f23-fd4b-39ca-ef9bb0331fb9@oracle.com> On 07/12/2017 11:20, Lindenmaier, Goetz wrote: > Hi, > > ... missed some lists in my first post ... > > I prepared a fifth webrev for this change. Please review. > > It incorporates the changes requested by the CSR reviewers > (not to remove docuemtation of '-help' where is was documented > before) and the changes proposed by Kumar: > http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.05/ > > Looks like it still drops -help from the javadoc usage message, I can't tell if you meant to do that. -Alan. From chris.plummer at oracle.com Mon Dec 11 18:19:31 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 11 Dec 2017 10:19:31 -0800 Subject: RFR (S): 8193258: Better usage of JDWP HEADER SIZE In-Reply-To: <18402b3adaac40318233487eedd5e9e7@sap.com> References: <3acbaa87f2ab4df69dbddc277d2ea673@sap.com> <7cc996bb-b8ec-b147-5dea-e2f21e7ff9e5@oracle.com> <414830ddd74f46e988afb14a146616e0@sap.com> <18402b3adaac40318233487eedd5e9e7@sap.com> Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Dec 11 19:10:43 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 11 Dec 2017 11:10:43 -0800 Subject: RFR (S): 8193258: Better usage of JDWP HEADER SIZE In-Reply-To: <18402b3adaac40318233487eedd5e9e7@sap.com> References: <3acbaa87f2ab4df69dbddc277d2ea673@sap.com> <7cc996bb-b8ec-b147-5dea-e2f21e7ff9e5@oracle.com> <414830ddd74f46e988afb14a146616e0@sap.com> <18402b3adaac40318233487eedd5e9e7@sap.com> Message-ID: <3dcba359-8daf-0520-9634-5c88451bfa37@oracle.com> An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Mon Dec 11 21:04:32 2017 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 11 Dec 2017 13:04:32 -0800 Subject: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code [internal] In-Reply-To: <7a69f608-9271-42ef-8048-faeddc7b0b8a@default> References: <84a40b32-51aa-445d-b325-8b751a7e9516@default> <7a69f608-9271-42ef-8048-faeddc7b0b8a@default> Message-ID: On 12/11/17 2:31 AM, Shafi Ahmad wrote: > > The method hasListeners() is referenced ?inside MemoryImpl.java and > defined in ?NotificationEmitterSupport. > > This method is not present in ?NotificationBroadcasterSupport so I > added it to NotificationBroadcasterSupport. > This is a spec change.? Is this intentional?? I replied in Sept in reviewing an earlier version [1] that this cannot be backported.? If you intend to make this spec change, it's better to separate this RFE and it requires CSR. > Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8170299 > > Webrev link: http://cr.openjdk.java.net/~shshahma/8170299/webrev.02/ > > MemoryImpl.java 189 th.setName("Debugger"); this is not a debugger thread. Maybe rename it to "MemoryPool notification thread"? Mandy [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021836.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Mon Dec 11 23:13:08 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 11 Dec 2017 15:13:08 -0800 Subject: RFR: JDK-8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands In-Reply-To: References: Message-ID: <5b89187b-d49a-a239-864a-07be31e78b6f@oracle.com> Hi Jini, On 12/7/17 11:03 PM, Jini George wrote: > Hello, > > Requesting reviews for: > > JBS Id: https://bugs.openjdk.java.net/browse/JDK-8192985 > Webrev: http://cr.openjdk.java.net/~jgeorge/8192985/webrev.00/ > > These are the new test cases for the following clhsdb commands: > 1. inspect tokensMap code can all move to inside the "if" block that follows it. > 2. scanoops When will "universe" not return any output? > 3. printas Ok. thanks, Chris > > These tests have been verified through the Mach5 and jprt systems. > > Thanks, > Jini. > From shafi.s.ahmad at oracle.com Tue Dec 12 05:02:15 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Mon, 11 Dec 2017 21:02:15 -0800 (PST) Subject: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code [internal] In-Reply-To: References: <84a40b32-51aa-445d-b325-8b751a7e9516@default> <7a69f608-9271-42ef-8048-faeddc7b0b8a@default> Message-ID: <464374d2-018b-4579-a948-f6ea8bfca539@default> Thank you Mandy and David. I am sorry, somehow I missed your earlier comment regarding the RFE. >> This is a spec change. Is this intentional? Yes, this change is required as this is referenced inside MemoryImpl.java. I will file a separate RFE for adding hasListeners(). I will send the updated webrev after incorporating the review comment. Regards, Shafi From: mandy chung Sent: Tuesday, December 12, 2017 2:35 AM To: Shafi Ahmad Cc: serviceability-dev at openjdk.java.net Subject: Re: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code [internal] On 12/11/17 2:31 AM, Shafi Ahmad wrote: The method hasListeners() is referenced inside MemoryImpl.java and defined in NotificationEmitterSupport. This method is not present in NotificationBroadcasterSupport so I added it to NotificationBroadcasterSupport. This is a spec change. Is this intentional? I replied in Sept in reviewing an earlier version [1] that this cannot be backported. If you intend to make this spec change, it's better to separate this RFE and it requires CSR. Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8170299 Webrev link: HYPERLINK "http://cr.openjdk.java.net/%7Eshshahma/8170299/webrev.02/"http://cr.openjdk.java.net/~shshahma/8170299/webrev.02/ MemoryImpl.java 189 th.setName("Debugger"); this is not a debugger thread. Maybe rename it to "MemoryPool notification thread"? Mandy [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021836.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Dec 12 05:32:35 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Dec 2017 15:32:35 +1000 Subject: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code [internal] In-Reply-To: <464374d2-018b-4579-a948-f6ea8bfca539@default> References: <84a40b32-51aa-445d-b325-8b751a7e9516@default> <7a69f608-9271-42ef-8048-faeddc7b0b8a@default> <464374d2-018b-4579-a948-f6ea8bfca539@default> Message-ID: <85c93c52-76dd-a56b-ace2-a7c145329779@oracle.com> Hi Shafi, I missed the first round of reviews on this so hadn't seen previous discussion. I'm still uneasy about introducing a new thread to the mix here, but at least Mandy's suggestion to modify the *Emitter class rather than change to the *Broadcaster is a lot less disruptive: http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021851.html David On 12/12/2017 3:02 PM, Shafi Ahmad wrote: > Thank you Mandy and David. > > I am sorry, somehow I missed your earlier comment regarding the RFE. > > >> This is a spec change.? Is this intentional? > > Yes, this change is required as this is referenced inside ?MemoryImpl.java. > > I will file a separate RFE for adding hasListeners(). > > I will send the updated webrev after incorporating the review comment. > > Regards, > > Shafi > > *From:*mandy chung > *Sent:* Tuesday, December 12, 2017 2:35 AM > *To:* Shafi Ahmad > *Cc:* serviceability-dev at openjdk.java.net > *Subject:* Re: [10] RFR for JDK-8170299: Debugger does not stop inside > the low memory notifications code [internal] > > On 12/11/17 2:31 AM, Shafi Ahmad wrote: > > The method hasListeners() is referenced ?inside MemoryImpl.java and > defined in ?NotificationEmitterSupport. > > This method is not present in ?NotificationBroadcasterSupport so I > added it to NotificationBroadcasterSupport. > > > This is a spec change.? Is this intentional?? I replied in Sept in > reviewing an earlier version [1] that this cannot be backported.? If you > intend to make this spec change, it's better to separate this RFE and it > requires CSR. > > > Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8170299 > > Webrev link: http://cr.openjdk.java.net/~shshahma/8170299/webrev.02/ > > > > MemoryImpl.java > > 189???????????????????? th.setName("Debugger"); > > this is not a debugger thread.? Maybe rename it to > > "MemoryPool notification thread"? > > Mandy > > [1] > http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021836.html > From serguei.spitsyn at oracle.com Tue Dec 12 05:50:56 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 11 Dec 2017 21:50:56 -0800 Subject: RFR (S): 8193258: Better usage of JDWP HEADER SIZE In-Reply-To: <3dcba359-8daf-0520-9634-5c88451bfa37@oracle.com> References: <3acbaa87f2ab4df69dbddc277d2ea673@sap.com> <7cc996bb-b8ec-b147-5dea-e2f21e7ff9e5@oracle.com> <414830ddd74f46e988afb14a146616e0@sap.com> <18402b3adaac40318233487eedd5e9e7@sap.com> <3dcba359-8daf-0520-9634-5c88451bfa37@oracle.com> Message-ID: <401a93fa-1129-6e9f-5528-5b68981c8d32@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Tue Dec 12 06:24:00 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 11 Dec 2017 22:24:00 -0800 Subject: RFR (S): 8193258: Better usage of JDWP HEADER SIZE In-Reply-To: <401a93fa-1129-6e9f-5528-5b68981c8d32@oracle.com> References: <3acbaa87f2ab4df69dbddc277d2ea673@sap.com> <7cc996bb-b8ec-b147-5dea-e2f21e7ff9e5@oracle.com> <414830ddd74f46e988afb14a146616e0@sap.com> <18402b3adaac40318233487eedd5e9e7@sap.com> <3dcba359-8daf-0520-9634-5c88451bfa37@oracle.com> <401a93fa-1129-6e9f-5528-5b68981c8d32@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Dec 12 06:34:58 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 11 Dec 2017 22:34:58 -0800 Subject: RFR (S): 8193258: Better usage of JDWP HEADER SIZE In-Reply-To: References: <3acbaa87f2ab4df69dbddc277d2ea673@sap.com> <7cc996bb-b8ec-b147-5dea-e2f21e7ff9e5@oracle.com> <414830ddd74f46e988afb14a146616e0@sap.com> <18402b3adaac40318233487eedd5e9e7@sap.com> <3dcba359-8daf-0520-9634-5c88451bfa37@oracle.com> <401a93fa-1129-6e9f-5528-5b68981c8d32@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Tue Dec 12 06:35:45 2017 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 11 Dec 2017 22:35:45 -0800 Subject: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code [internal] In-Reply-To: <85c93c52-76dd-a56b-ace2-a7c145329779@oracle.com> References: <84a40b32-51aa-445d-b325-8b751a7e9516@default> <7a69f608-9271-42ef-8048-faeddc7b0b8a@default> <464374d2-018b-4579-a948-f6ea8bfca539@default> <85c93c52-76dd-a56b-ace2-a7c145329779@oracle.com> Message-ID: On 12/11/17 9:32 PM, David Holmes wrote: > Hi Shafi, > > I missed the first round of reviews on this so hadn't seen previous > discussion. I'm still uneasy about introducing a new thread to the mix > here, but at least Mandy's suggestion to modify the *Emitter class > rather than change to the *Broadcaster is a lot less disruptive: > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021851.html > > Yes this is a better alternative (thanks for bringing this up, David). Mandy > David > > On 12/12/2017 3:02 PM, Shafi Ahmad wrote: >> Thank you Mandy and David. >> >> I am sorry, somehow I missed your earlier comment regarding the RFE. >> >> ?>> This is a spec change.? Is this intentional? >> >> Yes, this change is required as this is referenced inside >> ?MemoryImpl.java. >> >> I will file a separate RFE for adding hasListeners(). >> >> I will send the updated webrev after incorporating the review comment. >> >> Regards, >> >> Shafi >> >> *From:*mandy chung >> *Sent:* Tuesday, December 12, 2017 2:35 AM >> *To:* Shafi Ahmad >> *Cc:* serviceability-dev at openjdk.java.net >> *Subject:* Re: [10] RFR for JDK-8170299: Debugger does not stop >> inside the low memory notifications code [internal] >> >> On 12/11/17 2:31 AM, Shafi Ahmad wrote: >> >> ??? The method hasListeners() is referenced ?inside MemoryImpl.java and >> ??? defined in ?NotificationEmitterSupport. >> >> ??? This method is not present in ?NotificationBroadcasterSupport so I >> ??? added it to NotificationBroadcasterSupport. >> >> >> This is a spec change.? Is this intentional?? I replied in Sept in >> reviewing an earlier version [1] that this cannot be backported.? If >> you intend to make this spec change, it's better to separate this RFE >> and it requires CSR. >> >> >> ??? Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8170299 >> >> ??? Webrev link: http://cr.openjdk.java.net/~shshahma/8170299/webrev.02/ >> >> >> >> MemoryImpl.java >> >> 189???????????????????? th.setName("Debugger"); >> >> this is not a debugger thread.? Maybe rename it to >> >> "MemoryPool notification thread"? >> >> Mandy >> >> [1] >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021836.html >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Tue Dec 12 08:50:26 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 12 Dec 2017 08:50:26 +0000 Subject: RFR (S): 8193258: Better usage of JDWP HEADER SIZE In-Reply-To: References: <3acbaa87f2ab4df69dbddc277d2ea673@sap.com> <7cc996bb-b8ec-b147-5dea-e2f21e7ff9e5@oracle.com> <414830ddd74f46e988afb14a146616e0@sap.com> <18402b3adaac40318233487eedd5e9e7@sap.com> <3dcba359-8daf-0520-9634-5c88451bfa37@oracle.com> <401a93fa-1129-6e9f-5528-5b68981c8d32@oracle.com> Message-ID: <6c54ec8a39ea48f6a76b49b4d1855f85@sap.com> Hi, no problem. I already thought that I would not be able to see this. I pushed it: http://hg.openjdk.java.net/jdk/jdk/rev/61e60548c0cf Thanks for all your help in reviewing/testing this. Best regards Christoph From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Dienstag, 12. Dezember 2017 07:35 To: Chris Plummer ; Langer, Christoph ; serviceability-dev at openjdk.java.net Subject: Re: RFR (S): 8193258: Better usage of JDWP HEADER SIZE Yes. That was stupid. :( Thanks, Chris! Serguei On 12/11/17 22:24, Chris Plummer wrote: That's an internal link. Christoph won't be able to see them. Chris On 12/11/17 9:50 PM, serguei.spitsyn at oracle.com wrote: Hi Christoph, The testing looks good. These are the results: http://java.se.oracle.com:10065/mdash/jobs/sspitsyn-clanger-JDK-8193258-20171212-0054-7258 The job includes hs-tier's from 1-5. There are some failures there but nothing related to the JDI or JDWP tests. Thanks, Serguei On 12/11/17 11:10, serguei.spitsyn at oracle.com wrote: Hi Christoph, The fix looks good to me. I'll submit a mach5 job to make sure nothing is broken. Thanks, Serguei On 12/11/17 07:43, Langer, Christoph wrote: Hi Serguei, Chris, please look at this webrev: http://cr.openjdk.java.net/~clanger/webrevs/8193258.2/ I spotted a few other locations in libdt_shmem where JDWP HEADER SIZE should be used. Builds and tests running? Best regards Christoph From: Langer, Christoph Sent: Sonntag, 10. Dezember 2017 10:52 To: 'serguei.spitsyn at oracle.com' ; serviceability-dev at openjdk.java.net Cc: Chris Plummer Subject: RE: RFR (S): 8193258: Better usage of JDWP HEADER SIZE Hi Serguei, I wasn?t aware that the jdk/com/sun/jdi tests would test libjdwp, I just found hotspot/jtreg/serviceability/jdwp when searching for jdwp in the tests. But thanks to your hints I know better now. In fact I ran the jdi tests when testing my change for 8193183. I made a new webrev which includes the removal of inStream_endOfInput: http://cr.openjdk.java.net/~clanger/webrevs/8193258.1/. Can you please approve this. This time I ran the jdi tests without issues and also did builds on Windows, linux x86, AIX, Solaris and Mac. J Best regards Christoph From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Samstag, 9. Dezember 2017 06:27 To: Langer, Christoph >; serviceability-dev at openjdk.java.net; Chris Plummer > Subject: Re: RFR (S): 8193258: Better usage of JDWP HEADER SIZE Hi Christoph, You need to run at least the jdk/com/sun/jdi tests. Thanks, Serguei On 12/8/17 13:07, Langer, Christoph wrote: Hi Serguei, I did only run hotspot/jtreg/serviceability/jdwp, didn?t find a lot more in that area. I?m hoping/waiting for Chris? tests then. I agree, I will then remove inStream_endOfInput. If something like that is needed for future developments, it can easily be added again. Best regards Christoph From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] Sent: Freitag, 8. Dezember 2017 21:12 To: Langer, Christoph ; serviceability-dev at openjdk.java.net; Chris Plummer Subject: Re: RFR (S): 8193258: Better usage of JDWP HEADER SIZE Hi Christoph, The fix looks good to me. What tests did you run? On 12/8/17 07:07, Langer, Christoph wrote: Hi, Here?s a proposal to clean up the usage of the JDWP header size within the source code of libjdwp. Bug: https://bugs.openjdk.java.net/browse/JDK-8193258 WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8193258.0/ As for inStream.c, I?m wondering wether inStream_endOfInput shall be removed? It seems to be unused? I'm inclined to remove it. Otherwise, it must be: 417 return (stream->left <= 0); Thanks, Serguei Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Tue Dec 12 10:36:51 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 12 Dec 2017 10:36:51 +0000 Subject: FW: RFR(M): 8189102: All tools should support -?, -h and --help In-Reply-To: <6d7d895f-9f23-fd4b-39ca-ef9bb0331fb9@oracle.com> References: <8aa25976d496465fac00a4ae3628e533@sap.com> <456c694ec25a42658af1b8600aaa136d@sap.com> <6d7d895f-9f23-fd4b-39ca-ef9bb0331fb9@oracle.com> Message-ID: <7be3772e8060494cbecf3097bd0a8a85@sap.com> Hi Alan, Javadoc combines documentation and support of a flag in the way the flag handling is implemented. On the other side, it prints the help message anyways if a wrong flag is presented to it, so if you call it with -help you get the help message. Therefore, in my original change where I tried to get it more cleaned up, I removed -help support and documentation from Javadoc. I added it again and updated the table in the CSR: http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.06/ Best regards, Goetz. > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Montag, 11. Dezember 2017 17:53 > To: Lindenmaier, Goetz ; core-libs- > dev at openjdk.java.net; 'compiler-dev at openjdk.java.net' dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: FW: RFR(M): 8189102: All tools should support -?, -h and --help > > > > On 07/12/2017 11:20, Lindenmaier, Goetz wrote: > > Hi, > > > > ... missed some lists in my first post ... > > > > I prepared a fifth webrev for this change. Please review. > > > > It incorporates the changes requested by the CSR reviewers > > (not to remove docuemtation of '-help' where is was documented > > before) and the changes proposed by Kumar: > > http://cr.openjdk.java.net/~goetz/wr17/8189102- > helpMessage/webrev.05/ > > > > > Looks like it still drops -help from the javadoc usage message, I can't > tell if you meant to do that. > > -Alan. From jini.george at oracle.com Tue Dec 12 10:38:44 2017 From: jini.george at oracle.com (Jini George) Date: Tue, 12 Dec 2017 16:08:44 +0530 Subject: RFR: JDK-8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands In-Reply-To: <5b89187b-d49a-a239-864a-07be31e78b6f@oracle.com> References: <5b89187b-d49a-a239-864a-07be31e78b6f@oracle.com> Message-ID: <5cd9edaf-e766-bbdd-7eea-8b9afc264f2e@oracle.com> Thank you, Chris. Answers inline. On 12/12/2017 4:43 AM, Chris Plummer wrote: >> These are the new test cases for the following clhsdb commands: >> 1. inspect > tokensMap code can all move to inside the "if" block that follows it. Done. >> 2. scanoops > When will "universe" not return any output? universeOutput could be null if there are attach permission issues and if we are skipping the test. I have added these comments there for clarity. I have a new webrev at: http://cr.openjdk.java.net/~jgeorge/8192985/webrev.01/ Thanks, Jini. From jini.george at oracle.com Tue Dec 12 10:38:51 2017 From: jini.george at oracle.com (Jini George) Date: Tue, 12 Dec 2017 16:08:51 +0530 Subject: RFR: JDK-8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands In-Reply-To: References: Message-ID: Thank you, Sharath. I have a modified webrev at: http://cr.openjdk.java.net/~jgeorge/8192985/webrev.01/ Could a Reviewer also please take a look at it ? Thanks, Jini. On 12/11/2017 3:41 PM, Sharath Ballal wrote: > Hi Jini, > Looks Good. Some nits: > > http://cr.openjdk.java.net/~jgeorge/8192985/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java.html > > Since you are not passing any new VM options, the following lines > > 28 import jdk.test.lib.Utils; > 47 List vmArgs = new ArrayList(); > 48 vmArgs.addAll(Utils.getVmOptions()); > 49 > 50 theApp = new LingeredAppWithLock(); > 51 LingeredApp.startApp(vmArgs, theApp); > > Can be replaced by > > theApp = new LingeredAppWithLock(); > LingeredApp.startApp(null, theApp); > > http://cr.openjdk.java.net/~jgeorge/8192985/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java.html > > 41 public static void testWithGcType > If you are not planning on this method being called from elsewhere, you can make it private. > > Thanks, > Sharath > > > -----Original Message----- > From: Jini George > Sent: Friday, December 08, 2017 12:33 PM > To: serviceability-dev at openjdk.java.net > Subject: RFR: JDK-8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands > > Hello, > > Requesting reviews for: > > JBS Id: https://bugs.openjdk.java.net/browse/JDK-8192985 > Webrev: http://cr.openjdk.java.net/~jgeorge/8192985/webrev.00/ > > These are the new test cases for the following clhsdb commands: > 1. inspect > 2. scanoops > 3. printas > > These tests have been verified through the Mach5 and jprt systems. > > Thanks, > Jini. > From daniel.daugherty at oracle.com Tue Dec 12 12:49:16 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 12 Dec 2017 07:49:16 -0500 Subject: JVMTI not receiving field access events with fast_getfield In-Reply-To: <4d64eee4-ede6-3177-6fd4-2cecfe0d7296@oracle.com> References: <76571dcc69fd5c8f80611008843d244d@mail.gmail.com> <4d64eee4-ede6-3177-6fd4-2cecfe0d7296@oracle.com> Message-ID: Adding in the Serviceability team since JVM/TI belongs there. Dan On 12/12/17 7:46 AM, Vladimir Ivanov wrote: > Thanks for the report, Amir! > > Unfortunately, I can't access the bug you filed. > > Can you, please, share the test case and instructions how to reproduce > the problem? > > Also, what Java version & platform do you observe the bug on? > > I briefly looked into template interpreter code on x86 and it does > have relevant code to post JVMTI events in fast accessors. > > Best regards, > Vladimir Ivanov > > On 12/12/17 11:12 AM, Amir Rapson wrote: >> Hi Daniel, Coleen and Vladimir, >> >> I tracked your email addresses from some mailing lists and hopefully >> one of you is a relevant person for my problem. >> >> I also filed a bug request (ID 9051849) but since I don?t have an >> option to add information I decided to email you. >> >> The problem I?m seeing is that JMTI does not receive field access >> events (and probably field modification events) when /fast_getfield/ >> is used instead of /get_field/. >> >> I verified this by disabling all the >> /patch_bytecode(Bytecodes::_fast_?getfield, bc, rbx)/ in >> /TemplateTable::getfield_or_static()/ and made sure that JVMTI >> receives all the correct events. >> >> I have the agent code and a short java program that can reproduce the >> problem and would be happy to assist in fixing and or debugging this >> issue. >> >> I would appreciate any feedback. >> >> Best regards, >> >> Amir >> >> ?????Amir Rapson | Founder & VP Eng @ *vFunction* | 7 HaPelech St. >> Tel-Aviv | +972-522650968 >> From sharath.ballal at oracle.com Tue Dec 12 12:16:30 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Tue, 12 Dec 2017 04:16:30 -0800 (PST) Subject: RFR: JDK-8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands In-Reply-To: References: Message-ID: Looks good Jini. Thanks, Sharath -----Original Message----- From: Jini George Sent: Tuesday, December 12, 2017 4:09 PM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands Thank you, Sharath. I have a modified webrev at: http://cr.openjdk.java.net/~jgeorge/8192985/webrev.01/ Could a Reviewer also please take a look at it ? Thanks, Jini. On 12/11/2017 3:41 PM, Sharath Ballal wrote: > Hi Jini, > Looks Good. Some nits: > > http://cr.openjdk.java.net/~jgeorge/8192985/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java.html > > Since you are not passing any new VM options, the following lines > > 28 import jdk.test.lib.Utils; > 47 List vmArgs = new ArrayList(); > 48 vmArgs.addAll(Utils.getVmOptions()); > 49 > 50 theApp = new LingeredAppWithLock(); > 51 LingeredApp.startApp(vmArgs, theApp); > > Can be replaced by > > theApp = new LingeredAppWithLock(); > LingeredApp.startApp(null, theApp); > > http://cr.openjdk.java.net/~jgeorge/8192985/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java.html > > 41 public static void testWithGcType > If you are not planning on this method being called from elsewhere, you can make it private. > > Thanks, > Sharath > > > -----Original Message----- > From: Jini George > Sent: Friday, December 08, 2017 12:33 PM > To: serviceability-dev at openjdk.java.net > Subject: RFR: JDK-8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands > > Hello, > > Requesting reviews for: > > JBS Id: https://bugs.openjdk.java.net/browse/JDK-8192985 > Webrev: http://cr.openjdk.java.net/~jgeorge/8192985/webrev.00/ > > These are the new test cases for the following clhsdb commands: > 1. inspect > 2. scanoops > 3. printas > > These tests have been verified through the Mach5 and jprt systems. > > Thanks, > Jini. > From daniel.daugherty at oracle.com Tue Dec 12 13:13:25 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 12 Dec 2017 08:13:25 -0500 Subject: JVMTI not receiving field access events with fast_getfield In-Reply-To: <79f508d7d1a393730eab95c61f6b7af9@mail.gmail.com> References: <76571dcc69fd5c8f80611008843d244d@mail.gmail.com> <4d64eee4-ede6-3177-6fd4-2cecfe0d7296@oracle.com> <79f508d7d1a393730eab95c61f6b7af9@mail.gmail.com> Message-ID: <3b763c16-05a2-28b8-07c3-e0b589575ed1@oracle.com> Amir, Your https://bugs.openjdk.java.net/browse/JI-9051849 bug has been moved to https://bugs.openjdk.java.net/browse/JDK-8193369. Someone on the Serviceability team should pick up this thread from here, but we're right at the end game for JDK10 so it might take some time... Dan On 12/12/17 8:03 AM, Amir Rapson wrote: > Hi, > > I know the code has some relevant code, but it doesn't seem to work. You > will see some differences: the CALL_VM to the post function has only 2 > arguments and not 3, I'm not sure it matters. > > The platform is x86_64, Java version is 1.8.0-152. I can try other versions > if you wish. > > Please find the attached MyAgent.cpp MyAgent.h and com_vfunction_Main.h to > compile the agent. > Please also find the attached com.vfunction.zip that holds the simple java > util to reproduce the problem. > > You'll see the problem on ArrayList.add(item) where you'll get events only > on codes #16 and #22 and not on #2 and #11 (see attached bytecode.txt of > said function). > > Please let me know once you managed to reproduce it. I can also send you a > patch file to disable the fast_getfield (and fast putfield) to show that the > problem disappears. > > I'm currently looking at the actual assembly of the add function, both with > the modified hotspot and without and will try to assist will offering a fix > for this issue. > > One last thing. I saw a very old issue (resolved by Daniel Daugherty) > stating that fast_getfield was not completely addressed with the resolution > on this issue. The bug ID is > https://bugs.openjdk.java.net/browse/JDK-4300409 > > I'll be happy to assist further. > > Best regards, > Amir > > > -----Original Message----- > From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > Sent: Tuesday, December 12, 2017 2:46 PM > To: Amir Rapson > Cc: Coleen.Phillimore at oracle.com; daniel.daugherty at oracle.com > Subject: Re: JVMTI not receiving field access events with fast_getfield > > Thanks for the report, Amir! > > Unfortunately, I can't access the bug you filed. > > Can you, please, share the test case and instructions how to reproduce the > problem? > > Also, what Java version & platform do you observe the bug on? > > I briefly looked into template interpreter code on x86 and it does have > relevant code to post JVMTI events in fast accessors. > > Best regards, > Vladimir Ivanov > > On 12/12/17 11:12 AM, Amir Rapson wrote: >> Hi Daniel, Coleen and Vladimir, >> >> I tracked your email addresses from some mailing lists and hopefully >> one of you is a relevant person for my problem. >> >> I also filed a bug request (ID 9051849) but since I don?t have an >> option to add information I decided to email you. >> >> The problem I?m seeing is that JMTI does not receive field access >> events (and probably field modification events) when /fast_getfield/ >> is used instead of /get_field/. >> >> I verified this by disabling all the >> /patch_bytecode(Bytecodes::_fast_?getfield, bc, rbx)/ in >> /TemplateTable::getfield_or_static()/ and made sure that JVMTI >> receives all the correct events. >> >> I have the agent code and a short java program that can reproduce the >> problem and would be happy to assist in fixing and or debugging this >> issue. >> >> I would appreciate any feedback. >> >> Best regards, >> >> Amir >> >> ?????Amir Rapson | Founder & VP Eng @ *vFunction* | 7 HaPelech St. >> Tel-Aviv | +972-522650968 >> From yasuenag at gmail.com Tue Dec 12 13:48:28 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 12 Dec 2017 22:48:28 +0900 Subject: RFR : Test bug : JDK-8179700 - Exceptions thrown in StartManagementAgent.java In-Reply-To: <70e51ad6-b8dd-4b82-95a4-2b7821e27ce0@default> References: <70e51ad6-b8dd-4b82-95a4-2b7821e27ce0@default> Message-ID: <46147504-c4dd-4403-9073-5e2b249482e3@gmail.com> Looks good. Thanks, Yasumasa (ysuenaga) On 2017/12/11 18:36, Amit Sapre wrote: > Hello, > > > > Please review this trival fix for removing test case from ProblemList.txt file. > > > > The Test case got updated from other changeset http://hg.openjdk.java.net/jdk/hs/rev/bc1cffa26561 > > But was not removed from ProblemList.txt. > > > > > > Bug id : https://bugs.openjdk.java.net/browse/JDK-8179700 > > > > Webrev : http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8179700/webrev.00/ > > > > > > Thanks, > > Amit > From serguei.spitsyn at oracle.com Tue Dec 12 23:14:34 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Dec 2017 15:14:34 -0800 Subject: RFR: JDK-8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands In-Reply-To: References: Message-ID: Hi Jini, Some minor comments: http://cr.openjdk.java.net/~jgeorge/8192985/webrev.01/test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java.html I'd suggest to unsplit some lines (check if same applies to other two tests): 56 String jstackOutput = 57 test.run(theApp.getPid(), cmds, null, null); ... 78 addressString = 79 (token.replace("<", "")).replace(">", ""); No need for brackets around the token.replace. Need a space after 'for': 70 for(String key: tokensMap.keySet()) { Q: In what condition the jstackOutput can be null? 59 if (jstackOutput != null) { A suggestion is to use the same approach as in the ClhsdbScanOops test: 60 if (universeOutput == null) { 61 // Output could be null due to attach permission issues 62 // and if we are skipping this. 63 LingeredApp.stopApp(theApp); 64 return; 65 } Otherwise, the fix looks good to me. Thanks, Serguei On 12/12/17 02:38, Jini George wrote: > Thank you, Sharath. I have a modified webrev at: > > http://cr.openjdk.java.net/~jgeorge/8192985/webrev.01/ > > Could a Reviewer also please take a look at it ? > > Thanks, > Jini. > > On 12/11/2017 3:41 PM, Sharath Ballal wrote: >> Hi Jini, >> Looks Good. Some nits: >> >> http://cr.openjdk.java.net/~jgeorge/8192985/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java.html >> >> >> Since you are not passing any new VM options, the following lines >> >> ??? 28???????? import jdk.test.lib.Utils; >> ?? 47???????????? List vmArgs = new ArrayList(); >> ?? 48???????????? vmArgs.addAll(Utils.getVmOptions()); >> ?? 49 >> ?? 50???????????? theApp = new LingeredAppWithLock(); >> ?? 51???????????? LingeredApp.startApp(vmArgs, theApp); >> >> Can be replaced by >> >> theApp = new LingeredAppWithLock(); >> LingeredApp.startApp(null, theApp); >> >> http://cr.openjdk.java.net/~jgeorge/8192985/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java.html >> >> >> 41???? public static void testWithGcType >> If you are not planning on this method being called from elsewhere, >> you can make it private. >> >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: Jini George >> Sent: Friday, December 08, 2017 12:33 PM >> To: serviceability-dev at openjdk.java.net >> Subject: RFR: JDK-8192985: SA: Test cases for the clhsdb 'inspect', >> 'scanoops' and 'printas' commands >> >> Hello, >> >> Requesting reviews for: >> >> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8192985 >> Webrev: http://cr.openjdk.java.net/~jgeorge/8192985/webrev.00/ >> >> These are the new test cases for the following clhsdb commands: >> 1. inspect >> 2. scanoops >> 3. printas >> >> These tests have been verified through the Mach5 and jprt systems. >> >> Thanks, >> Jini. >> From chris.plummer at oracle.com Wed Dec 13 01:14:21 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 12 Dec 2017 17:14:21 -0800 Subject: RFR: JDK-8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands In-Reply-To: <5cd9edaf-e766-bbdd-7eea-8b9afc264f2e@oracle.com> References: <5b89187b-d49a-a239-864a-07be31e78b6f@oracle.com> <5cd9edaf-e766-bbdd-7eea-8b9afc264f2e@oracle.com> Message-ID: Hi Jini, On 12/12/17 2:38 AM, Jini George wrote: > Thank you, Chris. Answers inline. > > On 12/12/2017 4:43 AM, Chris Plummer wrote: >>> These are the new test cases for the following clhsdb commands: >>> 1. inspect >> tokensMap code can all move to inside the "if" block that follows it. > Done. > >>> 2. scanoops >> When will "universe" not return any output? > universeOutput could be null if there are attach permission issues Why would this ever happen in a testing environment? > and if we are skipping the test. I'm not sure what you meant by this. If we are running the test, how are we skipping it? > I have added these comments there for clarity. My concern is that logic like this could be hiding some other issue. It's possible that some other bug causes universeOutput to be null on every run we do, yet the test will show as passed. thanks, Chris > > I have a new webrev at: > > http://cr.openjdk.java.net/~jgeorge/8192985/webrev.01/ > > Thanks, > Jini. From amit.sapre at oracle.com Wed Dec 13 05:33:28 2017 From: amit.sapre at oracle.com (Amit Sapre) Date: Tue, 12 Dec 2017 21:33:28 -0800 (PST) Subject: RFR : JDK-8175542 - JMX: Not enough JDP packets received Message-ID: Hello, Please review the timeout fix for this bug. Bug ID : https://bugs.openjdk.java.net/browse/JDK-8175542 Webrev : http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8175542/webrev.00/ Thanks, Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From shafi.s.ahmad at oracle.com Wed Dec 13 10:23:37 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Wed, 13 Dec 2017 02:23:37 -0800 (PST) Subject: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code [internal] In-Reply-To: References: <84a40b32-51aa-445d-b325-8b751a7e9516@default> <7a69f608-9271-42ef-8048-faeddc7b0b8a@default> <464374d2-018b-4579-a948-f6ea8bfca539@default> <85c93c52-76dd-a56b-ace2-a7c145329779@oracle.com> Message-ID: Thank you Mandy and David for review comments. Please find updated webrev: http://cr.openjdk.java.net/~shshahma/8170299/webrev.03/ I have modify the code to use Emitter class rather than Broadcaster. Regards, Shafi From: mandy chung Sent: Tuesday, December 12, 2017 12:06 PM To: David Holmes ; Shafi Ahmad Cc: serviceability-dev at openjdk.java.net Subject: Re: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code [internal] On 12/11/17 9:32 PM, David Holmes wrote: Hi Shafi, I missed the first round of reviews on this so hadn't seen previous discussion. I'm still uneasy about introducing a new thread to the mix here, but at least Mandy's suggestion to modify the *Emitter class rather than change to the *Broadcaster is a lot less disruptive: http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021851.html Yes this is a better alternative (thanks for bringing this up, David). Mandy David On 12/12/2017 3:02 PM, Shafi Ahmad wrote: Thank you Mandy and David. I am sorry, somehow I missed your earlier comment regarding the RFE. >> This is a spec change. Is this intentional? Yes, this change is required as this is referenced inside MemoryImpl.java. I will file a separate RFE for adding hasListeners(). I will send the updated webrev after incorporating the review comment. Regards, Shafi *From:*mandy chung *Sent:* Tuesday, December 12, 2017 2:35 AM *To:* Shafi Ahmad HYPERLINK "mailto:shafi.s.ahmad at oracle.com" *Cc:* HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net *Subject:* Re: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code [internal] On 12/11/17 2:31 AM, Shafi Ahmad wrote: The method hasListeners() is referenced inside MemoryImpl.java and defined in NotificationEmitterSupport. This method is not present in NotificationBroadcasterSupport so I added it to NotificationBroadcasterSupport. This is a spec change. Is this intentional? I replied in Sept in reviewing an earlier version [1] that this cannot be backported. If you intend to make this spec change, it's better to separate this RFE and it requires CSR. Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8170299 Webrev link: http://cr.openjdk.java.net/~shshahma/8170299/webrev.02/ HYPERLINK "http://cr.openjdk.java.net/%7Eshshahma/8170299/webrev.02/" MemoryImpl.java 189 th.setName("Debugger"); this is not a debugger thread. Maybe rename it to "MemoryPool notification thread"? Mandy [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021836.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Wed Dec 13 12:02:11 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 13 Dec 2017 17:32:11 +0530 Subject: RFR : JDK-8175542 - JMX: Not enough JDP packets received In-Reply-To: References: Message-ID: <2b05b6b7-e731-7bf0-83b9-cdb2a4252d84@oracle.com> Hi Amit, Increasing the timeout 'TIME_OUT_FACTOR' will increase both socket and test-case timeout. The test passed as can be seen from the log, but because of the race-condition: hasTestLivedLongEnough() checked before shouldContinue(), the test was declared failed because of time-out. One possible fix would be to change line 80 to, ??? ??????????? if (shouldContinue() && hasTestLivedLongEnough()) Thanks Harsha On Wednesday 13 December 2017 11:03 AM, Amit Sapre wrote: > > Hello, > > Please review the timeout fix for this bug. > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8175542 > > Webrev : > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8175542/webrev.00/ > > > Thanks, > > Amit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Wed Dec 13 16:44:04 2017 From: jini.george at oracle.com (Jini George) Date: Wed, 13 Dec 2017 22:14:04 +0530 Subject: RFR: JDK-8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands In-Reply-To: References: Message-ID: <1eea40cb-74d1-cb8f-0558-0ece0737d20e@oracle.com> Thank you, Serguei. I have the modified webrev after addressing the comments at: http://cr.openjdk.java.net/~jgeorge/8192985/webrev.02/ jstackOutput could be null if there are attach permission issues. Thanks, Jini. On 12/13/2017 4:44 AM, serguei.spitsyn at oracle.com wrote: > Hi Jini, > > Some minor comments: > http://cr.openjdk.java.net/~jgeorge/8192985/webrev.01/test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java.html > > > I'd suggest to unsplit some lines (check if same applies to other two > tests): > > ? 56???????????? String jstackOutput = > ? 57???????????????? test.run(theApp.getPid(), cmds, null, null); > ? ... > > ? 78???????????????????????????? addressString = > ? 79???????????????????????????????? (token.replace("<", > "")).replace(">", ""); > > ? No need for brackets around the token.replace. > > Need a space after 'for': > > ? 70???????????????? for(String key: tokensMap.keySet()) { > > > > Q: In what condition the jstackOutput can be null? > > ???? 59???????????? if (jstackOutput != null) { > > ?? A suggestion is to use the same approach as in the ClhsdbScanOops test: > > ? 60???????????? if (universeOutput == null) { > ? 61???????????????? // Output could be null due to attach permission > issues > ? 62???????????????? // and if we are skipping this. > ? 63???????????????? LingeredApp.stopApp(theApp); > ? 64???????????????? return; > ? 65???????????? } > > > Otherwise, the fix looks good to me. > > Thanks, > Serguei > > > > On 12/12/17 02:38, Jini George wrote: >> Thank you, Sharath. I have a modified webrev at: >> >> http://cr.openjdk.java.net/~jgeorge/8192985/webrev.01/ >> >> Could a Reviewer also please take a look at it ? >> >> Thanks, >> Jini. >> >> On 12/11/2017 3:41 PM, Sharath Ballal wrote: >>> Hi Jini, >>> Looks Good. Some nits: >>> >>> http://cr.openjdk.java.net/~jgeorge/8192985/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java.html >>> >>> >>> Since you are not passing any new VM options, the following lines >>> >>> ??? 28???????? import jdk.test.lib.Utils; >>> ?? 47???????????? List vmArgs = new ArrayList(); >>> ?? 48???????????? vmArgs.addAll(Utils.getVmOptions()); >>> ?? 49 >>> ?? 50???????????? theApp = new LingeredAppWithLock(); >>> ?? 51???????????? LingeredApp.startApp(vmArgs, theApp); >>> >>> Can be replaced by >>> >>> theApp = new LingeredAppWithLock(); >>> LingeredApp.startApp(null, theApp); >>> >>> http://cr.openjdk.java.net/~jgeorge/8192985/webrev.00/test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java.html >>> >>> >>> 41???? public static void testWithGcType >>> If you are not planning on this method being called from elsewhere, >>> you can make it private. >>> >>> Thanks, >>> Sharath >>> >>> >>> -----Original Message----- >>> From: Jini George >>> Sent: Friday, December 08, 2017 12:33 PM >>> To: serviceability-dev at openjdk.java.net >>> Subject: RFR: JDK-8192985: SA: Test cases for the clhsdb 'inspect', >>> 'scanoops' and 'printas' commands >>> >>> Hello, >>> >>> Requesting reviews for: >>> >>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8192985 >>> Webrev: http://cr.openjdk.java.net/~jgeorge/8192985/webrev.00/ >>> >>> These are the new test cases for the following clhsdb commands: >>> 1. inspect >>> 2. scanoops >>> 3. printas >>> >>> These tests have been verified through the Mach5 and jprt systems. >>> >>> Thanks, >>> Jini. >>> > From mandy.chung at oracle.com Wed Dec 13 18:33:00 2017 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 13 Dec 2017 10:33:00 -0800 Subject: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code [internal] In-Reply-To: References: <84a40b32-51aa-445d-b325-8b751a7e9516@default> <7a69f608-9271-42ef-8048-faeddc7b0b8a@default> <464374d2-018b-4579-a948-f6ea8bfca539@default> <85c93c52-76dd-a56b-ace2-a7c145329779@oracle.com> Message-ID: <676904a9-a471-4fe4-9d8e-4d8c0c6983ac@oracle.com> On 12/13/17 2:23 AM, Shafi Ahmad wrote: > > Thank you Mandy and David for review comments. > > Please find updated webrev: > http://cr.openjdk.java.net/~shshahma/8170299/webrev.03/ > > > I have modify the code to use Emitter class rather than Broadcaster. > It's good that this version does not need the new public API. The thread factory can be lazily created in the first time to handle a notification.? I think this fix can be made simpler for example, you can add a ListenerInfo::handle method to replace SendNotifJob and the new protected handleNotification method. ??????????? if (li.filter == null || li.filter.isNotificationEnabled(notification)) { ??????????????? NotificationThread.execute(() -> li.handle(notification)); ??????????? } The static Executor field can be moved to NotificationThread (was NotificationThreadFactory) class so that it will be lazily initialized only when there is a notification. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Thu Dec 14 10:12:10 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 14 Dec 2017 02:12:10 -0800 (PST) Subject: RFR: JDK-8193427 - serviceability/sa/ClhsdbPrintStatics.java fails: java.lang.RuntimeException: '_jfr_checkpoints' missing from stdout/stderr Message-ID: <97f0b0c2-c581-4fc8-a346-86b949a1b607@default> Hello, Requesting reviews for: JBS Id: https://bugs.openjdk.java.net/browse/JDK-8193427 Webrev: http://cr.openjdk.java.net/~sballal/8193427/webrev.00/ I tested the changes in an open only workspace. Also the test ran successfully in JPRT and Mach5. Thanks, Sharath -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Thu Dec 14 10:12:16 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 14 Dec 2017 02:12:16 -0800 (PST) Subject: RFR: JDK-8193428 - serviceability/sa/ClhsdbSymbol.java fails: java.lang.RuntimeException: 'UsageTracker' missing from stdout/stderr Message-ID: <2a78cc61-5439-453c-a365-66aaa89df735@default> Hello, Requesting reviews for: JBS Id: https://bugs.openjdk.java.net/browse/JDK-8193428 Webrev: http://cr.openjdk.java.net/~sballal/8193428/webrev.00/ I tested the changes in an open only workspace. Also the test ran successfully in JPRT and Mach5. Thanks, Sharath -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Dec 14 12:14:27 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Dec 2017 22:14:27 +1000 Subject: RFR: JDK-8193427 - serviceability/sa/ClhsdbPrintStatics.java fails: java.lang.RuntimeException: '_jfr_checkpoints' missing from stdout/stderr In-Reply-To: <97f0b0c2-c581-4fc8-a346-86b949a1b607@default> References: <97f0b0c2-c581-4fc8-a346-86b949a1b607@default> Message-ID: Looks fine. Thanks, David On 14/12/2017 8:12 PM, Sharath Ballal wrote: > Hello, > > Requesting reviews for: > > JBS Id: https://bugs.openjdk.java.net/browse/JDK-8193427 > > Webrev: http://cr.openjdk.java.net/~sballal/8193427/webrev.00/ > > I tested the changes in an open only workspace.? Also the test ran > successfully in JPRT and Mach5. > > Thanks, > > Sharath > From david.holmes at oracle.com Thu Dec 14 12:15:00 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Dec 2017 22:15:00 +1000 Subject: RFR: JDK-8193428 - serviceability/sa/ClhsdbSymbol.java fails: java.lang.RuntimeException: 'UsageTracker' missing from stdout/stderr In-Reply-To: <2a78cc61-5439-453c-a365-66aaa89df735@default> References: <2a78cc61-5439-453c-a365-66aaa89df735@default> Message-ID: <23577ef7-fcbf-a931-e3f0-021c749bb851@oracle.com> Looks fine. Thanks, David On 14/12/2017 8:12 PM, Sharath Ballal wrote: > Hello, > > Requesting reviews for: > > JBS Id: https://bugs.openjdk.java.net/browse/JDK-8193428 > > Webrev: http://cr.openjdk.java.net/~sballal/8193428/webrev.00/ > > I tested the changes in an open only workspace.? Also the test ran > successfully in JPRT and Mach5. > > Thanks, > > Sharath > From sharath.ballal at oracle.com Thu Dec 14 16:43:14 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 14 Dec 2017 08:43:14 -0800 (PST) Subject: RFR: JDK-8193427 - serviceability/sa/ClhsdbPrintStatics.java fails: java.lang.RuntimeException: '_jfr_checkpoints' missing from stdout/stderr In-Reply-To: References: <97f0b0c2-c581-4fc8-a346-86b949a1b607@default> Message-ID: <412acf07-7c38-4325-80e8-9036587a8934@default> Thank you David. Can I have one more review pls? Thanks, Sharath -----Original Message----- From: David Holmes Sent: Thursday, December 14, 2017 5:44 PM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8193427 - serviceability/sa/ClhsdbPrintStatics.java fails: java.lang.RuntimeException: '_jfr_checkpoints' missing from stdout/stderr Looks fine. Thanks, David On 14/12/2017 8:12 PM, Sharath Ballal wrote: > Hello, > > Requesting reviews for: > > JBS Id: https://bugs.openjdk.java.net/browse/JDK-8193427 > > Webrev: http://cr.openjdk.java.net/~sballal/8193427/webrev.00/ > > I tested the changes in an open only workspace.? Also the test ran > successfully in JPRT and Mach5. > > Thanks, > > Sharath > From sharath.ballal at oracle.com Thu Dec 14 16:43:29 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 14 Dec 2017 08:43:29 -0800 (PST) Subject: RFR: JDK-8193428 - serviceability/sa/ClhsdbSymbol.java fails: java.lang.RuntimeException: 'UsageTracker' missing from stdout/stderr In-Reply-To: <23577ef7-fcbf-a931-e3f0-021c749bb851@oracle.com> References: <2a78cc61-5439-453c-a365-66aaa89df735@default> <23577ef7-fcbf-a931-e3f0-021c749bb851@oracle.com> Message-ID: Thank you David. Can I have one more review pls? Thanks, Sharath -----Original Message----- From: David Holmes Sent: Thursday, December 14, 2017 5:45 PM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8193428 - serviceability/sa/ClhsdbSymbol.java fails: java.lang.RuntimeException: 'UsageTracker' missing from stdout/stderr Looks fine. Thanks, David On 14/12/2017 8:12 PM, Sharath Ballal wrote: > Hello, > > Requesting reviews for: > > JBS Id: https://bugs.openjdk.java.net/browse/JDK-8193428 > > Webrev: http://cr.openjdk.java.net/~sballal/8193428/webrev.00/ > > I tested the changes in an open only workspace.? Also the test ran > successfully in JPRT and Mach5. > > Thanks, > > Sharath > From serguei.spitsyn at oracle.com Thu Dec 14 17:23:43 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 14 Dec 2017 09:23:43 -0800 Subject: RFR: JDK-8193427 - serviceability/sa/ClhsdbPrintStatics.java fails: java.lang.RuntimeException: '_jfr_checkpoints' missing from stdout/stderr In-Reply-To: <97f0b0c2-c581-4fc8-a346-86b949a1b607@default> References: <97f0b0c2-c581-4fc8-a346-86b949a1b607@default> Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Dec 14 17:24:36 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 14 Dec 2017 09:24:36 -0800 Subject: RFR: JDK-8193428 - serviceability/sa/ClhsdbSymbol.java fails: java.lang.RuntimeException: 'UsageTracker' missing from stdout/stderr In-Reply-To: <2a78cc61-5439-453c-a365-66aaa89df735@default> References: <2a78cc61-5439-453c-a365-66aaa89df735@default> Message-ID: <9c445903-489f-dd8f-eb19-4839c98777c8@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Dec 15 02:20:51 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Dec 2017 12:20:51 +1000 Subject: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code [internal] In-Reply-To: References: <84a40b32-51aa-445d-b325-8b751a7e9516@default> <7a69f608-9271-42ef-8048-faeddc7b0b8a@default> <464374d2-018b-4579-a948-f6ea8bfca539@default> <85c93c52-76dd-a56b-ace2-a7c145329779@oracle.com> Message-ID: On 13/12/2017 8:23 PM, Shafi Ahmad wrote: > Thank you Mandy and David for review comments. > > Please find updated webrev: > http://cr.openjdk.java.net/~shshahma/8170299/webrev.03/ > > I have modify the code to use Emitter class rather than Broadcaster. Okay. This at least seems less intrusive/disruptive. Not sure why you added this: 180 protected void handleNotification(NotificationListener listener, 181 Notification notif, Object handback) { 182 listener.handleNotification(notif, handback); 183 } instead of executing line 182 directly at 228? 226 public void run() { 227 try { 228 handleNotification(listenerInfo.listener, 229 notif, listenerInfo.handback); 230 } catch (Exception e) { I'm still concerned that the introduction of a new thread to actually execute the notification will causes more problems than it solves: - the notifications are no longer synchronous wrt. sendNotification - the execution context (security credentials etc) may be different in the InnocuousThread compared to the service thread. - there may be synchronization/deadlock issues Despite the spec for NotificationEmitter stating: "Implementations of this interface can differ regarding the thread in which the methods of filters and listeners are called." this may be a significant behavioural change - just to fix a debugger issue. Thanks, David > Regards, > > Shafi > > *From:*mandy chung > *Sent:* Tuesday, December 12, 2017 12:06 PM > *To:* David Holmes ; Shafi Ahmad > > *Cc:* serviceability-dev at openjdk.java.net > *Subject:* Re: [10] RFR for JDK-8170299: Debugger does not stop inside > the low memory notifications code [internal] > > On 12/11/17 9:32 PM, David Holmes wrote: > > Hi Shafi, > > I missed the first round of reviews on this so hadn't seen previous > discussion. I'm still uneasy about introducing a new thread to the > mix here, but at least Mandy's suggestion to modify the *Emitter > class rather than change to the *Broadcaster is a lot less disruptive: > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021851.html > > > > Yes this is a better alternative (thanks for bringing this up, David). > > Mandy > > > David > > On 12/12/2017 3:02 PM, Shafi Ahmad wrote: > > Thank you Mandy and David. > > I am sorry, somehow I missed your earlier comment regarding the > RFE. > > ?>> This is a spec change.? Is this intentional? > > Yes, this change is required as this is referenced inside > ?MemoryImpl.java. > > I will file a separate RFE for adding hasListeners(). > > I will send the updated webrev after incorporating the review > comment. > > Regards, > > Shafi > > *From:*mandy chung > *Sent:* Tuesday, December 12, 2017 2:35 AM > *To:* Shafi Ahmad > > *Cc:* serviceability-dev at openjdk.java.net > > *Subject:* Re: [10] RFR for JDK-8170299: Debugger does not stop > inside the low memory notifications code [internal] > > On 12/11/17 2:31 AM, Shafi Ahmad wrote: > > ??? The method hasListeners() is referenced ?inside > MemoryImpl.java and > ??? defined in ?NotificationEmitterSupport. > > ??? This method is not present in > ?NotificationBroadcasterSupport so I > ??? added it to NotificationBroadcasterSupport. > > > This is a spec change.? Is this intentional?? I replied in Sept > in reviewing an earlier version [1] that this cannot be > backported.? If you intend to make this spec change, it's better > to separate this RFE and it requires CSR. > > > ??? Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8170299 > > ??? Webrev link: > http://cr.openjdk.java.net/~shshahma/8170299/webrev.02/ > > > > > MemoryImpl.java > > 189???????????????????? th.setName("Debugger"); > > this is not a debugger thread.? Maybe rename it to > > "MemoryPool notification thread"? > > Mandy > > [1] > http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021836.html > From sharath.ballal at oracle.com Fri Dec 15 04:16:14 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 14 Dec 2017 20:16:14 -0800 (PST) Subject: RFR: JDK-8193427 - serviceability/sa/ClhsdbPrintStatics.java fails: java.lang.RuntimeException: '_jfr_checkpoints' missing from stdout/stderr In-Reply-To: References: <97f0b0c2-c581-4fc8-a346-86b949a1b607@default> Message-ID: <2a66c2e6-1ebb-4fa0-b28d-545f9f2c4f08@default> Thank you for the review Serguei. ? ? Thanks, Sharath ? ? From: Serguei Spitsyn Sent: Thursday, December 14, 2017 10:54 PM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8193427 - serviceability/sa/ClhsdbPrintStatics.java fails: java.lang.RuntimeException: '_jfr_checkpoints' missing from stdout/stderr ? Hi Sharath, Looks fine. Thanks, Serguei On 12/14/17 02:12, Sharath Ballal wrote: ? Hello, ? Requesting reviews for: ? JBS Id:???? https://bugs.openjdk.java.net/browse/JDK-8193427 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esballal/8193427/webrev.00/"http://cr.openjdk.java.net/~sballal/8193427/webrev.00/ ? I tested the changes in an open only workspace.? Also the test ran successfully in JPRT and Mach5. ? Thanks, Sharath ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Fri Dec 15 04:16:31 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 14 Dec 2017 20:16:31 -0800 (PST) Subject: RFR: JDK-8193428 - serviceability/sa/ClhsdbSymbol.java fails: java.lang.RuntimeException: 'UsageTracker' missing from stdout/stderr In-Reply-To: <9c445903-489f-dd8f-eb19-4839c98777c8@oracle.com> References: <2a78cc61-5439-453c-a365-66aaa89df735@default> <9c445903-489f-dd8f-eb19-4839c98777c8@oracle.com> Message-ID: Thank you for the review Serguei. ? ? Thanks, Sharath ? ? From: Serguei Spitsyn Sent: Thursday, December 14, 2017 10:55 PM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8193428 - serviceability/sa/ClhsdbSymbol.java fails: java.lang.RuntimeException: 'UsageTracker' missing from stdout/stderr ? Looks fine too. Thanks, Serguei On 12/14/17 02:12, Sharath Ballal wrote: Hello, ? Requesting reviews for: ? JBS Id:???? https://bugs.openjdk.java.net/browse/JDK-8193428 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esballal/8193428/webrev.00/"http://cr.openjdk.java.net/~sballal/8193428/webrev.00/ ? I tested the changes in an open only workspace.? Also the test ran successfully in JPRT and Mach5. ? Thanks, Sharath ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.buck at oracle.com Fri Dec 15 05:42:42 2017 From: david.buck at oracle.com (David Buck) Date: Fri, 15 Dec 2017 14:42:42 +0900 Subject: [8u] RFR(S) 8059036: Implement Diagnostic Commands for heap and finalizerinfo Message-ID: <0f3f7d99-fccb-0305-4939-6a77d110b908@oracle.com> Hi! May I please get a review of the following very simple backport of this serviceability improvement to JDK 8? The two hotspot jtreg test cases needed to be modified slightly because of the lack of dcmd-specific test support in JDK 8's HS code base. The only non-test difference from the JDK 9 changeset is modifying an include directive (objArrayOop.inline.hpp -> objArrayOop.hpp) to compensate for JDK-8072911. bug report: https://bugs.openjdk.java.net/browse/JDK-8059036 JDK 9 changesets: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/56a527afc34a http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/9b17d0a2720f JDK 9 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-May/033169.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/033835.html JDK 8 backport webrevs for review: http://cr.openjdk.java.net/~dbuck/8059036.0_jdk8/ Cheers, -Buck [0] https://bugs.openjdk.java.net/browse/JDK-8072911 From gary.adams at oracle.com Fri Dec 15 14:05:47 2017 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 15 Dec 2017 09:05:47 -0500 Subject: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix Message-ID: <5A33D6BB.5000107@oracle.com> Looking into some minor bugs in the attach area for the next release. https://bugs.openjdk.java.net/browse/JDK-8188856 Seems like a minor change to fix this error message that mentions the java_pid socket file, but then outputs the attach_pid file when the socket file is not created . What is the general preference for this type fix? - remove the reference to the "socket file" in the error message - construct the filename for the socket that was not found From daniel.daugherty at oracle.com Fri Dec 15 14:14:33 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Dec 2017 09:14:33 -0500 Subject: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix In-Reply-To: <5A33D6BB.5000107@oracle.com> References: <5A33D6BB.5000107@oracle.com> Message-ID: <86a117f1-0dea-c3f8-4b2b-62ed89f258b4@oracle.com> On 12/15/17 9:05 AM, Gary Adams wrote: > Looking into some minor bugs in the attach area for the next release. > > ? https://bugs.openjdk.java.net/browse/JDK-8188856 > > Seems like a minor change to fix this error message that mentions the > java_pid socket file, > but then outputs the attach_pid file when the socket file is not > created . > > What is the general preference for this type fix? > ?? - remove the reference to the "socket file" in the error message > ?? - construct the filename for the socket that was not found Just an opinion... Having the specific pathname for the that cannot be found is a better diagnostic. Perhaps it's possible to refactor the code that generates the path so that both sides can share that function to generate the same name... It might not be possible to do this sharing, e.g., one side might be in Java and the other side might be in C... In that case, having the same algorithm implemented in both places with comments to link the two would be my next choice... Of course, you have to balance this level of effort against other things on your plate... Dan From gary.adams at oracle.com Fri Dec 15 15:18:21 2017 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 15 Dec 2017 10:18:21 -0500 Subject: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix In-Reply-To: <86a117f1-0dea-c3f8-4b2b-62ed89f258b4@oracle.com> References: <5A33D6BB.5000107@oracle.com> <86a117f1-0dea-c3f8-4b2b-62ed89f258b4@oracle.com> Message-ID: <5A33E7BD.20604@oracle.com> On 12/15/17, 9:14 AM, Daniel D. Daugherty wrote: > On 12/15/17 9:05 AM, Gary Adams wrote: >> Looking into some minor bugs in the attach area for the next release. >> >> https://bugs.openjdk.java.net/browse/JDK-8188856 >> >> Seems like a minor change to fix this error message that mentions the >> java_pid socket file, >> but then outputs the attach_pid file when the socket file is not >> created . >> >> What is the general preference for this type fix? >> - remove the reference to the "socket file" in the error message >> - construct the filename for the socket that was not found > > Just an opinion... > > Having the specific pathname for the that cannot be > found is a better diagnostic. Perhaps it's possible to refactor the > code that generates the path so that both sides can > share that function to generate the same name... > > It might not be possible to do this sharing, e.g., one side might > be in Java and the other side might be in C... In that case, having > the same algorithm implemented in both places with comments to link > the two would be my next choice... > > Of course, you have to balance this level of effort against other > things on your plate... > > Dan > So one minimal solution would be to save the socket file name, so it's available when the error message is created. diff --git a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java b/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java --- a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java +++ b/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java @@ -47,8 +47,9 @@ // Any changes to this needs to be synchronized with HotSpot. private static final String tmpdir = "/tmp"; - // The patch to the socket file created by the target VM + // The path to the socket file created by the target VM String path; + String socket_name; /** * Attaches to the target VM @@ -98,7 +99,7 @@ throw new AttachNotSupportedException( String.format("Unable to open socket file %s: " + "target process %d doesn't respond within %dms " + - "or HotSpot VM not loaded", f.getPath(), pid, time_spend)); + "or HotSpot VM not loaded", socket_name, pid, time_spend)); } } finally { f.delete(); @@ -267,10 +268,11 @@ // Return the socket file for the given process. private String findSocketFile(int pid) { File f = new File(tmpdir, ".java_pid" + pid); + socket_name = f.getPath(); if (!f.exists()) { return null; } - return f.getPath(); + return socket_name; } // On Solaris/Linux/Aix a simple handshake is used to start the attach mechanism diff --git a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java --- a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java +++ b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java @@ -48,8 +48,9 @@ // Any changes to this needs to be synchronized with HotSpot. private static final String tmpdir = "/tmp"; - // The patch to the socket file created by the target VM + // The path to the socket file created by the target VM String path; + String socket_name; /** * Attaches to the target VM @@ -102,7 +103,8 @@ throw new AttachNotSupportedException( String.format("Unable to open socket file %s: " + "target process %d doesn't respond within %dms " + - "or HotSpot VM not loaded", f.getPath(), pid, time_spend)); + "or HotSpot VM not loaded", socket_name, pid, + time_spend)); } } finally { f.delete(); @@ -275,10 +277,11 @@ // procfs regardless of namespaces. String root = "/proc/" + pid + "/root/" + tmpdir; File f = new File(root, ".java_pid" + ns_pid); + socket_name = f.getPath(); if (!f.exists()) { return null; } - return f.getPath(); + return socket_name; } // On Solaris/Linux a simple handshake is used to start the attach mechanism diff --git a/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java b/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java --- a/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java +++ b/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java @@ -46,8 +46,9 @@ // Any changes to this needs to be synchronized with HotSpot. private static final String tmpdir; - // The patch to the socket file created by the target VM + // The path to the socket file created by the target VM String path; + String socket_name; /** * Attaches to the target VM @@ -96,8 +97,9 @@ if (path == null) { throw new AttachNotSupportedException( String.format("Unable to open socket file %s: " + - "target process %d doesn't respond within %dms " + - "or HotSpot VM not loaded", f.getPath(), pid, time_spend)); + "target process %d doesn't respond within %dms " + + "or HotSpot VM not loaded", socket_name, + pid, time_spend)); } } finally { f.delete(); @@ -269,7 +271,8 @@ private String findSocketFile(int pid) { String fn = ".java_pid" + pid; File f = new File(tmpdir, fn); - return f.exists() ? f.getPath() : null; + socket_name = f.getPath(); + return f.exists() ? socket_name : null; } From daniel.daugherty at oracle.com Fri Dec 15 15:47:07 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Dec 2017 10:47:07 -0500 Subject: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix In-Reply-To: <5A33E7BD.20604@oracle.com> References: <5A33D6BB.5000107@oracle.com> <86a117f1-0dea-c3f8-4b2b-62ed89f258b4@oracle.com> <5A33E7BD.20604@oracle.com> Message-ID: On 12/15/17 10:18 AM, Gary Adams wrote: > On 12/15/17, 9:14 AM, Daniel D. Daugherty wrote: >> On 12/15/17 9:05 AM, Gary Adams wrote: >>> Looking into some minor bugs in the attach area for the next release. >>> >>> ? https://bugs.openjdk.java.net/browse/JDK-8188856 >>> >>> Seems like a minor change to fix this error message that mentions >>> the java_pid socket file, >>> but then outputs the attach_pid file when the socket file is not >>> created . >>> >>> What is the general preference for this type fix? >>> ?? - remove the reference to the "socket file" in the error message >>> ?? - construct the filename for the socket that was not found >> >> Just an opinion... >> >> Having the specific pathname for the that cannot be >> found is a better diagnostic. Perhaps it's possible to refactor the >> code that generates the path so that both sides can >> share that function to generate the same name... >> >> It might not be possible to do this sharing, e.g., one side might >> be in Java and the other side might be in C... In that case, having >> the same algorithm implemented in both places with comments to link >> the two would be my next choice... >> >> Of course, you have to balance this level of effort against other >> things on your plate... >> >> Dan >> > So one minimal solution would be to save the socket file name, so > it's available when the error message is created. This seems like a reasonable solution. Please wait for Serviceability team folks to chime in though... :-) Dan > > diff --git > a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java > b/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java > --- a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java > +++ b/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java > @@ -47,8 +47,9 @@ > ???? // Any changes to this needs to be synchronized with HotSpot. > ???? private static final String tmpdir = "/tmp"; > > -??? // The patch to the socket file created by the target VM > +??? // The path to the socket file created by the target VM > ???? String path; > +??? String socket_name; > > ???? /** > ????? * Attaches to the target VM > @@ -98,7 +99,7 @@ > ???????????????????? throw new AttachNotSupportedException( > ???????????????????????? String.format("Unable to open socket file %s: > " + > ?????????????????????????? "target process %d doesn't respond within > %dms " + > -????????????????????????? "or HotSpot VM not loaded", f.getPath(), > pid, time_spend)); > +????????????????????????? "or HotSpot VM not loaded", socket_name, > pid, time_spend)); > ???????????????? } > ???????????? } finally { > ???????????????? f.delete(); > @@ -267,10 +268,11 @@ > ???? // Return the socket file for the given process. > ???? private String findSocketFile(int pid) { > ???????? File f = new File(tmpdir, ".java_pid" + pid); > +??? socket_name = f.getPath(); > ???????? if (!f.exists()) { > ???????????? return null; > ???????? } > -??????? return f.getPath(); > +??????? return socket_name; > ???? } > > ???? // On Solaris/Linux/Aix a simple handshake is used to start the > attach mechanism > diff --git > a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > --- > a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > +++ > b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > @@ -48,8 +48,9 @@ > ???? // Any changes to this needs to be synchronized with HotSpot. > ???? private static final String tmpdir = "/tmp"; > > -??? // The patch to the socket file created by the target VM > +??? // The path to the socket file created by the target VM > ???? String path; > +??? String socket_name; > > ???? /** > ????? * Attaches to the target VM > @@ -102,7 +103,8 @@ > ???????????????????? throw new AttachNotSupportedException( > ???????????????????????? String.format("Unable to open socket file %s: > " + > ?????????????????????????? "target process %d doesn't respond within > %dms " + > -????????????????????????? "or HotSpot VM not loaded", f.getPath(), > pid, time_spend)); > +????????????????????????? "or HotSpot VM not loaded", socket_name, pid, > +????????????????????? time_spend)); > ???????????????? } > ???????????? } finally { > ???????????????? f.delete(); > @@ -275,10 +277,11 @@ > ???????? // procfs regardless of namespaces. > ???????? String root = "/proc/" + pid + "/root/" + tmpdir; > ???????? File f = new File(root, ".java_pid" + ns_pid); > +??? socket_name = f.getPath(); > ???????? if (!f.exists()) { > ???????????? return null; > ???????? } > -??????? return f.getPath(); > +??????? return socket_name; > ???? } > > ???? // On Solaris/Linux a simple handshake is used to start the > attach mechanism > diff --git > a/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > b/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > --- > a/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > +++ > b/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > @@ -46,8 +46,9 @@ > ???? // Any changes to this needs to be synchronized with HotSpot. > ???? private static final String tmpdir; > > -??? // The patch to the socket file created by the target VM > +??? // The path to the socket file created by the target VM > ???? String path; > +??? String socket_name; > > ???? /** > ????? * Attaches to the target VM > @@ -96,8 +97,9 @@ > ???????????????? if (path == null) { > ???????????????????? throw new AttachNotSupportedException( > ???????????????????????? String.format("Unable to open socket file %s: > " + > -????????????????????????? "target process %d doesn't respond within > %dms " + > -????????????????????????? "or HotSpot VM not loaded", f.getPath(), > pid, time_spend)); > +????????????????????? "target process %d doesn't respond within %dms " + > +????????????????????? "or HotSpot VM not loaded", socket_name, > +????????????????????? pid, time_spend)); > ???????????????? } > ???????????? } finally { > ???????????????? f.delete(); > @@ -269,7 +271,8 @@ > ???? private String findSocketFile(int pid) { > ???????? String fn = ".java_pid" + pid; > ???????? File f = new File(tmpdir, fn); > -??????? return f.exists() ? f.getPath() : null; > +??? socket_name = f.getPath(); > +??????? return f.exists() ? socket_name : null; > ???? } > From chris.plummer at oracle.com Fri Dec 15 18:31:08 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 15 Dec 2017 10:31:08 -0800 Subject: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix In-Reply-To: <5A33E7BD.20604@oracle.com> References: <5A33D6BB.5000107@oracle.com> <86a117f1-0dea-c3f8-4b2b-62ed89f258b4@oracle.com> <5A33E7BD.20604@oracle.com> Message-ID: <1258b963-5285-ae42-2d8b-0d85f42075bf@oracle.com> On 12/15/17 7:18 AM, Gary Adams wrote: > On 12/15/17, 9:14 AM, Daniel D. Daugherty wrote: >> On 12/15/17 9:05 AM, Gary Adams wrote: >>> Looking into some minor bugs in the attach area for the next release. >>> >>> ? https://bugs.openjdk.java.net/browse/JDK-8188856 >>> >>> Seems like a minor change to fix this error message that mentions >>> the java_pid socket file, >>> but then outputs the attach_pid file when the socket file is not >>> created . >>> >>> What is the general preference for this type fix? >>> ?? - remove the reference to the "socket file" in the error message >>> ?? - construct the filename for the socket that was not found >> >> Just an opinion... >> >> Having the specific pathname for the that cannot be >> found is a better diagnostic. Perhaps it's possible to refactor the >> code that generates the path so that both sides can >> share that function to generate the same name... >> >> It might not be possible to do this sharing, e.g., one side might >> be in Java and the other side might be in C... In that case, having >> the same algorithm implemented in both places with comments to link >> the two would be my next choice... >> >> Of course, you have to balance this level of effort against other >> things on your plate... >> >> Dan >> > So one minimal solution would be to save the socket file name, so > it's available when the error message is created. > > diff --git > a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java > b/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java > --- a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java > +++ b/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java > @@ -47,8 +47,9 @@ > ???? // Any changes to this needs to be synchronized with HotSpot. > ???? private static final String tmpdir = "/tmp"; > > -??? // The patch to the socket file created by the target VM > +??? // The path to the socket file created by the target VM > ???? String path; > +??? String socket_name; > > ???? /** > ????? * Attaches to the target VM > @@ -98,7 +99,7 @@ > ???????????????????? throw new AttachNotSupportedException( > ???????????????????????? String.format("Unable to open socket file %s: > " + > ?????????????????????????? "target process %d doesn't respond within > %dms " + > -????????????????????????? "or HotSpot VM not loaded", f.getPath(), > pid, time_spend)); > +????????????????????????? "or HotSpot VM not loaded", socket_name, > pid, time_spend)); > ???????????????? } > ???????????? } finally { > ???????????????? f.delete(); > @@ -267,10 +268,11 @@ > ???? // Return the socket file for the given process. > ???? private String findSocketFile(int pid) { > ???????? File f = new File(tmpdir, ".java_pid" + pid); > +??? socket_name = f.getPath(); > ???????? if (!f.exists()) { > ???????????? return null; > ???????? } > -??????? return f.getPath(); > +??????? return socket_name; > ???? } > > ???? // On Solaris/Linux/Aix a simple handshake is used to start the > attach mechanism > diff --git > a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > --- > a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > +++ > b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > @@ -48,8 +48,9 @@ > ???? // Any changes to this needs to be synchronized with HotSpot. > ???? private static final String tmpdir = "/tmp"; > > -??? // The patch to the socket file created by the target VM > +??? // The path to the socket file created by the target VM > ???? String path; > +??? String socket_name; > > ???? /** > ????? * Attaches to the target VM > @@ -102,7 +103,8 @@ > ???????????????????? throw new AttachNotSupportedException( > ???????????????????????? String.format("Unable to open socket file %s: > " + > ?????????????????????????? "target process %d doesn't respond within > %dms " + > -????????????????????????? "or HotSpot VM not loaded", f.getPath(), > pid, time_spend)); > +????????????????????????? "or HotSpot VM not loaded", socket_name, pid, > +????????????????????? time_spend)); > ???????????????? } > ???????????? } finally { > ???????????????? f.delete(); > @@ -275,10 +277,11 @@ > ???????? // procfs regardless of namespaces. > ???????? String root = "/proc/" + pid + "/root/" + tmpdir; > ???????? File f = new File(root, ".java_pid" + ns_pid); > +??? socket_name = f.getPath(); > ???????? if (!f.exists()) { > ???????????? return null; > ???????? } > -??????? return f.getPath(); > +??????? return socket_name; > ???? } > > ???? // On Solaris/Linux a simple handshake is used to start the > attach mechanism > diff --git > a/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > b/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > --- > a/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > +++ > b/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > @@ -46,8 +46,9 @@ > ???? // Any changes to this needs to be synchronized with HotSpot. > ???? private static final String tmpdir; > > -??? // The patch to the socket file created by the target VM > +??? // The path to the socket file created by the target VM > ???? String path; > +??? String socket_name; > > ???? /** > ????? * Attaches to the target VM > @@ -96,8 +97,9 @@ > ???????????????? if (path == null) { > ???????????????????? throw new AttachNotSupportedException( > ???????????????????????? String.format("Unable to open socket file %s: > " + > -????????????????????????? "target process %d doesn't respond within > %dms " + > -????????????????????????? "or HotSpot VM not loaded", f.getPath(), > pid, time_spend)); > +????????????????????? "target process %d doesn't respond within %dms " + > +????????????????????? "or HotSpot VM not loaded", socket_name, > +????????????????????? pid, time_spend)); > ???????????????? } > ???????????? } finally { > ???????????????? f.delete(); > @@ -269,7 +271,8 @@ > ???? private String findSocketFile(int pid) { > ???????? String fn = ".java_pid" + pid; > ???????? File f = new File(tmpdir, fn); > -??????? return f.exists() ? f.getPath() : null; > +??? socket_name = f.getPath(); > +??????? return f.exists() ? socket_name : null; > ???? } > You're explanation sounds reasonable, but I'm not clear on the code changes. What's the difference between "path" and "socket_name"? Maybe if I saw the diff in context it would be more apparent. Chris From serguei.spitsyn at oracle.com Fri Dec 15 20:06:25 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 15 Dec 2017 12:06:25 -0800 Subject: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix In-Reply-To: <5A33E7BD.20604@oracle.com> References: <5A33D6BB.5000107@oracle.com> <86a117f1-0dea-c3f8-4b2b-62ed89f258b4@oracle.com> <5A33E7BD.20604@oracle.com> Message-ID: <152e69b0-183f-e98b-fb82-88ccc6a36180@oracle.com> Hi Gary, This minimal solution looks reasonable to me. The fix looks good too. The whole context of this situation is not clear to me yet. Why the /tmp/.java_pid socket file could not be opened? Is it a lack of permissions or something else? Is it possible to reproduce this with a test? If it is not easy then I'm Ok to push the fix as it is. What tests do you run to make sure there is no regression? Thanks, Serguei On 12/15/17 07:18, Gary Adams wrote: > On 12/15/17, 9:14 AM, Daniel D. Daugherty wrote: >> On 12/15/17 9:05 AM, Gary Adams wrote: >>> Looking into some minor bugs in the attach area for the next release. >>> >>> ? https://bugs.openjdk.java.net/browse/JDK-8188856 >>> >>> Seems like a minor change to fix this error message that mentions >>> the java_pid socket file, >>> but then outputs the attach_pid file when the socket file is not >>> created . >>> >>> What is the general preference for this type fix? >>> ?? - remove the reference to the "socket file" in the error message >>> ?? - construct the filename for the socket that was not found >> >> Just an opinion... >> >> Having the specific pathname for the that cannot be >> found is a better diagnostic. Perhaps it's possible to refactor the >> code that generates the path so that both sides can >> share that function to generate the same name... >> >> It might not be possible to do this sharing, e.g., one side might >> be in Java and the other side might be in C... In that case, having >> the same algorithm implemented in both places with comments to link >> the two would be my next choice... >> >> Of course, you have to balance this level of effort against other >> things on your plate... >> >> Dan >> > So one minimal solution would be to save the socket file name, so > it's available when the error message is created. > > diff --git > a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java > b/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java > --- a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java > +++ b/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java > @@ -47,8 +47,9 @@ > ???? // Any changes to this needs to be synchronized with HotSpot. > ???? private static final String tmpdir = "/tmp"; > > -??? // The patch to the socket file created by the target VM > +??? // The path to the socket file created by the target VM > ???? String path; > +??? String socket_name; > > ???? /** > ????? * Attaches to the target VM > @@ -98,7 +99,7 @@ > ???????????????????? throw new AttachNotSupportedException( > ???????????????????????? String.format("Unable to open socket file %s: > " + > ?????????????????????????? "target process %d doesn't respond within > %dms " + > -????????????????????????? "or HotSpot VM not loaded", f.getPath(), > pid, time_spend)); > +????????????????????????? "or HotSpot VM not loaded", socket_name, > pid, time_spend)); > ???????????????? } > ???????????? } finally { > ???????????????? f.delete(); > @@ -267,10 +268,11 @@ > ???? // Return the socket file for the given process. > ???? private String findSocketFile(int pid) { > ???????? File f = new File(tmpdir, ".java_pid" + pid); > +??? socket_name = f.getPath(); > ???????? if (!f.exists()) { > ???????????? return null; > ???????? } > -??????? return f.getPath(); > +??????? return socket_name; > ???? } > > ???? // On Solaris/Linux/Aix a simple handshake is used to start the > attach mechanism > diff --git > a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > --- > a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > +++ > b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java > @@ -48,8 +48,9 @@ > ???? // Any changes to this needs to be synchronized with HotSpot. > ???? private static final String tmpdir = "/tmp"; > > -??? // The patch to the socket file created by the target VM > +??? // The path to the socket file created by the target VM > ???? String path; > +??? String socket_name; > > ???? /** > ????? * Attaches to the target VM > @@ -102,7 +103,8 @@ > ???????????????????? throw new AttachNotSupportedException( > ???????????????????????? String.format("Unable to open socket file %s: > " + > ?????????????????????????? "target process %d doesn't respond within > %dms " + > -????????????????????????? "or HotSpot VM not loaded", f.getPath(), > pid, time_spend)); > +????????????????????????? "or HotSpot VM not loaded", socket_name, pid, > +????????????????????? time_spend)); > ???????????????? } > ???????????? } finally { > ???????????????? f.delete(); > @@ -275,10 +277,11 @@ > ???????? // procfs regardless of namespaces. > ???????? String root = "/proc/" + pid + "/root/" + tmpdir; > ???????? File f = new File(root, ".java_pid" + ns_pid); > +??? socket_name = f.getPath(); > ???????? if (!f.exists()) { > ???????????? return null; > ???????? } > -??????? return f.getPath(); > +??????? return socket_name; > ???? } > > ???? // On Solaris/Linux a simple handshake is used to start the > attach mechanism > diff --git > a/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > b/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > --- > a/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > +++ > b/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java > @@ -46,8 +46,9 @@ > ???? // Any changes to this needs to be synchronized with HotSpot. > ???? private static final String tmpdir; > > -??? // The patch to the socket file created by the target VM > +??? // The path to the socket file created by the target VM > ???? String path; > +??? String socket_name; > > ???? /** > ????? * Attaches to the target VM > @@ -96,8 +97,9 @@ > ???????????????? if (path == null) { > ???????????????????? throw new AttachNotSupportedException( > ???????????????????????? String.format("Unable to open socket file %s: > " + > -????????????????????????? "target process %d doesn't respond within > %dms " + > -????????????????????????? "or HotSpot VM not loaded", f.getPath(), > pid, time_spend)); > +????????????????????? "target process %d doesn't respond within %dms " + > +????????????????????? "or HotSpot VM not loaded", socket_name, > +????????????????????? pid, time_spend)); > ???????????????? } > ???????????? } finally { > ???????????????? f.delete(); > @@ -269,7 +271,8 @@ > ???? private String findSocketFile(int pid) { > ???????? String fn = ".java_pid" + pid; > ???????? File f = new File(tmpdir, fn); > -??????? return f.exists() ? f.getPath() : null; > +??? socket_name = f.getPath(); > +??????? return f.exists() ? socket_name : null; > ???? } > From gary.adams at oracle.com Mon Dec 18 14:38:00 2017 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 18 Dec 2017 09:38:00 -0500 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error Message-ID: <5A37D2C8.5090504@oracle.com> Here's a simple fix to include additional information when the instrument library is missing from the jre and the command line requests -javaagent. Issue: https://bugs.openjdk.java.net/browse/JDK-8180709 Webrev: http://cr.openjdk.java.net/~gadams/8180709/webrev.00/ From gary.adams at oracle.com Mon Dec 18 14:47:46 2017 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 18 Dec 2017 09:47:46 -0500 Subject: RFR: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix Message-ID: <5A37D512.5070508@oracle.com> Here's a simple fix to correct the error message when the java_pid socket is not found. The code previously reported the attach_pid file name rather than the socket file name that was not found. Issue: https://bugs.openjdk.java.net/browse/JDK-8188856 Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.00/ From Alan.Bateman at oracle.com Mon Dec 18 14:53:05 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Dec 2017 14:53:05 +0000 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error In-Reply-To: <5A37D2C8.5090504@oracle.com> References: <5A37D2C8.5090504@oracle.com> Message-ID: <926b0c4b-769e-7859-cb2c-44b2a561ca8b@oracle.com> On 18/12/2017 14:38, Gary Adams wrote: > Here's a simple fix to include additional information when the > instrument library is > missing from the jre and the command line requests -javaagent. > > ?Issue: https://bugs.openjdk.java.net/browse/JDK-8180709 > ?Webrev: http://cr.openjdk.java.net/~gadams/8180709/webrev.00/ The approach looks okay to me, I just wonder if the failover to the library path can be skipped when is_instrument_lib is true. -Alan From goetz.lindenmaier at sap.com Mon Dec 18 17:35:08 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 18 Dec 2017 17:35:08 +0000 Subject: FW: RFR(M): 8189102: All tools should support -?, -h and --help In-Reply-To: <7be3772e8060494cbecf3097bd0a8a85@sap.com> References: <8aa25976d496465fac00a4ae3628e533@sap.com> <456c694ec25a42658af1b8600aaa136d@sap.com> <6d7d895f-9f23-fd4b-39ca-ef9bb0331fb9@oracle.com> <7be3772e8060494cbecf3097bd0a8a85@sap.com> Message-ID: <2124c07d77df43369bf3080c54f314b1@sap.com> Hi, I had to update my webrev after the javah launcher had been removed: http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.07/ I would appreciate a final decision to push this. Best regards, Goetz. -----Original Message----- From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Tuesday, December 12, 2017 11:37 AM To: Alan Bateman ; core-libs-dev at openjdk.java.net; 'compiler-dev at openjdk.java.net' ; serviceability-dev (serviceability-dev at openjdk.java.net) Subject: RE: FW: RFR(M): 8189102: All tools should support -?, -h and --help Hi Alan, Javadoc combines documentation and support of a flag in the way the flag handling is implemented. On the other side, it prints the help message anyways if a wrong flag is presented to it, so if you call it with -help you get the help message. Therefore, in my original change where I tried to get it more cleaned up, I removed -help support and documentation from Javadoc. I added it again and updated the table in the CSR: http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.06/ Best regards, Goetz. > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Montag, 11. Dezember 2017 17:53 > To: Lindenmaier, Goetz ; core-libs- > dev at openjdk.java.net; 'compiler-dev at openjdk.java.net' dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: FW: RFR(M): 8189102: All tools should support -?, -h and --help > > > > On 07/12/2017 11:20, Lindenmaier, Goetz wrote: > > Hi, > > > > ... missed some lists in my first post ... > > > > I prepared a fifth webrev for this change. Please review. > > > > It incorporates the changes requested by the CSR reviewers > > (not to remove docuemtation of '-help' where is was documented > > before) and the changes proposed by Kumar: > > http://cr.openjdk.java.net/~goetz/wr17/8189102- > helpMessage/webrev.05/ > > > > > Looks like it still drops -help from the javadoc usage message, I can't > tell if you meant to do that. > > -Alan. From serguei.spitsyn at oracle.com Mon Dec 18 18:31:57 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 18 Dec 2017 10:31:57 -0800 Subject: RFR: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix In-Reply-To: <5A37D512.5070508@oracle.com> References: <5A37D512.5070508@oracle.com> Message-ID: <44c540e9-06fe-90d2-a76f-83f3c418fee1@oracle.com> Hi Gary, It looks good to me. Thanks, Serguei On 12/18/17 06:47, Gary Adams wrote: > Here's a simple fix to correct the error message when the java_pid socket > is not found. The code previously reported the attach_pid file name > rather than the socket file name that was not found. > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8188856 > ? Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.00/ From chris.plummer at oracle.com Mon Dec 18 19:26:19 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 18 Dec 2017 11:26:19 -0800 Subject: RFR: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix In-Reply-To: <5A37D512.5070508@oracle.com> References: <5A37D512.5070508@oracle.com> Message-ID: <4b96505e-95e9-2988-236b-55e15253bcf7@oracle.com> Hi Gary, On 12/18/17 6:47 AM, Gary Adams wrote: > Here's a simple fix to correct the error message when the java_pid socket > is not found. The code previously reported the attach_pid file name > rather than the socket file name that was not found. > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8188856 > ? Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.00/ I don't understand why you couldn't simply have changed the f.getPath() reference to "path". From what I can see, there is no difference between "path" and "socket_name". The problem you are fixing is that the error message prints f.getPath(), but that refers to the attach file and the error message should refer to the socket file. You've correct this, but have done so in a round about way. Above the error message (in two places) exists: ?????????? path = findSocketFile(pid, ns_pid); So "path" is what you want. You have indirectly fixed the problem by having findSocketFile() store the path in socket_name, and then you print socket_name, but why not just do the direct fix and print "path". Also, the copyrights need to be updated. thanks, Chris From chris.plummer at oracle.com Mon Dec 18 19:39:26 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 18 Dec 2017 11:39:26 -0800 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error In-Reply-To: <5A37D2C8.5090504@oracle.com> References: <5A37D2C8.5090504@oracle.com> Message-ID: Hi Gary, Overall looks good. There's one minor change you might wanted to consider. It's possible the library failed to load for reasons other than java.instrument not being included. I see the error output already includes the error message from the failed dll_open() call, so why not just suggest that it *may* be due to java.instrument missing rather than implying that is known to be the reason why. thanks, Chris On 12/18/17 6:38 AM, Gary Adams wrote: > Here's a simple fix to include additional information when the > instrument library is > missing from the jre and the command line requests -javaagent. > > ?Issue: https://bugs.openjdk.java.net/browse/JDK-8180709 > ?Webrev: http://cr.openjdk.java.net/~gadams/8180709/webrev.00/ > > From serguei.spitsyn at oracle.com Mon Dec 18 21:09:52 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 18 Dec 2017 13:09:52 -0800 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error In-Reply-To: References: <5A37D2C8.5090504@oracle.com> Message-ID: <45cb1c38-3fd7-b6ef-bdc7-c72666ac93d7@oracle.com> Hi Gary, I have the same concern and like Chris's suggestion. The JMX case must be simpler as there is no need to load the agent library early at startup. So that it is possible to identify the module jdk.management.agent is absent in the image. I think, it happens in the java.lang.Module.Resolver. The instrument library is loaded early at startup when the Module system is not up yet, so we don't know if the module java.instrument is present or not. The instrument library can be not found because of other reasons. Other than that the fix looks okay to me. Thanks, Serguei On 12/18/17 11:39, Chris Plummer wrote: > Hi Gary, > > Overall looks good. There's one minor change you might wanted to > consider. It's possible the library failed to load for reasons other > than java.instrument not being included. I see the error output > already includes the error message from the failed dll_open() call, so > why not just suggest that it *may* be due to java.instrument missing > rather than implying that is known to be the reason why. > > thanks, > > Chris > > On 12/18/17 6:38 AM, Gary Adams wrote: >> Here's a simple fix to include additional information when the >> instrument library is >> missing from the jre and the command line requests -javaagent. >> >> ?Issue: https://bugs.openjdk.java.net/browse/JDK-8180709 >> ?Webrev: http://cr.openjdk.java.net/~gadams/8180709/webrev.00/ >> >> > > From gary.adams at oracle.com Mon Dec 18 21:11:39 2017 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Mon, 18 Dec 2017 16:11:39 -0500 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error In-Reply-To: References: <5A37D2C8.5090504@oracle.com> Message-ID: <3b038a07-c0e0-c785-9629-d266862ba45f@oracle.com> The only legitimate reason libinstrument would be missing is if java.instrument was not included. Any other speculation about why libinstrument was not found is hard to explain. e.g. until the vm is initialized we can not explicitly say whether java.instrument module is present or not. On 12/18/17 2:39 PM, Chris Plummer wrote: > Hi Gary, > > Overall looks good. There's one minor change you might wanted to > consider. It's possible the library failed to load for reasons other > than java.instrument not being included. I see the error output > already includes the error message from the failed dll_open() call, so > why not just suggest that it *may* be due to java.instrument missing > rather than implying that is known to be the reason why. > > thanks, > > Chris > > On 12/18/17 6:38 AM, Gary Adams wrote: >> Here's a simple fix to include additional information when the >> instrument library is >> missing from the jre and the command line requests -javaagent. >> >> ?Issue: https://bugs.openjdk.java.net/browse/JDK-8180709 >> ?Webrev: http://cr.openjdk.java.net/~gadams/8180709/webrev.00/ >> >> > > From gary.adams at oracle.com Mon Dec 18 21:14:05 2017 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Mon, 18 Dec 2017 16:14:05 -0500 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error In-Reply-To: <45cb1c38-3fd7-b6ef-bdc7-c72666ac93d7@oracle.com> References: <5A37D2C8.5090504@oracle.com> <45cb1c38-3fd7-b6ef-bdc7-c72666ac93d7@oracle.com> Message-ID: <20ad1b7b-b8bd-4e53-77d4-5be849b30ee1@oracle.com> I can just the error message. What would you like it to say? "Module java.instrument may be missing" On 12/18/17 4:09 PM, serguei.spitsyn at oracle.com wrote: > Hi Gary, > > I have the same concern and like Chris's suggestion. > > The JMX case must be simpler as there is no need to load the agent > library early at startup. > So that it is possible to identify the module jdk.management.agent is > absent in the image. > I think, it happens in the java.lang.Module.Resolver. > > The instrument library is loaded early at startup when the Module > system is not > up yet, so we don't know if the module java.instrument is present or not. > The instrument library can be not found because of other reasons. > > Other than that the fix looks okay to me. > > Thanks, > Serguei > > > On 12/18/17 11:39, Chris Plummer wrote: >> Hi Gary, >> >> Overall looks good. There's one minor change you might wanted to >> consider. It's possible the library failed to load for reasons other >> than java.instrument not being included. I see the error output >> already includes the error message from the failed dll_open() call, >> so why not just suggest that it *may* be due to java.instrument >> missing rather than implying that is known to be the reason why. >> >> thanks, >> >> Chris >> >> On 12/18/17 6:38 AM, Gary Adams wrote: >>> Here's a simple fix to include additional information when the >>> instrument library is >>> missing from the jre and the command line requests -javaagent. >>> >>> ?Issue: https://bugs.openjdk.java.net/browse/JDK-8180709 >>> ?Webrev: http://cr.openjdk.java.net/~gadams/8180709/webrev.00/ >>> >>> >> >> > From serguei.spitsyn at oracle.com Mon Dec 18 21:19:32 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 18 Dec 2017 13:19:32 -0800 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error In-Reply-To: <20ad1b7b-b8bd-4e53-77d4-5be849b30ee1@oracle.com> References: <5A37D2C8.5090504@oracle.com> <45cb1c38-3fd7-b6ef-bdc7-c72666ac93d7@oracle.com> <20ad1b7b-b8bd-4e53-77d4-5be849b30ee1@oracle.com> Message-ID: On 12/18/17 13:14, gary.adams at oracle.com wrote: > I can just the error message. > What would you like it to say? > > "Module java.instrument may be missing" Looks good to me (assuming it is for the sub_msg2). Thanks, Serguei > On 12/18/17 4:09 PM, serguei.spitsyn at oracle.com wrote: >> Hi Gary, >> >> I have the same concern and like Chris's suggestion. >> >> The JMX case must be simpler as there is no need to load the agent >> library early at startup. >> So that it is possible to identify the module jdk.management.agent is >> absent in the image. >> I think, it happens in the java.lang.Module.Resolver. >> >> The instrument library is loaded early at startup when the Module >> system is not >> up yet, so we don't know if the module java.instrument is present or >> not. >> The instrument library can be not found because of other reasons. >> >> Other than that the fix looks okay to me. >> >> Thanks, >> Serguei >> >> >> On 12/18/17 11:39, Chris Plummer wrote: >>> Hi Gary, >>> >>> Overall looks good. There's one minor change you might wanted to >>> consider. It's possible the library failed to load for reasons other >>> than java.instrument not being included. I see the error output >>> already includes the error message from the failed dll_open() call, >>> so why not just suggest that it *may* be due to java.instrument >>> missing rather than implying that is known to be the reason why. >>> >>> thanks, >>> >>> Chris >>> >>> On 12/18/17 6:38 AM, Gary Adams wrote: >>>> Here's a simple fix to include additional information when the >>>> instrument library is >>>> missing from the jre and the command line requests -javaagent. >>>> >>>> ?Issue: https://bugs.openjdk.java.net/browse/JDK-8180709 >>>> ?Webrev: http://cr.openjdk.java.net/~gadams/8180709/webrev.00/ >>>> >>>> >>> >>> >> > From gary.adams at oracle.com Mon Dec 18 21:22:03 2017 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Mon, 18 Dec 2017 16:22:03 -0500 Subject: RFR: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix In-Reply-To: <4b96505e-95e9-2988-236b-55e15253bcf7@oracle.com> References: <5A37D512.5070508@oracle.com> <4b96505e-95e9-2988-236b-55e15253bcf7@oracle.com> Message-ID: <23c19686-4ffa-9ddb-efee-e68b52ba071a@oracle.com> On 12/18/17 2:26 PM, Chris Plummer wrote: > Hi Gary, > > On 12/18/17 6:47 AM, Gary Adams wrote: >> Here's a simple fix to correct the error message when the java_pid >> socket >> is not found. The code previously reported the attach_pid file name >> rather than the socket file name that was not found. >> >> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8188856 >> ? Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.00/ > > I don't understand why you couldn't simply have changed the > f.getPath() reference to "path". From what I can see, there is no > difference between "path" and "socket_name". The problem you are > fixing is that the error message prints f.getPath(), but that refers > to the attach file and the error message should refer to the socket > file. You've correct this, but have done so in a round about way. > Above the error message (in two places) exists: > > ?????????? path = findSocketFile(pid, ns_pid); > > So "path" is what you want. You have indirectly fixed the problem by > having findSocketFile() store the path in socket_name, and then you > print socket_name, but why not just do the direct fix and print "path". > > Also, the copyrights need to be updated. > > thanks, > > Chris > > The problem was path is used to hold the constructed file name if it is confirmed to exist in the file system. Otherwise it is passed back from findSocketFile as a null to indicate the socket file was not found. I could refactor where the existence check is handled, but it seemed like the least invasive change to simply save the socket name for the printing in the error case. From chris.plummer at oracle.com Mon Dec 18 21:28:43 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 18 Dec 2017 13:28:43 -0800 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error In-Reply-To: <20ad1b7b-b8bd-4e53-77d4-5be849b30ee1@oracle.com> References: <5A37D2C8.5090504@oracle.com> <45cb1c38-3fd7-b6ef-bdc7-c72666ac93d7@oracle.com> <20ad1b7b-b8bd-4e53-77d4-5be849b30ee1@oracle.com> Message-ID: <07ebadb8-3bef-2d4b-f572-06c3add6f1ef@oracle.com> Yes. On 12/18/17 1:14 PM, gary.adams at oracle.com wrote: > I can just the error message. > What would you like it to say? > > "Module java.instrument may be missing" > > On 12/18/17 4:09 PM, serguei.spitsyn at oracle.com wrote: >> Hi Gary, >> >> I have the same concern and like Chris's suggestion. >> >> The JMX case must be simpler as there is no need to load the agent >> library early at startup. >> So that it is possible to identify the module jdk.management.agent is >> absent in the image. >> I think, it happens in the java.lang.Module.Resolver. >> >> The instrument library is loaded early at startup when the Module >> system is not >> up yet, so we don't know if the module java.instrument is present or >> not. >> The instrument library can be not found because of other reasons. >> >> Other than that the fix looks okay to me. >> >> Thanks, >> Serguei >> >> >> On 12/18/17 11:39, Chris Plummer wrote: >>> Hi Gary, >>> >>> Overall looks good. There's one minor change you might wanted to >>> consider. It's possible the library failed to load for reasons other >>> than java.instrument not being included. I see the error output >>> already includes the error message from the failed dll_open() call, >>> so why not just suggest that it *may* be due to java.instrument >>> missing rather than implying that is known to be the reason why. >>> >>> thanks, >>> >>> Chris >>> >>> On 12/18/17 6:38 AM, Gary Adams wrote: >>>> Here's a simple fix to include additional information when the >>>> instrument library is >>>> missing from the jre and the command line requests -javaagent. >>>> >>>> ?Issue: https://bugs.openjdk.java.net/browse/JDK-8180709 >>>> ?Webrev: http://cr.openjdk.java.net/~gadams/8180709/webrev.00/ >>>> >>>> >>> >>> >> > From chris.plummer at oracle.com Mon Dec 18 21:38:22 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 18 Dec 2017 13:38:22 -0800 Subject: RFR: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix In-Reply-To: <23c19686-4ffa-9ddb-efee-e68b52ba071a@oracle.com> References: <5A37D512.5070508@oracle.com> <4b96505e-95e9-2988-236b-55e15253bcf7@oracle.com> <23c19686-4ffa-9ddb-efee-e68b52ba071a@oracle.com> Message-ID: <3c50b1a1-82b8-dd09-47ed-7c00b3960b7c@oracle.com> On 12/18/17 1:22 PM, gary.adams at oracle.com wrote: > On 12/18/17 2:26 PM, Chris Plummer wrote: >> Hi Gary, >> >> On 12/18/17 6:47 AM, Gary Adams wrote: >>> Here's a simple fix to correct the error message when the java_pid >>> socket >>> is not found. The code previously reported the attach_pid file name >>> rather than the socket file name that was not found. >>> >>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8188856 >>> ? Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.00/ >> >> I don't understand why you couldn't simply have changed the >> f.getPath() reference to "path". From what I can see, there is no >> difference between "path" and "socket_name". The problem you are >> fixing is that the error message prints f.getPath(), but that refers >> to the attach file and the error message should refer to the socket >> file. You've correct this, but have done so in a round about way. >> Above the error message (in two places) exists: >> >> ?????????? path = findSocketFile(pid, ns_pid); >> >> So "path" is what you want. You have indirectly fixed the problem by >> having findSocketFile() store the path in socket_name, and then you >> print socket_name, but why not just do the direct fix and print "path". >> >> Also, the copyrights need to be updated. >> >> thanks, >> >> Chris >> >> > The problem was path is used to hold the constructed file name > if it is confirmed to exist in the file system. Otherwise it is passed > back from > findSocketFile as a null to indicate the socket file was not found. > > I could refactor where the existence check is handled, but it seemed > like the least > invasive change to simply save the socket name for the printing in the > error case. > Ah, right. Obviously "path" is null when you want to print the error message. I guess I? have a hard time with "path" and "socket_name" for the most part being the same (except "path" can end up being null), yet they have two completely dissimilar names. Why not rename path to socket_path and then add saved_socket_path, or something like that. No changes to your current logic, just to the names being used. Or, have findSocketFile() actually return the File, and then rename path to socket_file and also rename socket_name to socket_path. The truth of the matter is the result of findSocketFile() is only used to see if the socket file exists. You could even change it to return a boolean. Chris From david.buck at oracle.com Mon Dec 18 22:14:48 2017 From: david.buck at oracle.com (David Buck) Date: Tue, 19 Dec 2017 07:14:48 +0900 Subject: [8u] RFR(S) 8059036: Implement Diagnostic Commands for heap and finalizerinfo In-Reply-To: <0f3f7d99-fccb-0305-4939-6a77d110b908@oracle.com> References: <0f3f7d99-fccb-0305-4939-6a77d110b908@oracle.com> Message-ID: <26d1f9ee-6abf-bfed-b25d-2947e78f9577@oracle.com> Hi! Any love out there for my review request? Cheers, -Buck On 2017/12/15 14:42, David Buck wrote: > Hi! > > May I please get a review of the following very simple backport of this > serviceability improvement to JDK 8? > > The two hotspot jtreg test cases needed to be modified slightly because > of the lack of dcmd-specific test support in JDK 8's HS code base. The > only non-test difference from the JDK 9 changeset is modifying an > include directive (objArrayOop.inline.hpp -> objArrayOop.hpp) to > compensate for JDK-8072911. > > bug report: > https://bugs.openjdk.java.net/browse/JDK-8059036 > > JDK 9 changesets: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/56a527afc34a > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/9b17d0a2720f > > JDK 9 review thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-May/033169.html > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/033835.html > > JDK 8 backport webrevs for review: > http://cr.openjdk.java.net/~dbuck/8059036.0_jdk8/ > > Cheers, > -Buck > > [0] https://bugs.openjdk.java.net/browse/JDK-8072911 From mandy.chung at oracle.com Mon Dec 18 22:25:18 2017 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 18 Dec 2017 14:25:18 -0800 Subject: [8u] RFR(S) 8059036: Implement Diagnostic Commands for heap and finalizerinfo In-Reply-To: <0f3f7d99-fccb-0305-4939-6a77d110b908@oracle.com> References: <0f3f7d99-fccb-0305-4939-6a77d110b908@oracle.com> Message-ID: On 12/14/17 9:42 PM, David Buck wrote: > Hi! > > May I please get a review of the following very simple backport of > this serviceability improvement to JDK 8? > > : > > JDK 8 backport webrevs for review: > http://cr.openjdk.java.net/~dbuck/8059036.0_jdk8/ This patch looks okay to me. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Tue Dec 19 07:57:08 2017 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Tue, 19 Dec 2017 07:57:08 +0000 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error In-Reply-To: <3b038a07-c0e0-c785-9629-d266862ba45f@oracle.com> References: <5A37D2C8.5090504@oracle.com> <3b038a07-c0e0-c785-9629-d266862ba45f@oracle.com> Message-ID: <8183F984-0309-45F4-8F5B-2C68BF22664D@gmail.com> Hi, > On Dec 18, 2017, at 9:11 PM, gary.adams at oracle.com wrote: > > The only legitimate reason libinstrument would be missing is if java.instrument was not included. > Any other speculation about why libinstrument was not found is hard to explain. e.g. until > the vm is initialized we can not explicitly say whether java.instrument module is present or not. This is the only legitimate reason that is imaginable. I?d suggest that rather than overreaching you just state what you tried to do and that it failed. Kind regards, Kirk Pepperdine > > > On 12/18/17 2:39 PM, Chris Plummer wrote: >> Hi Gary, >> >> Overall looks good. There's one minor change you might wanted to consider. It's possible the library failed to load for reasons other than java.instrument not being included. I see the error output already includes the error message from the failed dll_open() call, so why not just suggest that it *may* be due to java.instrument missing rather than implying that is known to be the reason why. >> >> thanks, >> >> Chris >> >> On 12/18/17 6:38 AM, Gary Adams wrote: >>> Here's a simple fix to include additional information when the instrument library is >>> missing from the jre and the command line requests -javaagent. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8180709 >>> Webrev: http://cr.openjdk.java.net/~gadams/8180709/webrev.00/ >>> >>> >> >> > From david.buck at oracle.com Tue Dec 19 08:16:35 2017 From: david.buck at oracle.com (David Buck) Date: Tue, 19 Dec 2017 17:16:35 +0900 Subject: [8u] RFR(S) 8031304 : Add dcmd to print all loaded dynamic libraries Message-ID: Hi! Please review this straightforward serviceability backport to JDK 8. No real changes to product code. I just moved the import statements in the DynLibDcmdTest.java test case to below the copyright header. bug report: https://bugs.openjdk.java.net/browse/JDK-8031304 JDK 9 review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-January/013778.html JDK 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/afa21611f918 JDK 8 webrev for review: http://cr.openjdk.java.net/~dbuck/8031304_jdk8_ver00/ Cheers, -Buck From Alan.Bateman at oracle.com Tue Dec 19 10:10:38 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Dec 2017 10:10:38 +0000 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error In-Reply-To: <20ad1b7b-b8bd-4e53-77d4-5be849b30ee1@oracle.com> References: <5A37D2C8.5090504@oracle.com> <45cb1c38-3fd7-b6ef-bdc7-c72666ac93d7@oracle.com> <20ad1b7b-b8bd-4e53-77d4-5be849b30ee1@oracle.com> Message-ID: <18b82fb3-fdca-14a5-36b7-f39f4968a5d0@oracle.com> On 18/12/2017 21:14, gary.adams at oracle.com wrote: > I can just the error message. > What would you like it to say? > > "Module java.instrument may be missing" Technically it may be that the java.instrument module is not observable but saying that it may not be in the run-time image is probably clearer to the clearer. The main thing is to connect it to the java.instrument module, other details are useful too, say where someone has a corrupt installation or the wrong permissions on the library. -Alan From gary.adams at oracle.com Tue Dec 19 12:47:35 2017 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 19 Dec 2017 07:47:35 -0500 Subject: RFR: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix In-Reply-To: <3c50b1a1-82b8-dd09-47ed-7c00b3960b7c@oracle.com> References: <5A37D512.5070508@oracle.com> <4b96505e-95e9-2988-236b-55e15253bcf7@oracle.com> <23c19686-4ffa-9ddb-efee-e68b52ba071a@oracle.com> <3c50b1a1-82b8-dd09-47ed-7c00b3960b7c@oracle.com> Message-ID: <5A390A67.7040204@oracle.com> On 12/18/17, 4:38 PM, Chris Plummer wrote: > On 12/18/17 1:22 PM, gary.adams at oracle.com wrote: >> On 12/18/17 2:26 PM, Chris Plummer wrote: >>> Hi Gary, >>> >>> On 12/18/17 6:47 AM, Gary Adams wrote: >>>> Here's a simple fix to correct the error message when the java_pid >>>> socket >>>> is not found. The code previously reported the attach_pid file name >>>> rather than the socket file name that was not found. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8188856 >>>> Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.00/ >>> >>> I don't understand why you couldn't simply have changed the >>> f.getPath() reference to "path". From what I can see, there is no >>> difference between "path" and "socket_name". The problem you are >>> fixing is that the error message prints f.getPath(), but that refers >>> to the attach file and the error message should refer to the socket >>> file. You've correct this, but have done so in a round about way. >>> Above the error message (in two places) exists: >>> >>> path = findSocketFile(pid, ns_pid); >>> >>> So "path" is what you want. You have indirectly fixed the problem by >>> having findSocketFile() store the path in socket_name, and then you >>> print socket_name, but why not just do the direct fix and print "path". >>> >>> Also, the copyrights need to be updated. >>> >>> thanks, >>> >>> Chris >>> >>> >> The problem was path is used to hold the constructed file name >> if it is confirmed to exist in the file system. Otherwise it is >> passed back from >> findSocketFile as a null to indicate the socket file was not found. >> >> I could refactor where the existence check is handled, but it seemed >> like the least >> invasive change to simply save the socket name for the printing in >> the error case. >> > Ah, right. Obviously "path" is null when you want to print the error > message. I guess I have a hard time with "path" and "socket_name" for > the most part being the same (except "path" can end up being null), > yet they have two completely dissimilar names. Why not rename path to > socket_path and then add saved_socket_path, or something like that. No > changes to your current logic, just to the names being used. > > Or, have findSocketFile() actually return the File, and then rename > path to socket_file and also rename socket_name to socket_path. The > truth of the matter is the result of findSocketFile() is only used to > see if the socket file exists. You could even change it to return a > boolean. > > Chris > > So what I'm hearing is that we should fix more than just the error message while we're changing this code. If findSocketFile returns the File, it is easy enough for the calling code to handle the calls to exists and getPath without overloading path to be null as a returned flag. No need to recompute the file name each time through the loop. e.g. diff --git a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java b/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java --- a/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java +++ b/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2008, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2008, 2017, Oracle and/or its affiliates. All rights reserved. * Copyright (c) 2015 SAP SE. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * @@ -47,9 +47,6 @@ // Any changes to this needs to be synchronized with HotSpot. private static final String tmpdir = "/tmp"; - // The patch to the socket file created by the target VM - String path; - /** * Attaches to the target VM */ @@ -69,8 +66,9 @@ // Find the socket file. If not found then we attempt to start the // attach mechanism in the target VM by sending it a QUIT signal. // Then we attempt to find the socket file again. - path = findSocketFile(pid); - if (path == null) { + File path = new File(tmpdir, ".java_pid" + pid); + String socket_name = path.getPath(); + if (!path.exists()) { File f = createAttachFile(pid); try { sendQuitTo(pid); @@ -86,19 +84,18 @@ try { Thread.sleep(delay); } catch (InterruptedException x) { } - path = findSocketFile(pid); time_spend += delay; - if (time_spend > timeout/2 && path == null) { + if (time_spend > timeout/2 && !path.exists()) { // Send QUIT again to give target VM the last chance to react sendQuitTo(pid); } - } while (time_spend <= timeout && path == null); - if (path == null) { + } while (time_spend <= timeout && !path.exists()); + if (!path.exists()) { throw new AttachNotSupportedException( String.format("Unable to open socket file %s: " + "target process %d doesn't respond within %dms " + - "or HotSpot VM not loaded", f.getPath(), pid, time_spend)); + "or HotSpot VM not loaded", socket_name, pid, time_spend)); } } finally { f.delete(); @@ -107,14 +104,14 @@ // Check that the file owner/permission to avoid attaching to // bogus process - checkPermissions(path); + checkPermissions(socket_name); // Check that we can connect to the process // - this ensures we throw the permission denied error now rather than // later when we attempt to enqueue a command. int s = socket(); try { - connect(s, path); + connect(s, socket_name); } finally { close(s); } @@ -264,15 +261,6 @@ } } - // Return the socket file for the given process. - private String findSocketFile(int pid) { - File f = new File(tmpdir, ".java_pid" + pid); - if (!f.exists()) { - return null; - } - return f.getPath(); - } - // On Solaris/Linux/Aix a simple handshake is used to start the attach mechanism // if not already started. The client creates a .attach_pid file in the // target VM's working directory (or temp directory), and the SIGQUIT handler From gary.adams at oracle.com Tue Dec 19 14:58:46 2017 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 19 Dec 2017 09:58:46 -0500 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error In-Reply-To: <18b82fb3-fdca-14a5-36b7-f39f4968a5d0@oracle.com> References: <5A37D2C8.5090504@oracle.com> <45cb1c38-3fd7-b6ef-bdc7-c72666ac93d7@oracle.com> <20ad1b7b-b8bd-4e53-77d4-5be849b30ee1@oracle.com> <18b82fb3-fdca-14a5-36b7-f39f4968a5d0@oracle.com> Message-ID: <5A392926.60701@oracle.com> A refreshed webrev is vailable Webrev: http://cr.openjdk.java.net/~gadams/8180709/webrev.01/ On 12/19/17, 5:10 AM, Alan Bateman wrote: > On 18/12/2017 21:14, gary.adams at oracle.com wrote: >> I can just the error message. >> What would you like it to say? >> >> "Module java.instrument may be missing" > Technically it may be that the java.instrument module is not > observable but saying that it may not be in the run-time image is > probably clearer to the clearer. The main thing is to connect it to > the java.instrument module, other details are useful too, say where > someone has a corrupt installation or the wrong permissions on the > library. > > -Alan From gary.adams at oracle.com Tue Dec 19 15:00:39 2017 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 19 Dec 2017 10:00:39 -0500 Subject: RFR: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix In-Reply-To: <3c50b1a1-82b8-dd09-47ed-7c00b3960b7c@oracle.com> References: <5A37D512.5070508@oracle.com> <4b96505e-95e9-2988-236b-55e15253bcf7@oracle.com> <23c19686-4ffa-9ddb-efee-e68b52ba071a@oracle.com> <3c50b1a1-82b8-dd09-47ed-7c00b3960b7c@oracle.com> Message-ID: <5A392997.5080701@oracle.com> A refreshed webrev is available Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.01/ On 12/18/17, 4:38 PM, Chris Plummer wrote: > On 12/18/17 1:22 PM, gary.adams at oracle.com wrote: >> On 12/18/17 2:26 PM, Chris Plummer wrote: >>> Hi Gary, >>> >>> On 12/18/17 6:47 AM, Gary Adams wrote: >>>> Here's a simple fix to correct the error message when the java_pid >>>> socket >>>> is not found. The code previously reported the attach_pid file name >>>> rather than the socket file name that was not found. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8188856 >>>> Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.00/ >>> >>> I don't understand why you couldn't simply have changed the >>> f.getPath() reference to "path". From what I can see, there is no >>> difference between "path" and "socket_name". The problem you are >>> fixing is that the error message prints f.getPath(), but that refers >>> to the attach file and the error message should refer to the socket >>> file. You've correct this, but have done so in a round about way. >>> Above the error message (in two places) exists: >>> >>> path = findSocketFile(pid, ns_pid); >>> >>> So "path" is what you want. You have indirectly fixed the problem by >>> having findSocketFile() store the path in socket_name, and then you >>> print socket_name, but why not just do the direct fix and print "path". >>> >>> Also, the copyrights need to be updated. >>> >>> thanks, >>> >>> Chris >>> >>> >> The problem was path is used to hold the constructed file name >> if it is confirmed to exist in the file system. Otherwise it is >> passed back from >> findSocketFile as a null to indicate the socket file was not found. >> >> I could refactor where the existence check is handled, but it seemed >> like the least >> invasive change to simply save the socket name for the printing in >> the error case. >> > Ah, right. Obviously "path" is null when you want to print the error > message. I guess I have a hard time with "path" and "socket_name" for > the most part being the same (except "path" can end up being null), > yet they have two completely dissimilar names. Why not rename path to > socket_path and then add saved_socket_path, or something like that. No > changes to your current logic, just to the names being used. > > Or, have findSocketFile() actually return the File, and then rename > path to socket_file and also rename socket_name to socket_path. The > truth of the matter is the result of findSocketFile() is only used to > see if the socket file exists. You could even change it to return a > boolean. > > Chris > > From serguei.spitsyn at oracle.com Tue Dec 19 16:57:36 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Dec 2017 08:57:36 -0800 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error In-Reply-To: <5A392926.60701@oracle.com> References: <5A37D2C8.5090504@oracle.com> <45cb1c38-3fd7-b6ef-bdc7-c72666ac93d7@oracle.com> <20ad1b7b-b8bd-4e53-77d4-5be849b30ee1@oracle.com> <18b82fb3-fdca-14a5-36b7-f39f4968a5d0@oracle.com> <5A392926.60701@oracle.com> Message-ID: <68f45401-e931-48e3-088d-c8064752212c@oracle.com> Looks good. Thanks, Serguei On 12/19/17 06:58, Gary Adams wrote: > A refreshed webrev is vailable > ? Webrev: http://cr.openjdk.java.net/~gadams/8180709/webrev.01/ > > On 12/19/17, 5:10 AM, Alan Bateman wrote: >> On 18/12/2017 21:14, gary.adams at oracle.com wrote: >>> I can just the error message. >>> What would you like it to say? >>> >>> "Module java.instrument may be missing" >> Technically it may be that the java.instrument module is not >> observable but saying that it may not be in the run-time image is >> probably clearer to the clearer. The main thing is to connect it to >> the java.instrument module, other details are useful too, say where >> someone has a corrupt installation or the wrong permissions on the >> library. >> >> -Alan > From chris.plummer at oracle.com Tue Dec 19 22:12:31 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 19 Dec 2017 14:12:31 -0800 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error In-Reply-To: <68f45401-e931-48e3-088d-c8064752212c@oracle.com> References: <5A37D2C8.5090504@oracle.com> <45cb1c38-3fd7-b6ef-bdc7-c72666ac93d7@oracle.com> <20ad1b7b-b8bd-4e53-77d4-5be849b30ee1@oracle.com> <18b82fb3-fdca-14a5-36b7-f39f4968a5d0@oracle.com> <5A392926.60701@oracle.com> <68f45401-e931-48e3-088d-c8064752212c@oracle.com> Message-ID: +1 Thanks, Chris On 12/19/17 8:57 AM, serguei.spitsyn at oracle.com wrote: > Looks good. > > Thanks, Serguei > > > On 12/19/17 06:58, Gary Adams wrote: >> A refreshed webrev is vailable >> ? Webrev: http://cr.openjdk.java.net/~gadams/8180709/webrev.01/ >> >> On 12/19/17, 5:10 AM, Alan Bateman wrote: >>> On 18/12/2017 21:14, gary.adams at oracle.com wrote: >>>> I can just the error message. >>>> What would you like it to say? >>>> >>>> "Module java.instrument may be missing" >>> Technically it may be that the java.instrument module is not >>> observable but saying that it may not be in the run-time image is >>> probably clearer to the clearer. The main thing is to connect it to >>> the java.instrument module, other details are useful too, say where >>> someone has a corrupt installation or the wrong permissions on the >>> library. >>> >>> -Alan >> > From chris.plummer at oracle.com Tue Dec 19 22:23:50 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 19 Dec 2017 14:23:50 -0800 Subject: RFR: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix In-Reply-To: <5A392997.5080701@oracle.com> References: <5A37D512.5070508@oracle.com> <4b96505e-95e9-2988-236b-55e15253bcf7@oracle.com> <23c19686-4ffa-9ddb-efee-e68b52ba071a@oracle.com> <3c50b1a1-82b8-dd09-47ed-7c00b3960b7c@oracle.com> <5A392997.5080701@oracle.com> Message-ID: <484b0ced-a672-e706-d570-e88de7b3db2f@oracle.com> Hi Gary, I'm not sure about the detach() and execute() changes on linux (how can this.path references just be stripped and the code still work properly), and how does this code continue to work on AIX and MacOSX when "path" has been removed but is still referenced. Shouldn't this.path just be replaced with this.socket_name? thanks, Chris On 12/19/17 7:00 AM, Gary Adams wrote: > A refreshed webrev is available > ??? Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.01/ > > On 12/18/17, 4:38 PM, Chris Plummer wrote: >> On 12/18/17 1:22 PM, gary.adams at oracle.com wrote: >>> On 12/18/17 2:26 PM, Chris Plummer wrote: >>>> Hi Gary, >>>> >>>> On 12/18/17 6:47 AM, Gary Adams wrote: >>>>> Here's a simple fix to correct the error message when the java_pid >>>>> socket >>>>> is not found. The code previously reported the attach_pid file name >>>>> rather than the socket file name that was not found. >>>>> >>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8188856 >>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.00/ >>>> >>>> I don't understand why you couldn't simply have changed the >>>> f.getPath() reference to "path". From what I can see, there is no >>>> difference between "path" and "socket_name". The problem you are >>>> fixing is that the error message prints f.getPath(), but that >>>> refers to the attach file and the error message should refer to the >>>> socket file. You've correct this, but have done so in a round about >>>> way. Above the error message (in two places) exists: >>>> >>>> ?????????? path = findSocketFile(pid, ns_pid); >>>> >>>> So "path" is what you want. You have indirectly fixed the problem >>>> by having findSocketFile() store the path in socket_name, and then >>>> you print socket_name, but why not just do the direct fix and print >>>> "path". >>>> >>>> Also, the copyrights need to be updated. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> >>> The problem was path is used to hold the constructed file name >>> if it is confirmed to exist in the file system. Otherwise it is >>> passed back from >>> findSocketFile as a null to indicate the socket file was not found. >>> >>> I could refactor where the existence check is handled, but it seemed >>> like the least >>> invasive change to simply save the socket name for the printing in >>> the error case. >>> >> Ah, right. Obviously "path" is null when you want to print the error >> message. I guess I? have a hard time with "path" and "socket_name" >> for the most part being the same (except "path" can end up being >> null), yet they have two completely dissimilar names. Why not rename >> path to socket_path and then add saved_socket_path, or something like >> that. No changes to your current logic, just to the names being used. >> >> Or, have findSocketFile() actually return the File, and then rename >> path to socket_file and also rename socket_name to socket_path. The >> truth of the matter is the result of findSocketFile() is only used to >> see if the socket file exists. You could even change it to return a >> boolean. >> >> Chris >> >> > From gary.adams at oracle.com Tue Dec 19 22:46:20 2017 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Tue, 19 Dec 2017 17:46:20 -0500 Subject: RFR: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix In-Reply-To: <484b0ced-a672-e706-d570-e88de7b3db2f@oracle.com> References: <5A37D512.5070508@oracle.com> <4b96505e-95e9-2988-236b-55e15253bcf7@oracle.com> <23c19686-4ffa-9ddb-efee-e68b52ba071a@oracle.com> <3c50b1a1-82b8-dd09-47ed-7c00b3960b7c@oracle.com> <5A392997.5080701@oracle.com> <484b0ced-a672-e706-d570-e88de7b3db2f@oracle.com> Message-ID: More work is needed here. I have not tracked down how detach is actually used. The previous path as null string was a flag to reconnect (?). On 12/19/17 5:23 PM, Chris Plummer wrote: > Hi Gary, > > I'm not sure about the detach() and execute() changes on linux (how > can this.path references just be stripped and the code still work > properly), and how does this code continue to work on AIX and MacOSX > when "path" has been removed but is still referenced. Shouldn't > this.path just be replaced with this.socket_name? > > thanks, > > Chris > > On 12/19/17 7:00 AM, Gary Adams wrote: >> A refreshed webrev is available >> ??? Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.01/ >> >> On 12/18/17, 4:38 PM, Chris Plummer wrote: >>> On 12/18/17 1:22 PM, gary.adams at oracle.com wrote: >>>> On 12/18/17 2:26 PM, Chris Plummer wrote: >>>>> Hi Gary, >>>>> >>>>> On 12/18/17 6:47 AM, Gary Adams wrote: >>>>>> Here's a simple fix to correct the error message when the >>>>>> java_pid socket >>>>>> is not found. The code previously reported the attach_pid file name >>>>>> rather than the socket file name that was not found. >>>>>> >>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8188856 >>>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.00/ >>>>> >>>>> I don't understand why you couldn't simply have changed the >>>>> f.getPath() reference to "path". From what I can see, there is no >>>>> difference between "path" and "socket_name". The problem you are >>>>> fixing is that the error message prints f.getPath(), but that >>>>> refers to the attach file and the error message should refer to >>>>> the socket file. You've correct this, but have done so in a round >>>>> about way. Above the error message (in two places) exists: >>>>> >>>>> ?????????? path = findSocketFile(pid, ns_pid); >>>>> >>>>> So "path" is what you want. You have indirectly fixed the problem >>>>> by having findSocketFile() store the path in socket_name, and then >>>>> you print socket_name, but why not just do the direct fix and >>>>> print "path". >>>>> >>>>> Also, the copyrights need to be updated. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> >>>> The problem was path is used to hold the constructed file name >>>> if it is confirmed to exist in the file system. Otherwise it is >>>> passed back from >>>> findSocketFile as a null to indicate the socket file was not found. >>>> >>>> I could refactor where the existence check is handled, but it >>>> seemed like the least >>>> invasive change to simply save the socket name for the printing in >>>> the error case. >>>> >>> Ah, right. Obviously "path" is null when you want to print the error >>> message. I guess I? have a hard time with "path" and "socket_name" >>> for the most part being the same (except "path" can end up being >>> null), yet they have two completely dissimilar names. Why not rename >>> path to socket_path and then add saved_socket_path, or something >>> like that. No changes to your current logic, just to the names being >>> used. >>> >>> Or, have findSocketFile() actually return the File, and then rename >>> path to socket_file and also rename socket_name to socket_path. The >>> truth of the matter is the result of findSocketFile() is only used >>> to see if the socket file exists. You could even change it to return >>> a boolean. >>> >>> Chris >>> >>> >> > > From gary.adams at oracle.com Tue Dec 19 22:47:39 2017 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Tue, 19 Dec 2017 17:47:39 -0500 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error In-Reply-To: References: <5A37D2C8.5090504@oracle.com> <45cb1c38-3fd7-b6ef-bdc7-c72666ac93d7@oracle.com> <20ad1b7b-b8bd-4e53-77d4-5be849b30ee1@oracle.com> <18b82fb3-fdca-14a5-36b7-f39f4968a5d0@oracle.com> <5A392926.60701@oracle.com> <68f45401-e931-48e3-088d-c8064752212c@oracle.com> Message-ID: Now comes the catch ... ??? I'll need a sponsor. On 12/19/17 5:12 PM, Chris Plummer wrote: > +1 > > Thanks, Chris > > On 12/19/17 8:57 AM, serguei.spitsyn at oracle.com wrote: >> Looks good. >> >> Thanks, Serguei >> >> >> On 12/19/17 06:58, Gary Adams wrote: >>> A refreshed webrev is vailable >>> ? Webrev: http://cr.openjdk.java.net/~gadams/8180709/webrev.01/ >>> >>> On 12/19/17, 5:10 AM, Alan Bateman wrote: >>>> On 18/12/2017 21:14, gary.adams at oracle.com wrote: >>>>> I can just the error message. >>>>> What would you like it to say? >>>>> >>>>> "Module java.instrument may be missing" >>>> Technically it may be that the java.instrument module is not >>>> observable but saying that it may not be in the run-time image is >>>> probably clearer to the clearer. The main thing is to connect it to >>>> the java.instrument module, other details are useful too, say where >>>> someone has a corrupt installation or the wrong permissions on the >>>> library. >>>> >>>> -Alan >>> >> > > From chris.plummer at oracle.com Tue Dec 19 22:50:57 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 19 Dec 2017 14:50:57 -0800 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error In-Reply-To: References: <5A37D2C8.5090504@oracle.com> <45cb1c38-3fd7-b6ef-bdc7-c72666ac93d7@oracle.com> <20ad1b7b-b8bd-4e53-77d4-5be849b30ee1@oracle.com> <18b82fb3-fdca-14a5-36b7-f39f4968a5d0@oracle.com> <5A392926.60701@oracle.com> <68f45401-e931-48e3-088d-c8064752212c@oracle.com> Message-ID: I can push it this evening if no one else grabs it first (need to step out for a bit and won't be able to monitor CI results). Please produce a changeset first. thanks, Chris On 12/19/17 2:47 PM, gary.adams at oracle.com wrote: > Now comes the catch ... > ??? I'll need a sponsor. > > On 12/19/17 5:12 PM, Chris Plummer wrote: >> +1 >> >> Thanks, Chris >> >> On 12/19/17 8:57 AM, serguei.spitsyn at oracle.com wrote: >>> Looks good. >>> >>> Thanks, Serguei >>> >>> >>> On 12/19/17 06:58, Gary Adams wrote: >>>> A refreshed webrev is vailable >>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8180709/webrev.01/ >>>> >>>> On 12/19/17, 5:10 AM, Alan Bateman wrote: >>>>> On 18/12/2017 21:14, gary.adams at oracle.com wrote: >>>>>> I can just the error message. >>>>>> What would you like it to say? >>>>>> >>>>>> "Module java.instrument may be missing" >>>>> Technically it may be that the java.instrument module is not >>>>> observable but saying that it may not be in the run-time image is >>>>> probably clearer to the clearer. The main thing is to connect it >>>>> to the java.instrument module, other details are useful too, say >>>>> where someone has a corrupt installation or the wrong permissions >>>>> on the library. >>>>> >>>>> -Alan >>>> >>> >> >> > From serguei.spitsyn at oracle.com Wed Dec 20 01:26:17 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Dec 2017 17:26:17 -0800 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error In-Reply-To: References: <5A37D2C8.5090504@oracle.com> <45cb1c38-3fd7-b6ef-bdc7-c72666ac93d7@oracle.com> <20ad1b7b-b8bd-4e53-77d4-5be849b30ee1@oracle.com> <18b82fb3-fdca-14a5-36b7-f39f4968a5d0@oracle.com> <5A392926.60701@oracle.com> <68f45401-e931-48e3-088d-c8064752212c@oracle.com> Message-ID: <90200bdf-d67f-80d4-a3b6-d84c4a7d8e09@oracle.com> Gary, What tests did you run? Event though the fix looks save it is still a good idea to submit a mach5 job that includes the :jdk_instrument test suite. Most likely, it is in the hs-tier5 (or more specifically, hs-tier5-rt) Thanks, Serguei On 12/19/17 14:50, Chris Plummer wrote: > I can push it this evening if no one else grabs it first (need to step > out for a bit and won't be able to monitor CI results). Please produce > a changeset first. > > thanks, > > Chris > > On 12/19/17 2:47 PM, gary.adams at oracle.com wrote: >> Now comes the catch ... >> ??? I'll need a sponsor. >> >> On 12/19/17 5:12 PM, Chris Plummer wrote: >>> +1 >>> >>> Thanks, Chris >>> >>> On 12/19/17 8:57 AM, serguei.spitsyn at oracle.com wrote: >>>> Looks good. >>>> >>>> Thanks, Serguei >>>> >>>> >>>> On 12/19/17 06:58, Gary Adams wrote: >>>>> A refreshed webrev is vailable >>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8180709/webrev.01/ >>>>> >>>>> On 12/19/17, 5:10 AM, Alan Bateman wrote: >>>>>> On 18/12/2017 21:14, gary.adams at oracle.com wrote: >>>>>>> I can just the error message. >>>>>>> What would you like it to say? >>>>>>> >>>>>>> "Module java.instrument may be missing" >>>>>> Technically it may be that the java.instrument module is not >>>>>> observable but saying that it may not be in the run-time image is >>>>>> probably clearer to the clearer. The main thing is to connect it >>>>>> to the java.instrument module, other details are useful too, say >>>>>> where someone has a corrupt installation or the wrong permissions >>>>>> on the library. >>>>>> >>>>>> -Alan >>>>> >>>> >>> >>> >> > > From serguei.spitsyn at oracle.com Wed Dec 20 03:21:41 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Dec 2017 19:21:41 -0800 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error In-Reply-To: <90200bdf-d67f-80d4-a3b6-d84c4a7d8e09@oracle.com> References: <5A37D2C8.5090504@oracle.com> <45cb1c38-3fd7-b6ef-bdc7-c72666ac93d7@oracle.com> <20ad1b7b-b8bd-4e53-77d4-5be849b30ee1@oracle.com> <18b82fb3-fdca-14a5-36b7-f39f4968a5d0@oracle.com> <5A392926.60701@oracle.com> <68f45401-e931-48e3-088d-c8064752212c@oracle.com> <90200bdf-d67f-80d4-a3b6-d84c4a7d8e09@oracle.com> Message-ID: <308058db-ef7e-15d5-056e-2850c79b1012@oracle.com> Chris pointed out, there is no point to run the tier5. It is enough to run the :jdk_instrument. Thanks, Serguei On 12/19/17 17:26, serguei.spitsyn at oracle.com wrote: > Gary, > > What tests did you run? > Event though the fix looks save it is still a good idea to submit a > mach5 job that includes the :jdk_instrument test suite. Most likely, > it is in the hs-tier5 (or more specifically, hs-tier5-rt) > > Thanks, > Serguei > > > On 12/19/17 14:50, Chris Plummer wrote: >> I can push it this evening if no one else grabs it first (need to >> step out for a bit and won't be able to monitor CI results). Please >> produce a changeset first. >> >> thanks, >> >> Chris >> >> On 12/19/17 2:47 PM, gary.adams at oracle.com wrote: >>> Now comes the catch ... >>> ??? I'll need a sponsor. >>> >>> On 12/19/17 5:12 PM, Chris Plummer wrote: >>>> +1 >>>> >>>> Thanks, Chris >>>> >>>> On 12/19/17 8:57 AM, serguei.spitsyn at oracle.com wrote: >>>>> Looks good. >>>>> >>>>> Thanks, Serguei >>>>> >>>>> >>>>> On 12/19/17 06:58, Gary Adams wrote: >>>>>> A refreshed webrev is vailable >>>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8180709/webrev.01/ >>>>>> >>>>>> On 12/19/17, 5:10 AM, Alan Bateman wrote: >>>>>>> On 18/12/2017 21:14, gary.adams at oracle.com wrote: >>>>>>>> I can just the error message. >>>>>>>> What would you like it to say? >>>>>>>> >>>>>>>> "Module java.instrument may be missing" >>>>>>> Technically it may be that the java.instrument module is not >>>>>>> observable but saying that it may not be in the run-time image >>>>>>> is probably clearer to the clearer. The main thing is to connect >>>>>>> it to the java.instrument module, other details are useful too, >>>>>>> say where someone has a corrupt installation or the wrong >>>>>>> permissions on the library. >>>>>>> >>>>>>> -Alan >>>>>> >>>>> >>>> >>>> >>> >> >> > From gary.adams at oracle.com Wed Dec 20 13:28:28 2017 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 20 Dec 2017 08:28:28 -0500 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error In-Reply-To: References: <5A37D2C8.5090504@oracle.com> <45cb1c38-3fd7-b6ef-bdc7-c72666ac93d7@oracle.com> <20ad1b7b-b8bd-4e53-77d4-5be849b30ee1@oracle.com> <18b82fb3-fdca-14a5-36b7-f39f4968a5d0@oracle.com> <5A392926.60701@oracle.com> <68f45401-e931-48e3-088d-c8064752212c@oracle.com> Message-ID: <5A3A657C.2050809@oracle.com> Is the patch file in the webrev sufficient? http://bussund0416.us.oracle.com/export/users/gradams/work/webrevs/8180709/webrev.01/jdk-hs.patch For testing I had been running the closed tonga all.testlist and the open jdk-tier1 tests. But to demonstrate the error message, I would locally build "make profiles" and then compare jre-compact2 and jre-compact3 results. The compact2 profile does not include java.instrument, but compact3 does. On 12/19/17, 5:50 PM, Chris Plummer wrote: > I can push it this evening if no one else grabs it first (need to step > out for a bit and won't be able to monitor CI results). Please produce > a changeset first. > > thanks, > > Chris > > On 12/19/17 2:47 PM, gary.adams at oracle.com wrote: >> Now comes the catch ... >> I'll need a sponsor. From frederic.parain at oracle.com Wed Dec 20 14:29:08 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 20 Dec 2017 09:29:08 -0500 Subject: [8u] RFR(S) 8031304 : Add dcmd to print all loaded dynamic libraries In-Reply-To: References: Message-ID: Looks good to me. Fred > On Dec 19, 2017, at 03:16, David Buck wrote: > > Hi! > > Please review this straightforward serviceability backport to JDK 8. > > No real changes to product code. I just moved the import statements in the DynLibDcmdTest.java test case to below the copyright header. > > bug report: > https://bugs.openjdk.java.net/browse/JDK-8031304 > > JDK 9 review thread: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-January/013778.html > > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/afa21611f918 > > JDK 8 webrev for review: > http://cr.openjdk.java.net/~dbuck/8031304_jdk8_ver00/ > > Cheers, > -Buck From markus.gronlund at oracle.com Wed Dec 20 16:41:21 2017 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Wed, 20 Dec 2017 08:41:21 -0800 (PST) Subject: [8u] RFR(S) 8031304 : Add dcmd to print all loaded dynamic libraries In-Reply-To: References: Message-ID: <279b7211-9492-48ea-af64-571e898289a2@default> Hi David, Looks good. Thanks Markus -----Original Message----- From: David Buck Sent: den 19 december 2017 09:17 To: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: [8u] RFR(S) 8031304 : Add dcmd to print all loaded dynamic libraries Hi! Please review this straightforward serviceability backport to JDK 8. No real changes to product code. I just moved the import statements in the DynLibDcmdTest.java test case to below the copyright header. bug report: https://bugs.openjdk.java.net/browse/JDK-8031304 JDK 9 review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-January/013778.html JDK 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/afa21611f918 JDK 8 webrev for review: http://cr.openjdk.java.net/~dbuck/8031304_jdk8_ver00/ Cheers, -Buck From amir at vfunction.com Tue Dec 12 13:03:17 2017 From: amir at vfunction.com (Amir Rapson) Date: Tue, 12 Dec 2017 15:03:17 +0200 Subject: JVMTI not receiving field access events with fast_getfield In-Reply-To: <4d64eee4-ede6-3177-6fd4-2cecfe0d7296@oracle.com> References: <76571dcc69fd5c8f80611008843d244d@mail.gmail.com> <4d64eee4-ede6-3177-6fd4-2cecfe0d7296@oracle.com> Message-ID: <79f508d7d1a393730eab95c61f6b7af9@mail.gmail.com> Hi, I know the code has some relevant code, but it doesn't seem to work. You will see some differences: the CALL_VM to the post function has only 2 arguments and not 3, I'm not sure it matters. The platform is x86_64, Java version is 1.8.0-152. I can try other versions if you wish. Please find the attached MyAgent.cpp MyAgent.h and com_vfunction_Main.h to compile the agent. Please also find the attached com.vfunction.zip that holds the simple java util to reproduce the problem. You'll see the problem on ArrayList.add(item) where you'll get events only on codes #16 and #22 and not on #2 and #11 (see attached bytecode.txt of said function). Please let me know once you managed to reproduce it. I can also send you a patch file to disable the fast_getfield (and fast putfield) to show that the problem disappears. I'm currently looking at the actual assembly of the add function, both with the modified hotspot and without and will try to assist will offering a fix for this issue. One last thing. I saw a very old issue (resolved by Daniel Daugherty) stating that fast_getfield was not completely addressed with the resolution on this issue. The bug ID is https://bugs.openjdk.java.net/browse/JDK-4300409 I'll be happy to assist further. Best regards, Amir -----Original Message----- From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] Sent: Tuesday, December 12, 2017 2:46 PM To: Amir Rapson Cc: Coleen.Phillimore at oracle.com; daniel.daugherty at oracle.com Subject: Re: JVMTI not receiving field access events with fast_getfield Thanks for the report, Amir! Unfortunately, I can't access the bug you filed. Can you, please, share the test case and instructions how to reproduce the problem? Also, what Java version & platform do you observe the bug on? I briefly looked into template interpreter code on x86 and it does have relevant code to post JVMTI events in fast accessors. Best regards, Vladimir Ivanov On 12/12/17 11:12 AM, Amir Rapson wrote: > Hi Daniel, Coleen and Vladimir, > > I tracked your email addresses from some mailing lists and hopefully > one of you is a relevant person for my problem. > > I also filed a bug request (ID 9051849) but since I don?t have an > option to add information I decided to email you. > > The problem I?m seeing is that JMTI does not receive field access > events (and probably field modification events) when /fast_getfield/ > is used instead of /get_field/. > > I verified this by disabling all the > /patch_bytecode(Bytecodes::_fast_?getfield, bc, rbx)/ in > /TemplateTable::getfield_or_static()/ and made sure that JVMTI > receives all the correct events. > > I have the agent code and a short java program that can reproduce the > problem and would be happy to assist in fixing and or debugging this > issue. > > I would appreciate any feedback. > > Best regards, > > Amir > > ?????Amir Rapson | Founder & VP Eng @ *vFunction* | 7 HaPelech St. > Tel-Aviv | +972-522650968 > -------------- next part -------------- /* DO NOT EDIT THIS FILE - it is machine generated */ #include /* Header for class com_vfunction_Main */ #ifndef _Included_com_vfunction_Main #define _Included_com_vfunction_Main #ifdef __cplusplus extern "C" { #endif /* * Class: com_vfunction_Main * Method: inspectField * Signature: (Ljava/lang/Class;Ljava/lang/String;Ljava/lang/String;Z)V */ JNIEXPORT void JNICALL Java_com_vfunction_Main_inspectField (JNIEnv *, jclass, jclass, jobject); #ifdef __cplusplus } #endif #endif -------------- next part -------------- #include "string.h" #include "stdlib.h" #include "jvmti.h" #include "com_vfunction_Main.h" static jvmtiEnv *jvmti; static void printFieldAccessInfo(jmethodID method, jfieldID field, jclass field_klass, bool modified, jlocation location); static void tagAndWatch(JNIEnv * jni_env, const jobject newObject); static void JNICALL onFieldAccess(jvmtiEnv *jvmti_env, JNIEnv* jni_env, jthread thread, jmethodID method, jlocation location, jclass field_klass, jobject parentObject, jfieldID field) { printFieldAccessInfo(method, field, field_klass, false, location); } static void JNICALL onFieldModified(jvmtiEnv *jvmti_env, JNIEnv* jni_env, jthread thread, jmethodID method, jlocation location, jclass field_klass, jobject parentObject, jfieldID field, char signature_type, jvalue new_value) { printFieldAccessInfo(method, field, field_klass, true, location); if (signature_type == 'L') { jobject newObject = new_value.l; tagAndWatch(jni_env, newObject); } } void tagAndWatch(JNIEnv * jni_env, const jobject obj) { if (obj == NULL) { return; } jclass klass = jni_env->GetObjectClass(obj); do { jfieldID* klassFields; jint fieldCount; jvmtiError err = jvmti->GetClassFields(klass, &fieldCount, &klassFields); if (err != JVMTI_ERROR_NONE) { printf("Failed to get class fields\n"); } for (int i = 0; i < fieldCount; ++i) { err = jvmti->SetFieldModificationWatch(klass, klassFields[i]); if (err != JVMTI_ERROR_NONE && err != JVMTI_ERROR_DUPLICATE) { printf("%s Failed to set field modification %d\n", __FUNCTION__, err); } err = jvmti->SetFieldAccessWatch(klass, klassFields[i]); if (err != JVMTI_ERROR_NONE && err != JVMTI_ERROR_DUPLICATE) { printf("%s Failed to set field access %d\n", __FUNCTION__, err); } char *sig = NULL; err = jvmti->GetFieldName(klass, klassFields[i], NULL, &sig, NULL); if (sig) { if (sig[0] == 'L') { jobject fieldVal = jni_env->GetObjectField(obj, klassFields[i]); tagAndWatch(jni_env, fieldVal); } jvmti->Deallocate((unsigned char*)sig); } } err = jvmti->Deallocate((unsigned char*)klassFields); if (err != JVMTI_ERROR_NONE) { printf("%s Failed to deallocate fields %d\n", __FUNCTION__, err); } klass = jni_env->GetSuperclass(klass); } while (klass != NULL); } JNIEXPORT void JNICALL Java_com_vfunction_Main_inspectField(JNIEnv * env, jclass caller, jclass klass, jobject field) { jfieldID fieldId = env->FromReflectedField(field); jvmtiError err = jvmti->SetFieldModificationWatch(klass, fieldId); if (err != JVMTI_ERROR_NONE) { printf("%s Failed to set field modification %d\n", __FUNCTION__, err); } err = jvmti->SetFieldAccessWatch(klass, fieldId); if (err != JVMTI_ERROR_NONE) { printf("%s Failed to set field access %d\n", __FUNCTION__, err); } } JNIEXPORT jint JNICALL Agent_OnLoad(JavaVM *jvm, char *options, void *reserved) { jvmtiEventCallbacks callbacks = {}; jvmtiError error; jint result = jvm->GetEnv((void **)&jvmti, JVMTI_VERSION_1_1); if (result != JNI_OK) { printf("ERROR: Unable to access JVMTI!\n"); return JNI_ERR; } else { printf("Agent succesfully loaded\n"); } jvmtiCapabilities capa = {}; capa.can_generate_field_modification_events = 1; capa.can_generate_field_access_events = 1; capa.can_tag_objects = 1; error = jvmti->AddCapabilities(&capa); if (error != JVMTI_ERROR_NONE) { printf("Failed to set capabilities: %d\n", error); } callbacks.FieldModification = &onFieldModified; callbacks.FieldAccess = &onFieldAccess; error = jvmti->SetEventCallbacks(&callbacks, sizeof(callbacks)); if (error != JVMTI_ERROR_NONE) { printf("Failed to set event callbacks: %d\n", error); } error = jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_FIELD_ACCESS, NULL); if (error != JVMTI_ERROR_NONE) { printf("Failed to set event notifications: %d\n", error); } error = jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_FIELD_MODIFICATION, NULL); if (error != JVMTI_ERROR_NONE) { printf("Failed to set event notifications: %d\n", error); } return JNI_OK; } static void printFieldAccessInfo(jmethodID method, jfieldID field, jclass field_klass, bool modified, jlocation location) { char *name; jvmtiError err = jvmti->GetFieldName(field_klass, field, &name, NULL, NULL); if (err != JVMTI_ERROR_NONE) { printf("%s: Failed to get field name", __FUNCTION__); return; } char *fname; err = jvmti->GetMethodName(method, &fname, NULL, NULL); if (err != JVMTI_ERROR_NONE) { printf("%s: Failed to get method name", __FUNCTION__); return; } jclass methodClass; err = jvmti->GetMethodDeclaringClass(method, &methodClass); if (err != JVMTI_ERROR_NONE) { printf("%s: Failed to get method class", __FUNCTION__); return; } char *csig; err = jvmti->GetClassSignature(methodClass, &csig, NULL); if (err != JVMTI_ERROR_NONE) { printf("%s: Failed to get class signature", __FUNCTION__); return; } printf("\"%s%s\" %s field \"%s\", location: %d\n", csig, fname, modified ? "modified" : "accessed", name, (int)location); jvmti->Deallocate((unsigned char*)csig); jvmti->Deallocate((unsigned char*)fname); jvmti->Deallocate((unsigned char*)name); } -------------- next part -------------- A non-text attachment was scrubbed... Name: com.vfunction.zip Type: application/x-zip-compressed Size: 1282 bytes Desc: not available URL: -------------- next part -------------- public boolean add(E); descriptor: (Ljava/lang/Object;)Z flags: ACC_PUBLIC Code: stack=5, locals=2, args_size=2 0: aload_0 1: aload_0 2: getfield #2 // Field size:I 5: iconst_1 6: iadd 7: invokespecial #41 // Method ensureCapacityInternal:(I)V 10: aload_0 11: getfield #5 // Field elementData:[Ljava/lang/Object; 14: aload_0 15: dup 16: getfield #2 // Field size:I 19: dup_x1 20: iconst_1 21: iadd 22: putfield #2 // Field size:I 25: aload_1 26: aastore 27: iconst_1 28: ireturn LineNumberTable: line 462: 0 line 463: 10 line 464: 27 LocalVariableTable: Start Length Slot Name Signature 0 29 0 this Ljava/util/ArrayList; 0 29 1 e Ljava/lang/Object; LocalVariableTypeTable: Start Length Slot Name Signature 0 29 0 this Ljava/util/ArrayList; 0 29 1 e TE; Signature: #176 // (TE;)Z From amir at vfunction.com Tue Dec 12 13:24:17 2017 From: amir at vfunction.com (Amir Rapson) Date: Tue, 12 Dec 2017 15:24:17 +0200 Subject: JVMTI not receiving field access events with fast_getfield In-Reply-To: <3b763c16-05a2-28b8-07c3-e0b589575ed1@oracle.com> References: <76571dcc69fd5c8f80611008843d244d@mail.gmail.com> <4d64eee4-ede6-3177-6fd4-2cecfe0d7296@oracle.com> <79f508d7d1a393730eab95c61f6b7af9@mail.gmail.com> <3b763c16-05a2-28b8-07c3-e0b589575ed1@oracle.com> Message-ID: <73de4dfe050e237ec72cb8833f432691@mail.gmail.com> Thank you Dan. Much appreciated. Again, let me know if I can assist with anything. Best, Amir -----Original Message----- From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] Sent: Tuesday, December 12, 2017 3:13 PM To: Amir Rapson ; Vladimir Ivanov ; serviceability-dev at openjdk.java.net Cc: Coleen.Phillimore at oracle.com Subject: Re: JVMTI not receiving field access events with fast_getfield Amir, Your https://bugs.openjdk.java.net/browse/JI-9051849 bug has been moved to https://bugs.openjdk.java.net/browse/JDK-8193369. Someone on the Serviceability team should pick up this thread from here, but we're right at the end game for JDK10 so it might take some time... Dan On 12/12/17 8:03 AM, Amir Rapson wrote: > Hi, > > I know the code has some relevant code, but it doesn't seem to work. > You will see some differences: the CALL_VM to the post function has > only 2 arguments and not 3, I'm not sure it matters. > > The platform is x86_64, Java version is 1.8.0-152. I can try other > versions if you wish. > > Please find the attached MyAgent.cpp MyAgent.h and > com_vfunction_Main.h to compile the agent. > Please also find the attached com.vfunction.zip that holds the simple > java util to reproduce the problem. > > You'll see the problem on ArrayList.add(item) where you'll get events > only on codes #16 and #22 and not on #2 and #11 (see attached > bytecode.txt of said function). > > Please let me know once you managed to reproduce it. I can also send > you a patch file to disable the fast_getfield (and fast putfield) to > show that the problem disappears. > > I'm currently looking at the actual assembly of the add function, both > with the modified hotspot and without and will try to assist will > offering a fix for this issue. > > One last thing. I saw a very old issue (resolved by Daniel Daugherty) > stating that fast_getfield was not completely addressed with the > resolution on this issue. The bug ID is > https://bugs.openjdk.java.net/browse/JDK-4300409 > > I'll be happy to assist further. > > Best regards, > Amir > > > -----Original Message----- > From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > Sent: Tuesday, December 12, 2017 2:46 PM > To: Amir Rapson > Cc: Coleen.Phillimore at oracle.com; daniel.daugherty at oracle.com > Subject: Re: JVMTI not receiving field access events with > fast_getfield > > Thanks for the report, Amir! > > Unfortunately, I can't access the bug you filed. > > Can you, please, share the test case and instructions how to reproduce > the problem? > > Also, what Java version & platform do you observe the bug on? > > I briefly looked into template interpreter code on x86 and it does > have relevant code to post JVMTI events in fast accessors. > > Best regards, > Vladimir Ivanov > > On 12/12/17 11:12 AM, Amir Rapson wrote: >> Hi Daniel, Coleen and Vladimir, >> >> I tracked your email addresses from some mailing lists and hopefully >> one of you is a relevant person for my problem. >> >> I also filed a bug request (ID 9051849) but since I don?t have an >> option to add information I decided to email you. >> >> The problem I?m seeing is that JMTI does not receive field access >> events (and probably field modification events) when /fast_getfield/ >> is used instead of /get_field/. >> >> I verified this by disabling all the >> /patch_bytecode(Bytecodes::_fast_?getfield, bc, rbx)/ in >> /TemplateTable::getfield_or_static()/ and made sure that JVMTI >> receives all the correct events. >> >> I have the agent code and a short java program that can reproduce the >> problem and would be happy to assist in fixing and or debugging this >> issue. >> >> I would appreciate any feedback. >> >> Best regards, >> >> Amir >> >> ?????Amir Rapson | Founder & VP Eng @ *vFunction* | 7 HaPelech St. >> Tel-Aviv | +972-522650968 >> From amir at vfunction.com Wed Dec 20 13:40:39 2017 From: amir at vfunction.com (Amir Rapson) Date: Wed, 20 Dec 2017 15:40:39 +0200 Subject: JVMTI not receiving field access events with fast_getfield In-Reply-To: 73de4dfe050e237ec72cb8833f432691@mail.gmail.com References: <76571dcc69fd5c8f80611008843d244d@mail.gmail.com> <4d64eee4-ede6-3177-6fd4-2cecfe0d7296@oracle.com> <79f508d7d1a393730eab95c61f6b7af9@mail.gmail.com> <3b763c16-05a2-28b8-07c3-e0b589575ed1@oracle.com> 73de4dfe050e237ec72cb8833f432691@mail.gmail.com Message-ID: Hi, If you could please remove my phone number from the comments of the bug. Thanks, Amir -----Original Message----- From: Amir Rapson [mailto:amir at vfunction.com] Sent: Tuesday, December 12, 2017 3:24 PM To: 'daniel.daugherty at oracle.com' ; 'Vladimir Ivanov' ; 'serviceability-dev at openjdk.java.net' Cc: 'Coleen.Phillimore at oracle.com' Subject: RE: JVMTI not receiving field access events with fast_getfield Thank you Dan. Much appreciated. Again, let me know if I can assist with anything. Best, Amir -----Original Message----- From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] Sent: Tuesday, December 12, 2017 3:13 PM To: Amir Rapson ; Vladimir Ivanov ; serviceability-dev at openjdk.java.net Cc: Coleen.Phillimore at oracle.com Subject: Re: JVMTI not receiving field access events with fast_getfield Amir, Your https://bugs.openjdk.java.net/browse/JI-9051849 bug has been moved to https://bugs.openjdk.java.net/browse/JDK-8193369. Someone on the Serviceability team should pick up this thread from here, but we're right at the end game for JDK10 so it might take some time... Dan On 12/12/17 8:03 AM, Amir Rapson wrote: > Hi, > > I know the code has some relevant code, but it doesn't seem to work. > You will see some differences: the CALL_VM to the post function has > only 2 arguments and not 3, I'm not sure it matters. > > The platform is x86_64, Java version is 1.8.0-152. I can try other > versions if you wish. > > Please find the attached MyAgent.cpp MyAgent.h and > com_vfunction_Main.h to compile the agent. > Please also find the attached com.vfunction.zip that holds the simple > java util to reproduce the problem. > > You'll see the problem on ArrayList.add(item) where you'll get events > only on codes #16 and #22 and not on #2 and #11 (see attached > bytecode.txt of said function). > > Please let me know once you managed to reproduce it. I can also send > you a patch file to disable the fast_getfield (and fast putfield) to > show that the problem disappears. > > I'm currently looking at the actual assembly of the add function, both > with the modified hotspot and without and will try to assist will > offering a fix for this issue. > > One last thing. I saw a very old issue (resolved by Daniel Daugherty) > stating that fast_getfield was not completely addressed with the > resolution on this issue. The bug ID is > https://bugs.openjdk.java.net/browse/JDK-4300409 > > I'll be happy to assist further. > > Best regards, > Amir > > > -----Original Message----- > From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > Sent: Tuesday, December 12, 2017 2:46 PM > To: Amir Rapson > Cc: Coleen.Phillimore at oracle.com; daniel.daugherty at oracle.com > Subject: Re: JVMTI not receiving field access events with > fast_getfield > > Thanks for the report, Amir! > > Unfortunately, I can't access the bug you filed. > > Can you, please, share the test case and instructions how to reproduce > the problem? > > Also, what Java version & platform do you observe the bug on? > > I briefly looked into template interpreter code on x86 and it does > have relevant code to post JVMTI events in fast accessors. > > Best regards, > Vladimir Ivanov > > On 12/12/17 11:12 AM, Amir Rapson wrote: >> Hi Daniel, Coleen and Vladimir, >> >> I tracked your email addresses from some mailing lists and hopefully >> one of you is a relevant person for my problem. >> >> I also filed a bug request (ID 9051849) but since I don?t have an >> option to add information I decided to email you. >> >> The problem I?m seeing is that JMTI does not receive field access >> events (and probably field modification events) when /fast_getfield/ >> is used instead of /get_field/. >> >> I verified this by disabling all the >> /patch_bytecode(Bytecodes::_fast_?getfield, bc, rbx)/ in >> /TemplateTable::getfield_or_static()/ and made sure that JVMTI >> receives all the correct events. >> >> I have the agent code and a short java program that can reproduce the >> problem and would be happy to assist in fixing and or debugging this >> issue. >> >> I would appreciate any feedback. >> >> Best regards, >> >> Amir >> >> ?????Amir Rapson | Founder & VP Eng @ *vFunction* | 7 HaPelech St. >> Tel-Aviv | +972-522650968 >> From tim.bell at oracle.com Wed Dec 20 16:53:34 2017 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 20 Dec 2017 08:53:34 -0800 Subject: JVMTI not receiving field access events with fast_getfield In-Reply-To: References: <76571dcc69fd5c8f80611008843d244d@mail.gmail.com> <4d64eee4-ede6-3177-6fd4-2cecfe0d7296@oracle.com> <79f508d7d1a393730eab95c61f6b7af9@mail.gmail.com> <3b763c16-05a2-28b8-07c3-e0b589575ed1@oracle.com> 73de4dfe050e237ec72cb8833f432691@mail.gmail.com Message-ID: <5A3A958E.2000805@oracle.com> Adding chris.plummer at oracle.com Chris - could you remove the personal number from the bug report please? The system won't let me do it. Thank you- Tim (list moderator for serviceability-dev at openjdk.java.net) On 12/20/17 05:40, Amir Rapson wrote: > Hi, > > If you could please remove my phone number from the comments of the bug. > > Thanks, > Amir > > -----Original Message----- > From: Amir Rapson [mailto:amir at vfunction.com] > Sent: Tuesday, December 12, 2017 3:24 PM > To: 'daniel.daugherty at oracle.com' ; 'Vladimir > Ivanov' ; > 'serviceability-dev at openjdk.java.net' > Cc: 'Coleen.Phillimore at oracle.com' > Subject: RE: JVMTI not receiving field access events with fast_getfield > > Thank you Dan. Much appreciated. > > Again, let me know if I can assist with anything. > > Best, > Amir > > -----Original Message----- > From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] > Sent: Tuesday, December 12, 2017 3:13 PM > To: Amir Rapson ; Vladimir Ivanov > ; serviceability-dev at openjdk.java.net > Cc: Coleen.Phillimore at oracle.com > Subject: Re: JVMTI not receiving field access events with fast_getfield > > Amir, > > Your https://bugs.openjdk.java.net/browse/JI-9051849 bug has been moved to > https://bugs.openjdk.java.net/browse/JDK-8193369. > > Someone on the Serviceability team should pick up this thread from here, but > we're right at the end game for JDK10 so it might take some time... > > Dan > > > On 12/12/17 8:03 AM, Amir Rapson wrote: >> Hi, >> >> I know the code has some relevant code, but it doesn't seem to work. >> You will see some differences: the CALL_VM to the post function has >> only 2 arguments and not 3, I'm not sure it matters. >> >> The platform is x86_64, Java version is 1.8.0-152. I can try other >> versions if you wish. >> >> Please find the attached MyAgent.cpp MyAgent.h and >> com_vfunction_Main.h to compile the agent. >> Please also find the attached com.vfunction.zip that holds the simple >> java util to reproduce the problem. >> >> You'll see the problem on ArrayList.add(item) where you'll get events >> only on codes #16 and #22 and not on #2 and #11 (see attached >> bytecode.txt of said function). >> >> Please let me know once you managed to reproduce it. I can also send >> you a patch file to disable the fast_getfield (and fast putfield) to >> show that the problem disappears. >> >> I'm currently looking at the actual assembly of the add function, both >> with the modified hotspot and without and will try to assist will >> offering a fix for this issue. >> >> One last thing. I saw a very old issue (resolved by Daniel Daugherty) >> stating that fast_getfield was not completely addressed with the >> resolution on this issue. The bug ID is >> https://bugs.openjdk.java.net/browse/JDK-4300409 >> >> I'll be happy to assist further. >> >> Best regards, >> Amir >> >> >> -----Original Message----- >> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >> Sent: Tuesday, December 12, 2017 2:46 PM >> To: Amir Rapson >> Cc: Coleen.Phillimore at oracle.com; daniel.daugherty at oracle.com >> Subject: Re: JVMTI not receiving field access events with >> fast_getfield >> >> Thanks for the report, Amir! >> >> Unfortunately, I can't access the bug you filed. >> >> Can you, please, share the test case and instructions how to reproduce >> the problem? >> >> Also, what Java version & platform do you observe the bug on? >> >> I briefly looked into template interpreter code on x86 and it does >> have relevant code to post JVMTI events in fast accessors. >> >> Best regards, >> Vladimir Ivanov >> >> On 12/12/17 11:12 AM, Amir Rapson wrote: >>> Hi Daniel, Coleen and Vladimir, >>> >>> I tracked your email addresses from some mailing lists and hopefully >>> one of you is a relevant person for my problem. >>> >>> I also filed a bug request (ID 9051849) but since I don?t have an >>> option to add information I decided to email you. >>> >>> The problem I?m seeing is that JMTI does not receive field access >>> events (and probably field modification events) when /fast_getfield/ >>> is used instead of /get_field/. >>> >>> I verified this by disabling all the >>> /patch_bytecode(Bytecodes::_fast_?getfield, bc, rbx)/ in >>> /TemplateTable::getfield_or_static()/ and made sure that JVMTI >>> receives all the correct events. >>> >>> I have the agent code and a short java program that can reproduce the >>> problem and would be happy to assist in fixing and or debugging this >>> issue. >>> >>> I would appreciate any feedback. >>> >>> Best regards, >>> >>> Amir >>> >>> ?????Amir Rapson | Founder & VP Eng @ *vFunction* | 7 HaPelech St. >>> Tel-Aviv | +972-522650968 >>> From chris.plummer at oracle.com Wed Dec 20 18:08:56 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 20 Dec 2017 10:08:56 -0800 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error In-Reply-To: <5A3A657C.2050809@oracle.com> References: <5A37D2C8.5090504@oracle.com> <45cb1c38-3fd7-b6ef-bdc7-c72666ac93d7@oracle.com> <20ad1b7b-b8bd-4e53-77d4-5be849b30ee1@oracle.com> <18b82fb3-fdca-14a5-36b7-f39f4968a5d0@oracle.com> <5A392926.60701@oracle.com> <68f45401-e931-48e3-088d-c8064752212c@oracle.com> <5A3A657C.2050809@oracle.com> Message-ID: It's best if you actually do the commit and then produce the patch with "hg export". Then the commit comment and user are setup already and all I need to do is "hg import ; hg push". thanks, Chris On 12/20/17 5:28 AM, Gary Adams wrote: > Is the patch file in the webrev sufficient? > > http://bussund0416.us.oracle.com/export/users/gradams/work/webrevs/8180709/webrev.01/jdk-hs.patch > > For testing I had been running the closed tonga all.testlist and the > open jdk-tier1 tests. > > But to demonstrate the error message, I would locally build "make > profiles" > and then compare jre-compact2 and jre-compact3 results. The compact2 > profile does not include java.instrument, but compact3 does. > > On 12/19/17, 5:50 PM, Chris Plummer wrote: >> I can push it this evening if no one else grabs it first (need to >> step out for a bit and won't be able to monitor CI results). Please >> produce a changeset first. >> >> thanks, >> >> Chris >> >> On 12/19/17 2:47 PM, gary.adams at oracle.com wrote: >>> Now comes the catch ... >>> ??? I'll need a sponsor. > From chris.plummer at oracle.com Wed Dec 20 18:16:20 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 20 Dec 2017 10:16:20 -0800 Subject: JVMTI not receiving field access events with fast_getfield In-Reply-To: References: <76571dcc69fd5c8f80611008843d244d@mail.gmail.com> <4d64eee4-ede6-3177-6fd4-2cecfe0d7296@oracle.com> <79f508d7d1a393730eab95c61f6b7af9@mail.gmail.com> <3b763c16-05a2-28b8-07c3-e0b589575ed1@oracle.com> Message-ID: <59d40d63-42a1-88cc-b47c-3fa6e28e3719@oracle.com> Done. Sorry about that. Chris On 12/20/17 5:40 AM, Amir Rapson wrote: > Hi, > > If you could please remove my phone number from the comments of the bug. > > Thanks, > Amir > > -----Original Message----- > From: Amir Rapson [mailto:amir at vfunction.com] > Sent: Tuesday, December 12, 2017 3:24 PM > To: 'daniel.daugherty at oracle.com' ; 'Vladimir > Ivanov' ; > 'serviceability-dev at openjdk.java.net' > Cc: 'Coleen.Phillimore at oracle.com' > Subject: RE: JVMTI not receiving field access events with fast_getfield > > Thank you Dan. Much appreciated. > > Again, let me know if I can assist with anything. > > Best, > Amir > > -----Original Message----- > From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] > Sent: Tuesday, December 12, 2017 3:13 PM > To: Amir Rapson ; Vladimir Ivanov > ; serviceability-dev at openjdk.java.net > Cc: Coleen.Phillimore at oracle.com > Subject: Re: JVMTI not receiving field access events with fast_getfield > > Amir, > > Your https://bugs.openjdk.java.net/browse/JI-9051849 bug has been moved to > https://bugs.openjdk.java.net/browse/JDK-8193369. > > Someone on the Serviceability team should pick up this thread from here, but > we're right at the end game for JDK10 so it might take some time... > > Dan > > > On 12/12/17 8:03 AM, Amir Rapson wrote: >> Hi, >> >> I know the code has some relevant code, but it doesn't seem to work. >> You will see some differences: the CALL_VM to the post function has >> only 2 arguments and not 3, I'm not sure it matters. >> >> The platform is x86_64, Java version is 1.8.0-152. I can try other >> versions if you wish. >> >> Please find the attached MyAgent.cpp MyAgent.h and >> com_vfunction_Main.h to compile the agent. >> Please also find the attached com.vfunction.zip that holds the simple >> java util to reproduce the problem. >> >> You'll see the problem on ArrayList.add(item) where you'll get events >> only on codes #16 and #22 and not on #2 and #11 (see attached >> bytecode.txt of said function). >> >> Please let me know once you managed to reproduce it. I can also send >> you a patch file to disable the fast_getfield (and fast putfield) to >> show that the problem disappears. >> >> I'm currently looking at the actual assembly of the add function, both >> with the modified hotspot and without and will try to assist will >> offering a fix for this issue. >> >> One last thing. I saw a very old issue (resolved by Daniel Daugherty) >> stating that fast_getfield was not completely addressed with the >> resolution on this issue. The bug ID is >> https://bugs.openjdk.java.net/browse/JDK-4300409 >> >> I'll be happy to assist further. >> >> Best regards, >> Amir >> >> >> -----Original Message----- >> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >> Sent: Tuesday, December 12, 2017 2:46 PM >> To: Amir Rapson >> Cc: Coleen.Phillimore at oracle.com; daniel.daugherty at oracle.com >> Subject: Re: JVMTI not receiving field access events with >> fast_getfield >> >> Thanks for the report, Amir! >> >> Unfortunately, I can't access the bug you filed. >> >> Can you, please, share the test case and instructions how to reproduce >> the problem? >> >> Also, what Java version & platform do you observe the bug on? >> >> I briefly looked into template interpreter code on x86 and it does >> have relevant code to post JVMTI events in fast accessors. >> >> Best regards, >> Vladimir Ivanov >> >> On 12/12/17 11:12 AM, Amir Rapson wrote: >>> Hi Daniel, Coleen and Vladimir, >>> >>> I tracked your email addresses from some mailing lists and hopefully >>> one of you is a relevant person for my problem. >>> >>> I also filed a bug request (ID 9051849) but since I don?t have an >>> option to add information I decided to email you. >>> >>> The problem I?m seeing is that JMTI does not receive field access >>> events (and probably field modification events) when /fast_getfield/ >>> is used instead of /get_field/. >>> >>> I verified this by disabling all the >>> /patch_bytecode(Bytecodes::_fast_?getfield, bc, rbx)/ in >>> /TemplateTable::getfield_or_static()/ and made sure that JVMTI >>> receives all the correct events. >>> >>> I have the agent code and a short java program that can reproduce the >>> problem and would be happy to assist in fixing and or debugging this >>> issue. >>> >>> I would appreciate any feedback. >>> >>> Best regards, >>> >>> Amir >>> >>> ?????Amir Rapson | Founder & VP Eng @ *vFunction* | 7 HaPelech St. >>> Tel-Aviv | +972-522650968 >>> From serguei.spitsyn at oracle.com Wed Dec 20 18:21:14 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 20 Dec 2017 10:21:14 -0800 Subject: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error In-Reply-To: <5A3A657C.2050809@oracle.com> References: <5A37D2C8.5090504@oracle.com> <45cb1c38-3fd7-b6ef-bdc7-c72666ac93d7@oracle.com> <20ad1b7b-b8bd-4e53-77d4-5be849b30ee1@oracle.com> <18b82fb3-fdca-14a5-36b7-f39f4968a5d0@oracle.com> <5A392926.60701@oracle.com> <68f45401-e931-48e3-088d-c8064752212c@oracle.com> <5A3A657C.2050809@oracle.com> Message-ID: <9085b115-cb7d-ff32-ef43-a0d928f7224b@oracle.com> An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Wed Dec 20 18:46:10 2017 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 20 Dec 2017 13:46:10 -0500 Subject: RFR: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix In-Reply-To: References: <5A37D512.5070508@oracle.com> <4b96505e-95e9-2988-236b-55e15253bcf7@oracle.com> <23c19686-4ffa-9ddb-efee-e68b52ba071a@oracle.com> <3c50b1a1-82b8-dd09-47ed-7c00b3960b7c@oracle.com> <5A392997.5080701@oracle.com> <484b0ced-a672-e706-d570-e88de7b3db2f@oracle.com> Message-ID: <5A3AAFF2.8090800@oracle.com> I've done a little bit more investigation to learn how detach and execute are expected to work. Looking at the solaris implementation, detach actually closes the file descriptor and the check in execute is is fd == -1. In the macosx implementation the check uses path == null. So to correct the changeset in progress, I need to restore the flag indicating that a connection has been made and the detach case which clears the current connection. Let me run that through some instrumentation tests cases and come back with the next webrev tomorrow. On 12/19/17, 5:46 PM, gary.adams at oracle.com wrote: > More work is needed here. I have not tracked down how detach is > actually used. > The previous path as null string was a flag to reconnect (?). > > On 12/19/17 5:23 PM, Chris Plummer wrote: >> Hi Gary, >> >> I'm not sure about the detach() and execute() changes on linux (how >> can this.path references just be stripped and the code still work >> properly), and how does this code continue to work on AIX and MacOSX >> when "path" has been removed but is still referenced. Shouldn't >> this.path just be replaced with this.socket_name? >> >> thanks, >> >> Chris From serguei.spitsyn at oracle.com Wed Dec 20 20:48:25 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 20 Dec 2017 12:48:25 -0800 Subject: JVMTI not receiving field access events with fast_getfield In-Reply-To: References: <76571dcc69fd5c8f80611008843d244d@mail.gmail.com> <4d64eee4-ede6-3177-6fd4-2cecfe0d7296@oracle.com> <79f508d7d1a393730eab95c61f6b7af9@mail.gmail.com> <3b763c16-05a2-28b8-07c3-e0b589575ed1@oracle.com> Message-ID: Hi Amir, As a work around, could you try to enable the can_generate_breakpoint_events capability? This capability should disable the fast get/putfiled bytecodes generation. Adding this line to the MyAgent.cpp should do it: ?? capa.can_generate_breakpoint_events = 1; Thanks, Serguei On 12/20/17 05:40, Amir Rapson wrote: > Hi, > > If you could please remove my phone number from the comments of the bug. > > Thanks, > Amir > > -----Original Message----- > From: Amir Rapson [mailto:amir at vfunction.com] > Sent: Tuesday, December 12, 2017 3:24 PM > To: 'daniel.daugherty at oracle.com' ; 'Vladimir > Ivanov' ; > 'serviceability-dev at openjdk.java.net' > Cc: 'Coleen.Phillimore at oracle.com' > Subject: RE: JVMTI not receiving field access events with fast_getfield > > Thank you Dan. Much appreciated. > > Again, let me know if I can assist with anything. > > Best, > Amir > > -----Original Message----- > From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] > Sent: Tuesday, December 12, 2017 3:13 PM > To: Amir Rapson ; Vladimir Ivanov > ; serviceability-dev at openjdk.java.net > Cc: Coleen.Phillimore at oracle.com > Subject: Re: JVMTI not receiving field access events with fast_getfield > > Amir, > > Your https://bugs.openjdk.java.net/browse/JI-9051849 bug has been moved to > https://bugs.openjdk.java.net/browse/JDK-8193369. > > Someone on the Serviceability team should pick up this thread from here, but > we're right at the end game for JDK10 so it might take some time... > > Dan > > > On 12/12/17 8:03 AM, Amir Rapson wrote: >> Hi, >> >> I know the code has some relevant code, but it doesn't seem to work. >> You will see some differences: the CALL_VM to the post function has >> only 2 arguments and not 3, I'm not sure it matters. >> >> The platform is x86_64, Java version is 1.8.0-152. I can try other >> versions if you wish. >> >> Please find the attached MyAgent.cpp MyAgent.h and >> com_vfunction_Main.h to compile the agent. >> Please also find the attached com.vfunction.zip that holds the simple >> java util to reproduce the problem. >> >> You'll see the problem on ArrayList.add(item) where you'll get events >> only on codes #16 and #22 and not on #2 and #11 (see attached >> bytecode.txt of said function). >> >> Please let me know once you managed to reproduce it. I can also send >> you a patch file to disable the fast_getfield (and fast putfield) to >> show that the problem disappears. >> >> I'm currently looking at the actual assembly of the add function, both >> with the modified hotspot and without and will try to assist will >> offering a fix for this issue. >> >> One last thing. I saw a very old issue (resolved by Daniel Daugherty) >> stating that fast_getfield was not completely addressed with the >> resolution on this issue. The bug ID is >> https://bugs.openjdk.java.net/browse/JDK-4300409 >> >> I'll be happy to assist further. >> >> Best regards, >> Amir >> >> >> -----Original Message----- >> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >> Sent: Tuesday, December 12, 2017 2:46 PM >> To: Amir Rapson >> Cc: Coleen.Phillimore at oracle.com; daniel.daugherty at oracle.com >> Subject: Re: JVMTI not receiving field access events with >> fast_getfield >> >> Thanks for the report, Amir! >> >> Unfortunately, I can't access the bug you filed. >> >> Can you, please, share the test case and instructions how to reproduce >> the problem? >> >> Also, what Java version & platform do you observe the bug on? >> >> I briefly looked into template interpreter code on x86 and it does >> have relevant code to post JVMTI events in fast accessors. >> >> Best regards, >> Vladimir Ivanov >> >> On 12/12/17 11:12 AM, Amir Rapson wrote: >>> Hi Daniel, Coleen and Vladimir, >>> >>> I tracked your email addresses from some mailing lists and hopefully >>> one of you is a relevant person for my problem. >>> >>> I also filed a bug request (ID 9051849) but since I don?t have an >>> option to add information I decided to email you. >>> >>> The problem I?m seeing is that JMTI does not receive field access >>> events (and probably field modification events) when /fast_getfield/ >>> is used instead of /get_field/. >>> >>> I verified this by disabling all the >>> /patch_bytecode(Bytecodes::_fast_?getfield, bc, rbx)/ in >>> /TemplateTable::getfield_or_static()/ and made sure that JVMTI >>> receives all the correct events. >>> >>> I have the agent code and a short java program that can reproduce the >>> problem and would be happy to assist in fixing and or debugging this >>> issue. >>> >>> I would appreciate any feedback. >>> >>> Best regards, >>> >>> Amir >>> >>> ?????Amir Rapson | Founder & VP Eng @ *vFunction* | 7 HaPelech St. >>> Tel-Aviv | +972-522650968 >>> From daniil.x.titov at oracle.com Wed Dec 20 22:03:13 2017 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 20 Dec 2017 14:03:13 -0800 Subject: DOC RFR: JDK-8187448: 360 doc issues in jdwp-protocol.html Message-ID: Please review a fix for the doc bug. The fix does the following: 1. Removes empty
    elements. 2. Adds an outer
      element to the index section . 3. Removes obsolete in HTML5 ?summary? attribute in elements. 4. Removes empty

      elements. 5. Replaces not supported in HTML5 ?bgcolor? attribute for element with ?style="background-color?? attribute. 6. Removes

      element in ConstantSetNode (there is no outer
      element in this case) 7. Adds required by accessibility audits ?lang? attribute for element. Testing: 1. Built the docs target and looked at the resulting jdwp-protocol.html. 2. Tested that is passes validation with tidy 3. Tested it passes accessibility audits with Accessibility Developer Tool (Chrome) Bug: https://bugs.openjdk.java.net/browse/JDK-8187448 Webrev: http://cr.openjdk.java.net/~dtitov/8187448/webrev.01 Thanks, Daniil From gary.adams at oracle.com Thu Dec 21 20:17:56 2017 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 21 Dec 2017 15:17:56 -0500 Subject: RFR: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix In-Reply-To: <5A392997.5080701@oracle.com> References: <5A37D512.5070508@oracle.com> <4b96505e-95e9-2988-236b-55e15253bcf7@oracle.com> <23c19686-4ffa-9ddb-efee-e68b52ba071a@oracle.com> <3c50b1a1-82b8-dd09-47ed-7c00b3960b7c@oracle.com> <5A392997.5080701@oracle.com> Message-ID: <5A3C16F4.7020108@oracle.com> A refreshed webrev is available Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.02/ - added solaris version of the file which had the same original error reporting the wrong socket file name - restored the linux detach/execute logic - updated the macosx and aix detach/execute logic - a few minor differences between the various platform specific files curly braces and exception args. Ran into some issues with mach5 testing which will require another test run tomorrow. On 12/19/17, 10:00 AM, Gary Adams wrote: > A refreshed webrev is available > Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.01/ > > On 12/18/17, 4:38 PM, Chris Plummer wrote: >> On 12/18/17 1:22 PM, gary.adams at oracle.com wrote: >>> On 12/18/17 2:26 PM, Chris Plummer wrote: >>>> Hi Gary, >>>> >>>> On 12/18/17 6:47 AM, Gary Adams wrote: >>>>> Here's a simple fix to correct the error message when the java_pid >>>>> socket >>>>> is not found. The code previously reported the attach_pid file name >>>>> rather than the socket file name that was not found. >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8188856 >>>>> Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.00/ >>>> >>>> I don't understand why you couldn't simply have changed the >>>> f.getPath() reference to "path". From what I can see, there is no >>>> difference between "path" and "socket_name". The problem you are >>>> fixing is that the error message prints f.getPath(), but that >>>> refers to the attach file and the error message should refer to the >>>> socket file. You've correct this, but have done so in a round about >>>> way. Above the error message (in two places) exists: >>>> >>>> path = findSocketFile(pid, ns_pid); >>>> >>>> So "path" is what you want. You have indirectly fixed the problem >>>> by having findSocketFile() store the path in socket_name, and then >>>> you print socket_name, but why not just do the direct fix and print >>>> "path". >>>> >>>> Also, the copyrights need to be updated. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> >>> The problem was path is used to hold the constructed file name >>> if it is confirmed to exist in the file system. Otherwise it is >>> passed back from >>> findSocketFile as a null to indicate the socket file was not found. >>> >>> I could refactor where the existence check is handled, but it seemed >>> like the least >>> invasive change to simply save the socket name for the printing in >>> the error case. >>> >> Ah, right. Obviously "path" is null when you want to print the error >> message. I guess I have a hard time with "path" and "socket_name" >> for the most part being the same (except "path" can end up being >> null), yet they have two completely dissimilar names. Why not rename >> path to socket_path and then add saved_socket_path, or something like >> that. No changes to your current logic, just to the names being used. >> >> Or, have findSocketFile() actually return the File, and then rename >> path to socket_file and also rename socket_name to socket_path. The >> truth of the matter is the result of findSocketFile() is only used to >> see if the socket file exists. You could even change it to return a >> boolean. >> >> Chris >> >> > From serguei.spitsyn at oracle.com Thu Dec 21 23:37:29 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 21 Dec 2017 15:37:29 -0800 Subject: RFR: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix In-Reply-To: <5A3C16F4.7020108@oracle.com> References: <5A37D512.5070508@oracle.com> <4b96505e-95e9-2988-236b-55e15253bcf7@oracle.com> <23c19686-4ffa-9ddb-efee-e68b52ba071a@oracle.com> <3c50b1a1-82b8-dd09-47ed-7c00b3960b7c@oracle.com> <5A392997.5080701@oracle.com> <5A3C16F4.7020108@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Dec 21 23:43:33 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 21 Dec 2017 15:43:33 -0800 Subject: RFR: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix In-Reply-To: References: <5A37D512.5070508@oracle.com> <4b96505e-95e9-2988-236b-55e15253bcf7@oracle.com> <23c19686-4ffa-9ddb-efee-e68b52ba071a@oracle.com> <3c50b1a1-82b8-dd09-47ed-7c00b3960b7c@oracle.com> <5A392997.5080701@oracle.com> <5A3C16F4.7020108@oracle.com> Message-ID: <9e814645-1a4f-ebaf-0999-1b882e6a7dbe@oracle.com> An HTML attachment was scrubbed... URL: From david.buck at oracle.com Fri Dec 22 06:19:37 2017 From: david.buck at oracle.com (David Buck) Date: Fri, 22 Dec 2017 15:19:37 +0900 Subject: [8u] RFR(S) 8044107 : Add Diagnostic Command to list all ClassLoaders Message-ID: <30338e73-69c2-98c8-ac11-f3ed3913ec28@oracle.com> Hi! Please review this very simple serviceability backport to 8u. The only difference between the JDK 9 changeset and the JDK 8 changeset is that the ClassLoaderDataGraph::cld_do function was already backported to JDK 8 in the fix for 8049421 [0]. So the changes for adding classLoaderData.hpp|cpp are already in JDK 8 line-for-line exactly the same as they are in JDK 9. bug report: https://bugs.openjdk.java.net/browse/JDK-8044107 JDK 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/56a35b09e0d4 JDK 9 code review thread May 2014: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-May/014072.html June 2014: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-June/014127.html JDK 8 webrev for review: http://cr.openjdk.java.net/~dbuck/8044107_jdk8_ver00/ Testing: JPRT (hotspot testset) jtreg test included in changeset manually confirmed new diagnostic command works as expected Cheers, -Buck [0] http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/2c6ef90f030a From david.holmes at oracle.com Fri Dec 22 08:10:51 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Dec 2017 18:10:51 +1000 Subject: [8u] RFR(S) 8044107 : Add Diagnostic Command to list all ClassLoaders In-Reply-To: <30338e73-69c2-98c8-ac11-f3ed3913ec28@oracle.com> References: <30338e73-69c2-98c8-ac11-f3ed3913ec28@oracle.com> Message-ID: This looks like an accurate backport to me. Thanks, David On 22/12/2017 4:19 PM, David Buck wrote: > Hi! > > Please review this very simple serviceability backport to 8u. The only > difference between the JDK 9 changeset and the JDK 8 changeset is that > the ClassLoaderDataGraph::cld_do function was already backported to JDK > 8 in the fix for 8049421 [0]. So the changes for adding > classLoaderData.hpp|cpp are already in JDK 8 line-for-line exactly the > same as they are in JDK 9. > > bug report: > https://bugs.openjdk.java.net/browse/JDK-8044107 > > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/56a35b09e0d4 > > JDK 9 code review thread > May 2014: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-May/014072.html > June 2014: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-June/014127.html > > JDK 8 webrev for review: > http://cr.openjdk.java.net/~dbuck/8044107_jdk8_ver00/ > > Testing: > JPRT (hotspot testset) > jtreg test included in changeset > manually confirmed new diagnostic command works as expected > > Cheers, > -Buck > > [0] http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/2c6ef90f030a From egor.ushakov at jetbrains.com Fri Dec 22 15:32:18 2017 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Fri, 22 Dec 2017 18:32:18 +0300 Subject: RFR: cleanup - removed unneeded casts in jdi Message-ID: <1ed37870-6d58-f250-d984-9c455c50e43e@jetbrains.com> Hi all, could you please review and sponsor this small cleanup removing unneeded casts in jdi LocationImpl and MirrorImpl. They were preventing creating custom Location and Mirror implementations used for tests and IDEA debugger impl. http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ I do not have rights to create JDK bug report directly, please create it if it is needed for the procedure. Thanks! -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop From gary.adams at oracle.com Fri Dec 22 15:48:21 2017 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 22 Dec 2017 10:48:21 -0500 Subject: RFR: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix In-Reply-To: <5A3C16F4.7020108@oracle.com> References: <5A37D512.5070508@oracle.com> <4b96505e-95e9-2988-236b-55e15253bcf7@oracle.com> <23c19686-4ffa-9ddb-efee-e68b52ba071a@oracle.com> <3c50b1a1-82b8-dd09-47ed-7c00b3960b7c@oracle.com> <5A392997.5080701@oracle.com> <5A3C16F4.7020108@oracle.com> Message-ID: <5A3D2945.6010505@oracle.com> A refreshed webrev is available Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.03/ - "String socket_path" is now used where the original "path" variable was used - "File socket_file" is used for the exists() and getPath() calls - left solaris openDoor optimizations out, because it is not really related to the original reported issue - left linux findSocketFile as a separate method, because it contains extra nspid cgroup aware logic. The original findSocketFile performed 2 steps to formulate the java_pid path name and to check existence. Now that it only formulates the path name, it seems reasonable to fold the processing into the caller. There already was an asymmetry in the platform specific implementations as solaris was using openDoor and the open file descriptor for it's connected flag checks. Bypassed the mach5 errors I was seeing by moving over to testing with jdk/jdk repos. If this is acceptable, I'll create an hg export patch file for my sponsor. On 12/21/17, 3:17 PM, Gary Adams wrote: > A refreshed webrev is available > Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.02/ > > - added solaris version of the file which had the same original > error reporting > the wrong socket file name > - restored the linux detach/execute logic > - updated the macosx and aix detach/execute logic > - a few minor differences between the various platform specific files > curly braces and exception args. > > Ran into some issues with mach5 testing which will require another > test run tomorrow. > > On 12/19/17, 10:00 AM, Gary Adams wrote: >> A refreshed webrev is available >> Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.01/ >> >> On 12/18/17, 4:38 PM, Chris Plummer wrote: >>> On 12/18/17 1:22 PM, gary.adams at oracle.com wrote: >>>> On 12/18/17 2:26 PM, Chris Plummer wrote: >>>>> Hi Gary, >>>>> >>>>> On 12/18/17 6:47 AM, Gary Adams wrote: >>>>>> Here's a simple fix to correct the error message when the >>>>>> java_pid socket >>>>>> is not found. The code previously reported the attach_pid file name >>>>>> rather than the socket file name that was not found. >>>>>> >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8188856 >>>>>> Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.00/ >>>>> >>>>> I don't understand why you couldn't simply have changed the >>>>> f.getPath() reference to "path". From what I can see, there is no >>>>> difference between "path" and "socket_name". The problem you are >>>>> fixing is that the error message prints f.getPath(), but that >>>>> refers to the attach file and the error message should refer to >>>>> the socket file. You've correct this, but have done so in a round >>>>> about way. Above the error message (in two places) exists: >>>>> >>>>> path = findSocketFile(pid, ns_pid); >>>>> >>>>> So "path" is what you want. You have indirectly fixed the problem >>>>> by having findSocketFile() store the path in socket_name, and then >>>>> you print socket_name, but why not just do the direct fix and >>>>> print "path". >>>>> >>>>> Also, the copyrights need to be updated. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> >>>> The problem was path is used to hold the constructed file name >>>> if it is confirmed to exist in the file system. Otherwise it is >>>> passed back from >>>> findSocketFile as a null to indicate the socket file was not found. >>>> >>>> I could refactor where the existence check is handled, but it >>>> seemed like the least >>>> invasive change to simply save the socket name for the printing in >>>> the error case. >>>> >>> Ah, right. Obviously "path" is null when you want to print the error >>> message. I guess I have a hard time with "path" and "socket_name" >>> for the most part being the same (except "path" can end up being >>> null), yet they have two completely dissimilar names. Why not rename >>> path to socket_path and then add saved_socket_path, or something >>> like that. No changes to your current logic, just to the names being >>> used. >>> >>> Or, have findSocketFile() actually return the File, and then rename >>> path to socket_file and also rename socket_name to socket_path. The >>> truth of the matter is the result of findSocketFile() is only used >>> to see if the socket file exists. You could even change it to return >>> a boolean. >>> >>> Chris >>> >>> >> > From daniil.x.titov at oracle.com Fri Dec 22 17:39:52 2017 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 22 Dec 2017 09:39:52 -0800 Subject: DOC RFR: 8187448: 360 doc issues in jdwp-protocol.html Message-ID: Please review a fix for the doc bug. The fix does the following: 1. Removes empty
        elements. 2. Adds an outer
          element to the index section . 3. Removes obsolete in HTML5 ?summary? attribute in
      elements. 4. Removes empty

      elements. 5. Replaces not supported in HTML5 ?bgcolor? attribute for element with ?style="background-color?? attribute. 6. Removes

      element in ConstantSetNode (there is no outer
      element in this case) 7. Adds required by accessibility audits ?lang? attribute for element. Testing: 1. Built the docs target and looked at the resulting jdwp-protocol.html. 2. Tested that is passes validation with tidy 3. Tested it passes accessibility audits with Accessibility Developer Tool (Chrome) Bug: https://bugs.openjdk.java.net/browse/JDK-8187448 Webrev: http://cr.openjdk.java.net/~dtitov/8187448/webrev.01 Thanks, Daniil From serguei.spitsyn at oracle.com Fri Dec 22 19:25:28 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 22 Dec 2017 11:25:28 -0800 Subject: RFR: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix In-Reply-To: <5A3D2945.6010505@oracle.com> References: <5A37D512.5070508@oracle.com> <4b96505e-95e9-2988-236b-55e15253bcf7@oracle.com> <23c19686-4ffa-9ddb-efee-e68b52ba071a@oracle.com> <3c50b1a1-82b8-dd09-47ed-7c00b3960b7c@oracle.com> <5A392997.5080701@oracle.com> <5A3C16F4.7020108@oracle.com> <5A3D2945.6010505@oracle.com> Message-ID: Gary, The fix looks good. Thank you for the update! On 12/22/17 07:48, Gary Adams wrote: > A refreshed webrev is available > ??? Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.03/ > > ?- "String socket_path" is now used where the original "path" variable > was used > ?- "File socket_file" is used for the exists() and getPath() calls > ?- left solaris openDoor optimizations out, because it is not really > related > ??? to the original reported issue > ?- left linux findSocketFile as a separate method, because it contains > ??? extra nspid cgroup aware logic. The original findSocketFile performed > ??? 2 steps to formulate the java_pid path name and to check existence. > ??? Now that it only formulates the path name, it seems reasonable to > fold the > ??? processing into the caller. There already was an asymmetry in the > platform > ??? specific implementations as solaris was using openDoor and the > open file > ??? descriptor for it's connected flag checks. I was suggesting to also keep findSocketFile for aix and macosx to keep it unified with linux. Now I see it does not have much sense as the findSocketFile becomes too trivial for aix and macosx. Thanks, Serguei > Bypassed the mach5 errors I was seeing by moving over to testing with > jdk/jdk repos. > > If this is acceptable, I'll create an hg export patch file for > my sponsor. > > On 12/21/17, 3:17 PM, Gary Adams wrote: >> A refreshed webrev is available >> ??? Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.02/ >> >> ? - added solaris version of the file which had the same original >> error reporting >> ???? the wrong socket file name >> ? - restored the linux detach/execute logic >> ? - updated the macosx and aix detach/execute logic >> ? - a few minor differences between the various platform specific files >> ???? curly braces and exception args. >> >> Ran into some issues with mach5 testing which will require another >> test run tomorrow. >> >> On 12/19/17, 10:00 AM, Gary Adams wrote: >>> A refreshed webrev is available >>> ??? Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.01/ >>> >>> On 12/18/17, 4:38 PM, Chris Plummer wrote: >>>> On 12/18/17 1:22 PM, gary.adams at oracle.com wrote: >>>>> On 12/18/17 2:26 PM, Chris Plummer wrote: >>>>>> Hi Gary, >>>>>> >>>>>> On 12/18/17 6:47 AM, Gary Adams wrote: >>>>>>> Here's a simple fix to correct the error message when the >>>>>>> java_pid socket >>>>>>> is not found. The code previously reported the attach_pid file name >>>>>>> rather than the socket file name that was not found. >>>>>>> >>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8188856 >>>>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.00/ >>>>>> >>>>>> I don't understand why you couldn't simply have changed the >>>>>> f.getPath() reference to "path". From what I can see, there is no >>>>>> difference between "path" and "socket_name". The problem you are >>>>>> fixing is that the error message prints f.getPath(), but that >>>>>> refers to the attach file and the error message should refer to >>>>>> the socket file. You've correct this, but have done so in a round >>>>>> about way. Above the error message (in two places) exists: >>>>>> >>>>>> ?????????? path = findSocketFile(pid, ns_pid); >>>>>> >>>>>> So "path" is what you want. You have indirectly fixed the problem >>>>>> by having findSocketFile() store the path in socket_name, and >>>>>> then you print socket_name, but why not just do the direct fix >>>>>> and print "path". >>>>>> >>>>>> Also, the copyrights need to be updated. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> >>>>> The problem was path is used to hold the constructed file name >>>>> if it is confirmed to exist in the file system. Otherwise it is >>>>> passed back from >>>>> findSocketFile as a null to indicate the socket file was not found. >>>>> >>>>> I could refactor where the existence check is handled, but it >>>>> seemed like the least >>>>> invasive change to simply save the socket name for the printing in >>>>> the error case. >>>>> >>>> Ah, right. Obviously "path" is null when you want to print the >>>> error message. I guess I? have a hard time with "path" and >>>> "socket_name" for the most part being the same (except "path" can >>>> end up being null), yet they have two completely dissimilar names. >>>> Why not rename path to socket_path and then add saved_socket_path, >>>> or something like that. No changes to your current logic, just to >>>> the names being used. >>>> >>>> Or, have findSocketFile() actually return the File, and then rename >>>> path to socket_file and also rename socket_name to socket_path. The >>>> truth of the matter is the result of findSocketFile() is only used >>>> to see if the socket file exists. You could even change it to >>>> return a boolean. >>>> >>>> Chris >>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Fri Dec 22 19:49:52 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 22 Dec 2017 11:49:52 -0800 Subject: DOC RFR: 8187448: 360 doc issues in jdwp-protocol.html In-Reply-To: References: Message-ID: <786a91cb-e8c6-3450-996d-c6dbc89e1659@oracle.com> Hi Daniil, The fix looks good to me. Thank you for taking care about this! Thanks, Serguei On 12/22/17 09:39, Daniil Titov wrote: > Please review a fix for the doc bug. > > The fix does the following: > 1. Removes empty
        elements. > 2. Adds an outer
          element to the index section . > 3. Removes obsolete in HTML5 ?summary? attribute in
      elements. > 4. Removes empty

      elements. > 5. Replaces not supported in HTML5 ?bgcolor? attribute for element with ?style="background-color?? attribute. > 6. Removes

      element in ConstantSetNode (there is no outer
      element in this case) > 7. Adds required by accessibility audits ?lang? attribute for element. > > Testing: > 1. Built the docs target and looked at the resulting jdwp-protocol.html. > 2. Tested that is passes validation with tidy > 3. Tested it passes accessibility audits with Accessibility Developer Tool (Chrome) > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187448 > Webrev: http://cr.openjdk.java.net/~dtitov/8187448/webrev.01 > > Thanks, > Daniil > > > > > > From david.holmes at oracle.com Fri Dec 22 21:06:08 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 23 Dec 2017 07:06:08 +1000 Subject: RFR: cleanup - removed unneeded casts in jdi In-Reply-To: <1ed37870-6d58-f250-d984-9c455c50e43e@jetbrains.com> References: <1ed37870-6d58-f250-d984-9c455c50e43e@jetbrains.com> Message-ID: <35b836c0-82a6-cb19-94be-3db580ee689e@oracle.com> Hi Egor, On 23/12/2017 1:32 AM, Egor Ushakov wrote: > Hi all, > > could you please review and sponsor this small cleanup removing unneeded > casts in jdi LocationImpl and MirrorImpl. > They were preventing creating custom Location and Mirror implementations > used for tests and IDEA debugger impl. > http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ src/jdk.jdi/share/classes/com/sun/tools/jdi/LocationImpl.java ! public int compareTo(Location object) { - LocationImpl other = (LocationImpl)object; The existing code is somewhat suspect as the Location interface implements Comparable but it does not specify what it means to compare two Locations! That's a bug in itself. LocationImpl has decided how to compare two LocaltionImp's (but doesn't even check they are in the same VirtualMachine!). Can we generalize that to accommodate other Location implementations? Your change allows for this to happen, but it will only work as expected if the other Location implementations use the same comparison basis as LocationImpl - which is unspecified. src/jdk.jdi/share/classes/com/sun/tools/jdi/MirrorImpl.java Change looks good. It would also seem that now this change is made that this: 37 protected VirtualMachineImpl vm; 38 39 MirrorImpl(VirtualMachine aVm) { 40 super(); 41 42 // Yes, its a bit of a hack. But by doing it this 43 // way, this is the only place we have to change 44 // typing to substitute a new impl. 45 vm = (VirtualMachineImpl)aVm; might reduce to: 37 protected VirtualMachine vm; 38 39 MirrorImpl(VirtualMachine aVm) { 40 super(); 41 vm = aVm; if we no longer depend on it being VirtualMachineImpl ... and neither do subclasses. David ----- > I do not have rights to create JDK bug report directly, please create it > if it is needed for the procedure. > > Thanks! > From serguei.spitsyn at oracle.com Sat Dec 23 08:04:57 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sat, 23 Dec 2017 00:04:57 -0800 Subject: RFR: cleanup - removed unneeded casts in jdi In-Reply-To: <35b836c0-82a6-cb19-94be-3db580ee689e@oracle.com> References: <1ed37870-6d58-f250-d984-9c455c50e43e@jetbrains.com> <35b836c0-82a6-cb19-94be-3db580ee689e@oracle.com> Message-ID: <498b5e77-6b48-7cc5-7964-35e4932ee925@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sat Dec 23 23:32:40 2017 From: david.holmes at oracle.com (David Holmes) Date: Sun, 24 Dec 2017 09:32:40 +1000 Subject: RFR: cleanup - removed unneeded casts in jdi In-Reply-To: <498b5e77-6b48-7cc5-7964-35e4932ee925@oracle.com> References: <1ed37870-6d58-f250-d984-9c455c50e43e@jetbrains.com> <35b836c0-82a6-cb19-94be-3db580ee689e@oracle.com> <498b5e77-6b48-7cc5-7964-35e4932ee925@oracle.com> Message-ID: Hi Serguei, On 23/12/2017 6:04 PM, serguei.spitsyn at oracle.com wrote: > Hi Egor and David, > > > Egor, > > The fix looks good in general. > I've filed bug: > https://bugs.openjdk.java.net/browse/JDK-8194143 > ??? remove unneeded casts in LocationImpl and MirrorImpl classes > > > On 12/22/17 13:06, David Holmes wrote: >> Hi Egor, >> >> On 23/12/2017 1:32 AM, Egor Ushakov wrote: >>> Hi all, >>> >>> could you please review and sponsor this small cleanup removing >>> unneeded casts in jdi LocationImpl and MirrorImpl. >>> They were preventing creating custom Location and Mirror >>> implementations used for tests and IDEA debugger impl. >>> http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ >> >> src/jdk.jdi/share/classes/com/sun/tools/jdi/LocationImpl.java >> >> !???? public int compareTo(Location object) { >> -??????? LocationImpl other = (LocationImpl)object; >> >> The existing code is somewhat suspect as the Location interface >> implements Comparable but it does not specify what it means to compare >> two Locations! That's a bug in itself. > > Not sure, if it is really needed as it is abstract. > We could say: An implementation of the Location is expected to specify it. That makes it impossible to compare different implementations of the Location interface. The functionality has to be specified by the interface. >> LocationImpl has decided how to compare two LocaltionImp's (but >> doesn't even check they are in the same VirtualMachine!). > > Nice catch! > Interesting... > Should comparing of locations from different mirrors be a no-op? > Not sure if it would be right to throw a VMMismatchException in such cases. Not sure - without knowing why we need to compare Locations it's hard to say. >> Can we generalize that to accommodate other Location >> implementations?Your change allows for this to happen, but it will >> only work as expected if the other Location implementations use the >> same comparison basis as LocationImpl - which is unspecified. > > It is not clear, what you mean here. > What are the other Location implementations? The ones that Egor is implementing and the reason for this bug report. > A JDI implementation normally has one base implementation of the Location. > What would be a need to have multiple? Egor indicated it was for use in testing and the IDEA debugger. It's apparent they have their own implementation of Location, but these instances have to interact with the default LocationImpl implementations - else this bug report would not be needed. Cheers, David > And different JDI implementations are not supposed to interact with each > other, are they? > > >> src/jdk.jdi/share/classes/com/sun/tools/jdi/MirrorImpl.java >> >> Change looks good. It would also seem that now this change is made >> that this: >> >> ? 37???? protected VirtualMachineImpl vm; >> ? 38 >> ? 39???? MirrorImpl(VirtualMachine aVm) { >> ? 40???????? super(); >> ? 41 >> ? 42???????? // Yes, its a bit of a hack. But by doing it this >> ? 43???????? // way, this is the only place we have to change >> ? 44???????? // typing to substitute a new impl. >> ? 45???????? vm = (VirtualMachineImpl)aVm; >> >> might reduce to: >> >> ? 37???? protected VirtualMachine vm; >> ? 38 >> ? 39???? MirrorImpl(VirtualMachine aVm) { >> ? 40???????? super(); >> ? 41???????? vm = aVm; >> >> if we no longer depend on it being VirtualMachineImpl ... and neither >> do subclasses. > > Good suggestion. > > > Thanks, > Serguei > >> >> David >> ----- >> >>> I do not have rights to create JDK bug report directly, please create >>> it if it is needed for the procedure. >>> >>> Thanks! >>> > From serguei.spitsyn at oracle.com Sun Dec 24 00:32:19 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sat, 23 Dec 2017 16:32:19 -0800 Subject: RFR: cleanup - removed unneeded casts in jdi In-Reply-To: References: <1ed37870-6d58-f250-d984-9c455c50e43e@jetbrains.com> <35b836c0-82a6-cb19-94be-3db580ee689e@oracle.com> <498b5e77-6b48-7cc5-7964-35e4932ee925@oracle.com> Message-ID: <24d79366-218e-6c4b-99a3-132469df3844@oracle.com> Hi David, Thank you for the explanations! I've got your points. On 12/23/17 15:32, David Holmes wrote: > Hi Serguei, > > On 23/12/2017 6:04 PM, serguei.spitsyn at oracle.com wrote: >> Hi Egor and David, >> >> >> Egor, >> >> The fix looks good in general. >> I've filed bug: >> https://bugs.openjdk.java.net/browse/JDK-8194143 >> ???? remove unneeded casts in LocationImpl and MirrorImpl classes >> >> >> On 12/22/17 13:06, David Holmes wrote: >>> Hi Egor, >>> >>> On 23/12/2017 1:32 AM, Egor Ushakov wrote: >>>> Hi all, >>>> >>>> could you please review and sponsor this small cleanup removing >>>> unneeded casts in jdi LocationImpl and MirrorImpl. >>>> They were preventing creating custom Location and Mirror >>>> implementations used for tests and IDEA debugger impl. >>>> http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ >>> >>> src/jdk.jdi/share/classes/com/sun/tools/jdi/LocationImpl.java >>> >>> !???? public int compareTo(Location object) { >>> -??????? LocationImpl other = (LocationImpl)object; >>> >>> The existing code is somewhat suspect as the Location interface >>> implements Comparable but it does not specify what it means to >>> compare two Locations! That's a bug in itself. >> >> Not sure, if it is really needed as it is abstract. >> We could say: An implementation of the Location is expected to >> specify it. > > That makes it impossible to compare different implementations of the > Location interface. The functionality has to be specified by the > interface. We probably never needed to compare them before. But such comparison can be needed for an IDE that has a deal with different JDI implementations. >>> LocationImpl has decided how to compare two LocaltionImp's (but >>> doesn't even check they are in the same VirtualMachine!). >> >> Nice catch! >> Interesting... >> Should comparing of locations from different mirrors be a no-op? >> Not sure if it would be right to throw a VMMismatchException in such >> cases. > > Not sure - without knowing why we need to compare Locations it's hard > to say. Ok. >>> Can we generalize that to accommodate other Location >>> implementations?Your change allows for this to happen, but it will >>> only work as expected if the other Location implementations use the >>> same comparison basis as LocationImpl - which is unspecified. >> >> It is not clear, what you mean here. >> What are the other Location implementations? > > The ones that Egor is implementing and the reason for this bug report. It is not clear to me why do they need their own Location implementation. >> A JDI implementation normally has one base implementation of the >> Location. >> What would be a need to have multiple? > > Egor indicated it was for use in testing and the IDEA debugger. It's > apparent they have their own implementation of Location, but these > instances have to interact with the default LocationImpl > implementations - else this bug report would not be needed. Will need to look at it more closely after NY. I'm going to vacation in a couple of hours until the Jan 3-rd. Will probably have a limited internet access there. I wish you, guys, happy Xmas and New Year and nice Holidays! Thanks, Serguei > > Cheers, > David > >> And different JDI implementations are not supposed to interact with >> each other, are they? >> >> >>> src/jdk.jdi/share/classes/com/sun/tools/jdi/MirrorImpl.java >>> >>> Change looks good. It would also seem that now this change is made >>> that this: >>> >>> ? 37???? protected VirtualMachineImpl vm; >>> ? 38 >>> ? 39???? MirrorImpl(VirtualMachine aVm) { >>> ? 40???????? super(); >>> ? 41 >>> ? 42???????? // Yes, its a bit of a hack. But by doing it this >>> ? 43???????? // way, this is the only place we have to change >>> ? 44???????? // typing to substitute a new impl. >>> ? 45???????? vm = (VirtualMachineImpl)aVm; >>> >>> might reduce to: >>> >>> ? 37???? protected VirtualMachine vm; >>> ? 38 >>> ? 39???? MirrorImpl(VirtualMachine aVm) { >>> ? 40???????? super(); >>> ? 41???????? vm = aVm; >>> >>> if we no longer depend on it being VirtualMachineImpl ... and >>> neither do subclasses. >> >> Good suggestion. >> >> >> Thanks, >> Serguei >> >>> >>> David >>> ----- >>> >>>> I do not have rights to create JDK bug report directly, please >>>> create it if it is needed for the procedure. >>>> >>>> Thanks! >>>> >> From egor.ushakov at jetbrains.com Mon Dec 25 11:29:55 2017 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Mon, 25 Dec 2017 14:29:55 +0300 Subject: RFR: cleanup - removed unneeded casts in jdi In-Reply-To: <24d79366-218e-6c4b-99a3-132469df3844@oracle.com> References: <1ed37870-6d58-f250-d984-9c455c50e43e@jetbrains.com> <35b836c0-82a6-cb19-94be-3db580ee689e@oracle.com> <498b5e77-6b48-7cc5-7964-35e4932ee925@oracle.com> <24d79366-218e-6c4b-99a3-132469df3844@oracle.com> Message-ID: <6f30371a-fbbd-54c7-714d-aa98e637a8e3@jetbrains.com> Thanks for your comments! I'll try to provide more details: We have our own Location implementaion in IDEA code: GeneratedLocation.java which is not intended to be used inside the jdi, but mostly to mock Location in our own APIs like PositionManager.java Unfortunately some implementations keep the provided Location objects (both LocationImpl and ours) in collections (maybe sorted) so we have to prevent cast exceptions from compareTo somehow. Hope it helps. Egor On 24-Dec-17 03:32, serguei.spitsyn at oracle.com wrote: > Hi David, > > Thank you for the explanations! > I've got your points. > > > On 12/23/17 15:32, David Holmes wrote: >> Hi Serguei, >> >> On 23/12/2017 6:04 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Egor and David, >>> >>> >>> Egor, >>> >>> The fix looks good in general. >>> I've filed bug: >>> https://bugs.openjdk.java.net/browse/JDK-8194143 >>> ???? remove unneeded casts in LocationImpl and MirrorImpl classes >>> >>> >>> On 12/22/17 13:06, David Holmes wrote: >>>> Hi Egor, >>>> >>>> On 23/12/2017 1:32 AM, Egor Ushakov wrote: >>>>> Hi all, >>>>> >>>>> could you please review and sponsor this small cleanup removing >>>>> unneeded casts in jdi LocationImpl and MirrorImpl. >>>>> They were preventing creating custom Location and Mirror >>>>> implementations used for tests and IDEA debugger impl. >>>>> http://cr.openjdk.java.net/~avu/egor.ushakov/cast_fix/ >>>> >>>> src/jdk.jdi/share/classes/com/sun/tools/jdi/LocationImpl.java >>>> >>>> !???? public int compareTo(Location object) { >>>> -??????? LocationImpl other = (LocationImpl)object; >>>> >>>> The existing code is somewhat suspect as the Location interface >>>> implements Comparable but it does not specify what it means to >>>> compare two Locations! That's a bug in itself. >>> >>> Not sure, if it is really needed as it is abstract. >>> We could say: An implementation of the Location is expected to >>> specify it. >> >> That makes it impossible to compare different implementations of the >> Location interface. The functionality has to be specified by the >> interface. > > We probably never needed to compare them before. > But such comparison can be needed for an IDE that has a deal with > different JDI implementations. > > >>>> LocationImpl has decided how to compare two LocaltionImp's (but >>>> doesn't even check they are in the same VirtualMachine!). >>> >>> Nice catch! >>> Interesting... >>> Should comparing of locations from different mirrors be a no-op? >>> Not sure if it would be right to throw a VMMismatchException in such >>> cases. >> >> Not sure - without knowing why we need to compare Locations it's hard >> to say. > > Ok. > > >>>> Can we generalize that to accommodate other Location >>>> implementations?Your change allows for this to happen, but it will >>>> only work as expected if the other Location implementations use the >>>> same comparison basis as LocationImpl - which is unspecified. >>> >>> It is not clear, what you mean here. >>> What are the other Location implementations? >> >> The ones that Egor is implementing and the reason for this bug report. > > It is not clear to me why do they need their own Location implementation. > > >>> A JDI implementation normally has one base implementation of the >>> Location. >>> What would be a need to have multiple? >> >> Egor indicated it was for use in testing and the IDEA debugger. It's >> apparent they have their own implementation of Location, but these >> instances have to interact with the default LocationImpl >> implementations - else this bug report would not be needed. > > Will need to look at it more closely after NY. > I'm going to vacation in a couple of hours until the Jan 3-rd. > Will probably have a limited internet access there. > > I wish you, guys, happy Xmas and New Year and nice Holidays! > > Thanks, > Serguei > > >> >> Cheers, >> David >> >>> And different JDI implementations are not supposed to interact with >>> each other, are they? >>> >>> >>>> src/jdk.jdi/share/classes/com/sun/tools/jdi/MirrorImpl.java >>>> >>>> Change looks good. It would also seem that now this change is made >>>> that this: >>>> >>>> ? 37???? protected VirtualMachineImpl vm; >>>> ? 38 >>>> ? 39???? MirrorImpl(VirtualMachine aVm) { >>>> ? 40???????? super(); >>>> ? 41 >>>> ? 42???????? // Yes, its a bit of a hack. But by doing it this >>>> ? 43???????? // way, this is the only place we have to change >>>> ? 44???????? // typing to substitute a new impl. >>>> ? 45???????? vm = (VirtualMachineImpl)aVm; >>>> >>>> might reduce to: >>>> >>>> ? 37???? protected VirtualMachine vm; >>>> ? 38 >>>> ? 39???? MirrorImpl(VirtualMachine aVm) { >>>> ? 40???????? super(); >>>> ? 41???????? vm = aVm; >>>> >>>> if we no longer depend on it being VirtualMachineImpl ... and >>>> neither do subclasses. >>> >>> Good suggestion. >>> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> David >>>> ----- >>>> >>>>> I do not have rights to create JDK bug report directly, please >>>>> create it if it is needed for the procedure. >>>>> >>>>> Thanks! >>>>> >>> > -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at skarsaune.net Tue Dec 26 20:14:24 2017 From: martin at skarsaune.net (Martin Skarsaune) Date: Tue, 26 Dec 2017 20:14:24 +0000 Subject: Question about DiagnosticCommand.jfrCheck Message-ID: Hi I have a question about plans for com.sun.management.DiagnosticCommand.jfrCheck : If I run this command in JRE 9+181 i get this output: "Java Flight Recorder not enabled. Use VM.unlock_commercial_features to enable." Will the output change in future versions when the flight recorder goes open source? Will it work differently in Oracle and OpenJDK JRE ? My background for asking this question: I do some work on flight recorder support in hawt.io and would like to give the user proper warning before attempting to unlock commercial features at runtime. Cheers! Martin Skarsaune -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Thu Dec 28 04:24:41 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Wed, 27 Dec 2017 20:24:41 -0800 (PST) Subject: RFR: JDK-8193506 - serviceability/sa/TestClassDump.java fails in OpenJDK build Message-ID: Hello, Requesting reviews for: JBS Id: https://bugs.openjdk.java.net/browse/JDK-8193506 Webrev: http://cr.openjdk.java.net/~sballal/8193506/webrev.00/ I tested the changes in an open only workspace. Also the test ran successfully in JPRT and Mach5. Thanks, Sharath -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Thu Dec 28 05:09:21 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Wed, 27 Dec 2017 21:09:21 -0800 (PST) Subject: RFR: JDK-8194058 - [TESTBUG] serviceability/sa/ClhsdbWhere.java fails to find method 'sleep' in output In-Reply-To: <25f0e0eb-fa15-430e-a2a4-c293cf441f94@default> References: <25f0e0eb-fa15-430e-a2a4-c293cf441f94@default> Message-ID: <60cbf7cd-31f3-4d21-b357-c9d33488ec30@default> (Resending as I got a failure notice) Hello, Requesting reviews for: JBS Id: https://bugs.openjdk.java.net/browse/JDK-8194058 Webrev: http://cr.openjdk.java.net/~sballal/8194058/webrev.00/ Test ran successfully in JPRT and Mach5. Thanks, Sharath -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Thu Dec 28 05:29:54 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Wed, 27 Dec 2017 21:29:54 -0800 (PST) Subject: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* tests can't tolerate unrelated warnings Message-ID: <4648c2c0-15eb-4e03-827f-043b499d8eb4@default> Hello, Requesting reviews for: JBS Id: https://bugs.openjdk.java.net/browse/JDK-8194067 Webrev: http://cr.openjdk.java.net/~sballal/8194067/webrev.00/ The tests ran successfully in JPRT and Mach5. Thanks, Sharath -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.gahlin at oracle.com Thu Dec 28 12:27:42 2017 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 28 Dec 2017 13:27:42 +0100 Subject: Question about DiagnosticCommand.jfrCheck In-Reply-To: References: Message-ID: <5A44E33E.8030506@oracle.com> Hi Martin, There will be a JEP outlining how things will work in OpenJDK. When it comes to Oracle JDK, it is too early to say and should not be discussed on this mailing list, but feel free to mail me when there is a JEP. Cheers! Erik > Hi > > I have a question about plans for > com.sun.management.DiagnosticCommand.jfrCheck : > > If I run this command in JRE 9+181 i get this output: > > "Java Flight Recorder not enabled. > > Use VM.unlock_commercial_features to enable." > > Will the output change in future versions when the flight recorder > goes open source? > Will it work differently in Oracle and OpenJDK JRE ? > > My background for asking this question: I do some work on flight > recorder support in hawt.io and would like to give > the user proper warning before attempting to unlock commercial > features at runtime. > > Cheers! > > Martin Skarsaune -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Dec 29 00:37:30 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 29 Dec 2017 10:37:30 +1000 Subject: RFR: JDK-8193506 - serviceability/sa/TestClassDump.java fails in OpenJDK build In-Reply-To: References: Message-ID: Looks good. Thanks, David On 28/12/2017 2:24 PM, Sharath Ballal wrote: > Hello, > > Requesting reviews for: > > JBS Id: https://bugs.openjdk.java.net/browse/JDK-8193506 > > Webrev: http://cr.openjdk.java.net/~sballal/8193506/webrev.00/ > > I tested the changes in an open only workspace.? Also the test ran > successfully in JPRT and Mach5. > > Thanks, > > Sharath > From david.holmes at oracle.com Fri Dec 29 00:39:38 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 29 Dec 2017 10:39:38 +1000 Subject: RFR: JDK-8194058 - [TESTBUG] serviceability/sa/ClhsdbWhere.java fails to find method 'sleep' in output In-Reply-To: <60cbf7cd-31f3-4d21-b357-c9d33488ec30@default> References: <25f0e0eb-fa15-430e-a2a4-c293cf441f94@default> <60cbf7cd-31f3-4d21-b357-c9d33488ec30@default> Message-ID: <17f1071d-9110-e559-4aad-986f85364f9e@oracle.com> Seems reasonable. Thanks, David On 28/12/2017 3:09 PM, Sharath Ballal wrote: > (Resending as I got a failure notice) > > Hello, > > Requesting reviews for: > > JBS Id: https://bugs.openjdk.java.net/browse/JDK-8194058 > > Webrev: http://cr.openjdk.java.net/~sballal/8194058/webrev.00/ > > Test ran successfully in JPRT and Mach5. > > Thanks, > > Sharath > From david.holmes at oracle.com Fri Dec 29 00:43:04 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 29 Dec 2017 10:43:04 +1000 Subject: RFR: JDK-8194067 - [Testbug] serviceability/sa/Jhsdb* tests can't tolerate unrelated warnings In-Reply-To: <4648c2c0-15eb-4e03-827f-043b499d8eb4@default> References: <4648c2c0-15eb-4e03-827f-043b499d8eb4@default> Message-ID: <6ca5da1a-9339-29e0-f4b6-7ab72bc0b391@oracle.com> When I reported this one I thought about how to best fix it. What you propose is a simple fix, but may potentially allow other errors to go unnoticed. I was wondering whether there was a simple way to filter the stderr content to exclude VM Warnings, but still check for other unexpected content? Thanks, David On 28/12/2017 3:29 PM, Sharath Ballal wrote: > Hello, > > Requesting reviews for: > > JBS Id: https://bugs.openjdk.java.net/browse/JDK-8194067 > > Webrev: http://cr.openjdk.java.net/~sballal/8194067/webrev.00/ > > The tests ran successfully in JPRT and Mach5. > > Thanks, > > Sharath > From yasuenag at gmail.com Fri Dec 29 13:16:00 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 29 Dec 2017 22:16:00 +0900 Subject: RFR: 8194249: SA: G1HeapRegionTable#getByAddress() returns incorrect HeapRegion Message-ID: <323f09cf-a036-42b7-990c-0e42ad511a8f@gmail.com> Hi all, G1HeapRegionTable#getByAddress() returns incorrect HeapRegion which contains incorrect address. We can see it in Stack Memory window on HSDB. Some oop addresses are shown as Free Region (attached image). G1HeapRegion#getByAddress() should create HeapRegion instance from the address in _biased_base array. I uploaded webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.00/ I've tested this change with test/hotspot/jtreg/serviceability/sa, it works fine. But I received some failure from Mach 5. I also tested this change via submit repos. http://java.se.oracle.com:10065/mdash/jobs/mach5-one-ysuenaga-JDK-8194249-20171228-0605-8272 I cannot access this URL. Could you share the result? Also I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa From david.holmes at oracle.com Sat Dec 30 01:31:57 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 30 Dec 2017 11:31:57 +1000 Subject: RFR: 8194249: SA: G1HeapRegionTable#getByAddress() returns incorrect HeapRegion In-Reply-To: <323f09cf-a036-42b7-990c-0e42ad511a8f@gmail.com> References: <323f09cf-a036-42b7-990c-0e42ad511a8f@gmail.com> Message-ID: <3be47bde-46c1-3ad2-7521-5eecceea5dee@oracle.com> Hi Yasumasa, Not a review ... On 29/12/2017 11:16 PM, Yasumasa Suenaga wrote: > Hi all, > > G1HeapRegionTable#getByAddress() returns incorrect HeapRegion which > contains incorrect address. We can see it in Stack Memory window on > HSDB. Some oop addresses are shown as Free Region (attached image). > > G1HeapRegion#getByAddress() should create HeapRegion instance from the > address in _biased_base array. > > I uploaded webrev. Could you review it? > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.00/ > > I've tested this change with test/hotspot/jtreg/serviceability/sa, it > works fine. > But I received some failure from Mach 5. I also tested this change via > submit repos. > > > http://java.se.oracle.com:10065/mdash/jobs/mach5-one-ysuenaga-JDK-8194249-20171228-0605-8272 > > > I cannot access this URL. Could you share the result? How did you submit to mach5 ??? Anyway the failure is with: test/hotspot/jtreg/serviceability/sa/TestG1HeapRegion.java On linux and OS X: stderr: [Exception in thread "main" java.lang.NullPointerException at TestG1HeapRegion$G1HeapRegionTestClosure.doSpace(TestG1HeapRegion.java:70) at jdk.hotspot.agent/sun.jvm.hotspot.gc.g1.G1CollectedHeap.heapRegionIterate(G1CollectedHeap.java:121) at TestG1HeapRegion.scanHeapRegion(TestG1HeapRegion.java:81) at TestG1HeapRegion.main(TestG1HeapRegion.java:129) On Solaris sparcv9: stderr: [Exception in thread "main" java.lang.RuntimeException: Address of HeapRegion does not match.: expected 0x00000007afb00000 to equal 0x00000007afc00000 at jdk.test.lib.Asserts.fail(Asserts.java:594) at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) at TestG1HeapRegion$G1HeapRegionTestClosure.doSpace(TestG1HeapRegion.java:70) at jdk.hotspot.agent/sun.jvm.hotspot.gc.g1.G1CollectedHeap.heapRegionIterate(G1CollectedHeap.java:121) at TestG1HeapRegion.scanHeapRegion(TestG1HeapRegion.java:81) at TestG1HeapRegion.main(TestG1HeapRegion.java:129) ] David ----- > Also I cannot access JPRT. So I need a sponsor. > > > Thanks, > > Yasumasa From yasuenag at gmail.com Sun Dec 31 04:33:03 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 31 Dec 2017 13:33:03 +0900 Subject: RFR: 8194249: SA: G1HeapRegionTable#getByAddress() returns incorrect HeapRegion In-Reply-To: <3be47bde-46c1-3ad2-7521-5eecceea5dee@oracle.com> References: <323f09cf-a036-42b7-990c-0e42ad511a8f@gmail.com> <3be47bde-46c1-3ad2-7521-5eecceea5dee@oracle.com> Message-ID: <7332f28e-fe93-56c2-ce44-bff374b83728@gmail.com> Hi David, > How did you submit to mach5 ??? I'm using Submit Repo for testing: https://wiki.openjdk.java.net/display/Build/Submit+Repo > Anyway the failure is with: Thanks! I've fixed them in new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.01/ This webrev has passed Mach 5 tier 1 tests in Submit Repo: http://java.se.oracle.com:10065/mdash/jobs/mach5-one-ysuenaga-JDK-8194249-20171231-0202-8291 Yasumasa On 2017/12/30 10:31, David Holmes wrote: > Hi Yasumasa, > > Not a review ... > > On 29/12/2017 11:16 PM, Yasumasa Suenaga wrote: >> Hi all, >> >> G1HeapRegionTable#getByAddress() returns incorrect HeapRegion which contains incorrect address. We can see it in Stack Memory window on HSDB. Some oop addresses are shown as Free Region (attached image). >> >> G1HeapRegion#getByAddress() should create HeapRegion instance from the address in _biased_base array. >> >> I uploaded webrev. Could you review it? >> >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.00/ >> >> I've tested this change with test/hotspot/jtreg/serviceability/sa, it works fine. >> But I received some failure from Mach 5. I also tested this change via submit repos. >> >> http://java.se.oracle.com:10065/mdash/jobs/mach5-one-ysuenaga-JDK-8194249-20171228-0605-8272 >> >> I cannot access this URL. Could you share the result? > > How did you submit to mach5 ??? > > Anyway the failure is with: > > test/hotspot/jtreg/serviceability/sa/TestG1HeapRegion.java > > On linux and OS X: > > ?stderr: [Exception in thread "main" java.lang.NullPointerException > ????at TestG1HeapRegion$G1HeapRegionTestClosure.doSpace(TestG1HeapRegion.java:70) > ????at jdk.hotspot.agent/sun.jvm.hotspot.gc.g1.G1CollectedHeap.heapRegionIterate(G1CollectedHeap.java:121) > ????at TestG1HeapRegion.scanHeapRegion(TestG1HeapRegion.java:81) > ????at TestG1HeapRegion.main(TestG1HeapRegion.java:129) > > On Solaris sparcv9: > > ?stderr: [Exception in thread "main" java.lang.RuntimeException: Address of HeapRegion does not match.: expected 0x00000007afb00000 to equal 0x00000007afc00000 > ????at jdk.test.lib.Asserts.fail(Asserts.java:594) > ????at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) > ????at TestG1HeapRegion$G1HeapRegionTestClosure.doSpace(TestG1HeapRegion.java:70) > ????at jdk.hotspot.agent/sun.jvm.hotspot.gc.g1.G1CollectedHeap.heapRegionIterate(G1CollectedHeap.java:121) > ????at TestG1HeapRegion.scanHeapRegion(TestG1HeapRegion.java:81) > ????at TestG1HeapRegion.main(TestG1HeapRegion.java:129) > ] > > David > ----- > >> Also I cannot access JPRT. So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa