From david.holmes at oracle.com Tue Jan 3 00:09:34 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 3 Jan 2017 10:09:34 +1000 Subject: RFR(XXS): 8171960: Event-based tracing needs separate flag representation for Method In-Reply-To: <00b431e9-7b1d-4885-8248-23fe504f7966@default> References: <00b431e9-7b1d-4885-8248-23fe504f7966@default> Message-ID: <23bc088d-01e0-bbe2-407a-991ffa3d6bfa@oracle.com> Hi Markus, On 23/12/2016 9:29 PM, Markus Gronlund wrote: > Greetings, > > Kindly asking for reviews for the following fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171960 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8171960/webrev01/ > > Summary: > > In order to fix a closed confidential bug, I would need to separate the > flag representation that is currently being used by the Event-based > tracing framework for Method. > > The separate flag representation will be non-existent by default; it > will only materialize under the conjunction (INCLUDE_TRACE AND > implementation available). > > The existing bit will be removed from the Flags enum with the associated > accessors. This looks good to me. It is nice to the the jfr specific logic no longer evident in the open code. Thanks, David ----- > > > Thank you > > Markus > > > > > > > > > From yasuenag at gmail.com Tue Jan 3 02:18:54 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 3 Jan 2017 11:18:54 +0900 Subject: Add new CLHSDB command to print all methods in CodeCache Message-ID: Hi all, I want to check what methods have been compiled in memory dump. I know we can use dumpcodecache command in CLHSDB, but it is too long fot it because dumpcodecache prints contents (assembly code). I want to add a command to CLHSDB to print all method name and signature in CodeCache as below. Is it accepted? If so, I will file it to JBS and will upload webrev. ------------------------------------------- diff -r 8d23544aa002 src/jdk.hotspot.agent/doc/clhsdb.html --- a/src/jdk.hotspot.agent/doc/clhsdb.html Mon Jan 02 00:26:40 2017 -0800 +++ b/src/jdk.hotspot.agent/doc/clhsdb.html Tue Jan 03 11:16:46 2017 +0900 @@ -46,6 +46,7 @@ dumpcfg -a | id Dump the PhaseCFG for every compiler thread that has one live dumpclass { address | name } [ directory ] dump .class file for given Klass* or class name dumpcodecache dump codecache contents + listcodecache list methods in codecache dumpheap [ file ] dump heap in hprof binary format dumpideal -a | id dump ideal graph like debug flag -XX:+PrintIdeal dumpilt -a | id dump inline tree for C2 compilation diff -r 8d23544aa002 src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java Mon Jan 02 00:26:40 2017 -0800 +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java Tue Jan 03 11:16:46 2017 +0900 @@ -1559,6 +1559,24 @@ } } }, + new Command("listcodecache", "listcodecache", false) { + public void doit(Tokens t) { + if (t.countTokens() != 0) { + usage(); + } else { + CodeCacheVisitor v = new CodeCacheVisitor() { + public void prologue(Address start, Address end) { + } + public void visit(CodeBlob blob) { + blob.printOn(out); + } + public void epilogue() { + } + }; + VM.getVM().getCodeCache().iterate(v); + } + } + }, new Command("where", "where { -a | id }", false) { public void doit(Tokens t) { if (t.countTokens() != 1) { ------------------------------------------- Thanks, Yasumasa From yasuenag at gmail.com Tue Jan 3 02:33:07 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 3 Jan 2017 11:33:07 +0900 Subject: JEP 158 support for JIT Message-ID: Hi all, Java 9 has JEP 158: Unified JVM Logging. This JEP describes that existing 'tty->print...' logging should use unified logging as output. However, C2 compiler does not seem to use it. Do you have any plan to use JEP 158 in JIT codes? I uploaded Unified JVM logging viewer to GitHub [1]. I want to draw chart(s) or list all JIT'ed methods on it if possible. (Especially I want to get log from PrintCompilation and PrintIntrinsics through Unified JVM logging) Thanks, Yasumasa [1] https://github.com/YaSuenag/ulviewer From vladimir.kozlov at oracle.com Tue Jan 3 03:00:26 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 2 Jan 2017 19:00:26 -0800 Subject: JEP 158 support for JIT In-Reply-To: References: Message-ID: On 1/2/17 6:33 PM, Yasumasa Suenaga wrote: > Hi all, > > Java 9 has JEP 158: Unified JVM Logging. > This JEP describes that existing 'tty->print...' logging should use unified logging as output. However, C2 compiler does > not seem to use it. > > Do you have any plan to use JEP 158 in JIT codes? Definitely not in JDK 9. And I can't say when it could be done or done at all. Regards, Vladimir > > I uploaded Unified JVM logging viewer to GitHub [1]. > I want to draw chart(s) or list all JIT'ed methods on it if possible. > (Especially I want to get log from PrintCompilation and PrintIntrinsics through Unified JVM logging) > > > Thanks, > > Yasumasa > > > [1] https://github.com/YaSuenag/ulviewer > From yasuenag at gmail.com Tue Jan 3 04:08:34 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 3 Jan 2017 13:08:34 +0900 Subject: JEP 158 support for JIT In-Reply-To: References: Message-ID: <81baa810-18c2-147b-d83c-aec44fb9dbe7@gmail.com> Thanks Vladimir, > Definitely not in JDK 9. And I can't say when it could be done or done at all. I hope this feature will be implemented ASAP. Yasumasa On 2017/01/03 12:00, Vladimir Kozlov wrote: > On 1/2/17 6:33 PM, Yasumasa Suenaga wrote: >> Hi all, >> >> Java 9 has JEP 158: Unified JVM Logging. >> This JEP describes that existing 'tty->print...' logging should use unified logging as output. However, C2 compiler does >> not seem to use it. >> >> Do you have any plan to use JEP 158 in JIT codes? > > Definitely not in JDK 9. And I can't say when it could be done or done at all. > > Regards, > Vladimir > >> >> I uploaded Unified JVM logging viewer to GitHub [1]. >> I want to draw chart(s) or list all JIT'ed methods on it if possible. >> (Especially I want to get log from PrintCompilation and PrintIntrinsics through Unified JVM logging) >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] https://github.com/YaSuenag/ulviewer >> From vladimir.kozlov at oracle.com Tue Jan 3 23:06:17 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 3 Jan 2017 15:06:17 -0800 Subject: JEP 158 support for JIT In-Reply-To: <5E127666-A112-4C34-BC7B-25E2D0134027@twitter.com> References: <81baa810-18c2-147b-d83c-aec44fb9dbe7@gmail.com> <5E127666-A112-4C34-BC7B-25E2D0134027@twitter.com> Message-ID: <586C2E69.9010603@oracle.com> Contributions are always welcome! :) But for JDK 9 we already passed Features freeze dates. Thanks, Vladimir On 1/3/17 3:01 PM, Christian Thalinger wrote: > >> On Jan 2, 2017, at 6:08 PM, Yasumasa Suenaga wrote: >> >> Thanks Vladimir, >> >>> Definitely not in JDK 9. And I can't say when it could be done or done at all. >> >> I hope this feature will be implemented ASAP. > > You can always contribute an implementation. Shouldn?t be too difficult. > >> >> >> Yasumasa >> >> >> On 2017/01/03 12:00, Vladimir Kozlov wrote: >>> On 1/2/17 6:33 PM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Java 9 has JEP 158: Unified JVM Logging. >>>> This JEP describes that existing 'tty->print...' logging should use unified logging as output. However, C2 compiler does >>>> not seem to use it. >>>> >>>> Do you have any plan to use JEP 158 in JIT codes? >>> >>> Definitely not in JDK 9. And I can't say when it could be done or done at all. >>> >>> Regards, >>> Vladimir >>> >>>> >>>> I uploaded Unified JVM logging viewer to GitHub [1]. >>>> I want to draw chart(s) or list all JIT'ed methods on it if possible. >>>> (Especially I want to get log from PrintCompilation and PrintIntrinsics through Unified JVM logging) >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] https://github.com/YaSuenag/ulviewer >>>> > From cthalinger at twitter.com Tue Jan 3 23:01:31 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Tue, 3 Jan 2017 13:01:31 -1000 Subject: JEP 158 support for JIT In-Reply-To: <81baa810-18c2-147b-d83c-aec44fb9dbe7@gmail.com> References: <81baa810-18c2-147b-d83c-aec44fb9dbe7@gmail.com> Message-ID: <5E127666-A112-4C34-BC7B-25E2D0134027@twitter.com> > On Jan 2, 2017, at 6:08 PM, Yasumasa Suenaga wrote: > > Thanks Vladimir, > >> Definitely not in JDK 9. And I can't say when it could be done or done at all. > > I hope this feature will be implemented ASAP. You can always contribute an implementation. Shouldn?t be too difficult. > > > Yasumasa > > > On 2017/01/03 12:00, Vladimir Kozlov wrote: >> On 1/2/17 6:33 PM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Java 9 has JEP 158: Unified JVM Logging. >>> This JEP describes that existing 'tty->print...' logging should use unified logging as output. However, C2 compiler does >>> not seem to use it. >>> >>> Do you have any plan to use JEP 158 in JIT codes? >> >> Definitely not in JDK 9. And I can't say when it could be done or done at all. >> >> Regards, >> Vladimir >> >>> >>> I uploaded Unified JVM logging viewer to GitHub [1]. >>> I want to draw chart(s) or list all JIT'ed methods on it if possible. >>> (Especially I want to get log from PrintCompilation and PrintIntrinsics through Unified JVM logging) >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] https://github.com/YaSuenag/ulviewer >>> From cnewland at chrisnewland.com Wed Jan 4 08:02:21 2017 From: cnewland at chrisnewland.com (Chris Newland) Date: Wed, 4 Jan 2017 08:02:21 -0000 Subject: JEP 158 support for JIT Message-ID: <3c81618463bd4b70e5a04e840ac3a8db.squirrel@excalibur.xssl.net> Hi Yasumasa-san, all, I'm also very interested in changes to JIT logging (I'm the author of the JITWatch tool [1] for visualising JIT-compiler decisions). JITWatch consumes the LogCompilation (XML) output which contains more detail (escape analysis etc.) and better contextualisation (inlining chains etc.) than the tty-based Print* outputs. I had a brief discussion on how LogCompilation/UL would interact back in Sep 2015: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-September/019788.html and John Rose left this comment on the JEP https://bugs.openjdk.java.net/browse/JDK-8046148#comment-13568278 but as far as I can tell there is no plan to migrate LogCompilation to UL yet. Kind regards, Chris [1] https://github.com/AdoptOpenJDK/jitwatch On Tue, January 3, 2017 04:08, Yasumasa Suenaga wrote: > Thanks Vladimir, > > >> Definitely not in JDK 9. And I can't say when it could be done or done >> at all. > > I hope this feature will be implemented ASAP. > > > > Yasumasa > > > > On 2017/01/03 12:00, Vladimir Kozlov wrote: > >> On 1/2/17 6:33 PM, Yasumasa Suenaga wrote: >> >>> Hi all, >>> >>> >>> Java 9 has JEP 158: Unified JVM Logging. >>> This JEP describes that existing 'tty->print...' logging should use >>> unified logging as output. However, C2 compiler does not seem to use >>> it. >>> >>> Do you have any plan to use JEP 158 in JIT codes? >>> >> >> Definitely not in JDK 9. And I can't say when it could be done or done >> at all. >> >> Regards, >> Vladimir >> >> >>> >>> I uploaded Unified JVM logging viewer to GitHub [1]. >>> I want to draw chart(s) or list all JIT'ed methods on it if possible. >>> (Especially I want to get log from PrintCompilation and >>> PrintIntrinsics through Unified JVM logging) >>> >>> >>> >>> Thanks, >>> >>> >>> Yasumasa >>> >>> >>> >>> [1] https://github.com/YaSuenag/ulviewer >>> >>> > From yasuenag at gmail.com Wed Jan 4 12:21:15 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 4 Jan 2017 21:21:15 +0900 Subject: JEP 158 support for JIT In-Reply-To: <586C2E69.9010603@oracle.com> References: <81baa810-18c2-147b-d83c-aec44fb9dbe7@gmail.com> <5E127666-A112-4C34-BC7B-25E2D0134027@twitter.com> <586C2E69.9010603@oracle.com> Message-ID: <463a97a2-3588-413a-b595-c9a56765a428@gmail.com> Hi, > Contributions are always welcome! :) I uploaded patches for using UL. I want to get JIT logs as below: Compilation logging: http://cr.openjdk.java.net/~ysuenaga/ul-jit/compilation/ CodeCache flushing logging: http://cr.openjdk.java.net/~ysuenaga/ul-jit/codecache/ > But for JDK 9 we already passed Features freeze dates. Should I file them to JBS and send webrev after jdk10 repos is opened? Thanks, Yasumasa On 2017/01/04 8:06, Vladimir Kozlov wrote: > Contributions are always welcome! :) > > But for JDK 9 we already passed Features freeze dates. > > Thanks, > Vladimir > > On 1/3/17 3:01 PM, Christian Thalinger wrote: >> >>> On Jan 2, 2017, at 6:08 PM, Yasumasa Suenaga wrote: >>> >>> Thanks Vladimir, >>> >>>> Definitely not in JDK 9. And I can't say when it could be done or done at all. >>> >>> I hope this feature will be implemented ASAP. >> >> You can always contribute an implementation. Shouldn?t be too difficult. >> >>> >>> >>> Yasumasa >>> >>> >>> On 2017/01/03 12:00, Vladimir Kozlov wrote: >>>> On 1/2/17 6:33 PM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Java 9 has JEP 158: Unified JVM Logging. >>>>> This JEP describes that existing 'tty->print...' logging should use unified logging as output. However, C2 compiler does >>>>> not seem to use it. >>>>> >>>>> Do you have any plan to use JEP 158 in JIT codes? >>>> >>>> Definitely not in JDK 9. And I can't say when it could be done or done at all. >>>> >>>> Regards, >>>> Vladimir >>>> >>>>> >>>>> I uploaded Unified JVM logging viewer to GitHub [1]. >>>>> I want to draw chart(s) or list all JIT'ed methods on it if possible. >>>>> (Especially I want to get log from PrintCompilation and PrintIntrinsics through Unified JVM logging) >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] https://github.com/YaSuenag/ulviewer >>>>> >> From yasuenag at gmail.com Wed Jan 4 12:25:20 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 4 Jan 2017 21:25:20 +0900 Subject: JEP 158 support for JIT In-Reply-To: <3c81618463bd4b70e5a04e840ac3a8db.squirrel@excalibur.xssl.net> References: <3c81618463bd4b70e5a04e840ac3a8db.squirrel@excalibur.xssl.net> Message-ID: <51bbc652-0fdb-dc5c-011f-2fcc99baf9bd@gmail.com> Hi Chris, Thank you for your information. IMHO, LogCompilation is too difficult to migrate to UL. So I think we should implement basic (?) JIT logs at first. I uploaded patches for using UL. Please see them. http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-January/025267.html Thanks, Yasumasa On 2017/01/04 17:02, Chris Newland wrote: > Hi Yasumasa-san, all, > > I'm also very interested in changes to JIT logging (I'm the author of the > JITWatch tool [1] for visualising JIT-compiler decisions). > > JITWatch consumes the LogCompilation (XML) output which contains more > detail (escape analysis etc.) and better contextualisation (inlining > chains etc.) than the tty-based Print* outputs. > > I had a brief discussion on how LogCompilation/UL would interact back in > Sep 2015: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-September/019788.html > and John Rose left this comment on the JEP > https://bugs.openjdk.java.net/browse/JDK-8046148#comment-13568278 but as > far as I can tell there is no plan to migrate LogCompilation to UL yet. > > Kind regards, > > Chris > > [1] https://github.com/AdoptOpenJDK/jitwatch > > On Tue, January 3, 2017 04:08, Yasumasa Suenaga wrote: >> Thanks Vladimir, >> >> >>> Definitely not in JDK 9. And I can't say when it could be done or done >>> at all. >> >> I hope this feature will be implemented ASAP. >> >> >> >> Yasumasa >> >> >> >> On 2017/01/03 12:00, Vladimir Kozlov wrote: >> >>> On 1/2/17 6:33 PM, Yasumasa Suenaga wrote: >>> >>>> Hi all, >>>> >>>> >>>> Java 9 has JEP 158: Unified JVM Logging. >>>> This JEP describes that existing 'tty->print...' logging should use >>>> unified logging as output. However, C2 compiler does not seem to use >>>> it. >>>> >>>> Do you have any plan to use JEP 158 in JIT codes? >>>> >>> >>> Definitely not in JDK 9. And I can't say when it could be done or done >>> at all. >>> >>> Regards, >>> Vladimir >>> >>> >>>> >>>> I uploaded Unified JVM logging viewer to GitHub [1]. >>>> I want to draw chart(s) or list all JIT'ed methods on it if possible. >>>> (Especially I want to get log from PrintCompilation and >>>> PrintIntrinsics through Unified JVM logging) >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> >>>> [1] https://github.com/YaSuenag/ulviewer >>>> >>>> >> > > From vladimir.kozlov at oracle.com Wed Jan 4 18:47:22 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 4 Jan 2017 10:47:22 -0800 Subject: JEP 158 support for JIT In-Reply-To: <463a97a2-3588-413a-b595-c9a56765a428@gmail.com> References: <81baa810-18c2-147b-d83c-aec44fb9dbe7@gmail.com> <5E127666-A112-4C34-BC7B-25E2D0134027@twitter.com> <586C2E69.9010603@oracle.com> <463a97a2-3588-413a-b595-c9a56765a428@gmail.com> Message-ID: <4cbc07f4-3d74-98ca-2369-71852909dfac@oracle.com> Thank you, Yasumasa Yes, please, file "Enchantment" in JBS for hotspot/compiler category and set "Fix version" 10. We can review it now - no need to wait when jdk 10 is opened (should be soon). On 1/4/17 4:21 AM, Yasumasa Suenaga wrote: > Hi, > >> Contributions are always welcome! :) > > I uploaded patches for using UL. > I want to get JIT logs as below: > > Compilation logging: http://cr.openjdk.java.net/~ysuenaga/ul-jit/compilation/ In all places you have unified logging followed by the same normal out may be you should factor out into separate method which does both outputs instead of having almost duplicated code all over places. > CodeCache flushing logging: http://cr.openjdk.java.net/~ysuenaga/ul-jit/codecache/ codeCache.cpp - may be use const char* locals for messages instead of duplicating them. Thanks, Vladimir > > >> But for JDK 9 we already passed Features freeze dates. > > Should I file them to JBS and send webrev after jdk10 repos is opened? > > > Thanks, > > Yasumasa > > > On 2017/01/04 8:06, Vladimir Kozlov wrote: >> Contributions are always welcome! :) >> >> But for JDK 9 we already passed Features freeze dates. >> >> Thanks, >> Vladimir >> >> On 1/3/17 3:01 PM, Christian Thalinger wrote: >>> >>>> On Jan 2, 2017, at 6:08 PM, Yasumasa Suenaga wrote: >>>> >>>> Thanks Vladimir, >>>> >>>>> Definitely not in JDK 9. And I can't say when it could be done or done at all. >>>> >>>> I hope this feature will be implemented ASAP. >>> >>> You can always contribute an implementation. Shouldn?t be too difficult. >>> >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> On 2017/01/03 12:00, Vladimir Kozlov wrote: >>>>> On 1/2/17 6:33 PM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> Java 9 has JEP 158: Unified JVM Logging. >>>>>> This JEP describes that existing 'tty->print...' logging should use unified logging as output. However, C2 >>>>>> compiler does >>>>>> not seem to use it. >>>>>> >>>>>> Do you have any plan to use JEP 158 in JIT codes? >>>>> >>>>> Definitely not in JDK 9. And I can't say when it could be done or done at all. >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>>> >>>>>> I uploaded Unified JVM logging viewer to GitHub [1]. >>>>>> I want to draw chart(s) or list all JIT'ed methods on it if possible. >>>>>> (Especially I want to get log from PrintCompilation and PrintIntrinsics through Unified JVM logging) >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] https://github.com/YaSuenag/ulviewer >>>>>> >>> From cthalinger at twitter.com Wed Jan 4 20:18:44 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 4 Jan 2017 10:18:44 -1000 Subject: JEP 158 support for JIT In-Reply-To: <4cbc07f4-3d74-98ca-2369-71852909dfac@oracle.com> References: <81baa810-18c2-147b-d83c-aec44fb9dbe7@gmail.com> <5E127666-A112-4C34-BC7B-25E2D0134027@twitter.com> <586C2E69.9010603@oracle.com> <463a97a2-3588-413a-b595-c9a56765a428@gmail.com> <4cbc07f4-3d74-98ca-2369-71852909dfac@oracle.com> Message-ID: > On Jan 4, 2017, at 8:47 AM, Vladimir Kozlov wrote: > > Thank you, Yasumasa > > Yes, please, file ?Enchantment" Funny Freudian autocorrect :-) > in JBS for hotspot/compiler category and set "Fix version" 10. > We can review it now - no need to wait when jdk 10 is opened (should be soon). > > On 1/4/17 4:21 AM, Yasumasa Suenaga wrote: >> Hi, >> >>> Contributions are always welcome! :) >> >> I uploaded patches for using UL. >> I want to get JIT logs as below: >> >> Compilation logging: http://cr.openjdk.java.net/~ysuenaga/ul-jit/compilation/ > > In all places you have unified logging followed by the same normal out may be you should factor out into separate method which does both outputs instead of having almost duplicated code all over places. > >> CodeCache flushing logging: http://cr.openjdk.java.net/~ysuenaga/ul-jit/codecache/ > > codeCache.cpp - may be use const char* locals for messages instead of duplicating them. > > Thanks, > Vladimir > >> >> >>> But for JDK 9 we already passed Features freeze dates. >> >> Should I file them to JBS and send webrev after jdk10 repos is opened? >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2017/01/04 8:06, Vladimir Kozlov wrote: >>> Contributions are always welcome! :) >>> >>> But for JDK 9 we already passed Features freeze dates. >>> >>> Thanks, >>> Vladimir >>> >>> On 1/3/17 3:01 PM, Christian Thalinger wrote: >>>> >>>>> On Jan 2, 2017, at 6:08 PM, Yasumasa Suenaga wrote: >>>>> >>>>> Thanks Vladimir, >>>>> >>>>>> Definitely not in JDK 9. And I can't say when it could be done or done at all. >>>>> >>>>> I hope this feature will be implemented ASAP. >>>> >>>> You can always contribute an implementation. Shouldn?t be too difficult. >>>> >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2017/01/03 12:00, Vladimir Kozlov wrote: >>>>>> On 1/2/17 6:33 PM, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Java 9 has JEP 158: Unified JVM Logging. >>>>>>> This JEP describes that existing 'tty->print...' logging should use unified logging as output. However, C2 >>>>>>> compiler does >>>>>>> not seem to use it. >>>>>>> >>>>>>> Do you have any plan to use JEP 158 in JIT codes? >>>>>> >>>>>> Definitely not in JDK 9. And I can't say when it could be done or done at all. >>>>>> >>>>>> Regards, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> I uploaded Unified JVM logging viewer to GitHub [1]. >>>>>>> I want to draw chart(s) or list all JIT'ed methods on it if possible. >>>>>>> (Especially I want to get log from PrintCompilation and PrintIntrinsics through Unified JVM logging) >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> [1] https://github.com/YaSuenag/ulviewer >>>>>>> >>>> From coleen.phillimore at oracle.com Wed Jan 4 23:05:53 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 4 Jan 2017 18:05:53 -0500 Subject: RFR (xs) 8172246: [TESTBUG] runtime/RedefineTests/RedefinePreviousVersions.java 'Class unloading: has_previous_vers,ions = true' missing from stdout/stderr Message-ID: <4c1e41bf-372d-d78e-9bb8-61fc3df2900c@oracle.com> Summary: add boolean to gate redefinition start open webrev at http://cr.openjdk.java.net/~coleenp/8172246/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8172246 Tested multiple times with new better test code. Thanks, Coleen From serguei.spitsyn at oracle.com Wed Jan 4 23:35:50 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 4 Jan 2017 15:35:50 -0800 Subject: RFR (xs) 8172246: [TESTBUG] runtime/RedefineTests/RedefinePreviousVersions.java 'Class unloading: has_previous_vers,ions = true' missing from stdout/stderr In-Reply-To: <4c1e41bf-372d-d78e-9bb8-61fc3df2900c@oracle.com> References: <4c1e41bf-372d-d78e-9bb8-61fc3df2900c@oracle.com> Message-ID: <0facef4c-a5b3-ef21-d280-11452d88100c@oracle.com> Coleen, The fix looks good. Thanks, Serguei On 1/4/17 15:05, Coleen Phillimore wrote: > Summary: add boolean to gate redefinition start > > open webrev at http://cr.openjdk.java.net/~coleenp/8172246/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8172246 > > Tested multiple times with new better test code. > > Thanks, > Coleen From coleen.phillimore at oracle.com Wed Jan 4 23:44:46 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 4 Jan 2017 18:44:46 -0500 Subject: RFR (xs) 8172246: [TESTBUG] runtime/RedefineTests/RedefinePreviousVersions.java 'Class unloading: has_previous_vers,ions = true' missing from stdout/stderr In-Reply-To: <0facef4c-a5b3-ef21-d280-11452d88100c@oracle.com> References: <4c1e41bf-372d-d78e-9bb8-61fc3df2900c@oracle.com> <0facef4c-a5b3-ef21-d280-11452d88100c@oracle.com> Message-ID: <1398dae5-079d-f2f0-88d8-286123410651@oracle.com> Thanks, Serguei! Coleen On 1/4/17 6:35 PM, serguei.spitsyn at oracle.com wrote: > Coleen, > > The fix looks good. > > Thanks, > Serguei > > > On 1/4/17 15:05, Coleen Phillimore wrote: >> Summary: add boolean to gate redefinition start >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8172246/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8172246 >> >> Tested multiple times with new better test code. >> >> Thanks, >> Coleen > From david.holmes at oracle.com Thu Jan 5 00:33:49 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 5 Jan 2017 10:33:49 +1000 Subject: RFR (xs) 8172246: [TESTBUG] runtime/RedefineTests/RedefinePreviousVersions.java 'Class unloading: has_previous_vers,ions = true' missing from stdout/stderr In-Reply-To: <4c1e41bf-372d-d78e-9bb8-61fc3df2900c@oracle.com> References: <4c1e41bf-372d-d78e-9bb8-61fc3df2900c@oracle.com> Message-ID: Hi Coleen, On 5/01/2017 9:05 AM, Coleen Phillimore wrote: > Summary: add boolean to gate redefinition start > > open webrev at http://cr.openjdk.java.net/~coleenp/8172246/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8172246 Minor nit. Please change both: Thread.currentThread().sleep(10); to Thread.sleep(10); sleep() always applies to the current thread. Also, as it is a boolean variable style dictates that: while (Running.running != true) { be written as: while (!Running.running) { One related query with this test: are we guaranteed that the loop of System.gc() calls will trigger class unloading? Thanks, David > Tested multiple times with new better test code. > > Thanks, > Coleen From coleen.phillimore at oracle.com Thu Jan 5 01:33:02 2017 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 4 Jan 2017 20:33:02 -0500 Subject: RFR (xs) 8172246: [TESTBUG] runtime/RedefineTests/RedefinePreviousVersions.java 'Class unloading: has_previous_vers,ions = true' missing from stdout/stderr In-Reply-To: References: <4c1e41bf-372d-d78e-9bb8-61fc3df2900c@oracle.com> Message-ID: <0c174658-d94a-b4c5-1b2a-c6546bc38c17@oracle.com> On 1/4/17 7:33 PM, David Holmes wrote: > Hi Coleen, > > On 5/01/2017 9:05 AM, Coleen Phillimore wrote: >> Summary: add boolean to gate redefinition start >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8172246/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8172246 > > Minor nit. Please change both: > > Thread.currentThread().sleep(10); > > to > > Thread.sleep(10); Sure, I'll change it. > > sleep() always applies to the current thread. > > Also, as it is a boolean variable style dictates that: > > while (Running.running != true) { > > be written as: > > while (!Running.running) { > ok. > One related query with this test: are we guaranteed that the loop of > System.gc() calls will trigger class unloading? > No, the test doesn't rely on that. I did the system.gc so that I could see it when running the test but it doesn't need to deallocate the previous versions of the class. And it doesn't deallocate them if the 'infinite' method has been compiled because it hangs out in the code cache for a long time. Thanks! Coleen > Thanks, > David > >> Tested multiple times with new better test code. >> >> Thanks, >> Coleen From yasuenag at gmail.com Thu Jan 5 12:49:53 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 5 Jan 2017 21:49:53 +0900 Subject: JEP 158 support for JIT In-Reply-To: <4cbc07f4-3d74-98ca-2369-71852909dfac@oracle.com> References: <81baa810-18c2-147b-d83c-aec44fb9dbe7@gmail.com> <5E127666-A112-4C34-BC7B-25E2D0134027@twitter.com> <586C2E69.9010603@oracle.com> <463a97a2-3588-413a-b595-c9a56765a428@gmail.com> <4cbc07f4-3d74-98ca-2369-71852909dfac@oracle.com> Message-ID: <376b811d-2daa-cf1c-e2f0-0e325388953a@gmail.com> Hi Vladimir, > Yes, please, file "Enchantment" in JBS for hotspot/compiler category and set "Fix version" 10. > We can review it now - no need to wait when jdk 10 is opened (should be soon). Thanks! I filed them to JBS. >> Compilation logging: http://cr.openjdk.java.net/~ysuenaga/ul-jit/compilation/ > > In all places you have unified logging followed by the same normal out may be you should factor out into separate method which does both outputs instead of having almost duplicated code all over places. I've sent review request: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-January/025275.html According to JEP, I guess we should remove existed logging code. So I just add new function for UL to CompileTask class. >> CodeCache flushing logging: http://cr.openjdk.java.net/~ysuenaga/ul-jit/codecache/ > > codeCache.cpp - may be use const char* locals for messages instead of duplicating them. I've sent review request: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-January/025276.html I fixed them in this webrev. Thanks, Yasumasa On 2017/01/05 3:47, Vladimir Kozlov wrote: > Thank you, Yasumasa > > Yes, please, file "Enchantment" in JBS for hotspot/compiler category and set "Fix version" 10. > We can review it now - no need to wait when jdk 10 is opened (should be soon). > > On 1/4/17 4:21 AM, Yasumasa Suenaga wrote: >> Hi, >> >>> Contributions are always welcome! :) >> >> I uploaded patches for using UL. >> I want to get JIT logs as below: >> >> Compilation logging: http://cr.openjdk.java.net/~ysuenaga/ul-jit/compilation/ > > In all places you have unified logging followed by the same normal out may be you should factor out into separate method which does both outputs instead of having almost duplicated code all over places. > >> CodeCache flushing logging: http://cr.openjdk.java.net/~ysuenaga/ul-jit/codecache/ > > codeCache.cpp - may be use const char* locals for messages instead of duplicating them. > > Thanks, > Vladimir > >> >> >>> But for JDK 9 we already passed Features freeze dates. >> >> Should I file them to JBS and send webrev after jdk10 repos is opened? >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2017/01/04 8:06, Vladimir Kozlov wrote: >>> Contributions are always welcome! :) >>> >>> But for JDK 9 we already passed Features freeze dates. >>> >>> Thanks, >>> Vladimir >>> >>> On 1/3/17 3:01 PM, Christian Thalinger wrote: >>>> >>>>> On Jan 2, 2017, at 6:08 PM, Yasumasa Suenaga wrote: >>>>> >>>>> Thanks Vladimir, >>>>> >>>>>> Definitely not in JDK 9. And I can't say when it could be done or done at all. >>>>> >>>>> I hope this feature will be implemented ASAP. >>>> >>>> You can always contribute an implementation. Shouldn?t be too difficult. >>>> >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2017/01/03 12:00, Vladimir Kozlov wrote: >>>>>> On 1/2/17 6:33 PM, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Java 9 has JEP 158: Unified JVM Logging. >>>>>>> This JEP describes that existing 'tty->print...' logging should use unified logging as output. However, C2 >>>>>>> compiler does >>>>>>> not seem to use it. >>>>>>> >>>>>>> Do you have any plan to use JEP 158 in JIT codes? >>>>>> >>>>>> Definitely not in JDK 9. And I can't say when it could be done or done at all. >>>>>> >>>>>> Regards, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> I uploaded Unified JVM logging viewer to GitHub [1]. >>>>>>> I want to draw chart(s) or list all JIT'ed methods on it if possible. >>>>>>> (Especially I want to get log from PrintCompilation and PrintIntrinsics through Unified JVM logging) >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> [1] https://github.com/YaSuenag/ulviewer >>>>>>> >>>> From amit.sapre at oracle.com Fri Jan 13 06:17:56 2017 From: amit.sapre at oracle.com (Amit Sapre) Date: Thu, 12 Jan 2017 22:17:56 -0800 (PST) Subject: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts "0" instead of assigned port Message-ID: Hello, Please review the fix for JDK-8167337 Bug Id : https://bugs.openjdk.java.net/browse/JDK-8167337 Webrev : http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8167337/webrev.00/ Thanks, Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From ujwal.vangapally at oracle.com Fri Jan 13 08:26:03 2017 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Fri, 13 Jan 2017 13:56:03 +0530 Subject: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" Message-ID: kindly review the fix for bug JDK-8024352 Bug Id : https://bugs.openjdk.java.net/browse/JDK-8024352 webrev : http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8024352/webrev.00/ Thanks, Ujwal. From dmitry.samersoff at oracle.com Sun Jan 15 11:19:24 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 15 Jan 2017 14:19:24 +0300 Subject: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts "0" instead of assigned port In-Reply-To: References: Message-ID: Amit, Changes looks good to me. -Dmitry On 2017-01-13 09:17, Amit Sapre wrote: > Hello, > > > > Please review the fix for JDK-8167337 > > > > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8167337 > > Webrev : > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8167337/webrev.00/ > > > > Thanks, > > Amit > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From amit.sapre at oracle.com Mon Jan 16 05:46:33 2017 From: amit.sapre at oracle.com (Amit Sapre) Date: Sun, 15 Jan 2017 21:46:33 -0800 (PST) Subject: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts "0" instead of assigned port In-Reply-To: References: Message-ID: <1c49ec63-f79a-4501-8f0b-dee7379a3061@default> Thanks Dmitry for the review. Can I have one more reviewer for this fix ? Thanks, Amit > -----Original Message----- > From: Dmitry Samersoff > Sent: Sunday, January 15, 2017 4:49 PM > To: Amit Sapre; serviceability-dev > Subject: Re: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts > "0" instead of assigned port > > Amit, > > Changes looks good to me. > > -Dmitry > > > On 2017-01-13 09:17, Amit Sapre wrote: > > Hello, > > > > > > > > Please review the fix for JDK-8167337 > > > > > > > > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8167337 > > > > Webrev : > > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8167337/webrev.00/ > > > > > > > > Thanks, > > > > Amit > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From harsha.wardhana.b at oracle.com Mon Jan 16 06:21:45 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 16 Jan 2017 11:51:45 +0530 Subject: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts "0" instead of assigned port In-Reply-To: <1c49ec63-f79a-4501-8f0b-dee7379a3061@default> References: <1c49ec63-f79a-4501-8f0b-dee7379a3061@default> Message-ID: <1f26fc9b-064f-c76a-15f9-a73bf6858824@oracle.com> Hi Amit, In JdpJmxRemoteDynamicPortTestCase:48 needs null/empty check for jmx url. JdpJmxRemoteDynamicPortTestCase:49, array length needs to checked before accessing index at token[6]. It is possible that port number need not always be present at given index and hence we may have to follow different approach to extract port number. Please check if approach below works. int idx = jmxurl.indexOf(':'); while (idx != -1) { jmxurl = jmxurl.substring(idx+1); idx = jmxurl.indexOf(':'); } if(jmxurl.indexOf('/') == -1) { throw new RuntimeException("Test failed : Invalid JMXServiceURL"); } String portStr = jmxurl.substring(0,jmxurl.indexOf('/')); int port = Integer.parseInt(portStr); if( port == 0 ) { throw new RuntimeException("Test failed : Zero port for jmxremote"); } Regards Harsha On Monday 16 January 2017 11:16 AM, Amit Sapre wrote: > Thanks Dmitry for the review. > > Can I have one more reviewer for this fix ? > > Thanks, > Amit > >> -----Original Message----- >> From: Dmitry Samersoff >> Sent: Sunday, January 15, 2017 4:49 PM >> To: Amit Sapre; serviceability-dev >> Subject: Re: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts >> "0" instead of assigned port >> >> Amit, >> >> Changes looks good to me. >> >> -Dmitry >> >> >> On 2017-01-13 09:17, Amit Sapre wrote: >>> Hello, >>> >>> >>> >>> Please review the fix for JDK-8167337 >>> >>> >>> >>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8167337 >>> >>> Webrev : >>> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8167337/webrev.00/ >>> >>> >>> >>> Thanks, >>> >>> Amit >>> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. From ujwal.vangapally at oracle.com Tue Jan 17 09:37:21 2017 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Tue, 17 Jan 2017 15:07:21 +0530 Subject: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" In-Reply-To: References: Message-ID: <0a0b8f5b-1320-fdb2-06c0-2185db263499@oracle.com> Gentle reminder On 1/13/2017 1:56 PM, Ujwal Vangapally wrote: > kindly review the fix for bug JDK-8024352 > > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8024352 > > webrev : > http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8024352/webrev.00/ > > Thanks, > > Ujwal. > > From goetz.lindenmaier at sap.com Tue Jan 17 10:23:15 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 17 Jan 2017 10:23:15 +0000 Subject: Wrong merge after 8169232: SA: TestCpoolForInvokeDynamic.java fails with ... Message-ID: <25e04e3989e74682825e5a38264b8cf0@DEROTE13DE04.global.corp.sap> Hi, I think this merge http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a28955e16c78 wrongly added + * @ignore 8169232 to TestCpoolForInvokeDynamic.java which was fixed in 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/13e6043fcdcb Best regards, Goetz -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Tue Jan 17 10:35:50 2017 From: harsha.wardhana.b at oracle.com (harsha.wardhana.b at oracle.com) Date: Tue, 17 Jan 2017 10:35:50 +0000 (UTC) Subject: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" In-Reply-To: References: Message-ID: Looks fine. On Fri, Jan 13, 2017 at 1:56 PM +0530, "Ujwal Vangapally" wrote: kindly review the fix for bug JDK-8024352 Bug Id : https://bugs.openjdk.java.net/browse/JDK-8024352 webrev : http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8024352/webrev.00/ Thanks, Ujwal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amit.sapre at oracle.com Tue Jan 17 10:49:12 2017 From: amit.sapre at oracle.com (Amit Sapre) Date: Tue, 17 Jan 2017 02:49:12 -0800 (PST) Subject: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts "0" instead of assigned port In-Reply-To: <1c49ec63-f79a-4501-8f0b-dee7379a3061@default> References: <1c49ec63-f79a-4501-8f0b-dee7379a3061@default> Message-ID: <69a9f99f-cdd0-4914-8998-601705d8ef20@default> > Hi Amit, > > In JdpJmxRemoteDynamicPortTestCase:48 needs null/empty check for jmx > url. Ok. Will add this. > > JdpJmxRemoteDynamicPortTestCase:49, array length needs to checked > before > accessing index at token[6]. > > It is possible that port number need not always be present at given > index and hence we may have to follow different approach to extract > port > number. Please check if approach below works. > > > > int idx = jmxurl.indexOf(':'); > while (idx != -1) { > jmxurl = jmxurl.substring(idx+1); > idx = jmxurl.indexOf(':'); > } > > if(jmxurl.indexOf('/') == -1) { > throw new RuntimeException("Test failed : Invalid > JMXServiceURL"); > } > > String portStr = jmxurl.substring(0,jmxurl.indexOf('/')); > int port = Integer.parseInt(portStr); > if( port == 0 ) { > throw new RuntimeException("Test failed : Zero port for > jmxremote"); > } > > I had thought if this and then found out that checking with ":" character first will bring out all these uncertainties. That's the reason , I first split with "/", whose count is constant for either form of jmx url. So accessing token[6] will always give the substring containing remote port. Amit > -----Original Message----- > From: Amit Sapre > Sent: Monday, January 16, 2017 11:17 AM > To: Dmitry Samersoff; serviceability-dev > Subject: RE: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts > "0" instead of assigned port > > Thanks Dmitry for the review. > > Can I have one more reviewer for this fix ? > > Thanks, > Amit > > > -----Original Message----- > > From: Dmitry Samersoff > > Sent: Sunday, January 15, 2017 4:49 PM > > To: Amit Sapre; serviceability-dev > > Subject: Re: RFR : JDK-8167337 - When jmxremote.port=0, JDP > broadcasts > > "0" instead of assigned port > > > > Amit, > > > > Changes looks good to me. > > > > -Dmitry > > > > > > On 2017-01-13 09:17, Amit Sapre wrote: > > > Hello, > > > > > > > > > > > > Please review the fix for JDK-8167337 > > > > > > > > > > > > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8167337 > > > > > > Webrev : > > > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK- > 8167337/webrev.00 > > > / > > > > > > > > > > > > Thanks, > > > > > > Amit > > > > > > > > > -- > > Dmitry Samersoff > > Oracle Java development team, Saint Petersburg, Russia > > * I would love to change the world, but they won't give me the > sources. From Roger.Riggs at Oracle.com Tue Jan 17 16:09:06 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 17 Jan 2017 11:09:06 -0500 Subject: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts "0" instead of assigned port In-Reply-To: <1f26fc9b-064f-c76a-15f9-a73bf6858824@oracle.com> References: <1c49ec63-f79a-4501-8f0b-dee7379a3061@default> <1f26fc9b-064f-c76a-15f9-a73bf6858824@oracle.com> Message-ID: <18af09d1-2810-e138-25ca-81c484180673@Oracle.com> Hi Harsha, On 1/16/2017 1:21 AM, Harsha Wardhana B wrote: > Hi Amit, > > In JdpJmxRemoteDynamicPortTestCase:48 needs null/empty check for jmx url. > > JdpJmxRemoteDynamicPortTestCase:49, array length needs to checked > before accessing index at token[6]. > > It is possible that port number need not always be present at given > index and hence we may have to follow different approach to extract > port number. Please check if approach below works. > > > > int idx = jmxurl.indexOf(':'); > while (idx != -1) { > jmxurl = jmxurl.substring(idx+1); > idx = jmxurl.indexOf(':'); > } This loop would very eagerly find the last ":" in the string even it was well past the host/port field. String.lastIndex would be equivalent. > > if(jmxurl.indexOf('/') == -1) { > throw new RuntimeException("Test failed : Invalid > JMXServiceURL"); > } It would be more efficient to compare the index of the '/' after the last ":" than to re-create new substrings. int colon = jmxurl.lastIndexOf(':'); int slash = jmxurl.indexOf('/', colon); int port = Integer.parseInt(jmxurl, colon + 1, slash, 10); > > String portStr = jmxurl.substring(0,jmxurl.indexOf('/')); > int port = Integer.parseInt(portStr); > if( port == 0 ) { > throw new RuntimeException("Test failed : Zero port for > jmxremote"); > } Or It might be just as effective to just to check if ":0/" is present. if (jmxurl.contains(":0/")) {...} $.02, Roger > > > > Regards > > Harsha > > > On Monday 16 January 2017 11:16 AM, Amit Sapre wrote: >> Thanks Dmitry for the review. >> >> Can I have one more reviewer for this fix ? >> >> Thanks, >> Amit >> >>> -----Original Message----- >>> From: Dmitry Samersoff >>> Sent: Sunday, January 15, 2017 4:49 PM >>> To: Amit Sapre; serviceability-dev >>> Subject: Re: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts >>> "0" instead of assigned port >>> >>> Amit, >>> >>> Changes looks good to me. >>> >>> -Dmitry >>> >>> >>> On 2017-01-13 09:17, Amit Sapre wrote: >>>> Hello, >>>> >>>> >>>> >>>> Please review the fix for JDK-8167337 >>>> >>>> >>>> >>>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8167337 >>>> >>>> Webrev : >>>> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8167337/webrev.00/ >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Amit >>>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. > From harsha.wardhana.b at oracle.com Tue Jan 17 16:26:34 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 17 Jan 2017 21:56:34 +0530 Subject: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts "0" instead of assigned port In-Reply-To: <18af09d1-2810-e138-25ca-81c484180673@Oracle.com> References: <1c49ec63-f79a-4501-8f0b-dee7379a3061@default> <1f26fc9b-064f-c76a-15f9-a73bf6858824@oracle.com> <18af09d1-2810-e138-25ca-81c484180673@Oracle.com> Message-ID: Hi Roger, Your approach is more elegant. However checking for ":0/" may not work as we can have non-zero port number that can end in 0. Regards Harsha On Tuesday 17 January 2017 09:39 PM, Roger Riggs wrote: > Hi Harsha, > > On 1/16/2017 1:21 AM, Harsha Wardhana B wrote: >> Hi Amit, >> >> In JdpJmxRemoteDynamicPortTestCase:48 needs null/empty check for jmx >> url. >> >> JdpJmxRemoteDynamicPortTestCase:49, array length needs to checked >> before accessing index at token[6]. >> >> It is possible that port number need not always be present at given >> index and hence we may have to follow different approach to extract >> port number. Please check if approach below works. >> >> >> >> int idx = jmxurl.indexOf(':'); >> while (idx != -1) { >> jmxurl = jmxurl.substring(idx+1); >> idx = jmxurl.indexOf(':'); >> } > This loop would very eagerly find the last ":" in the string even it > was well past the host/port field. > String.lastIndex would be equivalent. >> >> if(jmxurl.indexOf('/') == -1) { >> throw new RuntimeException("Test failed : Invalid >> JMXServiceURL"); >> } > It would be more efficient to compare the index of the '/' after the > last ":" than to re-create new substrings. > int colon = jmxurl.lastIndexOf(':'); > int slash = jmxurl.indexOf('/', colon); > int port = Integer.parseInt(jmxurl, colon + 1, slash, 10); > >> >> String portStr = jmxurl.substring(0,jmxurl.indexOf('/')); >> int port = Integer.parseInt(portStr); >> if( port == 0 ) { >> throw new RuntimeException("Test failed : Zero port for >> jmxremote"); >> } > Or It might be just as effective to just to check if ":0/" is present. > if (jmxurl.contains(":0/")) {...} > > $.02, Roger > > >> >> >> >> Regards >> >> Harsha >> >> >> On Monday 16 January 2017 11:16 AM, Amit Sapre wrote: >>> Thanks Dmitry for the review. >>> >>> Can I have one more reviewer for this fix ? >>> >>> Thanks, >>> Amit >>> >>>> -----Original Message----- >>>> From: Dmitry Samersoff >>>> Sent: Sunday, January 15, 2017 4:49 PM >>>> To: Amit Sapre; serviceability-dev >>>> Subject: Re: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts >>>> "0" instead of assigned port >>>> >>>> Amit, >>>> >>>> Changes looks good to me. >>>> >>>> -Dmitry >>>> >>>> >>>> On 2017-01-13 09:17, Amit Sapre wrote: >>>>> Hello, >>>>> >>>>> >>>>> >>>>> Please review the fix for JDK-8167337 >>>>> >>>>> >>>>> >>>>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8167337 >>>>> >>>>> Webrev : >>>>> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8167337/webrev.00/ >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Amit >>>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the >>>> sources. >> > From Roger.Riggs at Oracle.com Tue Jan 17 16:34:55 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 17 Jan 2017 11:34:55 -0500 Subject: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts "0" instead of assigned port In-Reply-To: References: <1c49ec63-f79a-4501-8f0b-dee7379a3061@default> <1f26fc9b-064f-c76a-15f9-a73bf6858824@oracle.com> <18af09d1-2810-e138-25ca-81c484180673@Oracle.com> Message-ID: <3ef61a9e-a3f3-5080-776b-925860487d47@Oracle.com> Hi, yes, but the pattern looks for the ":" before and the "/" after the zero. It would not match the port ":000000/" ; in this test code the URL is assumed/known to be relatively well formed. Roger On 1/17/2017 11:26 AM, Harsha Wardhana B wrote: > Hi Roger, > > Your approach is more elegant. However checking for ":0/" may not work > as we can have non-zero port number that can end in 0. > > Regards > > Harsha > > > On Tuesday 17 January 2017 09:39 PM, Roger Riggs wrote: >> Hi Harsha, >> >> On 1/16/2017 1:21 AM, Harsha Wardhana B wrote: >>> Hi Amit, >>> >>> In JdpJmxRemoteDynamicPortTestCase:48 needs null/empty check for jmx >>> url. >>> >>> JdpJmxRemoteDynamicPortTestCase:49, array length needs to checked >>> before accessing index at token[6]. >>> >>> It is possible that port number need not always be present at given >>> index and hence we may have to follow different approach to extract >>> port number. Please check if approach below works. >>> >>> >>> >>> int idx = jmxurl.indexOf(':'); >>> while (idx != -1) { >>> jmxurl = jmxurl.substring(idx+1); >>> idx = jmxurl.indexOf(':'); >>> } >> This loop would very eagerly find the last ":" in the string even it >> was well past the host/port field. >> String.lastIndex would be equivalent. >>> >>> if(jmxurl.indexOf('/') == -1) { >>> throw new RuntimeException("Test failed : Invalid >>> JMXServiceURL"); >>> } >> It would be more efficient to compare the index of the '/' after the >> last ":" than to re-create new substrings. >> int colon = jmxurl.lastIndexOf(':'); >> int slash = jmxurl.indexOf('/', colon); >> int port = Integer.parseInt(jmxurl, colon + 1, slash, 10); >> >>> >>> String portStr = jmxurl.substring(0,jmxurl.indexOf('/')); >>> int port = Integer.parseInt(portStr); >>> if( port == 0 ) { >>> throw new RuntimeException("Test failed : Zero port for >>> jmxremote"); >>> } >> Or It might be just as effective to just to check if ":0/" is present. >> if (jmxurl.contains(":0/")) {...} >> >> $.02, Roger >> >> >>> >>> >>> >>> Regards >>> >>> Harsha >>> >>> >>> On Monday 16 January 2017 11:16 AM, Amit Sapre wrote: >>>> Thanks Dmitry for the review. >>>> >>>> Can I have one more reviewer for this fix ? >>>> >>>> Thanks, >>>> Amit >>>> >>>>> -----Original Message----- >>>>> From: Dmitry Samersoff >>>>> Sent: Sunday, January 15, 2017 4:49 PM >>>>> To: Amit Sapre; serviceability-dev >>>>> Subject: Re: RFR : JDK-8167337 - When jmxremote.port=0, JDP >>>>> broadcasts >>>>> "0" instead of assigned port >>>>> >>>>> Amit, >>>>> >>>>> Changes looks good to me. >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2017-01-13 09:17, Amit Sapre wrote: >>>>>> Hello, >>>>>> >>>>>> >>>>>> >>>>>> Please review the fix for JDK-8167337 >>>>>> >>>>>> >>>>>> >>>>>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8167337 >>>>>> >>>>>> Webrev : >>>>>> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8167337/webrev.00/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Amit >>>>>> >>>>> >>>>> -- >>>>> Dmitry Samersoff >>>>> Oracle Java development team, Saint Petersburg, Russia >>>>> * I would love to change the world, but they won't give me the >>>>> sources. >>> >> > From david.holmes at oracle.com Wed Jan 18 01:03:38 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Jan 2017 11:03:38 +1000 Subject: RFR (XS): 8172261: [JVMTI] Specification for early VM start event needs to lower expectations in relation class loading Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8172261 webrev: http://cr.openjdk.java.net/~dholmes/8172261/webrev/ This is a simple relaxation of the spec in regards to the new "early VM start" event, to explicitly allow for the possibility that arbitrary class loading during this "early VM start" time may fail in extreme ways. Changes are easier to see in text than webrev: Extend: The VM is capable of executing bytecode but it may not have initialized to the point where it can load classes in modules other than java.base. to read: The VM is capable of executing bytecode but it may not have initialized to the point where it can load classes in modules other than java.base, or even arbitrary classes in java.base. --- Replace: Care should also be taken with JNI FindClass as it may not be possible to load classes that are not in the java.base module. with: Extreme care should also be taken with JNI FindClass as it may not be possible to load classes, and attempts to do so may result in unpredictable behavior, maybe even stability issues on some VM implementations. --- Thanks, David From david.holmes at oracle.com Wed Jan 18 01:08:19 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Jan 2017 11:08:19 +1000 Subject: RFR (XS): 8172261: [JVMTI] Specification for early VM start event needs to lower expectations in relation class loading In-Reply-To: References: Message-ID: <4c38fc7e-2d55-ae79-d625-ee4e5efbec3e@oracle.com> Forgot to state this has gone through CCC approval. David On 18/01/2017 11:03 AM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8172261 > > webrev: http://cr.openjdk.java.net/~dholmes/8172261/webrev/ > > This is a simple relaxation of the spec in regards to the new "early VM > start" event, to explicitly allow for the possibility that arbitrary > class loading during this "early VM start" time may fail in extreme ways. > > Changes are easier to see in text than webrev: > > Extend: > > The VM is capable of executing bytecode but it may not have initialized > to the point where it can load classes in modules other than java.base. > > to read: > > The VM is capable of executing bytecode but it may not have initialized > to the point where it can load classes in modules other than java.base, > or even arbitrary classes in java.base. > > --- > > Replace: > > Care should also be taken with JNI FindClass as it may not be possible > to load classes that are not in the java.base module. > > with: > > Extreme care should also be taken with JNI FindClass as it may not be > possible to load classes, and attempts to do so may result in > unpredictable behavior, maybe even stability issues on some VM > implementations. > > --- > > Thanks, > David From daniel.daugherty at oracle.com Wed Jan 18 02:27:05 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 17 Jan 2017 19:27:05 -0700 Subject: RFR (XS): 8172261: [JVMTI] Specification for early VM start event needs to lower expectations in relation class loading In-Reply-To: References: Message-ID: On 1/17/17 6:03 PM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8172261 > > webrev: http://cr.openjdk.java.net/~dholmes/8172261/webrev/ src/share/vm/prims/jvmti.xml No comments. Thumbs up. Dan > > This is a simple relaxation of the spec in regards to the new "early > VM start" event, to explicitly allow for the possibility that > arbitrary class loading during this "early VM start" time may fail in > extreme ways. > > Changes are easier to see in text than webrev: > > Extend: > > The VM is capable of executing bytecode but it may not have > initialized to the point where it can load classes in modules other > than java.base. > > to read: > > The VM is capable of executing bytecode but it may not have > initialized to the point where it can load classes in modules other > than java.base, or even arbitrary classes in java.base. > > --- > > Replace: > > Care should also be taken with JNI FindClass as it may not be possible > to load classes that are not in the java.base module. > > with: > > Extreme care should also be taken with JNI FindClass as it may not be > possible to load classes, and attempts to do so may result in > unpredictable behavior, maybe even stability issues on some VM > implementations. > > --- > > Thanks, > David From david.holmes at oracle.com Wed Jan 18 02:57:59 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Jan 2017 12:57:59 +1000 Subject: RFR (XS): 8172261: [JVMTI] Specification for early VM start event needs to lower expectations in relation class loading In-Reply-To: References: Message-ID: Thanks Dan! David On 18/01/2017 12:27 PM, Daniel D. Daugherty wrote: > On 1/17/17 6:03 PM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8172261 >> >> webrev: http://cr.openjdk.java.net/~dholmes/8172261/webrev/ > > src/share/vm/prims/jvmti.xml > No comments. > > Thumbs up. > > Dan > > > >> >> This is a simple relaxation of the spec in regards to the new "early >> VM start" event, to explicitly allow for the possibility that >> arbitrary class loading during this "early VM start" time may fail in >> extreme ways. >> >> Changes are easier to see in text than webrev: >> >> Extend: >> >> The VM is capable of executing bytecode but it may not have >> initialized to the point where it can load classes in modules other >> than java.base. >> >> to read: >> >> The VM is capable of executing bytecode but it may not have >> initialized to the point where it can load classes in modules other >> than java.base, or even arbitrary classes in java.base. >> >> --- >> >> Replace: >> >> Care should also be taken with JNI FindClass as it may not be possible >> to load classes that are not in the java.base module. >> >> with: >> >> Extreme care should also be taken with JNI FindClass as it may not be >> possible to load classes, and attempts to do so may result in >> unpredictable behavior, maybe even stability issues on some VM >> implementations. >> >> --- >> >> Thanks, >> David > From serguei.spitsyn at oracle.com Wed Jan 18 04:53:29 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 17 Jan 2017 20:53:29 -0800 Subject: RFR (XS): 8172261: [JVMTI] Specification for early VM start event needs to lower expectations in relation class loading In-Reply-To: References: Message-ID: David, It looks good. Thank you for taking care about this jck issue! Thanks, Serguei On 1/17/17 17:03, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8172261 > > webrev: http://cr.openjdk.java.net/~dholmes/8172261/webrev/ > > This is a simple relaxation of the spec in regards to the new "early > VM start" event, to explicitly allow for the possibility that > arbitrary class loading during this "early VM start" time may fail in > extreme ways. > > Changes are easier to see in text than webrev: > > Extend: > > The VM is capable of executing bytecode but it may not have > initialized to the point where it can load classes in modules other > than java.base. > > to read: > > The VM is capable of executing bytecode but it may not have > initialized to the point where it can load classes in modules other > than java.base, or even arbitrary classes in java.base. > > --- > > Replace: > > Care should also be taken with JNI FindClass as it may not be possible > to load classes that are not in the java.base module. > > with: > > Extreme care should also be taken with JNI FindClass as it may not be > possible to load classes, and attempts to do so may result in > unpredictable behavior, maybe even stability issues on some VM > implementations. > > --- > > Thanks, > David From david.holmes at oracle.com Wed Jan 18 05:04:09 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Jan 2017 15:04:09 +1000 Subject: RFR (XS): 8172261: [JVMTI] Specification for early VM start event needs to lower expectations in relation class loading In-Reply-To: References: Message-ID: <89b07f4c-e579-45bd-5baa-05ec0700af17@oracle.com> Thanks Serguei. David On 18/01/2017 2:53 PM, serguei.spitsyn at oracle.com wrote: > David, > > It looks good. > Thank you for taking care about this jck issue! > > Thanks, > Serguei > > > > On 1/17/17 17:03, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8172261 >> >> webrev: http://cr.openjdk.java.net/~dholmes/8172261/webrev/ >> >> This is a simple relaxation of the spec in regards to the new "early >> VM start" event, to explicitly allow for the possibility that >> arbitrary class loading during this "early VM start" time may fail in >> extreme ways. >> >> Changes are easier to see in text than webrev: >> >> Extend: >> >> The VM is capable of executing bytecode but it may not have >> initialized to the point where it can load classes in modules other >> than java.base. >> >> to read: >> >> The VM is capable of executing bytecode but it may not have >> initialized to the point where it can load classes in modules other >> than java.base, or even arbitrary classes in java.base. >> >> --- >> >> Replace: >> >> Care should also be taken with JNI FindClass as it may not be possible >> to load classes that are not in the java.base module. >> >> with: >> >> Extreme care should also be taken with JNI FindClass as it may not be >> possible to load classes, and attempts to do so may result in >> unpredictable behavior, maybe even stability issues on some VM >> implementations. >> >> --- >> >> Thanks, >> David > From amit.sapre at oracle.com Wed Jan 18 08:38:58 2017 From: amit.sapre at oracle.com (Amit Sapre) Date: Wed, 18 Jan 2017 00:38:58 -0800 (PST) Subject: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts "0" instead of assigned port In-Reply-To: <3ef61a9e-a3f3-5080-776b-925860487d47@Oracle.com> References: <1c49ec63-f79a-4501-8f0b-dee7379a3061@default> <1f26fc9b-064f-c76a-15f9-a73bf6858824@oracle.com> <18af09d1-2810-e138-25ca-81c484180673@Oracle.com> <3ef61a9e-a3f3-5080-776b-925860487d47@Oracle.com> Message-ID: Hello, Looks like basic check on Jdp packet includes a check for JMX_SERVICE_URL https://java.se.oracle.com/source/xref/jdk9-dev/jdk/test/sun/management/jdp/JdpTestCase.java#184 I feel we don't need any further check on jmx service url. > -----Original Message----- > From: Roger Riggs > Sent: Tuesday, January 17, 2017 10:05 PM > To: serviceability-dev at openjdk.java.net > Subject: Re: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts > "0" instead of assigned port > > Hi, > > yes, but the pattern looks for the ":" before and the "/" after the > zero. > It would not match the port ":000000/" ; in this test code the URL is > assumed/known to be relatively well formed. > > Roger I kept the focus on what needs to be tested. This however doesn't mean we shouldn't validate the url format. I would prefer to do that in a separate test case all together. > > > On 1/17/2017 11:26 AM, Harsha Wardhana B wrote: > > Hi Roger, > > > > Your approach is more elegant. However checking for ":0/" may not > work > > as we can have non-zero port number that can end in 0. > > > > Regards > > > > Harsha > > > > > > On Tuesday 17 January 2017 09:39 PM, Roger Riggs wrote: > >> Hi Harsha, > >> > >> On 1/16/2017 1:21 AM, Harsha Wardhana B wrote: > >>> Hi Amit, > >>> > >>> In JdpJmxRemoteDynamicPortTestCase:48 needs null/empty check for > jmx > >>> url. > >>> > >>> JdpJmxRemoteDynamicPortTestCase:49, array length needs to checked > >>> before accessing index at token[6]. > >>> > >>> It is possible that port number need not always be present at given > >>> index and hence we may have to follow different approach to extract > >>> port number. Please check if approach below works. > >>> > >>> > >>> > >>> int idx = jmxurl.indexOf(':'); > >>> while (idx != -1) { > >>> jmxurl = jmxurl.substring(idx+1); > >>> idx = jmxurl.indexOf(':'); > >>> } > >> This loop would very eagerly find the last ":" in the string even it > >> was well past the host/port field. > >> String.lastIndex would be equivalent. > >>> > >>> if(jmxurl.indexOf('/') == -1) { > >>> throw new RuntimeException("Test failed : Invalid > >>> JMXServiceURL"); > >>> } > >> It would be more efficient to compare the index of the '/' after the > >> last ":" than to re-create new substrings. > >> int colon = jmxurl.lastIndexOf(':'); > >> int slash = jmxurl.indexOf('/', colon); int port = > >> Integer.parseInt(jmxurl, colon + 1, slash, 10); > >> > >>> > >>> String portStr = jmxurl.substring(0,jmxurl.indexOf('/')); > >>> int port = Integer.parseInt(portStr); > >>> if( port == 0 ) { > >>> throw new RuntimeException("Test failed : Zero port for > >>> jmxremote"); > >>> } > >> Or It might be just as effective to just to check if ":0/" is > present. > >> if (jmxurl.contains(":0/")) {...} > >> > >> $.02, Roger > >> > >> > >>> > >>> > >>> > >>> Regards > >>> > >>> Harsha > >>> > >>> > >>> On Monday 16 January 2017 11:16 AM, Amit Sapre wrote: > >>>> Thanks Dmitry for the review. > >>>> > >>>> Can I have one more reviewer for this fix ? > >>>> > >>>> Thanks, > >>>> Amit > >>>> > >>>>> -----Original Message----- > >>>>> From: Dmitry Samersoff > >>>>> Sent: Sunday, January 15, 2017 4:49 PM > >>>>> To: Amit Sapre; serviceability-dev > >>>>> Subject: Re: RFR : JDK-8167337 - When jmxremote.port=0, JDP > >>>>> broadcasts "0" instead of assigned port > >>>>> > >>>>> Amit, > >>>>> > >>>>> Changes looks good to me. > >>>>> > >>>>> -Dmitry > >>>>> > >>>>> > >>>>> On 2017-01-13 09:17, Amit Sapre wrote: > >>>>>> Hello, > >>>>>> > >>>>>> > >>>>>> > >>>>>> Please review the fix for JDK-8167337 > >>>>>> > >>>>>> > >>>>>> > >>>>>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8167337 > >>>>>> > >>>>>> Webrev : > >>>>>> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK- > 8167337/webrev > >>>>>> .00/ > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Amit > >>>>>> > >>>>> > >>>>> -- > >>>>> Dmitry Samersoff > >>>>> Oracle Java development team, Saint Petersburg, Russia > >>>>> * I would love to change the world, but they won't give me the > >>>>> sources. > >>> > >> > > > From Alan.Bateman at oracle.com Wed Jan 18 09:40:21 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Jan 2017 09:40:21 +0000 Subject: RFR (XS): 8172261: [JVMTI] Specification for early VM start event needs to lower expectations in relation class loading In-Reply-To: References: Message-ID: On 18/01/2017 01:03, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8172261 > > webrev: http://cr.openjdk.java.net/~dholmes/8172261/webrev/ This looks okay. It might be a bit easier to read if "and attempts" were a new sentence, as in: "... as it may not be possible to load classes. Attempts to ..." This doesn't change anything semantically of course. -Alan From david.holmes at oracle.com Wed Jan 18 12:12:33 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Jan 2017 22:12:33 +1000 Subject: RFR (XS): 8172261: [JVMTI] Specification for early VM start event needs to lower expectations in relation class loading In-Reply-To: References: Message-ID: On 18/01/2017 7:40 PM, Alan Bateman wrote: > > > On 18/01/2017 01:03, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8172261 >> >> webrev: http://cr.openjdk.java.net/~dholmes/8172261/webrev/ > This looks okay. It might be a bit easier to read if "and attempts" were > a new sentence, as in: > > "... as it may not be possible to load classes. Attempts to ..." > > This doesn't change anything semantically of course. Thanks Alan. As this already went through CCC I prefer to leave it as is. Also I don't think it would be grammatically correct as the new sentence lacks a subject. David > -Alan From amit.sapre at oracle.com Thu Jan 19 11:54:59 2017 From: amit.sapre at oracle.com (Amit Sapre) Date: Thu, 19 Jan 2017 03:54:59 -0800 (PST) Subject: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts "0" instead of assigned port In-Reply-To: References: <1c49ec63-f79a-4501-8f0b-dee7379a3061@default> <1f26fc9b-064f-c76a-15f9-a73bf6858824@oracle.com> <18af09d1-2810-e138-25ca-81c484180673@Oracle.com> <3ef61a9e-a3f3-5080-776b-925860487d47@Oracle.com> Message-ID: <761915a2-b5d3-4e25-bff2-65e8f92c6d16@default> Hi, I updated the parsing logic for extracting port number in test case. Here is the updated webrev : http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8167337/webrev.01/ Thanks, Amit > -----Original Message----- > From: Amit Sapre > Sent: Wednesday, January 18, 2017 2:09 PM > To: Roger Riggs; serviceability-dev at openjdk.java.net; Harsha Wardhana B > Subject: RE: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts > "0" instead of assigned port > > Hello, > > Looks like basic check on Jdp packet includes a check for > JMX_SERVICE_URL > https://java.se.oracle.com/source/xref/jdk9- > dev/jdk/test/sun/management/jdp/JdpTestCase.java#184 > > I feel we don't need any further check on jmx service url. > > > > -----Original Message----- > > From: Roger Riggs > > Sent: Tuesday, January 17, 2017 10:05 PM > > To: serviceability-dev at openjdk.java.net > > Subject: Re: RFR : JDK-8167337 - When jmxremote.port=0, JDP > broadcasts > > "0" instead of assigned port > > > > Hi, > > > > yes, but the pattern looks for the ":" before and the "/" after the > > zero. > > It would not match the port ":000000/" ; in this test code the URL is > > assumed/known to be relatively well formed. > > > > Roger > > I kept the focus on what needs to be tested. This however doesn't mean > we shouldn't validate the url format. > I would prefer to do that in a separate test case all together. > > > > > > > On 1/17/2017 11:26 AM, Harsha Wardhana B wrote: > > > Hi Roger, > > > > > > Your approach is more elegant. However checking for ":0/" may not > > work > > > as we can have non-zero port number that can end in 0. > > > > > > Regards > > > > > > Harsha > > > > > > > > > On Tuesday 17 January 2017 09:39 PM, Roger Riggs wrote: > > >> Hi Harsha, > > >> > > >> On 1/16/2017 1:21 AM, Harsha Wardhana B wrote: > > >>> Hi Amit, > > >>> > > >>> In JdpJmxRemoteDynamicPortTestCase:48 needs null/empty check for > > jmx > > >>> url. > > >>> > > >>> JdpJmxRemoteDynamicPortTestCase:49, array length needs to checked > > >>> before accessing index at token[6]. > > >>> > > >>> It is possible that port number need not always be present at > > >>> given index and hence we may have to follow different approach to > > >>> extract port number. Please check if approach below works. > > >>> > > >>> > > >>> > > >>> int idx = jmxurl.indexOf(':'); > > >>> while (idx != -1) { > > >>> jmxurl = jmxurl.substring(idx+1); > > >>> idx = jmxurl.indexOf(':'); > > >>> } > > >> This loop would very eagerly find the last ":" in the string even > > >> it was well past the host/port field. > > >> String.lastIndex would be equivalent. > > >>> > > >>> if(jmxurl.indexOf('/') == -1) { > > >>> throw new RuntimeException("Test failed : Invalid > > >>> JMXServiceURL"); > > >>> } > > >> It would be more efficient to compare the index of the '/' after > > >> the last ":" than to re-create new substrings. > > >> int colon = jmxurl.lastIndexOf(':'); int slash = > > >> jmxurl.indexOf('/', colon); int port = Integer.parseInt(jmxurl, > > >> colon + 1, slash, 10); > > >> > > >>> > > >>> String portStr = jmxurl.substring(0,jmxurl.indexOf('/')); > > >>> int port = Integer.parseInt(portStr); > > >>> if( port == 0 ) { > > >>> throw new RuntimeException("Test failed : Zero port > > >>> for jmxremote"); > > >>> } > > >> Or It might be just as effective to just to check if ":0/" is > > present. > > >> if (jmxurl.contains(":0/")) {...} > > >> > > >> $.02, Roger > > >> > > >> > > >>> > > >>> > > >>> > > >>> Regards > > >>> > > >>> Harsha > > >>> > > >>> > > >>> On Monday 16 January 2017 11:16 AM, Amit Sapre wrote: > > >>>> Thanks Dmitry for the review. > > >>>> > > >>>> Can I have one more reviewer for this fix ? > > >>>> > > >>>> Thanks, > > >>>> Amit > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Dmitry Samersoff > > >>>>> Sent: Sunday, January 15, 2017 4:49 PM > > >>>>> To: Amit Sapre; serviceability-dev > > >>>>> Subject: Re: RFR : JDK-8167337 - When jmxremote.port=0, JDP > > >>>>> broadcasts "0" instead of assigned port > > >>>>> > > >>>>> Amit, > > >>>>> > > >>>>> Changes looks good to me. > > >>>>> > > >>>>> -Dmitry > > >>>>> > > >>>>> > > >>>>> On 2017-01-13 09:17, Amit Sapre wrote: > > >>>>>> Hello, > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Please review the fix for JDK-8167337 > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8167337 > > >>>>>> > > >>>>>> Webrev : > > >>>>>> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK- > > 8167337/webrev > > >>>>>> .00/ > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Thanks, > > >>>>>> > > >>>>>> Amit > > >>>>>> > > >>>>> > > >>>>> -- > > >>>>> Dmitry Samersoff > > >>>>> Oracle Java development team, Saint Petersburg, Russia > > >>>>> * I would love to change the world, but they won't give me the > > >>>>> sources. > > >>> > > >> > > > > > From daniel.fuchs at oracle.com Thu Jan 19 15:30:51 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 19 Jan 2017 15:30:51 +0000 Subject: 8172971: java.management could use System.Logger Message-ID: Hi, Please find below a patch for: 8172971: java.management could use System.Logger https://bugs.openjdk.java.net/browse/JDK-8172971 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8172971/webrev.00/ I have also added a new test: test/sun/management/LoggingTest/LoggingTest.java This is a simple smoke test that verifies that we still get expected debug traces when creating and populating the platform MBeanServer. This test should always pass - whether the fix is present or not. best regards, -- daniel From jini.george at oracle.com Thu Jan 19 16:40:24 2017 From: jini.george at oracle.com (Jini George) Date: Thu, 19 Jan 2017 22:10:24 +0530 Subject: RFR: JDK-8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow Message-ID: <5880EBF8.1080607@oracle.com> Hi, Requesting for reviews for the following SA issue: https://bugs.openjdk.java.net/browse/JDK-8171084 Webrev:http://cr.openjdk.java.net/~jgeorge/8171084/webrev.00/ Thanks, Jini. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Thu Jan 19 17:12:03 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 Jan 2017 09:12:03 -0800 Subject: 8172971: java.management could use System.Logger In-Reply-To: References: Message-ID: <9D6C2F96-6375-40BC-B33D-200D38B0F27C@oracle.com> > On Jan 19, 2017, at 7:30 AM, Daniel Fuchs wrote: > > Hi, > > Please find below a patch for: > > 8172971: java.management could use System.Logger > https://bugs.openjdk.java.net/browse/JDK-8172971 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8172971/webrev.00/ > This looks good in general and pretty straight forward change. Is it intentional to change the level FINEST to DEBUG as opposed to TRACE in a couple places? For example, src/java.management/share/classes/javax/management/MBeanServerFactory.java - if (MBEANSERVER_LOGGER.isLoggable(Level.FINEST)) { + if (MBEANSERVER_LOGGER.isLoggable(Level.DEBUG)) { src/java.management/share/classes/com/sun/jmx/mbeanserver/MBeanServerDelegateImpl.java - if (MBEANSERVER_LOGGER.isLoggable(Level.FINEST)) { - MBEANSERVER_LOGGER.logp(Level.FINEST, - MBeanServerDelegateImpl.class.getName(), - "getAttributes", + if (MBEANSERVER_LOGGER.isLoggable(Level.TRACE)) { + MBEANSERVER_LOGGER.log(Level.TRACE, "Attribute " + attn[i] + " not found"); } > I have also added a new test: > test/sun/management/LoggingTest/LoggingTest.java This test should have @modules java.logging and java.management. Mandy From daniel.fuchs at oracle.com Thu Jan 19 18:50:47 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 19 Jan 2017 18:50:47 +0000 Subject: 8172971: java.management could use System.Logger In-Reply-To: <9D6C2F96-6375-40BC-B33D-200D38B0F27C@oracle.com> References: <9D6C2F96-6375-40BC-B33D-200D38B0F27C@oracle.com> Message-ID: Hi Mandy, Thanks for the review! On 19/01/17 17:12, Mandy Chung wrote: > >> On Jan 19, 2017, at 7:30 AM, Daniel Fuchs wrote: >> >> Hi, >> >> Please find below a patch for: >> >> 8172971: java.management could use System.Logger >> https://bugs.openjdk.java.net/browse/JDK-8172971 >> >> webrev: >> http://cr.openjdk.java.net/~dfuchs/webrev_8172971/webrev.00/ >> > > This looks good in general and pretty straight forward change. > > Is it intentional to change the level FINEST to DEBUG as opposed to TRACE in a couple places? For example, The regular mapping would be: [CONFIG,FINE] -> DEBUG, [FINER,FINEST] -> TRACE. There are a couple of places were unexpected exceptions where traced at level FINEST, and I arbitrarily decided that they should rather be traced with level DEBUG. > src/java.management/share/classes/javax/management/MBeanServerFactory.java > - if (MBEANSERVER_LOGGER.isLoggable(Level.FINEST)) { > + if (MBEANSERVER_LOGGER.isLoggable(Level.DEBUG)) { > > src/java.management/share/classes/com/sun/jmx/mbeanserver/MBeanServerDelegateImpl.java > - if (MBEANSERVER_LOGGER.isLoggable(Level.FINEST)) { > - MBEANSERVER_LOGGER.logp(Level.FINEST, > - MBeanServerDelegateImpl.class.getName(), > - "getAttributes", > + if (MBEANSERVER_LOGGER.isLoggable(Level.TRACE)) { > + MBEANSERVER_LOGGER.log(Level.TRACE, > "Attribute " + attn[i] + " not found"); > } > >> I have also added a new test: >> test/sun/management/LoggingTest/LoggingTest.java > > This test should have @modules java.logging and java.management. OK - I believed @modules java.management should already be in TEST.ROOT I will double check. best regards, -- daniel > > Mandy > From mandy.chung at oracle.com Thu Jan 19 19:07:11 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 Jan 2017 11:07:11 -0800 Subject: 8172971: java.management could use System.Logger In-Reply-To: References: <9D6C2F96-6375-40BC-B33D-200D38B0F27C@oracle.com> Message-ID: <0ED0BC42-B8ED-4AA7-A0E9-B1423524A507@oracle.com> > On Jan 19, 2017, at 10:50 AM, Daniel Fuchs wrote: > > Hi Mandy, > > Thanks for the review! > > On 19/01/17 17:12, Mandy Chung wrote: >> >> >> Is it intentional to change the level FINEST to DEBUG as opposed to TRACE in a couple places? For example, > > The regular mapping would be: > [CONFIG,FINE] -> DEBUG, > [FINER,FINEST] -> TRACE. > > There are a couple of places were unexpected exceptions where traced > at level FINEST, and I arbitrarily decided that they should rather > be traced with level DEBUG. > That?s fine since there isn?t a very clear policy when to use FINEST and FINER anyway. >> >> This test should have @modules java.logging and java.management. > > OK - I believed @modules java.management should already be in TEST.ROOT > I will double check. If @modules is specified in a test, it will override the one in TEST.properties (I think that?s what you meant). In any case, this test depends on java.logging. Mandy From Roger.Riggs at Oracle.com Thu Jan 19 20:18:46 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 19 Jan 2017 15:18:46 -0500 Subject: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts "0" instead of assigned port In-Reply-To: <761915a2-b5d3-4e25-bff2-65e8f92c6d16@default> References: <1c49ec63-f79a-4501-8f0b-dee7379a3061@default> <1f26fc9b-064f-c76a-15f9-a73bf6858824@oracle.com> <18af09d1-2810-e138-25ca-81c484180673@Oracle.com> <3ef61a9e-a3f3-5080-776b-925860487d47@Oracle.com> <761915a2-b5d3-4e25-bff2-65e8f92c6d16@default> Message-ID: <034f463e-a468-ebfa-0e63-14b6aa2589fa@Oracle.com> Hi Amit, Looks fine to me. Thanks, Roger On 1/19/2017 6:54 AM, Amit Sapre wrote: > Hi, > I updated the parsing logic for extracting port number in test case. Here is the updated webrev : > > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8167337/webrev.01/ > > Thanks, > Amit > >> -----Original Message----- >> From: Amit Sapre >> Sent: Wednesday, January 18, 2017 2:09 PM >> To: Roger Riggs; serviceability-dev at openjdk.java.net; Harsha Wardhana B >> Subject: RE: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts >> "0" instead of assigned port >> >> Hello, >> >> Looks like basic check on Jdp packet includes a check for >> JMX_SERVICE_URL >> https://java.se.oracle.com/source/xref/jdk9- >> dev/jdk/test/sun/management/jdp/JdpTestCase.java#184 >> >> I feel we don't need any further check on jmx service url. >> >> >>> -----Original Message----- >>> From: Roger Riggs >>> Sent: Tuesday, January 17, 2017 10:05 PM >>> To: serviceability-dev at openjdk.java.net >>> Subject: Re: RFR : JDK-8167337 - When jmxremote.port=0, JDP >> broadcasts >>> "0" instead of assigned port >>> >>> Hi, >>> >>> yes, but the pattern looks for the ":" before and the "/" after the >>> zero. >>> It would not match the port ":000000/" ; in this test code the URL is >>> assumed/known to be relatively well formed. >>> >>> Roger >> I kept the focus on what needs to be tested. This however doesn't mean >> we shouldn't validate the url format. >> I would prefer to do that in a separate test case all together. >> >>> >>> On 1/17/2017 11:26 AM, Harsha Wardhana B wrote: >>>> Hi Roger, >>>> >>>> Your approach is more elegant. However checking for ":0/" may not >>> work >>>> as we can have non-zero port number that can end in 0. >>>> >>>> Regards >>>> >>>> Harsha >>>> >>>> >>>> On Tuesday 17 January 2017 09:39 PM, Roger Riggs wrote: >>>>> Hi Harsha, >>>>> >>>>> On 1/16/2017 1:21 AM, Harsha Wardhana B wrote: >>>>>> Hi Amit, >>>>>> >>>>>> In JdpJmxRemoteDynamicPortTestCase:48 needs null/empty check for >>> jmx >>>>>> url. >>>>>> >>>>>> JdpJmxRemoteDynamicPortTestCase:49, array length needs to checked >>>>>> before accessing index at token[6]. >>>>>> >>>>>> It is possible that port number need not always be present at >>>>>> given index and hence we may have to follow different approach to >>>>>> extract port number. Please check if approach below works. >>>>>> >>>>>> >>>>>> >>>>>> int idx = jmxurl.indexOf(':'); >>>>>> while (idx != -1) { >>>>>> jmxurl = jmxurl.substring(idx+1); >>>>>> idx = jmxurl.indexOf(':'); >>>>>> } >>>>> This loop would very eagerly find the last ":" in the string even >>>>> it was well past the host/port field. >>>>> String.lastIndex would be equivalent. >>>>>> if(jmxurl.indexOf('/') == -1) { >>>>>> throw new RuntimeException("Test failed : Invalid >>>>>> JMXServiceURL"); >>>>>> } >>>>> It would be more efficient to compare the index of the '/' after >>>>> the last ":" than to re-create new substrings. >>>>> int colon = jmxurl.lastIndexOf(':'); int slash = >>>>> jmxurl.indexOf('/', colon); int port = Integer.parseInt(jmxurl, >>>>> colon + 1, slash, 10); >>>>> >>>>>> String portStr = jmxurl.substring(0,jmxurl.indexOf('/')); >>>>>> int port = Integer.parseInt(portStr); >>>>>> if( port == 0 ) { >>>>>> throw new RuntimeException("Test failed : Zero port >>>>>> for jmxremote"); >>>>>> } >>>>> Or It might be just as effective to just to check if ":0/" is >>> present. >>>>> if (jmxurl.contains(":0/")) {...} >>>>> >>>>> $.02, Roger >>>>> >>>>> >>>>>> >>>>>> >>>>>> Regards >>>>>> >>>>>> Harsha >>>>>> >>>>>> >>>>>> On Monday 16 January 2017 11:16 AM, Amit Sapre wrote: >>>>>>> Thanks Dmitry for the review. >>>>>>> >>>>>>> Can I have one more reviewer for this fix ? >>>>>>> >>>>>>> Thanks, >>>>>>> Amit >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Dmitry Samersoff >>>>>>>> Sent: Sunday, January 15, 2017 4:49 PM >>>>>>>> To: Amit Sapre; serviceability-dev >>>>>>>> Subject: Re: RFR : JDK-8167337 - When jmxremote.port=0, JDP >>>>>>>> broadcasts "0" instead of assigned port >>>>>>>> >>>>>>>> Amit, >>>>>>>> >>>>>>>> Changes looks good to me. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2017-01-13 09:17, Amit Sapre wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Please review the fix for JDK-8167337 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8167337 >>>>>>>>> >>>>>>>>> Webrev : >>>>>>>>> http://cr.openjdk.java.net/~asapre/webrev/2017/JDK- >>> 8167337/webrev >>>>>>>>> .00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Amit >>>>>>>>> >>>>>>>> -- >>>>>>>> Dmitry Samersoff >>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>> * I would love to change the world, but they won't give me the >>>>>>>> sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Jan 20 01:57:03 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Jan 2017 11:57:03 +1000 Subject: RFR: JDK-8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow In-Reply-To: <5880EBF8.1080607@oracle.com> References: <5880EBF8.1080607@oracle.com> Message-ID: Hi Jini, Seems reasonable. I don't fully understand all the details here but have one non trivial comment ... On 20/01/2017 2:40 AM, Jini George wrote: > Hi, Requesting for reviews for the following SA issue: > > https://bugs.openjdk.java.net/browse/JDK-8171084 > Webrev:http://cr.openjdk.java.net/~jgeorge/8171084/webrev.00/ src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java This change: 870 protected void writeInstance(Instance instance, int length) throws IOException { seems incorrect. It adds a length parameter that is unused and also creates an overload, rather than override of the inherited version. As a result this code: 612 writeInstance(instance); will call the super version in AbstractHeapGraphWriter. Minor nit: 379 private static final long MAX_U4_VALUE = 4294967295L; would be clearer as: 379 private static final long MAX_U4_VALUE = 0xFFFFFFFFL; --- test/serviceability/sa/LingeredAppWithLargeArray.java Style nit: 27 public int hugeArray[]; should be 27 public int[] hugeArray; but why public ?? I don't know how LingeredApp works, but this looks odd: 32 public static void main(String args[]) { 33 LingeredAppWithLargeArray appObject = new LingeredAppWithLargeArray(); 34 LingeredApp.main(args); 35 } as the appObject is never used. ?? --- test/serviceability/sa/TestHeapDumpForLargeArray.java Why is the test excluded on Mac? Thanks, David ----- > Thanks, > Jini. From amit.sapre at oracle.com Fri Jan 20 12:57:26 2017 From: amit.sapre at oracle.com (Amit Sapre) Date: Fri, 20 Jan 2017 04:57:26 -0800 (PST) Subject: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts "0" instead of assigned port In-Reply-To: <034f463e-a468-ebfa-0e63-14b6aa2589fa@Oracle.com> References: <1c49ec63-f79a-4501-8f0b-dee7379a3061@default> <1f26fc9b-064f-c76a-15f9-a73bf6858824@oracle.com> <18af09d1-2810-e138-25ca-81c484180673@Oracle.com> <3ef61a9e-a3f3-5080-776b-925860487d47@Oracle.com> <761915a2-b5d3-4e25-bff2-65e8f92c6d16@default> <034f463e-a468-ebfa-0e63-14b6aa2589fa@Oracle.com> Message-ID: Thanks for the review Roger ! From: Roger Riggs Sent: Friday, January 20, 2017 1:49 AM To: Amit Sapre; serviceability-dev at openjdk.java.net Cc: Harsha Wardhana B; Dmitry Samersoff Subject: Re: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts "0" instead of assigned port Hi Amit, Looks fine to me. Thanks, Roger On 1/19/2017 6:54 AM, Amit Sapre wrote: Hi, I updated the parsing logic for extracting port number in test case. Here is the updated webrev : http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8167337/webrev.01/ Thanks, Amit -----Original Message----- From: Amit Sapre Sent: Wednesday, January 18, 2017 2:09 PM To: Roger Riggs; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net; Harsha Wardhana B Subject: RE: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts "0" instead of assigned port Hello, Looks like basic check on Jdp packet includes a check for JMX_SERVICE_URL https://java.se.oracle.com/source/xref/jdk9- dev/jdk/test/sun/management/jdp/JdpTestCase.java#184 I feel we don't need any further check on jmx service url. -----Original Message----- From: Roger Riggs Sent: Tuesday, January 17, 2017 10:05 PM To: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts "0" instead of assigned port Hi, yes, but the pattern looks for the ":" before and the "/" after the zero. It would not match the port ":000000/" ; in this test code the URL is assumed/known to be relatively well formed. Roger I kept the focus on what needs to be tested. This however doesn't mean we shouldn't validate the url format. I would prefer to do that in a separate test case all together. On 1/17/2017 11:26 AM, Harsha Wardhana B wrote: Hi Roger, Your approach is more elegant. However checking for ":0/" may not work as we can have non-zero port number that can end in 0. Regards Harsha On Tuesday 17 January 2017 09:39 PM, Roger Riggs wrote: Hi Harsha, On 1/16/2017 1:21 AM, Harsha Wardhana B wrote: Hi Amit, In JdpJmxRemoteDynamicPortTestCase:48 needs null/empty check for jmx url. JdpJmxRemoteDynamicPortTestCase:49, array length needs to checked before accessing index at token[6]. It is possible that port number need not always be present at given index and hence we may have to follow different approach to extract port number. Please check if approach below works. int idx = jmxurl.indexOf(':'); while (idx != -1) { jmxurl = jmxurl.substring(idx+1); idx = jmxurl.indexOf(':'); } This loop would very eagerly find the last ":" in the string even it was well past the host/port field. String.lastIndex would be equivalent. if(jmxurl.indexOf('/') == -1) { throw new RuntimeException("Test failed : Invalid JMXServiceURL"); } It would be more efficient to compare the index of the '/' after the last ":" than to re-create new substrings. int colon = jmxurl.lastIndexOf(':'); int slash = jmxurl.indexOf('/', colon); int port = Integer.parseInt(jmxurl, colon + 1, slash, 10); String portStr = jmxurl.substring(0,jmxurl.indexOf('/')); int port = Integer.parseInt(portStr); if( port == 0 ) { throw new RuntimeException("Test failed : Zero port for jmxremote"); } Or It might be just as effective to just to check if ":0/" is present. if (jmxurl.contains(":0/")) {...} $.02, Roger Regards Harsha On Monday 16 January 2017 11:16 AM, Amit Sapre wrote: Thanks Dmitry for the review. Can I have one more reviewer for this fix ? Thanks, Amit -----Original Message----- From: Dmitry Samersoff Sent: Sunday, January 15, 2017 4:49 PM To: Amit Sapre; serviceability-dev Subject: Re: RFR : JDK-8167337 - When jmxremote.port=0, JDP broadcasts "0" instead of assigned port Amit, Changes looks good to me. -Dmitry On 2017-01-13 09:17, Amit Sapre wrote: Hello, Please review the fix for JDK-8167337 Bug Id : https://bugs.openjdk.java.net/browse/JDK-8167337 Webrev : http://cr.openjdk.java.net/~asapre/webrev/2017/JDK- 8167337/webrev .00/ Thanks, Amit -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Fri Jan 20 13:07:24 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 20 Jan 2017 13:07:24 +0000 Subject: 8172971: java.management could use System.Logger In-Reply-To: <0ED0BC42-B8ED-4AA7-A0E9-B1423524A507@oracle.com> References: <9D6C2F96-6375-40BC-B33D-200D38B0F27C@oracle.com> <0ED0BC42-B8ED-4AA7-A0E9-B1423524A507@oracle.com> Message-ID: Hi Mandy, On 19/01/17 19:07, Mandy Chung wrote: >>> This test should have @modules java.logging and java.management. >> OK - I believed @modules java.management should already be in TEST.ROOT >> I will double check. > If @modules is specified in a test, it will override the one in TEST.properties (I think that?s what you meant). In any case, this test depends on java.logging. I fixed the @modules tag, and added a second test that installs its own LoggerFinder and doesn't depend on java.logging. The rest is unchanged (only test changes). http://cr.openjdk.java.net/~dfuchs/webrev_8172971/webrev.01/ best regards, -- daniel From mandy.chung at oracle.com Fri Jan 20 15:42:48 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 20 Jan 2017 07:42:48 -0800 Subject: 8172971: java.management could use System.Logger In-Reply-To: References: <9D6C2F96-6375-40BC-B33D-200D38B0F27C@oracle.com> <0ED0BC42-B8ED-4AA7-A0E9-B1423524A507@oracle.com> Message-ID: <16CD0F6E-EC28-4191-9662-88EA0C5EF4CA@oracle.com> > On Jan 20, 2017, at 5:07 AM, Daniel Fuchs wrote: > > The rest is unchanged (only test changes). > > http://cr.openjdk.java.net/~dfuchs/webrev_8172971/webrev.01/ > +1 Mandy From jini.george at oracle.com Mon Jan 23 08:40:46 2017 From: jini.george at oracle.com (Jini George) Date: Mon, 23 Jan 2017 14:10:46 +0530 Subject: RFR: JDK-8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow In-Reply-To: References: <5880EBF8.1080607@oracle.com> Message-ID: <5885C18E.70103@oracle.com> Thanks much for the review, David. My answers inline: > 870 protected void writeInstance(Instance instance, int length) > throws IOException { > > seems incorrect. It adds a length parameter that is unused and also > creates an overload, rather than override of the inherited version. As > a result this code: Thank you for this very good catch! This was an accidental cut-n-paste error. I have corrected this. > Minor nit: > > 379 private static final long MAX_U4_VALUE = 4294967295L; > > would be clearer as: > > 379 private static final long MAX_U4_VALUE = 0xFFFFFFFFL; > Makes sense. Done. > test/serviceability/sa/LingeredAppWithLargeArray.java > > Style nit: > > 27 public int hugeArray[]; > > should be > > 27 public int[] hugeArray; > > but why public ?? No particular reason. Changed it. > > I don't know how LingeredApp works, but this looks odd: > > 32 public static void main(String args[]) { > 33 LingeredAppWithLargeArray appObject = new > LingeredAppWithLargeArray(); > 34 LingeredApp.main(args); > 35 } > > as the appObject is never used. ?? I have changed the test case now to have the array allocation done in main() and not in the constructor. > test/serviceability/sa/TestHeapDumpForLargeArray.java > > Why is the test excluded on Mac? There used to be SA related failures on Mac a while back, but it seems those have gotten fixed with 8169638 and probably 8160376 . I am removing the restriction and will be running the tests. Planning on sending out a new webrev once the testing comes clean. Thanks, Jini. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Thu Jan 26 08:26:42 2017 From: jini.george at oracle.com (Jini George) Date: Thu, 26 Jan 2017 13:56:42 +0530 Subject: RFR: JDK-8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow In-Reply-To: <5885C18E.70103@oracle.com> References: <5880EBF8.1080607@oracle.com> <5885C18E.70103@oracle.com> Message-ID: <5889B2C2.1090004@oracle.com> Modified webrev: http://cr.openjdk.java.net/~jgeorge/8171084/webrev.01/index.html Requesting one more Reviewer also to take a look at this. Thank you, Jini. On 1/23/2017 2:10 PM, Jini George wrote: > Thanks much for the review, David. My answers inline: > >> 870 protected void writeInstance(Instance instance, int length) >> throws IOException { >> >> seems incorrect. It adds a length parameter that is unused and also >> creates an overload, rather than override of the inherited version. >> As a result this code: > Thank you for this very good catch! This was an accidental cut-n-paste > error. I have corrected this. >> Minor nit: >> >> 379 private static final long MAX_U4_VALUE = 4294967295L; >> >> would be clearer as: >> >> 379 private static final long MAX_U4_VALUE = 0xFFFFFFFFL; >> > Makes sense. Done. >> test/serviceability/sa/LingeredAppWithLargeArray.java >> >> Style nit: >> >> 27 public int hugeArray[]; >> >> should be >> >> 27 public int[] hugeArray; >> >> but why public ?? > No particular reason. Changed it. >> >> I don't know how LingeredApp works, but this looks odd: >> >> 32 public static void main(String args[]) { >> 33 LingeredAppWithLargeArray appObject = new >> LingeredAppWithLargeArray(); >> 34 LingeredApp.main(args); >> 35 } >> >> as the appObject is never used. ?? > I have changed the test case now to have the array allocation done in > main() and not in the constructor. >> test/serviceability/sa/TestHeapDumpForLargeArray.java >> >> Why is the test excluded on Mac? > There used to be SA related failures on Mac a while back, but it seems > those have gotten fixed with 8169638 > and probably > 8160376 . I am > removing the restriction and will be running the tests. Planning on > sending out a new webrev once the testing comes clean. > > Thanks, > Jini. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Thu Jan 26 09:19:17 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 26 Jan 2017 12:19:17 +0300 Subject: RFR: JDK-8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow In-Reply-To: <5889B2C2.1090004@oracle.com> References: <5880EBF8.1080607@oracle.com> <5885C18E.70103@oracle.com> <5889B2C2.1090004@oracle.com> Message-ID: <1daa0dab-19d9-2ff3-fb90-789365264ec0@oracle.com> Jini, The changes looks good to me besides some nits (below) don't need to re-review. HeapHprofBinWriter.java 494 - missed space before bracket 536, 810 - could you add something like "Unknown type " to "shouldn't reach here" message. 751, 769 - it might be better to create a separate int headerSize() function. heapDumper.cpp:1077 I understand the reason of removing do-nothing code, but it's the only changes outside of SA and it clearly out of scope of this CR. So it might be better to don't change hotspot heapdumper. TestHeapDumpForLargeArray.java: I'm not sure we should add long and resource consuming test to every-night test pile. It might be better to add @ignore to this test with a proper comments and run it manually if we see a problem with SA dumper (but it's just an opinion - I'm OK to leave it as is). -Dmitry On 2017-01-26 11:26, Jini George wrote: > Modified webrev: > http://cr.openjdk.java.net/~jgeorge/8171084/webrev.01/index.html > > Requesting one more Reviewer also to take a look at this. > > Thank you, > Jini. > > On 1/23/2017 2:10 PM, Jini George wrote: >> Thanks much for the review, David. My answers inline: >> >>> 870 protected void writeInstance(Instance instance, int length) >>> throws IOException { >>> >>> seems incorrect. It adds a length parameter that is unused and also >>> creates an overload, rather than override of the inherited version. >>> As a result this code: >> Thank you for this very good catch! This was an accidental cut-n-paste >> error. I have corrected this. >>> Minor nit: >>> >>> 379 private static final long MAX_U4_VALUE = 4294967295L; >>> >>> would be clearer as: >>> >>> 379 private static final long MAX_U4_VALUE = 0xFFFFFFFFL; >>> >> Makes sense. Done. >>> test/serviceability/sa/LingeredAppWithLargeArray.java >>> >>> Style nit: >>> >>> 27 public int hugeArray[]; >>> >>> should be >>> >>> 27 public int[] hugeArray; >>> >>> but why public ?? >> No particular reason. Changed it. >>> >>> I don't know how LingeredApp works, but this looks odd: >>> >>> 32 public static void main(String args[]) { >>> 33 LingeredAppWithLargeArray appObject = new >>> LingeredAppWithLargeArray(); >>> 34 LingeredApp.main(args); >>> 35 } >>> >>> as the appObject is never used. ?? >> I have changed the test case now to have the array allocation done in >> main() and not in the constructor. >>> test/serviceability/sa/TestHeapDumpForLargeArray.java >>> >>> Why is the test excluded on Mac? >> There used to be SA related failures on Mac a while back, but it seems >> those have gotten fixed with 8169638 >> and probably >> 8160376 . I am >> removing the restriction and will be running the tests. Planning on >> sending out a new webrev once the testing comes clean. >> >> Thanks, >> Jini. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jini.george at oracle.com Fri Jan 27 04:49:39 2017 From: jini.george at oracle.com (Jini George) Date: Fri, 27 Jan 2017 10:19:39 +0530 Subject: RFR: JDK-8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow In-Reply-To: <1daa0dab-19d9-2ff3-fb90-789365264ec0@oracle.com> References: <5880EBF8.1080607@oracle.com> <5885C18E.70103@oracle.com> <5889B2C2.1090004@oracle.com> <1daa0dab-19d9-2ff3-fb90-789365264ec0@oracle.com> Message-ID: <588AD163.6010102@oracle.com> Thank you very much, Dmitry, for the review. I am addressing all your comments, except for the @ignore in the test. -jini On 1/26/2017 2:49 PM, Dmitry Samersoff wrote: > Jini, > > The changes looks good to me besides some nits (below) don't need to > re-review. > > HeapHprofBinWriter.java > > 494 - missed space before bracket > > 536, 810 - could you add something like "Unknown type " to "shouldn't > reach here" message. > > 751, 769 - it might be better to create a separate int headerSize() > function. > > heapDumper.cpp:1077 > > I understand the reason of removing do-nothing code, but it's the only > changes outside of SA and it clearly out of scope of this CR. > > So it might be better to don't change hotspot heapdumper. > > TestHeapDumpForLargeArray.java: > > I'm not sure we should add long and resource consuming test to > every-night test pile. > > It might be better to add @ignore to this test with a proper comments > and run it manually if we see a problem with SA dumper (but it's just an > opinion - I'm OK to leave it as is). > > -Dmitry > > > On 2017-01-26 11:26, Jini George wrote: >> Modified webrev: >> http://cr.openjdk.java.net/~jgeorge/8171084/webrev.01/index.html >> >> Requesting one more Reviewer also to take a look at this. >> >> Thank you, >> Jini. >> >> On 1/23/2017 2:10 PM, Jini George wrote: >>> Thanks much for the review, David. My answers inline: >>> >>>> 870 protected void writeInstance(Instance instance, int length) >>>> throws IOException { >>>> >>>> seems incorrect. It adds a length parameter that is unused and also >>>> creates an overload, rather than override of the inherited version. >>>> As a result this code: >>> Thank you for this very good catch! This was an accidental cut-n-paste >>> error. I have corrected this. >>>> Minor nit: >>>> >>>> 379 private static final long MAX_U4_VALUE = 4294967295L; >>>> >>>> would be clearer as: >>>> >>>> 379 private static final long MAX_U4_VALUE = 0xFFFFFFFFL; >>>> >>> Makes sense. Done. >>>> test/serviceability/sa/LingeredAppWithLargeArray.java >>>> >>>> Style nit: >>>> >>>> 27 public int hugeArray[]; >>>> >>>> should be >>>> >>>> 27 public int[] hugeArray; >>>> >>>> but why public ?? >>> No particular reason. Changed it. >>>> I don't know how LingeredApp works, but this looks odd: >>>> >>>> 32 public static void main(String args[]) { >>>> 33 LingeredAppWithLargeArray appObject = new >>>> LingeredAppWithLargeArray(); >>>> 34 LingeredApp.main(args); >>>> 35 } >>>> >>>> as the appObject is never used. ?? >>> I have changed the test case now to have the array allocation done in >>> main() and not in the constructor. >>>> test/serviceability/sa/TestHeapDumpForLargeArray.java >>>> >>>> Why is the test excluded on Mac? >>> There used to be SA related failures on Mac a while back, but it seems >>> those have gotten fixed with 8169638 >>> and probably >>> 8160376 . I am >>> removing the restriction and will be running the tests. Planning on >>> sending out a new webrev once the testing comes clean. >>> >>> Thanks, >>> Jini. > From david.holmes at oracle.com Fri Jan 27 05:56:10 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Jan 2017 15:56:10 +1000 Subject: RFR: JDK-8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow In-Reply-To: <588AD163.6010102@oracle.com> References: <5880EBF8.1080607@oracle.com> <5885C18E.70103@oracle.com> <5889B2C2.1090004@oracle.com> <1daa0dab-19d9-2ff3-fb90-789365264ec0@oracle.com> <588AD163.6010102@oracle.com> Message-ID: <2de31ba5-8300-66ab-8ecb-e92bc5e88895@oracle.com> Updates looks good to me too Jini! Thanks, David On 27/01/2017 2:49 PM, Jini George wrote: > Thank you very much, Dmitry, for the review. I am addressing all your > comments, except for the @ignore in the test. > > -jini > > On 1/26/2017 2:49 PM, Dmitry Samersoff wrote: >> Jini, >> >> The changes looks good to me besides some nits (below) don't need to >> re-review. >> >> HeapHprofBinWriter.java >> >> 494 - missed space before bracket >> >> 536, 810 - could you add something like "Unknown type " to "shouldn't >> reach here" message. >> >> 751, 769 - it might be better to create a separate int headerSize() >> function. >> >> heapDumper.cpp:1077 >> >> I understand the reason of removing do-nothing code, but it's the only >> changes outside of SA and it clearly out of scope of this CR. >> >> So it might be better to don't change hotspot heapdumper. >> >> TestHeapDumpForLargeArray.java: >> >> I'm not sure we should add long and resource consuming test to >> every-night test pile. >> >> It might be better to add @ignore to this test with a proper comments >> and run it manually if we see a problem with SA dumper (but it's just an >> opinion - I'm OK to leave it as is). >> >> -Dmitry >> >> >> On 2017-01-26 11:26, Jini George wrote: >>> Modified webrev: >>> http://cr.openjdk.java.net/~jgeorge/8171084/webrev.01/index.html >>> >>> >>> Requesting one more Reviewer also to take a look at this. >>> >>> Thank you, >>> Jini. >>> >>> On 1/23/2017 2:10 PM, Jini George wrote: >>>> Thanks much for the review, David. My answers inline: >>>> >>>>> 870 protected void writeInstance(Instance instance, int length) >>>>> throws IOException { >>>>> >>>>> seems incorrect. It adds a length parameter that is unused and also >>>>> creates an overload, rather than override of the inherited version. >>>>> As a result this code: >>>> Thank you for this very good catch! This was an accidental cut-n-paste >>>> error. I have corrected this. >>>>> Minor nit: >>>>> >>>>> 379 private static final long MAX_U4_VALUE = 4294967295L; >>>>> >>>>> would be clearer as: >>>>> >>>>> 379 private static final long MAX_U4_VALUE = 0xFFFFFFFFL; >>>>> >>>> Makes sense. Done. >>>>> test/serviceability/sa/LingeredAppWithLargeArray.java >>>>> >>>>> Style nit: >>>>> >>>>> 27 public int hugeArray[]; >>>>> >>>>> should be >>>>> >>>>> 27 public int[] hugeArray; >>>>> >>>>> but why public ?? >>>> No particular reason. Changed it. >>>>> I don't know how LingeredApp works, but this looks odd: >>>>> >>>>> 32 public static void main(String args[]) { >>>>> 33 LingeredAppWithLargeArray appObject = new >>>>> LingeredAppWithLargeArray(); >>>>> 34 LingeredApp.main(args); >>>>> 35 } >>>>> >>>>> as the appObject is never used. ?? >>>> I have changed the test case now to have the array allocation done in >>>> main() and not in the constructor. >>>>> test/serviceability/sa/TestHeapDumpForLargeArray.java >>>>> >>>>> Why is the test excluded on Mac? >>>> There used to be SA related failures on Mac a while back, but it seems >>>> those have gotten fixed with 8169638 >>>> and probably >>>> 8160376 . I am >>>> removing the restriction and will be running the tests. Planning on >>>> sending out a new webrev once the testing comes clean. >>>> >>>> Thanks, >>>> Jini. >> > From jini.george at oracle.com Fri Jan 27 05:58:41 2017 From: jini.george at oracle.com (Jini George) Date: Fri, 27 Jan 2017 11:28:41 +0530 Subject: RFR: JDK-8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow In-Reply-To: <2de31ba5-8300-66ab-8ecb-e92bc5e88895@oracle.com> References: <5880EBF8.1080607@oracle.com> <5885C18E.70103@oracle.com> <5889B2C2.1090004@oracle.com> <1daa0dab-19d9-2ff3-fb90-789365264ec0@oracle.com> <588AD163.6010102@oracle.com> <2de31ba5-8300-66ab-8ecb-e92bc5e88895@oracle.com> Message-ID: <588AE191.5080702@oracle.com> Thank you, David. -Jini. On 1/27/2017 11:26 AM, David Holmes wrote: > Updates looks good to me too Jini! > > Thanks, > David > > On 27/01/2017 2:49 PM, Jini George wrote: >> Thank you very much, Dmitry, for the review. I am addressing all your >> comments, except for the @ignore in the test. >> >> -jini >> >> On 1/26/2017 2:49 PM, Dmitry Samersoff wrote: >>> Jini, >>> >>> The changes looks good to me besides some nits (below) don't need to >>> re-review. >>> >>> HeapHprofBinWriter.java >>> >>> 494 - missed space before bracket >>> >>> 536, 810 - could you add something like "Unknown type " to >>> "shouldn't >>> reach here" message. >>> >>> 751, 769 - it might be better to create a separate int headerSize() >>> function. >>> >>> heapDumper.cpp:1077 >>> >>> I understand the reason of removing do-nothing code, but it's the >>> only >>> changes outside of SA and it clearly out of scope of this CR. >>> >>> So it might be better to don't change hotspot heapdumper. >>> >>> TestHeapDumpForLargeArray.java: >>> >>> I'm not sure we should add long and resource consuming test to >>> every-night test pile. >>> >>> It might be better to add @ignore to this test with a proper >>> comments >>> and run it manually if we see a problem with SA dumper (but it's >>> just an >>> opinion - I'm OK to leave it as is). >>> >>> -Dmitry >>> >>> >>> On 2017-01-26 11:26, Jini George wrote: >>>> Modified webrev: >>>> http://cr.openjdk.java.net/~jgeorge/8171084/webrev.01/index.html >>>> >>>> >>>> >>>> Requesting one more Reviewer also to take a look at this. >>>> >>>> Thank you, >>>> Jini. >>>> >>>> On 1/23/2017 2:10 PM, Jini George wrote: >>>>> Thanks much for the review, David. My answers inline: >>>>> >>>>>> 870 protected void writeInstance(Instance instance, int >>>>>> length) >>>>>> throws IOException { >>>>>> >>>>>> seems incorrect. It adds a length parameter that is unused and also >>>>>> creates an overload, rather than override of the inherited version. >>>>>> As a result this code: >>>>> Thank you for this very good catch! This was an accidental >>>>> cut-n-paste >>>>> error. I have corrected this. >>>>>> Minor nit: >>>>>> >>>>>> 379 private static final long MAX_U4_VALUE = 4294967295L; >>>>>> >>>>>> would be clearer as: >>>>>> >>>>>> 379 private static final long MAX_U4_VALUE = 0xFFFFFFFFL; >>>>>> >>>>> Makes sense. Done. >>>>>> test/serviceability/sa/LingeredAppWithLargeArray.java >>>>>> >>>>>> Style nit: >>>>>> >>>>>> 27 public int hugeArray[]; >>>>>> >>>>>> should be >>>>>> >>>>>> 27 public int[] hugeArray; >>>>>> >>>>>> but why public ?? >>>>> No particular reason. Changed it. >>>>>> I don't know how LingeredApp works, but this looks odd: >>>>>> >>>>>> 32 public static void main(String args[]) { >>>>>> 33 LingeredAppWithLargeArray appObject = new >>>>>> LingeredAppWithLargeArray(); >>>>>> 34 LingeredApp.main(args); >>>>>> 35 } >>>>>> >>>>>> as the appObject is never used. ?? >>>>> I have changed the test case now to have the array allocation done in >>>>> main() and not in the constructor. >>>>>> test/serviceability/sa/TestHeapDumpForLargeArray.java >>>>>> >>>>>> Why is the test excluded on Mac? >>>>> There used to be SA related failures on Mac a while back, but it >>>>> seems >>>>> those have gotten fixed with 8169638 >>>>> and probably >>>>> 8160376 . I am >>>>> removing the restriction and will be running the tests. Planning on >>>>> sending out a new webrev once the testing comes clean. >>>>> >>>>> Thanks, >>>>> Jini. >>> >> From david.holmes at oracle.com Fri Jan 27 09:39:26 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Jan 2017 19:39:26 +1000 Subject: (svc) JDK 10 RFR: 8173421: Obsolete and expired flags for JDK 10 need to be removed and related tests updated In-Reply-To: References: Message-ID: A small serviceability part of this change, to update some management tests that refer to flags that have been removed. webrev: http://cr.openjdk.java.net/~dholmes/8173421/webrev.jdk/ Changes: - com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java UseParNewGC is gone, but MaxNewSize will be set ergonomically. - java/lang/management/MemoryMXBean/LowMemoryTest.java - java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java ExplicitGCInvokesConcurrentAndUnloadsClasses no longer exists. - java/lang/management/MemoryMXBean/LowMemoryTest2.sh UseParNewGC no longer exists. Thanks, David On 27/01/2017 3:13 PM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8173421 > > When we try to bump the JDK version to 10 we trigger all the warnings > (and an assert) surrounding the VM deprecated/obsolete/expired flag > handling. In short anything that expires in 10 must now be removed; > anything now obsolete in 10 must go in a different table. Related > changes required to source code and tests. Gory details below. > > webrev: http://cr.openjdk.java.net/~dholmes/8173421/webrev/ > > Testing: JPRT (in progress) > Manual runs of affected regression tests > > This will be pushed to jdk10/jdk10 along with the actual change to bump > the major version number. > > There are some Zero and Aarch64 code tweaks that should have been > handled in JDK 9 but got overlooked somehow. Nothing significant. > > Thanks, > David > --- > > Non-aliased flags: > > AutoGCSelectPauseMillis (def: 5000) has now expired and is removed > completely from the source code. > > UseAutoGCSelectPolicy (def: false) has now expired and is removed > completely from the source code as-if replaced by false. > > UseParNewGC (def: false) expired. However it is expected/required to be > true whenever UseConcMarkSweepGC is true, and UseConcMarkSweepGC has not > been deprecated. So we must remove all uses as-if it were true, not false. > > ExplicitGCInvokesConcurrentAndUnloadsClasses (def: false) has now > expired and is removed completely from the source as-if replaced by false. > > ConvertSleepToYield (def: true) is now obsolete. It is moved to the > obsolete table and is removed completely from the source code as-if > replaced by true. > > ConvertYieldToSleep (def: false) is now obsolete. It is moved to the > obsolete table and is removed completely from the source code as-if > replaced by false. > > As a result of the above MinSleepInterval is no longer used (it should > have also been deprecated in 9) and is also marked as obsolete. > > --- > > Aliased options that have expired: > > CMSMarkStackSizeMax is an alias and has expired. It is removed from the > alias and obsolete flag tables. > > CMSMarkStackSize is an alias and has expired. It is removed from the > alias and obsolete flag tables. > > G1MarkStackSize is an alias and has expired. It is removed from the > alias and obsolete flag tables. > > ParallelMarkingThreads is an alias and has expired. It is removed from > the alias and obsolete flag tables. > > ParallelCMSThreads is an alias and has expired. It is removed from the > alias and obsolete flag tables. > > --- > > The following flags all expire in 10 and exist (except where noted) only > in the special-flag table (from which they are now removed). Any other > uses of the flag are removed. > > UseOldInlining > SafepointPollOffset (defined in ./cpu/aarch64/vm/c1_globals_aarch64.hpp) > UseBoundThreads (comments in os_solaris.cpp) > DefaultThreadPriority > NoYieldsInMicrolock > BackEdgeThreshold (defined in c1/2_globals_aarch64.hpp) > UseNewReflection > ReflectionWrapResolutionErrors > VerifyReflectionBytecodes > AutoShutdownNMT > NmethodSweepFraction > NmethodSweepCheckInterval > CodeCacheMinimumFreeSpace > UseFastAccessorMethods (ZERO) (still used in > ccpInterpreterGenerator_zero.cpp, jvmtiManageCapabilities.cpp) > UseFastEmptyMethods (ZERO) (still used in > ccpInterpreterGenerator_zero.cpp, jvmtiManageCapabilities.cpp) > UseCompilerSafepoints > AdaptiveSizePausePolicy > ParallelGCRetainPLAB > ThreadSafetyMargin > LazyBootClassLoader > StarvationMonitorInterval > PreInflateSpin > JNIDetachReleasesMonitors > UseAltSigs > SegmentedHeapDumpThreshold > PrintOopAddress (comment in method.cpp) > PermSize > MaxPermSize > > --- > > Tests modified: > > runtime/CommandLine/ > ObsoleteFlagErrorMessage.java > VMDeprecatedOptions.java > VMAliasOptions.java > > gc/arguments/TestSelectDefaultGC.java > > --- > > Tests removed (TEST.groups updated as needed): > > gc/startup_warnings/ > TestUseAutoGCSelectPolicy.java > TestParNewSerialOld.java > TestParNewCMS.java > TestDefNewCMS.java > gc/arguments/TestExplicitGCInvokesConcurrentAndUnloadsClasses.java > > runtime/CommandLine/PermGenFlagsTest.java > runtime/NMT/AutoshutdownNMT.java From mandy.chung at oracle.com Sat Jan 28 21:20:59 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 28 Jan 2017 13:20:59 -0800 Subject: (svc) JDK 10 RFR: 8173421: Obsolete and expired flags for JDK 10 need to be removed and related tests updated In-Reply-To: References: Message-ID: <17755E6B-2D0E-4788-9F2D-9CC437AE4C7A@oracle.com> > On Jan 27, 2017, at 1:39 AM, David Holmes wrote: > > A small serviceability part of this change, to update some management tests that refer to flags that have been removed. > > webrev: http://cr.openjdk.java.net/~dholmes/8173421/webrev.jdk/ > This change looks okay. Mandy From ecki at zusammenkunft.net Sat Jan 28 23:40:35 2017 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 28 Jan 2017 23:40:35 +0000 (UTC) Subject: (svc) JDK 10 RFR: 8173421: Obsolete and expired flags for JDK 10 need to be removed and related tests updated In-Reply-To: <17755E6B-2D0E-4788-9F2D-9CC437AE4C7A@oracle.com> References: <17755E6B-2D0E-4788-9F2D-9CC437AE4C7A@oracle.com> Message-ID: <57A008FAA9E6E1E3.8631E8BB-532D-4F26-A749-D6E712DE4788@mail.outlook.com> The comment in LowMemoryTest2 could be fixed as well, I would remove the "8mb" Gruss Bernd -- http://bernd.eckenfels.net On Sat, Jan 28, 2017 at 10:32 PM +0100, "Mandy Chung" wrote: > On Jan 27, 2017, at 1:39 AM, David Holmes wrote: > > A small serviceability part of this change, to update some management tests that refer to flags that have been removed. > > webrev: http://cr.openjdk.java.net/~dholmes/8173421/webrev.jdk/ > This change looks okay. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sun Jan 29 09:37:53 2017 From: david.holmes at oracle.com (David Holmes) Date: Sun, 29 Jan 2017 19:37:53 +1000 Subject: (svc) JDK 10 RFR: 8173421: Obsolete and expired flags for JDK 10 need to be removed and related tests updated In-Reply-To: <17755E6B-2D0E-4788-9F2D-9CC437AE4C7A@oracle.com> References: <17755E6B-2D0E-4788-9F2D-9CC437AE4C7A@oracle.com> Message-ID: <46911bdf-e962-b976-9f09-cb18871b9854@oracle.com> Thanks Mandy! David On 29/01/2017 7:20 AM, Mandy Chung wrote: > >> On Jan 27, 2017, at 1:39 AM, David Holmes wrote: >> >> A small serviceability part of this change, to update some management tests that refer to flags that have been removed. >> >> webrev: http://cr.openjdk.java.net/~dholmes/8173421/webrev.jdk/ >> > > This change looks okay. > > Mandy > From david.holmes at oracle.com Sun Jan 29 09:38:45 2017 From: david.holmes at oracle.com (David Holmes) Date: Sun, 29 Jan 2017 19:38:45 +1000 Subject: (svc) JDK 10 RFR: 8173421: Obsolete and expired flags for JDK 10 need to be removed and related tests updated In-Reply-To: <57A008FAA9E6E1E3.8631E8BB-532D-4F26-A749-D6E712DE4788@mail.outlook.com> References: <17755E6B-2D0E-4788-9F2D-9CC437AE4C7A@oracle.com> <57A008FAA9E6E1E3.8631E8BB-532D-4F26-A749-D6E712DE4788@mail.outlook.com> Message-ID: On 29/01/2017 9:40 AM, Bernd Eckenfels wrote: > The comment in LowMemoryTest2 could be fixed as well, I would remove the > "8mb" I'll change to 16MB, or perhaps just delete the entire sentence. Thanks, David > Gruss > Bernd > -- > http://bernd.eckenfels.net > > > > > On Sat, Jan 28, 2017 at 10:32 PM +0100, "Mandy Chung" > > wrote: > > > On Jan 27, 2017, at 1:39 AM, David Holmes wrote: > > A small serviceability part of this change, to update > some management tests that refer to flags that have been removed. > > > webrev: http://cr.openjdk.java.net/~dholmes/8173421/webrev.jdk/ > > This change looks okay. Mandy > From mandy.chung at oracle.com Mon Jan 30 23:42:14 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 30 Jan 2017 15:42:14 -0800 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module Message-ID: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> java.management is the module for JMX and JMX remote API and java.lang.management. JDK management agent provides the JDK-specific out-of-the-box monitoring and management support and it?s cleaner for it to live in its own module. It is proposed to move it to a new module named `jdk.management.agent`. This change involves: 1) renaming of sun.management.Agent along with 3 other classes in sun.management package to jdk.internal.agent package 2) move sun.management.resources to jdk.internal.agent.resources 3) move sun.management.jmxremote and sun.management.jdp packages to jdk.management.agent module 4) move the configuration files under conf/management 5) sun/management/jmxremote/ConnectorBootstrap.java is updated to replace the use of the ClassLogger API with System.Logger. 6) change hotspot VM to add `jdk.management.agent` when -Dcom.sun.management.* system property is set as well as the Agent class rename Daniel is working on JDK-8173607 [1] that conflicts with this patch and require merges/coordination. We propose to integrate these changes to jdk9/dev unless there is any objection concerning that this trivial hotspot change might cause any issue. I have submitted a RBT on hotspot_runtime and hotspot_serviceability in addition to PIT test runs. thanks Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8173607 From mandy.chung at oracle.com Mon Jan 30 23:48:18 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 30 Jan 2017 15:48:18 -0800 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> Message-ID: <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html Mandy > On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: > > java.management is the module for JMX and JMX remote API and > java.lang.management. JDK management agent provides the JDK-specific > out-of-the-box monitoring and management support and it?s cleaner > for it to live in its own module. It is proposed to move it > to a new module named `jdk.management.agent`. > > This change involves: > 1) renaming of sun.management.Agent along with 3 other classes > in sun.management package to jdk.internal.agent package > > 2) move sun.management.resources to jdk.internal.agent.resources > > 3) move sun.management.jmxremote and sun.management.jdp packages > to jdk.management.agent module > > 4) move the configuration files under conf/management > > 5) sun/management/jmxremote/ConnectorBootstrap.java is updated > to replace the use of the ClassLogger API with System.Logger. > > 6) change hotspot VM to add `jdk.management.agent` when > -Dcom.sun.management.* system property is set as well as > the Agent class rename > > Daniel is working on JDK-8173607 [1] that conflicts with this > patch and require merges/coordination. > > We propose to integrate these changes to jdk9/dev unless > there is any objection concerning that this trivial hotspot change > might cause any issue. I have submitted a RBT on hotspot_runtime > and hotspot_serviceability in addition to PIT test runs. > > thanks > Mandy > [1] https://bugs.openjdk.java.net/browse/JDK-8173607 From david.holmes at oracle.com Tue Jan 31 07:00:38 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Jan 2017 17:00:38 +1000 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> Message-ID: <90abbd53-411e-645c-1c96-700bde19fd56@oracle.com> Hi Mandy, On 31/01/2017 9:48 AM, Mandy Chung wrote: > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html This all seems okay. But we have quite a few hotspot tests that include: @modules java.management/sun.management that would seem to need updating as well. Thanks, David ----- > Mandy > >> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >> >> java.management is the module for JMX and JMX remote API and >> java.lang.management. JDK management agent provides the JDK-specific >> out-of-the-box monitoring and management support and it?s cleaner >> for it to live in its own module. It is proposed to move it >> to a new module named `jdk.management.agent`. >> >> This change involves: >> 1) renaming of sun.management.Agent along with 3 other classes >> in sun.management package to jdk.internal.agent package >> >> 2) move sun.management.resources to jdk.internal.agent.resources >> >> 3) move sun.management.jmxremote and sun.management.jdp packages >> to jdk.management.agent module >> >> 4) move the configuration files under conf/management >> >> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >> to replace the use of the ClassLogger API with System.Logger. >> >> 6) change hotspot VM to add `jdk.management.agent` when >> -Dcom.sun.management.* system property is set as well as >> the Agent class rename >> >> Daniel is working on JDK-8173607 [1] that conflicts with this >> patch and require merges/coordination. >> >> We propose to integrate these changes to jdk9/dev unless >> there is any objection concerning that this trivial hotspot change >> might cause any issue. I have submitted a RBT on hotspot_runtime >> and hotspot_serviceability in addition to PIT test runs. >> >> thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 > From erik.joelsson at oracle.com Tue Jan 31 08:20:00 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 31 Jan 2017 09:20:00 +0100 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> Message-ID: <05c34397-9ba6-1cc5-048d-96d29f3af62e@oracle.com> Hello Mandy, In Lib-jdk.management.agent.gmk: OPENJDK_TARGET_OS and OPENJDK_TARGET_OS_TYPE are both "windows" on Windows platforms, so no need to treat Windows differently when defining the src dirs. The -DPSAPI_VERSION=1 seems to be copied from Lib-jdk.management.gmk and/or Lib-jdk.attach.gmk, but was not applied to the library from which the native src for this new lib was copied from. I just wonder if this is actually needed for this new library? Please remove the "LANG := C" parameter, it no longer has a meaning but it keeps reappearing due to copy pasting of old make code. Are all the libraries added to LIBS still needed for this breakout lib? And are all of them still needed for libmanagement.so from which this was split out? /Erik On 2017-01-31 00:48, Mandy Chung wrote: > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html > > Mandy > >> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >> >> java.management is the module for JMX and JMX remote API and >> java.lang.management. JDK management agent provides the JDK-specific >> out-of-the-box monitoring and management support and it?s cleaner >> for it to live in its own module. It is proposed to move it >> to a new module named `jdk.management.agent`. >> >> This change involves: >> 1) renaming of sun.management.Agent along with 3 other classes >> in sun.management package to jdk.internal.agent package >> >> 2) move sun.management.resources to jdk.internal.agent.resources >> >> 3) move sun.management.jmxremote and sun.management.jdp packages >> to jdk.management.agent module >> >> 4) move the configuration files under conf/management >> >> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >> to replace the use of the ClassLogger API with System.Logger. >> >> 6) change hotspot VM to add `jdk.management.agent` when >> -Dcom.sun.management.* system property is set as well as >> the Agent class rename >> >> Daniel is working on JDK-8173607 [1] that conflicts with this >> patch and require merges/coordination. >> >> We propose to integrate these changes to jdk9/dev unless >> there is any objection concerning that this trivial hotspot change >> might cause any issue. I have submitted a RBT on hotspot_runtime >> and hotspot_serviceability in addition to PIT test runs. >> >> thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 From mandy.chung at oracle.com Tue Jan 31 14:57:40 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Jan 2017 06:57:40 -0800 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <90abbd53-411e-645c-1c96-700bde19fd56@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> <90abbd53-411e-645c-1c96-700bde19fd56@oracle.com> Message-ID: <0769A989-4EDE-4D8E-B3C5-9AE89EFD8529@oracle.com> > On Jan 30, 2017, at 11:00 PM, David Holmes wrote: > > Hi Mandy, > > On 31/01/2017 9:48 AM, Mandy Chung wrote: >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html > > This all seems okay. > Thanks for the review. > But we have quite a few hotspot tests that include: > > @modules java.management/sun.management > Only 4 classes in the java.management/sun.management are moved to jdk.management.agent/jdk.internal.agent. From my grep on hotspot tests, no test uses those renamed classes. Mandy > that would seem to need updating as well. > > Thanks, > David > ----- > >> Mandy >> >>> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >>> >>> java.management is the module for JMX and JMX remote API and >>> java.lang.management. JDK management agent provides the JDK-specific >>> out-of-the-box monitoring and management support and it?s cleaner >>> for it to live in its own module. It is proposed to move it >>> to a new module named `jdk.management.agent`. >>> >>> This change involves: >>> 1) renaming of sun.management.Agent along with 3 other classes >>> in sun.management package to jdk.internal.agent package >>> >>> 2) move sun.management.resources to jdk.internal.agent.resources >>> >>> 3) move sun.management.jmxremote and sun.management.jdp packages >>> to jdk.management.agent module >>> >>> 4) move the configuration files under conf/management >>> >>> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >>> to replace the use of the ClassLogger API with System.Logger. >>> >>> 6) change hotspot VM to add `jdk.management.agent` when >>> -Dcom.sun.management.* system property is set as well as >>> the Agent class rename >>> >>> Daniel is working on JDK-8173607 [1] that conflicts with this >>> patch and require merges/coordination. >>> >>> We propose to integrate these changes to jdk9/dev unless >>> there is any objection concerning that this trivial hotspot change >>> might cause any issue. I have submitted a RBT on hotspot_runtime >>> and hotspot_serviceability in addition to PIT test runs. >>> >>> thanks >>> Mandy >>> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 >> From daniel.fuchs at oracle.com Tue Jan 31 15:35:30 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 31 Jan 2017 15:35:30 +0000 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> Message-ID: <3e8ce8e6-2b0d-8791-9295-c633affef22a@oracle.com> Hi Mandy, Looks good to me in general. Suggestion: FileLoginModule.java 112 private static final String PASSWORD_FILE_NAME = "jmxremote.password"; Maybe the constant could be public, then it could be referred to by ConnectorBootstrap? I see that com.sun.jmx.remote.internal is already being exported to jdk.management.agent. FileSystem.java: I wonder if this functionality should have remained in java.management. It doesn't have any type to any specific protocol - and it seems to be something that anyone using the FileLoginModule above might also need. ConnectorBootstrap.java: I would normally discourage creating helper methods (such as config()) in a class that doesn't implement System.Logger, as that will make the 'config' method appear as the source of the log message (rather than the method that calls config()). In this specific case I don't think it matters much though. It's probably better to keep it like this so as not distract reviewers from the meaningful changes, and we can clean that up any time later in a separate changeset (and possibly not before 10). best regards, -- daniel On 30/01/17 23:48, Mandy Chung wrote: > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html > > Mandy > >> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >> >> java.management is the module for JMX and JMX remote API and >> java.lang.management. JDK management agent provides the JDK-specific >> out-of-the-box monitoring and management support and it?s cleaner >> for it to live in its own module. It is proposed to move it >> to a new module named `jdk.management.agent`. >> >> This change involves: >> 1) renaming of sun.management.Agent along with 3 other classes >> in sun.management package to jdk.internal.agent package >> >> 2) move sun.management.resources to jdk.internal.agent.resources >> >> 3) move sun.management.jmxremote and sun.management.jdp packages >> to jdk.management.agent module >> >> 4) move the configuration files under conf/management >> >> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >> to replace the use of the ClassLogger API with System.Logger. >> >> 6) change hotspot VM to add `jdk.management.agent` when >> -Dcom.sun.management.* system property is set as well as >> the Agent class rename >> >> Daniel is working on JDK-8173607 [1] that conflicts with this >> patch and require merges/coordination. >> >> We propose to integrate these changes to jdk9/dev unless >> there is any objection concerning that this trivial hotspot change >> might cause any issue. I have submitted a RBT on hotspot_runtime >> and hotspot_serviceability in addition to PIT test runs. >> >> thanks >> Mandy >> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 > From mandy.chung at oracle.com Tue Jan 31 16:04:27 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Jan 2017 08:04:27 -0800 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <05c34397-9ba6-1cc5-048d-96d29f3af62e@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> <05c34397-9ba6-1cc5-048d-96d29f3af62e@oracle.com> Message-ID: > On Jan 31, 2017, at 12:20 AM, Erik Joelsson wrote: > > Hello Mandy, > > In Lib-jdk.management.agent.gmk: > > OPENJDK_TARGET_OS and OPENJDK_TARGET_OS_TYPE are both "windows" on Windows platforms, so no need to treat Windows differently when defining the src dirs. > Good to know. Thanks. > The -DPSAPI_VERSION=1 seems to be copied from Lib-jdk.management.gmk and/or Lib-jdk.attach.gmk, but was not applied to the library from which the native src for this new lib was copied from. I just wonder if this is actually needed for this new library? I was also wondering it and now track it down. jdk.management.agent doesn?t use PS api. I will take it out. > > Please remove the "LANG := C" parameter, it no longer has a meaning but it keeps reappearing due to copy pasting of old make code. > > Are all the libraries added to LIBS still needed for this breakout lib? And are all of them still needed for libmanagement.so from which this was split out? > Good catch. I updated Lib-jdk.management.agent.gmk with: LIBS := $(JDKLIB_LIBS), \ LIBS_windows := $(WIN_JAVA_LIB) advapi32.lib, \ We should examine the native code in both java.management and jdk.management and I suspect the makefile would need cleanup. Are you okay to follow up the makefile as a separate issue? As the native code in jdk.management.agent, it can be converted to use NIO 2 and hope to get to it in a near future so that jdk.management.agent will have java code only. Mandy > /Erik > > > On 2017-01-31 00:48, Mandy Chung wrote: >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html >> >> Mandy >> >>> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >>> >>> java.management is the module for JMX and JMX remote API and >>> java.lang.management. JDK management agent provides the JDK-specific >>> out-of-the-box monitoring and management support and it?s cleaner >>> for it to live in its own module. It is proposed to move it >>> to a new module named `jdk.management.agent`. >>> >>> This change involves: >>> 1) renaming of sun.management.Agent along with 3 other classes >>> in sun.management package to jdk.internal.agent package >>> >>> 2) move sun.management.resources to jdk.internal.agent.resources >>> >>> 3) move sun.management.jmxremote and sun.management.jdp packages >>> to jdk.management.agent module >>> >>> 4) move the configuration files under conf/management >>> >>> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >>> to replace the use of the ClassLogger API with System.Logger. >>> >>> 6) change hotspot VM to add `jdk.management.agent` when >>> -Dcom.sun.management.* system property is set as well as >>> the Agent class rename >>> >>> Daniel is working on JDK-8173607 [1] that conflicts with this >>> patch and require merges/coordination. >>> >>> We propose to integrate these changes to jdk9/dev unless >>> there is any objection concerning that this trivial hotspot change >>> might cause any issue. I have submitted a RBT on hotspot_runtime >>> and hotspot_serviceability in addition to PIT test runs. >>> >>> thanks >>> Mandy >>> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 > From mandy.chung at oracle.com Tue Jan 31 16:22:25 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Jan 2017 08:22:25 -0800 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <3e8ce8e6-2b0d-8791-9295-c633affef22a@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> <3e8ce8e6-2b0d-8791-9295-c633affef22a@oracle.com> Message-ID: > On Jan 31, 2017, at 7:35 AM, Daniel Fuchs wrote: > > Hi Mandy, > > Looks good to me in general. > > Suggestion: FileLoginModule.java > > 112 private static final String PASSWORD_FILE_NAME = "jmxremote.password"; > > Maybe the constant could be public, then it could be > referred to by ConnectorBootstrap? > I see that com.sun.jmx.remote.internal is already > being exported to jdk.management.agent. > You meant com.sun.jmx.remote.security. I?d leave these 2 constants as is. Some future closer look to the relationship between FileLoginModule and ConnectorBootstrap may help to determine if future clean up should be done. > FileSystem.java: > > I wonder if this functionality should have remained in > java.management. It doesn't have any type to any specific > protocol - and it seems to be something that anyone using > the FileLoginModule above might also need. > That was added for the management agent and solely internal. We should look into converting the native code with NIO 2. No one should depend on it. > ConnectorBootstrap.java: > > I would normally discourage creating helper methods > (such as config()) in a class that doesn't implement > System.Logger, as that will make the 'config' method > appear as the source of the log message (rather than > the method that calls config()). > In this specific case I don't think it matters much > though. It's probably better to keep it like this so > as not distract reviewers from the meaningful changes, > and we can clean that up any time later in a separate > changeset (and possibly not before 10). > This is just an expedient way to remove the dependency to ClassLogger since the source method isn?t significant in this case. Thanks for the review. Mandy > > best regards, > > -- daniel > > On 30/01/17 23:48, Mandy Chung wrote: >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html >> >> Mandy >> >>> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >>> >>> java.management is the module for JMX and JMX remote API and >>> java.lang.management. JDK management agent provides the JDK-specific >>> out-of-the-box monitoring and management support and it?s cleaner >>> for it to live in its own module. It is proposed to move it >>> to a new module named `jdk.management.agent`. >>> >>> This change involves: >>> 1) renaming of sun.management.Agent along with 3 other classes >>> in sun.management package to jdk.internal.agent package >>> >>> 2) move sun.management.resources to jdk.internal.agent.resources >>> >>> 3) move sun.management.jmxremote and sun.management.jdp packages >>> to jdk.management.agent module >>> >>> 4) move the configuration files under conf/management >>> >>> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >>> to replace the use of the ClassLogger API with System.Logger. >>> >>> 6) change hotspot VM to add `jdk.management.agent` when >>> -Dcom.sun.management.* system property is set as well as >>> the Agent class rename >>> >>> Daniel is working on JDK-8173607 [1] that conflicts with this >>> patch and require merges/coordination. >>> >>> We propose to integrate these changes to jdk9/dev unless >>> there is any objection concerning that this trivial hotspot change >>> might cause any issue. I have submitted a RBT on hotspot_runtime >>> and hotspot_serviceability in addition to PIT test runs. >>> >>> thanks >>> Mandy >>> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 >> > From erik.joelsson at oracle.com Tue Jan 31 16:44:41 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 31 Jan 2017 17:44:41 +0100 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> <05c34397-9ba6-1cc5-048d-96d29f3af62e@oracle.com> Message-ID: <108c0107-83cc-e763-5f76-723aeae2b8ff@oracle.com> On 2017-01-31 17:04, Mandy Chung wrote: > >> On Jan 31, 2017, at 12:20 AM, Erik Joelsson wrote: >> >> Are all the libraries added to LIBS still needed for this breakout lib? And are all of them still needed for libmanagement.so from which this was split out? >> > Good catch. I updated Lib-jdk.management.agent.gmk with: > > LIBS := $(JDKLIB_LIBS), \ > LIBS_windows := $(WIN_JAVA_LIB) advapi32.lib, \ > > We should examine the native code in both java.management and jdk.management and I suspect the makefile would need cleanup. Are you okay to follow up the makefile as a separate issue? As the native code in jdk.management.agent, it can be converted to use NIO 2 and hope to get to it in a near future so that jdk.management.agent will have java code only. The adjustment proposed here is fine with me. /Erik From daniel.daugherty at oracle.com Tue Jan 31 17:18:41 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 31 Jan 2017 10:18:41 -0700 Subject: RFR (XXXS) 8173693 disable post_class_unload() for non JavaThread initiators Message-ID: <58758a09-fc40-1c56-37bf-607ccc67bb0a@oracle.com> Greetings, I have a very small work around for a JVM/TI event posting bug: JDK-8173693 disable post_class_unload() for non JavaThread initiators https://bugs.openjdk.java.net/browse/JDK-8173693 This work around disables the JVM/TI post_class_unload() function when the thread requesting the event is not a JavaThread. See: JDK-8173658 JvmtiExport::post_class_unload() is broken for non-JavaThread initiators https://bugs.openjdk.java.net/browse/JDK-8173658 for the gory details of what can (and has) gone wrong. Fixing JDK-8173658 is non-trivial so this work around is proposed to avoid allowing a Class Unload event to crash the VM or silently corrupt the non JavaThread that tried to post the event. Webrev URL: http://cr.openjdk.java.net/~dcubed/8173693-webrev/0-jdk9-hs/ Testing: Oracle internal VM/NSK JVM/TI test suite JPRT testing (in progress) Thanks, in advance, for any comments, questions or suggestions. Dan From daniel.fuchs at oracle.com Tue Jan 31 18:26:49 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 31 Jan 2017 18:26:49 +0000 Subject: RFR: 8173607: JMX RMI connector should be in its own module Message-ID: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com> Hi, Please find below a patch for: 8173607: JMX RMI connector should be in its own module https://bugs.openjdk.java.net/browse/JDK-8173607 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05 This patch makes it possible to remove the requires transitive java.rmi from the java.management module. For convenience here is the HTML module-level API documentation produced by javadoc for the new java.management.rmi module: http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05/java.management.rmi-summary.html The patch has some temporary hacks (mainly ConnectorBootstrap.java) that we will be able to revert when JDK-8173608 Separate JDK management agent from java.management module is pushed. The changes were mainly mechanical except for: ConnectorBootstrap.java: see above JMXConnectorFactory.java/JMXConnectorServerFactory.java: ServiceLoader is now used to load the default RMI Connector provider as a service. There should however be no observable behavior change to existing application. ProxyRef.java, Unmarshal.java: are moved to a new com.sun.jmx.remote.internal.rmi package in the new module. ClientNotifForwarder.java: is modified to no longer depend on java.rmi.UnmarshalException - NotSerializableException is used instead RMIConnector.java: fetchNotif is updated to throw NotSerializableException instead of UnmarshalException The PRef serialization bytes are updated to accomodate the new ProxyRef package name. Some further cleanup of java.base and java.rmi module-info.java should become possible once JDK-8173608 is in (as well as moving RMIExporter to java.management.rmi - which is not possible yet). Further cleanup of @modules in tests might become possible as well. Note: JCK tests for api/javax_management and api/java_lang/management are passing with this change. best regards, -- daniel From serguei.spitsyn at oracle.com Tue Jan 31 18:28:58 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 31 Jan 2017 10:28:58 -0800 Subject: RFR (XXXS) 8173693 disable post_class_unload() for non JavaThread initiators In-Reply-To: <58758a09-fc40-1c56-37bf-607ccc67bb0a@oracle.com> References: <58758a09-fc40-1c56-37bf-607ccc67bb0a@oracle.com> Message-ID: <81982068-af77-6114-b047-ebf55d45757f@oracle.com> Dan, It looks good. Thank you for the work around. Thanks, Serguei On 1/31/17 09:18, Daniel D. Daugherty wrote: > Greetings, > > I have a very small work around for a JVM/TI event posting bug: > > JDK-8173693 disable post_class_unload() for non JavaThread initiators > https://bugs.openjdk.java.net/browse/JDK-8173693 > > This work around disables the JVM/TI post_class_unload() function > when the thread requesting the event is not a JavaThread. See: > > JDK-8173658 JvmtiExport::post_class_unload() is broken for > non-JavaThread initiators > https://bugs.openjdk.java.net/browse/JDK-8173658 > > for the gory details of what can (and has) gone wrong. > > Fixing JDK-8173658 is non-trivial so this work around is proposed > to avoid allowing a Class Unload event to crash the VM or silently > corrupt the non JavaThread that tried to post the event. > > Webrev URL: http://cr.openjdk.java.net/~dcubed/8173693-webrev/0-jdk9-hs/ > > Testing: Oracle internal VM/NSK JVM/TI test suite > JPRT testing (in progress) > > > Thanks, in advance, for any comments, questions or suggestions. > > Dan From daniel.daugherty at oracle.com Tue Jan 31 18:32:55 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 31 Jan 2017 11:32:55 -0700 Subject: RFR (XXXS) 8173693 disable post_class_unload() for non JavaThread initiators In-Reply-To: <81982068-af77-6114-b047-ebf55d45757f@oracle.com> References: <58758a09-fc40-1c56-37bf-607ccc67bb0a@oracle.com> <81982068-af77-6114-b047-ebf55d45757f@oracle.com> Message-ID: <6c6a1348-5593-f733-a687-47bd9e953ead@oracle.com> Serguei, Thanks for the fast review! Dan On 1/31/17 11:28 AM, serguei.spitsyn at oracle.com wrote: > Dan, > > It looks good. > Thank you for the work around. > > Thanks, > Serguei > > > On 1/31/17 09:18, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a very small work around for a JVM/TI event posting bug: >> >> JDK-8173693 disable post_class_unload() for non JavaThread >> initiators >> https://bugs.openjdk.java.net/browse/JDK-8173693 >> >> This work around disables the JVM/TI post_class_unload() function >> when the thread requesting the event is not a JavaThread. See: >> >> JDK-8173658 JvmtiExport::post_class_unload() is broken for >> non-JavaThread initiators >> https://bugs.openjdk.java.net/browse/JDK-8173658 >> >> for the gory details of what can (and has) gone wrong. >> >> Fixing JDK-8173658 is non-trivial so this work around is proposed >> to avoid allowing a Class Unload event to crash the VM or silently >> corrupt the non JavaThread that tried to post the event. >> >> Webrev URL: http://cr.openjdk.java.net/~dcubed/8173693-webrev/0-jdk9-hs/ >> >> Testing: Oracle internal VM/NSK JVM/TI test suite >> JPRT testing (in progress) >> >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan > From gerald.thornbrugh at oracle.com Tue Jan 31 18:36:54 2017 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Tue, 31 Jan 2017 11:36:54 -0700 Subject: RFR (XXXS) 8173693 disable post_class_unload() for non JavaThread initiators In-Reply-To: <58758a09-fc40-1c56-37bf-607ccc67bb0a@oracle.com> References: <58758a09-fc40-1c56-37bf-607ccc67bb0a@oracle.com> Message-ID: <6E9297B5-A110-4249-A268-A4598BD89C29@oracle.com> Hi Dan, Your changes look good. Thanks, Jerry > On Jan 31, 2017, at 10:18 AM, Daniel D. Daugherty wrote: > > Greetings, > > I have a very small work around for a JVM/TI event posting bug: > > JDK-8173693 disable post_class_unload() for non JavaThread initiators > https://bugs.openjdk.java.net/browse/JDK-8173693 > > This work around disables the JVM/TI post_class_unload() function > when the thread requesting the event is not a JavaThread. See: > > JDK-8173658 JvmtiExport::post_class_unload() is broken for non-JavaThread initiators > https://bugs.openjdk.java.net/browse/JDK-8173658 > > for the gory details of what can (and has) gone wrong. > > Fixing JDK-8173658 is non-trivial so this work around is proposed > to avoid allowing a Class Unload event to crash the VM or silently > corrupt the non JavaThread that tried to post the event. > > Webrev URL: http://cr.openjdk.java.net/~dcubed/8173693-webrev/0-jdk9-hs/ > > Testing: Oracle internal VM/NSK JVM/TI test suite > JPRT testing (in progress) > > > Thanks, in advance, for any comments, questions or suggestions. > > Dan From daniel.daugherty at oracle.com Tue Jan 31 18:37:35 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 31 Jan 2017 11:37:35 -0700 Subject: RFR (XXXS) 8173693 disable post_class_unload() for non JavaThread initiators In-Reply-To: <6E9297B5-A110-4249-A268-A4598BD89C29@oracle.com> References: <58758a09-fc40-1c56-37bf-607ccc67bb0a@oracle.com> <6E9297B5-A110-4249-A268-A4598BD89C29@oracle.com> Message-ID: <2084e9dd-3a49-dd6a-e891-3167231ef637@oracle.com> Jerry, Thanks for the fast review! Dan On 1/31/17 11:36 AM, Gerald Thornbrugh wrote: > Hi Dan, > > Your changes look good. > > Thanks, > > Jerry >> On Jan 31, 2017, at 10:18 AM, Daniel D. Daugherty wrote: >> >> Greetings, >> >> I have a very small work around for a JVM/TI event posting bug: >> >> JDK-8173693 disable post_class_unload() for non JavaThread initiators >> https://bugs.openjdk.java.net/browse/JDK-8173693 >> >> This work around disables the JVM/TI post_class_unload() function >> when the thread requesting the event is not a JavaThread. See: >> >> JDK-8173658 JvmtiExport::post_class_unload() is broken for non-JavaThread initiators >> https://bugs.openjdk.java.net/browse/JDK-8173658 >> >> for the gory details of what can (and has) gone wrong. >> >> Fixing JDK-8173658 is non-trivial so this work around is proposed >> to avoid allowing a Class Unload event to crash the VM or silently >> corrupt the non JavaThread that tried to post the event. >> >> Webrev URL: http://cr.openjdk.java.net/~dcubed/8173693-webrev/0-jdk9-hs/ >> >> Testing: Oracle internal VM/NSK JVM/TI test suite >> JPRT testing (in progress) >> >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan From david.holmes at oracle.com Tue Jan 31 20:45:45 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Feb 2017 06:45:45 +1000 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <0769A989-4EDE-4D8E-B3C5-9AE89EFD8529@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> <90abbd53-411e-645c-1c96-700bde19fd56@oracle.com> <0769A989-4EDE-4D8E-B3C5-9AE89EFD8529@oracle.com> Message-ID: <3ca0cbec-75d9-0517-6ede-5bcd46f377e1@oracle.com> On 1/02/2017 12:57 AM, Mandy Chung wrote: > >> On Jan 30, 2017, at 11:00 PM, David Holmes wrote: >> >> Hi Mandy, >> >> On 31/01/2017 9:48 AM, Mandy Chung wrote: >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html >> >> This all seems okay. >> > > Thanks for the review. > >> But we have quite a few hotspot tests that include: >> >> @modules java.management/sun.management >> > > Only 4 classes in the java.management/sun.management are moved to jdk.management.agent/jdk.internal.agent. > > From my grep on hotspot tests, no test uses those renamed classes. Ah I see. Thanks for clarifying. David > Mandy > >> that would seem to need updating as well. >> >> Thanks, >> David >> ----- >> >>> Mandy >>> >>>> On Jan 30, 2017, at 3:42 PM, Mandy Chung wrote: >>>> >>>> java.management is the module for JMX and JMX remote API and >>>> java.lang.management. JDK management agent provides the JDK-specific >>>> out-of-the-box monitoring and management support and it?s cleaner >>>> for it to live in its own module. It is proposed to move it >>>> to a new module named `jdk.management.agent`. >>>> >>>> This change involves: >>>> 1) renaming of sun.management.Agent along with 3 other classes >>>> in sun.management package to jdk.internal.agent package >>>> >>>> 2) move sun.management.resources to jdk.internal.agent.resources >>>> >>>> 3) move sun.management.jmxremote and sun.management.jdp packages >>>> to jdk.management.agent module >>>> >>>> 4) move the configuration files under conf/management >>>> >>>> 5) sun/management/jmxremote/ConnectorBootstrap.java is updated >>>> to replace the use of the ClassLogger API with System.Logger. >>>> >>>> 6) change hotspot VM to add `jdk.management.agent` when >>>> -Dcom.sun.management.* system property is set as well as >>>> the Agent class rename >>>> >>>> Daniel is working on JDK-8173607 [1] that conflicts with this >>>> patch and require merges/coordination. >>>> >>>> We propose to integrate these changes to jdk9/dev unless >>>> there is any objection concerning that this trivial hotspot change >>>> might cause any issue. I have submitted a RBT on hotspot_runtime >>>> and hotspot_serviceability in addition to PIT test runs. >>>> >>>> thanks >>>> Mandy >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8173607 >>> >