From serguei.spitsyn at oracle.com Sat Dec 3 06:54:44 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 2 Dec 2016 22:54:44 -0800 Subject: RFR(S): 7034834 JVMTI xml file referring to old JDK version Message-ID: Please, review a fix for the bug: https://bugs.openjdk.java.net/browse/JDK-7034834 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/7034834-Doc.hs1/ Summary: The JVM TI spec has links to the old JDK 7 release documents. The fix is to make it up-to-date and link to the JDK 9 docs. One issue with the fix that the JDK 9 doc pages do not exist yet. I hope that the JDK 9 release doc pages will be created the same way as they were for JDK 8. The JVM TI spec for JDK 8 has the same problem as it also has links to the JDK 7 release documents. I'd like to fix this issuein the JDK 9 ASAP to be able to backport the fix to JDK 8. Thanks, Serguei From serguei.spitsyn at oracle.com Sat Dec 3 06:58:42 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 2 Dec 2016 22:58:42 -0800 Subject: Fwd: RFR(S): 7034834 JVMTI xml file referring to old JDK version In-Reply-To: References: Message-ID: <576f8342-2632-33fe-6815-86f498f3c6b6@oracle.com> Added also the runtime open mailing list. Please, review a fix for the bug: https://bugs.openjdk.java.net/browse/JDK-7034834 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/7034834-Doc.hs1/ Summary: The JVM TI spec has links to the old JDK 7 release documents. The fix is to make it up-to-date and link to the JDK 9 docs. One issue with the fix that the JDK 9 doc pages do not exist yet. I hope that the JDK 9 release doc pages will be created the same way as they were for JDK 8. The JVM TI spec for JDK 8 has the same problem as it also has links to the JDK 7 release documents. I'd like to fix this issue in the JDK 9 ASAP in order to be able to backport the fix to JDK 8. Thanks, Serguei From serguei.spitsyn at oracle.com Sat Dec 3 07:01:35 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 2 Dec 2016 23:01:35 -0800 Subject: RFR(S): 7034834 JVMTI xml file referring to old JDK version In-Reply-To: <576f8342-2632-33fe-6815-86f498f3c6b6@oracle.com> References: <576f8342-2632-33fe-6815-86f498f3c6b6@oracle.com> Message-ID: <15088f1b-82bc-84b2-38f0-83b68a1168eb@oracle.com> One more attempt to send this e-mail correctly. :) Please, review a fix for the bug: https://bugs.openjdk.java.net/browse/JDK-7034834 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/7034834-Doc.hs1/ Summary: The JVM TI spec has links to the old JDK 7 release documents. The fix is to make it up-to-date and link to the JDK 9 docs. One issue with the fix that the JDK 9 doc pages do not exist yet. I hope that the JDK 9 release doc pages will be created the same way as they were for JDK 8. The JVM TI spec for JDK 8 has the same problem as it also has links to the JDK 7 release documents. I'd like to fix this issue in the JDK 9 ASAP in order to be able to backport the fix to JDK 8. Thanks, Serguei From dmitry.samersoff at oracle.com Sat Dec 3 08:43:57 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 3 Dec 2016 11:43:57 +0300 Subject: RFR(S): 7034834 JVMTI xml file referring to old JDK version In-Reply-To: <15088f1b-82bc-84b2-38f0-83b68a1168eb@oracle.com> References: <576f8342-2632-33fe-6815-86f498f3c6b6@oracle.com> <15088f1b-82bc-84b2-38f0-83b68a1168eb@oracle.com> Message-ID: Serguei, Looks good to me. Is it ok that http://docs.oracle.com/javase/9/docs/technotes/guides/jni/spec/invocation.html doesn't exist yet? -Dmitry On 2016-12-03 10:01, serguei.spitsyn at oracle.com wrote: > One more attempt to send this e-mail correctly. :) > > Please, review a fix for the bug: > https://bugs.openjdk.java.net/browse/JDK-7034834 > > Webrev: > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/7034834-Doc.hs1/ > > > Summary: > > The JVM TI spec has links to the old JDK 7 release documents. > The fix is to make it up-to-date and link to the JDK 9 docs. > > One issue with the fix that the JDK 9 doc pages do not exist yet. > I hope that the JDK 9 release doc pages will be created the same way > as they were for JDK 8. The JVM TI spec for JDK 8 has the same > problem as it also has links to the JDK 7 release documents. > I'd like to fix this issue in the JDK 9 ASAP in order to be able > to backport the fix to JDK 8. > > > Thanks, > Serguei > -- 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 serguei.spitsyn at oracle.com Sat Dec 3 09:05:59 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sat, 3 Dec 2016 01:05:59 -0800 Subject: RFR(S): 7034834 JVMTI xml file referring to old JDK version In-Reply-To: References: <576f8342-2632-33fe-6815-86f498f3c6b6@oracle.com> <15088f1b-82bc-84b2-38f0-83b68a1168eb@oracle.com> Message-ID: Dmitry, On 12/3/16 00:43, Dmitry Samersoff wrote: > Serguei, > > Looks good to me. Thanks! > > Is it ok that > > http://docs.oracle.com/javase/9/docs/technotes/guides/jni/spec/invocation.html > > doesn't exist yet? Please, see it discussed in the summary below. Thanks, Serguei > > -Dmitry > > On 2016-12-03 10:01, serguei.spitsyn at oracle.com wrote: >> One more attempt to send this e-mail correctly. :) >> >> Please, review a fix for the bug: >> https://bugs.openjdk.java.net/browse/JDK-7034834 >> >> Webrev: >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/7034834-Doc.hs1/ >> >> >> Summary: >> >> The JVM TI spec has links to the old JDK 7 release documents. >> The fix is to make it up-to-date and link to the JDK 9 docs. >> >> One issue with the fix that the JDK 9 doc pages do not exist yet. >> I hope that the JDK 9 release doc pages will be created the same way >> as they were for JDK 8. The JVM TI spec for JDK 8 has the same >> problem as it also has links to the JDK 7 release documents. >> I'd like to fix this issue in the JDK 9 ASAP in order to be able >> to backport the fix to JDK 8. >> >> >> Thanks, >> Serguei >> > From dmitry.samersoff at oracle.com Sat Dec 3 09:27:18 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 3 Dec 2016 12:27:18 +0300 Subject: RFR(S): 7034834 JVMTI xml file referring to old JDK version In-Reply-To: References: <576f8342-2632-33fe-6815-86f498f3c6b6@oracle.com> <15088f1b-82bc-84b2-38f0-83b68a1168eb@oracle.com> Message-ID: Serguei, OK. Thank you! -Dmitry On 2016-12-03 12:05, serguei.spitsyn at oracle.com wrote: > Dmitry, > > > On 12/3/16 00:43, Dmitry Samersoff wrote: >> Serguei, >> >> Looks good to me. > > Thanks! > >> >> Is it ok that >> >> http://docs.oracle.com/javase/9/docs/technotes/guides/jni/spec/invocation.html >> >> >> doesn't exist yet? > > Please, see it discussed in the summary below. > > Thanks, > Serguei > > >> >> -Dmitry >> >> On 2016-12-03 10:01, serguei.spitsyn at oracle.com wrote: >>> One more attempt to send this e-mail correctly. :) >>> >>> Please, review a fix for the bug: >>> https://bugs.openjdk.java.net/browse/JDK-7034834 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/7034834-Doc.hs1/ >>> >>> >>> >>> Summary: >>> >>> The JVM TI spec has links to the old JDK 7 release documents. >>> The fix is to make it up-to-date and link to the JDK 9 docs. >>> >>> One issue with the fix that the JDK 9 doc pages do not exist yet. >>> I hope that the JDK 9 release doc pages will be created the same way >>> as they were for JDK 8. The JVM TI spec for JDK 8 has the same >>> problem as it also has links to the JDK 7 release documents. >>> I'd like to fix this issue in the JDK 9 ASAP in order to be able >>> to backport the fix to JDK 8. >>> >>> >>> Thanks, >>> Serguei >>> >> > -- 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 Mon Dec 5 03:12:42 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 5 Dec 2016 13:12:42 +1000 Subject: RFR(S): 7034834 JVMTI xml file referring to old JDK version In-Reply-To: References: Message-ID: Hi Serguei, Looks okay. Ideally there would be some way to use a symbolic reference instead of hard wiring 7, 8 or 9. These are the kinds of paths that should be specified relative to some base URL that need only be set once. But I don't see that occurring in the JDK code either. Thanks, David On 3/12/2016 4:54 PM, serguei.spitsyn at oracle.com wrote: > Please, review a fix for the bug: > https://bugs.openjdk.java.net/browse/JDK-7034834 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/7034834-Doc.hs1/ > > > Summary: > > The JVM TI spec has links to the old JDK 7 release documents. > The fix is to make it up-to-date and link to the JDK 9 docs. > > > One issue with the fix that the JDK 9 doc pages do not exist yet. > I hope that the JDK 9 release doc pages will be created the same way as > they were for JDK 8. > The JVM TI spec for JDK 8 has the same problem as it also has links to > the JDK 7 release documents. > I'd like to fix this issuein the JDK 9 ASAP to be able to backport the > fix to JDK 8. > > > Thanks, > Serguei From serguei.spitsyn at oracle.com Mon Dec 5 03:19:14 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 4 Dec 2016 19:19:14 -0800 Subject: RFR(S): 7034834 JVMTI xml file referring to old JDK version In-Reply-To: References: Message-ID: <9670ebbe-221c-f005-710c-3c1d13a60f68@oracle.com> Hi David, On 12/4/16 19:12, David Holmes wrote: > Hi Serguei, > > Looks okay. Thank you a lot! > > Ideally there would be some way to use a symbolic reference instead of > hard wiring 7, 8 or 9. These are the kinds of paths that should be > specified relative to some base URL that need only be set once. But I > don't see that occurring in the JDK code either. I did not find yet how to express it in the xml format. Maybe, it is possible to do some XSL/T transformation. But I've not found a good approach either. Thanks, Serguei > > Thanks, > David > > On 3/12/2016 4:54 PM, serguei.spitsyn at oracle.com wrote: >> Please, review a fix for the bug: >> https://bugs.openjdk.java.net/browse/JDK-7034834 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/7034834-Doc.hs1/ >> >> >> >> Summary: >> >> The JVM TI spec has links to the old JDK 7 release documents. >> The fix is to make it up-to-date and link to the JDK 9 docs. >> >> >> One issue with the fix that the JDK 9 doc pages do not exist yet. >> I hope that the JDK 9 release doc pages will be created the same way as >> they were for JDK 8. >> The JVM TI spec for JDK 8 has the same problem as it also has links to >> the JDK 7 release documents. >> I'd like to fix this issuein the JDK 9 ASAP to be able to backport the >> fix to JDK 8. >> >> >> Thanks, >> Serguei From dmitry.samersoff at oracle.com Mon Dec 5 09:30:41 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 5 Dec 2016 12:30:41 +0300 Subject: RFR(M): JDK-8165496 assert(_exception_caught == false) failed: _exception_caught is out of phase Message-ID: <2c409f12-69fe-0dbe-af92-31e392840fa6@oracle.com> Everybody, Please review. http://cr.openjdk.java.net/~dsamersoff/JDK-8165496/webrev.07/ Bug link: https://bugs.openjdk.java.net/browse/JDK-8165496 Two separate flags, exception_detected and exception_caught, replaced with one that changes it's state. Assert assert(_exception_caught == false) and fix for JDK-8134434 are removed. Testing: 1. Manual testing of instrumented hotspot 2. Local ks with stress agent 3. RBT ks with stress agent 4. RBT hotspot_all -Dmitry -- 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 markus.gronlund at oracle.com Mon Dec 5 23:33:31 2016 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Mon, 5 Dec 2016 15:33:31 -0800 (PST) Subject: RFR(S): 8170672: Event-based tracing to support classloader instances Message-ID: <023cfba7-0c69-4dc8-bbd0-b65df3cd6f64@default> Greetings, Kindly asking for reviews for the following changeset: Bug/Enh: https://bugs.openjdk.java.net/browse/JDK-8170672 Webrev: http://cr.openjdk.java.net/~mgronlun/8170672/webrev01/ (this work is covered by an FC exception) Summary: Event-based tracing previously had little information about class loaders; a class loader was essentially treated no different than from a regular class (type information only). With JDK9, supported has been added to java.lang.ClassLoader to associate a name with an individual class loader instance. This changeset will allow the name information of individual class loader instances to be provided by the event-based tracing framework. Aux info: Some folding of the numerous macros completed as well. Thanks in advance Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Dec 6 05:57:53 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 5 Dec 2016 21:57:53 -0800 Subject: RFR(M): JDK-8165496 assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: <2c409f12-69fe-0dbe-af92-31e392840fa6@oracle.com> References: <2c409f12-69fe-0dbe-af92-31e392840fa6@oracle.com> Message-ID: Hi Dmitry, I'm repeating my comments from the internal review. It looks pretty good to me. Thank you for the work on it! I'm not a big fun of new jvmtiThreadState functions though: + inline void save_exception_state(ExceptionState *state) { *state = _exception_state; } + inline void restore_exception_state(ExceptionState state) { _exception_state = state; } The functions above do not really encapsulate and save/restore the _exception_state value so that these names are kind of misleading. The same functionality can be provided with a simplified approach: inline JvmtiThreadState exception_state() { return_exception_state; } inline void set_exception_state(ExceptionState state){ _exception_state = state; } I do not want to insist on my approach and will wait for other people comments on this. I hope, some compromise can be found here. On 12/5/16 01:30, Dmitry Samersoff wrote: > Everybody, > > Please review. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8165496/webrev.07/ > > Bug link: > > https://bugs.openjdk.java.net/browse/JDK-8165496 > > Two separate flags, exception_detected and exception_caught, replaced > with one that changes it's state. > > Assert assert(_exception_caught == false) and fix for JDK-8134434 are > removed. > > Testing: > 1. Manual testing of instrumented hotspot > 2. Local ks with stress agent > 3. RBT ks with stress agent What the 'ks' stands for? I have some guess but still would like to know this abbreviation. Thanks, Serguei > 4. RBT hotspot_all > > -Dmitry > From david.holmes at oracle.com Tue Dec 6 06:07:23 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Dec 2016 16:07:23 +1000 Subject: RFR(M): JDK-8165496 assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: References: <2c409f12-69fe-0dbe-af92-31e392840fa6@oracle.com> Message-ID: <5f94ce44-4d0e-412a-53a6-01cc73358b87@oracle.com> Hi Serguei, On 6/12/2016 3:57 PM, serguei.spitsyn at oracle.com wrote: > Hi Dmitry, > > > I'm repeating my comments from the internal review. > > It looks pretty good to me. > Thank you for the work on it! > > I'm not a big fun of new jvmtiThreadState functions though: > > + inline void save_exception_state(ExceptionState *state) { *state = > _exception_state; } This saves _exception_state into *state. > + inline void restore_exception_state(ExceptionState state) { > _exception_state = state; } This restores _exception_state from state. > The functions above do not really > encapsulate and save/restore the _exception_state value so that these I think they do. Cheers, David ----- > names are kind of misleading. The same functionality can be provided > with a simplified approach: inline JvmtiThreadState > exception_state() { return_exception_state; } > inline void set_exception_state(ExceptionState state){ > _exception_state = state; } > > > I do not want to insist on my approach and will wait for other people > comments on this. > I hope, some compromise can be found here. > > > On 12/5/16 01:30, Dmitry Samersoff wrote: >> Everybody, >> >> Please review. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8165496/webrev.07/ >> >> Bug link: >> >> https://bugs.openjdk.java.net/browse/JDK-8165496 >> >> Two separate flags, exception_detected and exception_caught, replaced >> with one that changes it's state. >> >> Assert assert(_exception_caught == false) and fix for JDK-8134434 are >> removed. >> >> Testing: >> 1. Manual testing of instrumented hotspot >> 2. Local ks with stress agent >> 3. RBT ks with stress agent > > What the 'ks' stands for? > I have some guess but still would like to know this abbreviation. > > Thanks, > Serguei > >> 4. RBT hotspot_all >> >> -Dmitry >> > From dmitry.samersoff at oracle.com Tue Dec 6 09:54:58 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 6 Dec 2016 12:54:58 +0300 Subject: RFR(M): JDK-8165496 assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: References: <2c409f12-69fe-0dbe-af92-31e392840fa6@oracle.com> Message-ID: Serguei. I intentionally decide not to provide generic accessor functions for _exception_state. Developers should use set_exception_detected(), set_exception_caught(), clear_exception_state() but don't change _exception_state directly. And save_exception_state()/restore_exception_state() name and signature clear indicates that the only valid usage of these functions is backup of exception_state. So I would prefer to leave it as is. -Dmitry On 2016-12-06 08:57, serguei.spitsyn at oracle.com wrote: > Hi Dmitry, > > > I'm repeating my comments from the internal review. > > It looks pretty good to me. > Thank you for the work on it! > > I'm not a big fun of new jvmtiThreadState functions though: > > + inline void save_exception_state(ExceptionState *state) { *state = > _exception_state; } > + inline void restore_exception_state(ExceptionState state) { > _exception_state = state; } The functions above do not really > encapsulate and save/restore the _exception_state value so that these > names are kind of misleading. The same functionality can be provided > with a simplified approach: inline JvmtiThreadState > exception_state() { return_exception_state; } > inline void set_exception_state(ExceptionState state){ > _exception_state = state; } > > > I do not want to insist on my approach and will wait for other people > comments on this. > I hope, some compromise can be found here. > > > On 12/5/16 01:30, Dmitry Samersoff wrote: >> Everybody, >> >> Please review. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8165496/webrev.07/ >> >> Bug link: >> >> https://bugs.openjdk.java.net/browse/JDK-8165496 >> >> Two separate flags, exception_detected and exception_caught, replaced >> with one that changes it's state. >> >> Assert assert(_exception_caught == false) and fix for JDK-8134434 are >> removed. >> >> Testing: >> 1. Manual testing of instrumented hotspot >> 2. Local ks with stress agent >> 3. RBT ks with stress agent > > What the 'ks' stands for? > I have some guess but still would like to know this abbreviation. > > Thanks, > Serguei > >> 4. RBT hotspot_all >> >> -Dmitry >> > -- 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 dmitry.samersoff at oracle.com Tue Dec 6 11:58:05 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 6 Dec 2016 14:58:05 +0300 Subject: [8u] RFR(S): Uninitialized memory in set_uintx_flag of attachListener.cpp Message-ID: Everybody, http://cr.openjdk.java.net/~dsamersoff/JDK-8170536/webrev.01/ Please, review the fix. The code should return error if op->arg(1) is NULL. -Dmitry -- 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 Tue Dec 6 13:05:24 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Dec 2016 23:05:24 +1000 Subject: [8u] RFR(S): Uninitialized memory in set_uintx_flag of attachListener.cpp In-Reply-To: References: Message-ID: <650a2295-e1ee-0e6b-f229-62521b91589d@oracle.com> On 6/12/2016 9:58 PM, Dmitry Samersoff wrote: > Everybody, > > http://cr.openjdk.java.net/~dsamersoff/JDK-8170536/webrev.01/ > > Please, review the fix. > > The code should return error if op->arg(1) is NULL. Looks ok. Only minor nit: 274 const char* arg1; 275 276 arg1 = op->arg(1); can be: 274 const char* arg1 = op->arg(1); Oh and copyright year needs updating. Thanks, David > -Dmitry > From goetz.lindenmaier at sap.com Tue Dec 6 13:12:30 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 6 Dec 2016 13:12:30 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. Message-ID: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> Hi, This change fixes some minor issues found in our code scans. I hope this correctly addresses corelib and serviceability issues. Please review: http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.01/ Best regards, Goetz. Changes in detail: e_asin.c Code scan reports missing {}. The code "if (huge+x>one) {" is only there to set the inexact flag of the processor. It's a way to avoid the C compiler to optimize the code away. It is always true, so the parenthesis of the outer else don't matter. Although this basically just adds the {} I would like to submit this to avoid anybody else spends more the 30sec on understanding these if statements. k_standard.c exc.retval is returned below and thus should always be initialized. imageDecompressor.cpp Wrong destructor is used. Reported also by David CARLIER java.c in line 1865 'name' was used, it should be 'alias'. java_md_solinux.c "//" in path is useless. Further down a free is missing. SDE.c Call to stratumTableIndex can return negative value if defaultStratumId == null. socket_md.c arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in the macros. unpack.cpp n.slice should not get negative argument for end, which is passed from dollar1. But dollar1 can get negative where it is set to the result of lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Tue Dec 6 13:22:48 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 6 Dec 2016 16:22:48 +0300 Subject: [8u] RFR(S): Uninitialized memory in set_uintx_flag of attachListener.cpp In-Reply-To: <650a2295-e1ee-0e6b-f229-62521b91589d@oracle.com> References: <650a2295-e1ee-0e6b-f229-62521b91589d@oracle.com> Message-ID: <3888e0f3-7cd0-e2ae-2a9e-a3fc7d47f9ef@oracle.com> David, Thank you! -Dmitry On 2016-12-06 16:05, David Holmes wrote: > On 6/12/2016 9:58 PM, Dmitry Samersoff wrote: >> Everybody, >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8170536/webrev.01/ >> >> Please, review the fix. >> >> The code should return error if op->arg(1) is NULL. > > Looks ok. Only minor nit: > > 274 const char* arg1; > 275 > 276 arg1 = op->arg(1); > > can be: > > 274 const char* arg1 = op->arg(1); > > Oh and copyright year needs updating. > > Thanks, > David > >> -Dmitry >> -- 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 dmitry.samersoff at oracle.com Tue Dec 6 15:59:26 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 6 Dec 2016 18:59:26 +0300 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> Message-ID: Goetz, For serviceability code, please see comments below: * src/java.base/share/native/libjli/java.c No comments * src/java.base/unix/native/libjli/java_md_solinux.c Is this line correct? 519 jvmpath = JLI_StringDup(jvmpath); * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c It might be better to return immediately if cnt < 0, regardless of value of sti. * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c It might be better to write arg.l_linger = (on) ? (unsigned short)value.i : 0; and leave one copy of setsockopt() call -Dmitry On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > Hi, > > > > This change fixes some minor issues found in our code scans. > > I hope this correctly addresses corelib and serviceability issues. > > > > Please review: > > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.01/ > > > > Best regards, > > Goetz. > > > > Changes in detail: > > > > e_asin.c > > Code scan reports missing {}. > > > The code "if (huge+x>one) {" is only there to set the inexact flag of > the processor. > It's a way to avoid the C compiler to optimize the code away. It is > always true, > so the parenthesis of the outer else don't matter. > > Although this basically just adds the {} I would like to submit this to > > avoid anybody else spends more the 30sec on understanding these > > if statements. > > > k_standard.c > > exc.retval is returned below and thus should always be initialized. > > > imageDecompressor.cpp > > Wrong destructor is used. Reported also by David CARLIER > > > java.c > > in line 1865 'name' was used, it should be 'alias'. > > > java_md_solinux.c > > "//" in path is useless. Further down a free is missing. > > > SDE.c > > Call to stratumTableIndex can return negative value if defaultStratumId > == null. > > > socket_md.c > > arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in > the macros. > > > unpack.cpp > > n.slice should not get negative argument for end, which is passed from > dollar1. > But dollar1 can get negative where it is set to the result of > lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > -- 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 serguei.spitsyn at oracle.com Tue Dec 6 16:43:37 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 6 Dec 2016 08:43:37 -0800 Subject: RFR(M): JDK-8165496 assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: <5f94ce44-4d0e-412a-53a6-01cc73358b87@oracle.com> References: <2c409f12-69fe-0dbe-af92-31e392840fa6@oracle.com> <5f94ce44-4d0e-412a-53a6-01cc73358b87@oracle.com> Message-ID: <0e0091a8-b3db-e15f-d7c4-0717a23591d2@oracle.com> Hi David, Thank you for sharing your opinion! I'm taking of my claim then. :) On 12/5/16 22:07, David Holmes wrote: > Hi Serguei, > > On 6/12/2016 3:57 PM, serguei.spitsyn at oracle.com wrote: >> Hi Dmitry, >> >> >> I'm repeating my comments from the internal review. >> >> It looks pretty good to me. >> Thank you for the work on it! >> >> I'm not a big fun of new jvmtiThreadState functions though: >> >> + inline void save_exception_state(ExceptionState *state) { *state = >> _exception_state; } > > This saves _exception_state into *state. > >> + inline void restore_exception_state(ExceptionState state) { >> _exception_state = state; } > > This restores _exception_state from state. > >> The functions above do not really >> encapsulate and save/restore the _exception_state value so that these > > I think they do. Just to explain. Of course, I see the prefixes save_ and restore_. :) I was concerned about the direction of saving/restoring. The consumer of the api is some other class, not the class itself. In this case, there is no encapsulation of the saved/restored value as the value is stored away of the object that should manage it. Then a misapplication is possible: one value is saved - another restored. The examples I like are: interpreter/templateInterpreterGenerator.hpp: void restore_native_result(void); interpreter/templateInterpreterGenerator.hpp: void save_native_result(void); runtime/sharedRuntime.hpp: static void restore_native_result(MacroAssembler *_masm, BasicType ret_type, int frame_slots); runtime/sharedRuntime.hpp: static void save_native_result(MacroAssembler *_masm, BasicType ret_type, int frame_slots); services/threadService.hpp: save_old_state(java_thread); opto/superword.hpp: void store_depth() {_depth_save = _depth;} opto/superword.hpp: void restore_depth() {_depth = _depth_save;} However, it looks minor to me, maybe a matter of taste. I'm silent now. Thanks! Serguei > > Cheers, > David > ----- > > >> names are kind of misleading. The same functionality can be provided >> with a simplified approach: inline JvmtiThreadState >> exception_state() { return_exception_state; } >> inline void set_exception_state(ExceptionState state){ >> _exception_state = state; } >> >> >> I do not want to insist on my approach and will wait for other people >> comments on this. >> I hope, some compromise can be found here. >> >> >> On 12/5/16 01:30, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please review. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8165496/webrev.07/ >>> >>> Bug link: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8165496 >>> >>> Two separate flags, exception_detected and exception_caught, replaced >>> with one that changes it's state. >>> >>> Assert assert(_exception_caught == false) and fix for JDK-8134434 are >>> removed. >>> >>> Testing: >>> 1. Manual testing of instrumented hotspot >>> 2. Local ks with stress agent >>> 3. RBT ks with stress agent >> >> What the 'ks' stands for? >> I have some guess but still would like to know this abbreviation. >> >> Thanks, >> Serguei >> >>> 4. RBT hotspot_all >>> >>> -Dmitry >>> >> From serguei.spitsyn at oracle.com Tue Dec 6 16:48:46 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 6 Dec 2016 08:48:46 -0800 Subject: RFR(M): JDK-8165496 assert(_exception_caught == false) failed: _exception_caught is out of phase In-Reply-To: References: <2c409f12-69fe-0dbe-af92-31e392840fa6@oracle.com> Message-ID: <7ae54cdf-1948-4340-d0ac-d92cc160364f@oracle.com> Dmitry, On 12/6/16 01:54, Dmitry Samersoff wrote: > Serguei. > > I intentionally decide not to provide generic accessor functions > for _exception_state. Unfortunately, provided functions are the same functionally. > > Developers should use set_exception_detected(), set_exception_caught(), > clear_exception_state() but don't change _exception_state directly. > > And save_exception_state()/restore_exception_state() name and signature > clear indicates that the only valid usage of these functions is backup > of exception_state. > > So I would prefer to leave it as is. No pressure. Thanks, Serguei > > -Dmitry > > > On 2016-12-06 08:57, serguei.spitsyn at oracle.com wrote: >> Hi Dmitry, >> >> >> I'm repeating my comments from the internal review. >> >> It looks pretty good to me. >> Thank you for the work on it! >> >> I'm not a big fun of new jvmtiThreadState functions though: >> >> + inline void save_exception_state(ExceptionState *state) { *state = >> _exception_state; } >> + inline void restore_exception_state(ExceptionState state) { >> _exception_state = state; } The functions above do not really >> encapsulate and save/restore the _exception_state value so that these >> names are kind of misleading. The same functionality can be provided >> with a simplified approach: inline JvmtiThreadState >> exception_state() { return_exception_state; } >> inline void set_exception_state(ExceptionState state){ >> _exception_state = state; } >> >> >> I do not want to insist on my approach and will wait for other people >> comments on this. >> I hope, some compromise can be found here. >> >> >> On 12/5/16 01:30, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please review. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8165496/webrev.07/ >>> >>> Bug link: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8165496 >>> >>> Two separate flags, exception_detected and exception_caught, replaced >>> with one that changes it's state. >>> >>> Assert assert(_exception_caught == false) and fix for JDK-8134434 are >>> removed. >>> >>> Testing: >>> 1. Manual testing of instrumented hotspot >>> 2. Local ks with stress agent >>> 3. RBT ks with stress agent >> What the 'ks' stands for? >> I have some guess but still would like to know this abbreviation. >> >> Thanks, >> Serguei >> >>> 4. RBT hotspot_all >>> >>> -Dmitry >>> > From erik.gahlin at oracle.com Tue Dec 6 20:52:51 2016 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 6 Dec 2016 21:52:51 +0100 Subject: RFR(S): 8170672: Event-based tracing to support classloader instances In-Reply-To: <023cfba7-0c69-4dc8-bbd0-b65df3cd6f64@default> References: <023cfba7-0c69-4dc8-bbd0-b65df3cd6f64@default> Message-ID: <58472523.3020402@oracle.com> Looks good. Erik > Greetings, > > Kindly asking for reviews for the following changeset: > > Bug/Enh: https://bugs.openjdk.java.net/browse/JDK-8170672 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8170672/webrev01/ > > > (this work is covered by an FC exception) > > Summary: > > Event-based tracing previously had little information about class > loaders; a class loader was essentially treated no different than from > a regular class (type information only). > > With JDK9, supported has been added to java.lang.ClassLoader to > associate a name with an individual class loader instance. > > This changeset will allow the name information of individual class > loader instances to be provided by the event-based tracing framework. > > Aux info: > > Some folding of the numerous macros completed as well. > > Thanks in advance > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.gronlund at oracle.com Tue Dec 6 21:24:15 2016 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 6 Dec 2016 13:24:15 -0800 (PST) Subject: RFR(S): 8170672: Event-based tracing to support classloader instances In-Reply-To: <58472523.3020402@oracle.com> References: <023cfba7-0c69-4dc8-bbd0-b65df3cd6f64@default> <58472523.3020402@oracle.com> Message-ID: <572926aa-d7c2-40f0-99aa-fc36f5e02649@default> Thanks Erik! Markus From: Erik Gahlin Sent: den 6 december 2016 21:53 To: serviceability-dev at openjdk.java.net Subject: Re: RFR(S): 8170672: Event-based tracing to support classloader instances Looks good. Erik Greetings, Kindly asking for reviews for the following changeset: Bug/Enh: https://bugs.openjdk.java.net/browse/JDK-8170672 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Emgronlun/8170672/webrev01/"http://cr.openjdk.java.net/~mgronlun/8170672/webrev01/ (this work is covered by an FC exception) Summary: Event-based tracing previously had little information about class loaders; a class loader was essentially treated no different than from a regular class (type information only). With JDK9, supported has been added to java.lang.ClassLoader to associate a name with an individual class loader instance. This changeset will allow the name information of individual class loader instances to be provided by the event-based tracing framework. Aux info: Some folding of the numerous macros completed as well. Thanks in advance Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From lois.foltan at oracle.com Tue Dec 6 22:02:15 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 06 Dec 2016 17:02:15 -0500 Subject: RFR(S): 8170672: Event-based tracing to support classloader instances In-Reply-To: <023cfba7-0c69-4dc8-bbd0-b65df3cd6f64@default> References: <023cfba7-0c69-4dc8-bbd0-b65df3cd6f64@default> Message-ID: <58473567.3030406@oracle.com> On 12/5/2016 6:33 PM, Markus Gronlund wrote: > Greetings, > > > > Kindly asking for reviews for the following changeset: > > > > Bug/Enh: https://bugs.openjdk.java.net/browse/JDK-8170672 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8170672/webrev01/ > > (this work is covered by an FC exception) Hi Markus, Looks good. One comment: src/share/vm/trace/traceStream.hpp - line #121 - you might want to check not only if the class_loader_name_oop is NULL but also for the empty string? Much like the code does in runtime/SharedRuntime.cpp class_loader_and_module_name()? Thanks, Lois > > > > Summary: > > Event-based tracing previously had little information about class loaders; a class loader was essentially treated no different than from a regular class (type information only). > > With JDK9, supported has been added to java.lang.ClassLoader to associate a name with an individual class loader instance. > > > > This changeset will allow the name information of individual class loader instances to be provided by the event-based tracing framework. > > > > Aux info: > > Some folding of the numerous macros completed as well. > > > > Thanks in advance > Markus > > From serguei.spitsyn at oracle.com Tue Dec 6 23:16:08 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 6 Dec 2016 15:16:08 -0800 Subject: [8u] RFR(S): Uninitialized memory in set_uintx_flag of attachListener.cpp In-Reply-To: <650a2295-e1ee-0e6b-f229-62521b91589d@oracle.com> References: <650a2295-e1ee-0e6b-f229-62521b91589d@oracle.com> Message-ID: <356562b9-e18d-6752-171f-945650a2941f@oracle.com> Ok++ Thanks, Serguei On 12/6/16 05:05, David Holmes wrote: > On 6/12/2016 9:58 PM, Dmitry Samersoff wrote: >> Everybody, >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8170536/webrev.01/ >> >> Please, review the fix. >> >> The code should return error if op->arg(1) is NULL. > > Looks ok. Only minor nit: > > 274 const char* arg1; > 275 > 276 arg1 = op->arg(1); > > can be: > > 274 const char* arg1 = op->arg(1); > > Oh and copyright year needs updating. > > Thanks, > David > >> -Dmitry >> From goetz.lindenmaier at sap.com Wed Dec 7 08:37:35 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 7 Dec 2016 08:37:35 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> Message-ID: <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> Hi Dmitry, thanks for looking at my change! Updated webrev: http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 > * src/java.base/unix/native/libjli/java_md_solinux.c > Is this line correct? > 519 jvmpath = JLI_StringDup(jvmpath); It seems pointless. Should I remove it? (The whole file is a horror.) > * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > It might be better to return immediately if cnt < 0, > regardless of value of sti. I'm not sure what you mean. I tried to fix it, but please double-check the new webrev. > * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > It might be better to write > arg.l_linger = (on) ? (unsigned short)value.i : 0; > and leave one copy of setsockopt() call Yes, looks better. Best regards, Goetz > > -Dmitry > > > On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > > Hi, > > > > > > > > This change fixes some minor issues found in our code scans. > > > > I hope this correctly addresses corelib and serviceability issues. > > > > > > > > Please review: > > > > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.01/ > > > > > > > > Best regards, > > > > Goetz. > > > > > > > > Changes in detail: > > > > > > > > e_asin.c > > > > Code scan reports missing {}. > > > > > > The code "if (huge+x>one) {" is only there to set the inexact flag of > > the processor. > > It's a way to avoid the C compiler to optimize the code away. It is > > always true, > > so the parenthesis of the outer else don't matter. > > > > Although this basically just adds the {} I would like to submit this to > > > > avoid anybody else spends more the 30sec on understanding these > > > > if statements. > > > > > > k_standard.c > > > > exc.retval is returned below and thus should always be initialized. > > > > > > imageDecompressor.cpp > > > > Wrong destructor is used. Reported also by David CARLIER > > > > > > java.c > > > > in line 1865 'name' was used, it should be 'alias'. > > > > > > java_md_solinux.c > > > > "//" in path is useless. Further down a free is missing. > > > > > > SDE.c > > > > Call to stratumTableIndex can return negative value if defaultStratumId > > == null. > > > > > > socket_md.c > > > > arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in > > the macros. > > > > > > unpack.cpp > > > > n.slice should not get negative argument for end, which is passed from > > dollar1. > > But dollar1 can get negative where it is set to the result of > > lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > > > > > -- > 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 Dec 7 09:31:50 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Dec 2016 19:31:50 +1000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> Message-ID: On 7/12/2016 6:37 PM, Lindenmaier, Goetz wrote: > Hi Dmitry, > > thanks for looking at my change! > Updated webrev: > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 > >> * src/java.base/unix/native/libjli/java_md_solinux.c >> Is this line correct? >> 519 jvmpath = JLI_StringDup(jvmpath); > > It seems pointless. Should I remove it? (The whole file is a horror.) Seems to me it is making a copy of the incoming char[] so that it can be modified in this function without affecting the original char[] in the caller. David ----- >> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >> It might be better to return immediately if cnt < 0, >> regardless of value of sti. > > I'm not sure what you mean. I tried to fix it, but please > double-check the new webrev. > >> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >> It might be better to write >> arg.l_linger = (on) ? (unsigned short)value.i : 0; >> and leave one copy of setsockopt() call > > Yes, looks better. > > Best regards, > Goetz > > >> >> -Dmitry >> >> >> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> >>> >>> This change fixes some minor issues found in our code scans. >>> >>> I hope this correctly addresses corelib and serviceability issues. >>> >>> >>> >>> Please review: >>> >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.01/ >>> >>> >>> >>> Best regards, >>> >>> Goetz. >>> >>> >>> >>> Changes in detail: >>> >>> >>> >>> e_asin.c >>> >>> Code scan reports missing {}. >>> >>> >>> The code "if (huge+x>one) {" is only there to set the inexact flag of >>> the processor. >>> It's a way to avoid the C compiler to optimize the code away. It is >>> always true, >>> so the parenthesis of the outer else don't matter. >>> >>> Although this basically just adds the {} I would like to submit this to >>> >>> avoid anybody else spends more the 30sec on understanding these >>> >>> if statements. >>> >>> >>> k_standard.c >>> >>> exc.retval is returned below and thus should always be initialized. >>> >>> >>> imageDecompressor.cpp >>> >>> Wrong destructor is used. Reported also by David CARLIER >>> >>> >>> java.c >>> >>> in line 1865 'name' was used, it should be 'alias'. >>> >>> >>> java_md_solinux.c >>> >>> "//" in path is useless. Further down a free is missing. >>> >>> >>> SDE.c >>> >>> Call to stratumTableIndex can return negative value if defaultStratumId >>> == null. >>> >>> >>> socket_md.c >>> >>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in >>> the macros. >>> >>> >>> unpack.cpp >>> >>> n.slice should not get negative argument for end, which is passed from >>> dollar1. >>> But dollar1 can get negative where it is set to the result of >>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>> >> >> >> -- >> 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 markus.gronlund at oracle.com Wed Dec 7 10:11:11 2016 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Wed, 7 Dec 2016 02:11:11 -0800 (PST) Subject: RFR(S): 8170672: Event-based tracing to support classloader instances In-Reply-To: <58473567.3030406@oracle.com> References: <023cfba7-0c69-4dc8-bbd0-b65df3cd6f64@default> <58473567.3030406@oracle.com> Message-ID: Hi Lois, Many thanks for taking a look at this - unfortunately i did submit the changeset before I saw your input, sorry about that. Good point about also checking for the empty string. I just filed https://bugs.openjdk.java.net/browse/JDK-8170847 so i will incorporate your feedback there. Thanks again Markus -----Original Message----- From: Lois Foltan Sent: den 6 december 2016 23:02 To: Markus Gronlund Cc: hotspot-runtime-dev; serviceability-dev at openjdk.java.net Subject: Re: RFR(S): 8170672: Event-based tracing to support classloader instances On 12/5/2016 6:33 PM, Markus Gronlund wrote: > Greetings, > > > > Kindly asking for reviews for the following changeset: > > > > Bug/Enh: https://bugs.openjdk.java.net/browse/JDK-8170672 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8170672/webrev01/ > > (this work is covered by an FC exception) Hi Markus, Looks good. One comment: src/share/vm/trace/traceStream.hpp - line #121 - you might want to check not only if the class_loader_name_oop is NULL but also for the empty string? Much like the code does in runtime/SharedRuntime.cpp class_loader_and_module_name()? Thanks, Lois > > > > Summary: > > Event-based tracing previously had little information about class loaders; a class loader was essentially treated no different than from a regular class (type information only). > > With JDK9, supported has been added to java.lang.ClassLoader to associate a name with an individual class loader instance. > > > > This changeset will allow the name information of individual class loader instances to be provided by the event-based tracing framework. > > > > Aux info: > > Some folding of the numerous macros completed as well. > > > > Thanks in advance > Markus > > From goetz.lindenmaier at sap.com Wed Dec 7 11:54:31 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 7 Dec 2016 11:54:31 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> Message-ID: <0a542d83bca24747a6361215e522304b@DEROTE13DE08.global.corp.sap> Ah, you're right, the 'lastslash' assignment! Thanks, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Wednesday, December 07, 2016 10:32 AM > To: Lindenmaier, Goetz ; 'Dmitry Samersoff' > ; Java Core Libs dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > On 7/12/2016 6:37 PM, Lindenmaier, Goetz wrote: > > Hi Dmitry, > > > > thanks for looking at my change! > > Updated webrev: > > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 > > > >> * src/java.base/unix/native/libjli/java_md_solinux.c > >> Is this line correct? > >> 519 jvmpath = JLI_StringDup(jvmpath); > > > > It seems pointless. Should I remove it? (The whole file is a horror.) > > Seems to me it is making a copy of the incoming char[] so that it can be > modified in this function without affecting the original char[] in the > caller. > > David > ----- > > > >> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > >> It might be better to return immediately if cnt < 0, > >> regardless of value of sti. > > > > I'm not sure what you mean. I tried to fix it, but please > > double-check the new webrev. > > > >> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > >> It might be better to write > >> arg.l_linger = (on) ? (unsigned short)value.i : 0; > >> and leave one copy of setsockopt() call > > > > Yes, looks better. > > > > Best regards, > > Goetz > > > > > >> > >> -Dmitry > >> > >> > >> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> > >>> > >>> This change fixes some minor issues found in our code scans. > >>> > >>> I hope this correctly addresses corelib and serviceability issues. > >>> > >>> > >>> > >>> Please review: > >>> > >>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > corlib_s11y/webrev.01/ > >>> > >>> > >>> > >>> Best regards, > >>> > >>> Goetz. > >>> > >>> > >>> > >>> Changes in detail: > >>> > >>> > >>> > >>> e_asin.c > >>> > >>> Code scan reports missing {}. > >>> > >>> > >>> The code "if (huge+x>one) {" is only there to set the inexact flag of > >>> the processor. > >>> It's a way to avoid the C compiler to optimize the code away. It is > >>> always true, > >>> so the parenthesis of the outer else don't matter. > >>> > >>> Although this basically just adds the {} I would like to submit this to > >>> > >>> avoid anybody else spends more the 30sec on understanding these > >>> > >>> if statements. > >>> > >>> > >>> k_standard.c > >>> > >>> exc.retval is returned below and thus should always be initialized. > >>> > >>> > >>> imageDecompressor.cpp > >>> > >>> Wrong destructor is used. Reported also by David CARLIER > >>> > >>> > >>> java.c > >>> > >>> in line 1865 'name' was used, it should be 'alias'. > >>> > >>> > >>> java_md_solinux.c > >>> > >>> "//" in path is useless. Further down a free is missing. > >>> > >>> > >>> SDE.c > >>> > >>> Call to stratumTableIndex can return negative value if defaultStratumId > >>> == null. > >>> > >>> > >>> socket_md.c > >>> > >>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in > >>> the macros. > >>> > >>> > >>> unpack.cpp > >>> > >>> n.slice should not get negative argument for end, which is passed from > >>> dollar1. > >>> But dollar1 can get negative where it is set to the result of > >>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > >>> > >> > >> > >> -- > >> 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 dmitry.samersoff at oracle.com Wed Dec 7 13:19:04 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 7 Dec 2016 16:19:04 +0300 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <0a542d83bca24747a6361215e522304b@DEROTE13DE08.global.corp.sap> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <0a542d83bca24747a6361215e522304b@DEROTE13DE08.global.corp.sap> Message-ID: Goetz, On 2016-12-07 14:54, Lindenmaier, Goetz wrote: > Ah, you're right, the 'lastslash' assignment! In this case we have to keep strdup. Could we at least change it to something like new_jvmpath = JLI_StringDup(jvmpath); and use new_jvmpath below. And yes, the whole file is a horror. -Dmitry > > Thanks, > Goetz. > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Wednesday, December 07, 2016 10:32 AM >> To: Lindenmaier, Goetz ; 'Dmitry Samersoff' >> ; Java Core Libs > dev at openjdk.java.net>; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >> coding. >> >> On 7/12/2016 6:37 PM, Lindenmaier, Goetz wrote: >>> Hi Dmitry, >>> >>> thanks for looking at my change! >>> Updated webrev: >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 >>> >>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>> Is this line correct? >>>> 519 jvmpath = JLI_StringDup(jvmpath); >>> >>> It seems pointless. Should I remove it? (The whole file is a horror.) >> >> Seems to me it is making a copy of the incoming char[] so that it can be >> modified in this function without affecting the original char[] in the >> caller. >> >> David >> ----- >> >> >>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>> It might be better to return immediately if cnt < 0, >>>> regardless of value of sti. >>> >>> I'm not sure what you mean. I tried to fix it, but please >>> double-check the new webrev. >>> >>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>> It might be better to write >>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>> and leave one copy of setsockopt() call >>> >>> Yes, looks better. >>> >>> Best regards, >>> Goetz >>> >>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> >>>>> >>>>> This change fixes some minor issues found in our code scans. >>>>> >>>>> I hope this correctly addresses corelib and serviceability issues. >>>>> >>>>> >>>>> >>>>> Please review: >>>>> >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >> corlib_s11y/webrev.01/ >>>>> >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> Changes in detail: >>>>> >>>>> >>>>> >>>>> e_asin.c >>>>> >>>>> Code scan reports missing {}. >>>>> >>>>> >>>>> The code "if (huge+x>one) {" is only there to set the inexact flag of >>>>> the processor. >>>>> It's a way to avoid the C compiler to optimize the code away. It is >>>>> always true, >>>>> so the parenthesis of the outer else don't matter. >>>>> >>>>> Although this basically just adds the {} I would like to submit this to >>>>> >>>>> avoid anybody else spends more the 30sec on understanding these >>>>> >>>>> if statements. >>>>> >>>>> >>>>> k_standard.c >>>>> >>>>> exc.retval is returned below and thus should always be initialized. >>>>> >>>>> >>>>> imageDecompressor.cpp >>>>> >>>>> Wrong destructor is used. Reported also by David CARLIER >>>>> >>>>> >>>>> java.c >>>>> >>>>> in line 1865 'name' was used, it should be 'alias'. >>>>> >>>>> >>>>> java_md_solinux.c >>>>> >>>>> "//" in path is useless. Further down a free is missing. >>>>> >>>>> >>>>> SDE.c >>>>> >>>>> Call to stratumTableIndex can return negative value if defaultStratumId >>>>> == null. >>>>> >>>>> >>>>> socket_md.c >>>>> >>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in >>>>> the macros. >>>>> >>>>> >>>>> unpack.cpp >>>>> >>>>> n.slice should not get negative argument for end, which is passed from >>>>> dollar1. >>>>> But dollar1 can get negative where it is set to the result of >>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>> >>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. -- 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 dmitry.samersoff at oracle.com Wed Dec 7 13:43:19 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 7 Dec 2016 16:43:19 +0300 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> Message-ID: Goetz, SDE.c: You might combine if at ll. 260 and 263 to one but it's just matter of test. if (sti == baseStratumIndex || sti < 0) { return; /* Java stratum - return unchanged */ } > I'm not sure what you mean. I tried to fix it, but please > double-check the new webrev. if cnt is <= 0 loop at l.267 for (; cnt-- > 0; ++fromEntry) { is never run and we effectively do *entryCountPtr = 0; at l.283 So if we you suspect that cnt may become negative or 0: (your v.01 changes) 260 if (sti < 0 && cnt > 0) { 261 return; 262 } it's better to check it early. But I'm not sure we have to care about negative/zero cnt here. -Dmitry On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > Hi Dmitry, > > thanks for looking at my change! > Updated webrev: > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 > >> * src/java.base/unix/native/libjli/java_md_solinux.c >> Is this line correct? >> 519 jvmpath = JLI_StringDup(jvmpath); > > It seems pointless. Should I remove it? (The whole file is a horror.) > >> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >> It might be better to return immediately if cnt < 0, >> regardless of value of sti. > > I'm not sure what you mean. I tried to fix it, but please > double-check the new webrev. > >> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >> It might be better to write >> arg.l_linger = (on) ? (unsigned short)value.i : 0; >> and leave one copy of setsockopt() call > > Yes, looks better. > > Best regards, > Goetz > > >> >> -Dmitry >> >> >> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> >>> >>> This change fixes some minor issues found in our code scans. >>> >>> I hope this correctly addresses corelib and serviceability issues. >>> >>> >>> >>> Please review: >>> >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.01/ >>> >>> >>> >>> Best regards, >>> >>> Goetz. >>> >>> >>> >>> Changes in detail: >>> >>> >>> >>> e_asin.c >>> >>> Code scan reports missing {}. >>> >>> >>> The code "if (huge+x>one) {" is only there to set the inexact flag of >>> the processor. >>> It's a way to avoid the C compiler to optimize the code away. It is >>> always true, >>> so the parenthesis of the outer else don't matter. >>> >>> Although this basically just adds the {} I would like to submit this to >>> >>> avoid anybody else spends more the 30sec on understanding these >>> >>> if statements. >>> >>> >>> k_standard.c >>> >>> exc.retval is returned below and thus should always be initialized. >>> >>> >>> imageDecompressor.cpp >>> >>> Wrong destructor is used. Reported also by David CARLIER >>> >>> >>> java.c >>> >>> in line 1865 'name' was used, it should be 'alias'. >>> >>> >>> java_md_solinux.c >>> >>> "//" in path is useless. Further down a free is missing. >>> >>> >>> SDE.c >>> >>> Call to stratumTableIndex can return negative value if defaultStratumId >>> == null. >>> >>> >>> socket_md.c >>> >>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in >>> the macros. >>> >>> >>> unpack.cpp >>> >>> n.slice should not get negative argument for end, which is passed from >>> dollar1. >>> But dollar1 can get negative where it is set to the result of >>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. -- 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 goetz.lindenmaier at sap.com Wed Dec 7 15:26:59 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 7 Dec 2016 15:26:59 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> Message-ID: Hi Dmitry, yes, new_jvmpath is consistent with the other variables. I also merged the ifs in SDE.c. new webrev: http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ Best regards, Goetz. > -----Original Message----- > From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > Sent: Wednesday, December 07, 2016 2:43 PM > To: Lindenmaier, Goetz ; Java Core Libs > ; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > Goetz, > > SDE.c: > > You might combine if at ll. 260 and 263 to one but it's just matter of test. > > if (sti == baseStratumIndex || sti < 0) { > return; /* Java stratum - return unchanged */ > } > > > I'm not sure what you mean. I tried to fix it, but please > > double-check the new webrev. > > if cnt is <= 0 loop at l.267 > > for (; cnt-- > 0; ++fromEntry) { > > is never run and we effectively do > > *entryCountPtr = 0; > > at l.283 > > So if we you suspect that cnt may become negative or 0: > (your v.01 changes) > > 260 if (sti < 0 && cnt > 0) { > 261 return; > 262 } > > it's better to check it early. > > But I'm not sure we have to care about negative/zero cnt here. > > -Dmitry > > On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > > Hi Dmitry, > > > > thanks for looking at my change! > > Updated webrev: > > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 > > > >> * src/java.base/unix/native/libjli/java_md_solinux.c > >> Is this line correct? > >> 519 jvmpath = JLI_StringDup(jvmpath); > > > > It seems pointless. Should I remove it? (The whole file is a horror.) > > > >> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > >> It might be better to return immediately if cnt < 0, > >> regardless of value of sti. > > > > I'm not sure what you mean. I tried to fix it, but please > > double-check the new webrev. > > > >> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > >> It might be better to write > >> arg.l_linger = (on) ? (unsigned short)value.i : 0; > >> and leave one copy of setsockopt() call > > > > Yes, looks better. > > > > Best regards, > > Goetz > > > > > >> > >> -Dmitry > >> > >> > >> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> > >>> > >>> This change fixes some minor issues found in our code scans. > >>> > >>> I hope this correctly addresses corelib and serviceability issues. > >>> > >>> > >>> > >>> Please review: > >>> > >>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > corlib_s11y/webrev.01/ > >>> > >>> > >>> > >>> Best regards, > >>> > >>> Goetz. > >>> > >>> > >>> > >>> Changes in detail: > >>> > >>> > >>> > >>> e_asin.c > >>> > >>> Code scan reports missing {}. > >>> > >>> > >>> The code "if (huge+x>one) {" is only there to set the inexact flag of > >>> the processor. > >>> It's a way to avoid the C compiler to optimize the code away. It is > >>> always true, > >>> so the parenthesis of the outer else don't matter. > >>> > >>> Although this basically just adds the {} I would like to submit this to > >>> > >>> avoid anybody else spends more the 30sec on understanding these > >>> > >>> if statements. > >>> > >>> > >>> k_standard.c > >>> > >>> exc.retval is returned below and thus should always be initialized. > >>> > >>> > >>> imageDecompressor.cpp > >>> > >>> Wrong destructor is used. Reported also by David CARLIER > >>> > >>> > >>> java.c > >>> > >>> in line 1865 'name' was used, it should be 'alias'. > >>> > >>> > >>> java_md_solinux.c > >>> > >>> "//" in path is useless. Further down a free is missing. > >>> > >>> > >>> SDE.c > >>> > >>> Call to stratumTableIndex can return negative value if defaultStratumId > >>> == null. > >>> > >>> > >>> socket_md.c > >>> > >>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in > >>> the macros. > >>> > >>> > >>> unpack.cpp > >>> > >>> n.slice should not get negative argument for end, which is passed from > >>> dollar1. > >>> But dollar1 can get negative where it is set to the result of > >>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > >>> > >> > >> > >> -- > >> Dmitry Samersoff > >> Oracle Java development team, Saint Petersburg, Russia > >> * I would love to change the world, but they won't give me the sources. > > > -- > 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 dmitry.samersoff at oracle.com Wed Dec 7 16:10:06 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 7 Dec 2016 19:10:06 +0300 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> Message-ID: Goetz, This version of serviceability changes looks good to me. -Dmitry On 2016-12-07 18:26, Lindenmaier, Goetz wrote: > Hi Dmitry, > > yes, new_jvmpath is consistent with the other variables. > I also merged the ifs in SDE.c. > > new webrev: > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ > > Best regards, > Goetz. > >> -----Original Message----- >> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >> Sent: Wednesday, December 07, 2016 2:43 PM >> To: Lindenmaier, Goetz ; Java Core Libs >> ; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >> coding. >> >> Goetz, >> >> SDE.c: >> >> You might combine if at ll. 260 and 263 to one but it's just matter of test. >> >> if (sti == baseStratumIndex || sti < 0) { >> return; /* Java stratum - return unchanged */ >> } >> >>> I'm not sure what you mean. I tried to fix it, but please >>> double-check the new webrev. >> >> if cnt is <= 0 loop at l.267 >> >> for (; cnt-- > 0; ++fromEntry) { >> >> is never run and we effectively do >> >> *entryCountPtr = 0; >> >> at l.283 >> >> So if we you suspect that cnt may become negative or 0: >> (your v.01 changes) >> >> 260 if (sti < 0 && cnt > 0) { >> 261 return; >> 262 } >> >> it's better to check it early. >> >> But I'm not sure we have to care about negative/zero cnt here. >> >> -Dmitry >> >> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>> Hi Dmitry, >>> >>> thanks for looking at my change! >>> Updated webrev: >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 >>> >>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>> Is this line correct? >>>> 519 jvmpath = JLI_StringDup(jvmpath); >>> >>> It seems pointless. Should I remove it? (The whole file is a horror.) >>> >>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>> It might be better to return immediately if cnt < 0, >>>> regardless of value of sti. >>> >>> I'm not sure what you mean. I tried to fix it, but please >>> double-check the new webrev. >>> >>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>> It might be better to write >>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>> and leave one copy of setsockopt() call >>> >>> Yes, looks better. >>> >>> Best regards, >>> Goetz >>> >>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> >>>>> >>>>> This change fixes some minor issues found in our code scans. >>>>> >>>>> I hope this correctly addresses corelib and serviceability issues. >>>>> >>>>> >>>>> >>>>> Please review: >>>>> >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >> corlib_s11y/webrev.01/ >>>>> >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> Changes in detail: >>>>> >>>>> >>>>> >>>>> e_asin.c >>>>> >>>>> Code scan reports missing {}. >>>>> >>>>> >>>>> The code "if (huge+x>one) {" is only there to set the inexact flag of >>>>> the processor. >>>>> It's a way to avoid the C compiler to optimize the code away. It is >>>>> always true, >>>>> so the parenthesis of the outer else don't matter. >>>>> >>>>> Although this basically just adds the {} I would like to submit this to >>>>> >>>>> avoid anybody else spends more the 30sec on understanding these >>>>> >>>>> if statements. >>>>> >>>>> >>>>> k_standard.c >>>>> >>>>> exc.retval is returned below and thus should always be initialized. >>>>> >>>>> >>>>> imageDecompressor.cpp >>>>> >>>>> Wrong destructor is used. Reported also by David CARLIER >>>>> >>>>> >>>>> java.c >>>>> >>>>> in line 1865 'name' was used, it should be 'alias'. >>>>> >>>>> >>>>> java_md_solinux.c >>>>> >>>>> "//" in path is useless. Further down a free is missing. >>>>> >>>>> >>>>> SDE.c >>>>> >>>>> Call to stratumTableIndex can return negative value if defaultStratumId >>>>> == null. >>>>> >>>>> >>>>> socket_md.c >>>>> >>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in >>>>> the macros. >>>>> >>>>> >>>>> unpack.cpp >>>>> >>>>> n.slice should not get negative argument for end, which is passed from >>>>> dollar1. >>>>> But dollar1 can get negative where it is set to the result of >>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>> >>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. -- 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 martinrb at google.com Wed Dec 7 17:09:21 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 7 Dec 2016 09:09:21 -0800 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> Message-ID: This changes fdlibm, which has historically been untouched. Don't commit without Joe Darcy's approval. On Wed, Dec 7, 2016 at 7:26 AM, Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi Dmitry, > > yes, new_jvmpath is consistent with the other variables. > I also merged the ifs in SDE.c. > > new webrev: > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ > > Best regards, > Goetz. > > > -----Original Message----- > > From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > > Sent: Wednesday, December 07, 2016 2:43 PM > > To: Lindenmaier, Goetz ; Java Core Libs > > ; serviceability-dev (serviceability- > > dev at openjdk.java.net) > > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > servicabilty > > coding. > > > > Goetz, > > > > SDE.c: > > > > You might combine if at ll. 260 and 263 to one but it's just matter of > test. > > > > if (sti == baseStratumIndex || sti < 0) { > > return; /* Java stratum - return unchanged */ > > } > > > > > I'm not sure what you mean. I tried to fix it, but please > > > double-check the new webrev. > > > > if cnt is <= 0 loop at l.267 > > > > for (; cnt-- > 0; ++fromEntry) { > > > > is never run and we effectively do > > > > *entryCountPtr = 0; > > > > at l.283 > > > > So if we you suspect that cnt may become negative or 0: > > (your v.01 changes) > > > > 260 if (sti < 0 && cnt > 0) { > > 261 return; > > 262 } > > > > it's better to check it early. > > > > But I'm not sure we have to care about negative/zero cnt here. > > > > -Dmitry > > > > On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > > > Hi Dmitry, > > > > > > thanks for looking at my change! > > > Updated webrev: > > > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 > > > > > >> * src/java.base/unix/native/libjli/java_md_solinux.c > > >> Is this line correct? > > >> 519 jvmpath = JLI_StringDup(jvmpath); > > > > > > It seems pointless. Should I remove it? (The whole file is a horror.) > > > > > >> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > > >> It might be better to return immediately if cnt < 0, > > >> regardless of value of sti. > > > > > > I'm not sure what you mean. I tried to fix it, but please > > > double-check the new webrev. > > > > > >> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > > >> It might be better to write > > >> arg.l_linger = (on) ? (unsigned short)value.i : 0; > > >> and leave one copy of setsockopt() call > > > > > > Yes, looks better. > > > > > > Best regards, > > > Goetz > > > > > > > > >> > > >> -Dmitry > > >> > > >> > > >> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > > >>> Hi, > > >>> > > >>> > > >>> > > >>> This change fixes some minor issues found in our code scans. > > >>> > > >>> I hope this correctly addresses corelib and serviceability issues. > > >>> > > >>> > > >>> > > >>> Please review: > > >>> > > >>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > > corlib_s11y/webrev.01/ > > >>> > > >>> > > >>> > > >>> Best regards, > > >>> > > >>> Goetz. > > >>> > > >>> > > >>> > > >>> Changes in detail: > > >>> > > >>> > > >>> > > >>> e_asin.c > > >>> > > >>> Code scan reports missing {}. > > >>> > > >>> > > >>> The code "if (huge+x>one) {" is only there to set the inexact flag of > > >>> the processor. > > >>> It's a way to avoid the C compiler to optimize the code away. It is > > >>> always true, > > >>> so the parenthesis of the outer else don't matter. > > >>> > > >>> Although this basically just adds the {} I would like to submit this > to > > >>> > > >>> avoid anybody else spends more the 30sec on understanding these > > >>> > > >>> if statements. > > >>> > > >>> > > >>> k_standard.c > > >>> > > >>> exc.retval is returned below and thus should always be initialized. > > >>> > > >>> > > >>> imageDecompressor.cpp > > >>> > > >>> Wrong destructor is used. Reported also by David CARLIER > > >>> > > >>> > > >>> java.c > > >>> > > >>> in line 1865 'name' was used, it should be 'alias'. > > >>> > > >>> > > >>> java_md_solinux.c > > >>> > > >>> "//" in path is useless. Further down a free is missing. > > >>> > > >>> > > >>> SDE.c > > >>> > > >>> Call to stratumTableIndex can return negative value if > defaultStratumId > > >>> == null. > > >>> > > >>> > > >>> socket_md.c > > >>> > > >>> arg.l_linger is passed to setsockopt uninitialized. Its use is > hidden in > > >>> the macros. > > >>> > > >>> > > >>> unpack.cpp > > >>> > > >>> n.slice should not get negative argument for end, which is passed > from > > >>> dollar1. > > >>> But dollar1 can get negative where it is set to the result of > > >>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > > >>> > > >> > > >> > > >> -- > > >> Dmitry Samersoff > > >> Oracle Java development team, Saint Petersburg, Russia > > >> * I would love to change the world, but they won't give me the > sources. > > > > > > -- > > 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 Thu Dec 8 08:13:31 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Dec 2016 18:13:31 +1000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> Message-ID: <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> Hi Goetz, On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: > Hi Dmitry, > > yes, new_jvmpath is consistent with the other variables. > I also merged the ifs in SDE.c. > > new webrev: > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ src/java.base/share/native/libjli/java.c As far as I can see the existing code is working perfectly fine. Given a jvm.cfg with: -server KNOWN -client IGNORE -myvm KNOWN -oldvm ALIASED_TO -server The usage text is: -server to select the "server" VM -myvm to select the "myvm" VM -oldvm is a synonym for the "server" VM [deprecated] The default VM is server, because you are running on a server-class machine. which is exactly what I would expect. Why do you think there is a bug? --- src/java.base/unix/native/libjli/java_md_solinux.c Again I'm not sure what the bug is here. On AIX the output string is expanded with: "%s/lib/%s/jli:" so it needs to account for the extra "/lib//jli:" characters - and that is exactly what the existing code does: + JLI_StrLen("/lib//jli:") The jvmpath -> jvm_newpath change wasn't really necessary - a comment on the strdup would have sufficed IMO. Thanks, David ----- > Best regards, > Goetz. > >> -----Original Message----- >> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >> Sent: Wednesday, December 07, 2016 2:43 PM >> To: Lindenmaier, Goetz ; Java Core Libs >> ; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >> coding. >> >> Goetz, >> >> SDE.c: >> >> You might combine if at ll. 260 and 263 to one but it's just matter of test. >> >> if (sti == baseStratumIndex || sti < 0) { >> return; /* Java stratum - return unchanged */ >> } >> >>> I'm not sure what you mean. I tried to fix it, but please >>> double-check the new webrev. >> >> if cnt is <= 0 loop at l.267 >> >> for (; cnt-- > 0; ++fromEntry) { >> >> is never run and we effectively do >> >> *entryCountPtr = 0; >> >> at l.283 >> >> So if we you suspect that cnt may become negative or 0: >> (your v.01 changes) >> >> 260 if (sti < 0 && cnt > 0) { >> 261 return; >> 262 } >> >> it's better to check it early. >> >> But I'm not sure we have to care about negative/zero cnt here. >> >> -Dmitry >> >> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>> Hi Dmitry, >>> >>> thanks for looking at my change! >>> Updated webrev: >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 >>> >>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>> Is this line correct? >>>> 519 jvmpath = JLI_StringDup(jvmpath); >>> >>> It seems pointless. Should I remove it? (The whole file is a horror.) >>> >>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>> It might be better to return immediately if cnt < 0, >>>> regardless of value of sti. >>> >>> I'm not sure what you mean. I tried to fix it, but please >>> double-check the new webrev. >>> >>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>> It might be better to write >>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>> and leave one copy of setsockopt() call >>> >>> Yes, looks better. >>> >>> Best regards, >>> Goetz >>> >>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> >>>>> >>>>> This change fixes some minor issues found in our code scans. >>>>> >>>>> I hope this correctly addresses corelib and serviceability issues. >>>>> >>>>> >>>>> >>>>> Please review: >>>>> >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >> corlib_s11y/webrev.01/ >>>>> >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> Changes in detail: >>>>> >>>>> >>>>> >>>>> e_asin.c >>>>> >>>>> Code scan reports missing {}. >>>>> >>>>> >>>>> The code "if (huge+x>one) {" is only there to set the inexact flag of >>>>> the processor. >>>>> It's a way to avoid the C compiler to optimize the code away. It is >>>>> always true, >>>>> so the parenthesis of the outer else don't matter. >>>>> >>>>> Although this basically just adds the {} I would like to submit this to >>>>> >>>>> avoid anybody else spends more the 30sec on understanding these >>>>> >>>>> if statements. >>>>> >>>>> >>>>> k_standard.c >>>>> >>>>> exc.retval is returned below and thus should always be initialized. >>>>> >>>>> >>>>> imageDecompressor.cpp >>>>> >>>>> Wrong destructor is used. Reported also by David CARLIER >>>>> >>>>> >>>>> java.c >>>>> >>>>> in line 1865 'name' was used, it should be 'alias'. >>>>> >>>>> >>>>> java_md_solinux.c >>>>> >>>>> "//" in path is useless. Further down a free is missing. >>>>> >>>>> >>>>> SDE.c >>>>> >>>>> Call to stratumTableIndex can return negative value if defaultStratumId >>>>> == null. >>>>> >>>>> >>>>> socket_md.c >>>>> >>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in >>>>> the macros. >>>>> >>>>> >>>>> unpack.cpp >>>>> >>>>> n.slice should not get negative argument for end, which is passed from >>>>> dollar1. >>>>> But dollar1 can get negative where it is set to the result of >>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>> >>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. >> >> >> -- >> 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 goetz.lindenmaier at sap.com Thu Dec 8 14:21:23 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 8 Dec 2016 14:21:23 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> Message-ID: Hi David, thanks for looking at the change. New webrev: http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ > src/java.base/share/native/libjli/java.c > As far as I can see the existing code is working perfectly fine. Ah, thanks for the explanation, now I got it! Removed. > Again I'm not sure what the bug is here. On AIX the output string is > expanded with: > "%s/lib/%s/jli:" I first edited this against jdk9/hs, where the arch is gone since 8066474, http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc but the // was not adapted. Then I moved the change to jdk9/dev because I thought I have to push it there. And yes, in that coding // would be correct. So I have to wait until hs is promoted ... > The jvmpath -> jvm_newpath change wasn't really necessary - a comment on > the strdup would have sufficed IMO. Dmitry asked me to add it. But I think it's ok. Can I consider this reviewed now? I.e. could I push it once 8066474 is promoted and Joe Darcy agreed? Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 8. Dezember 2016 09:14 > To: Lindenmaier, Goetz ; 'Dmitry Samersoff' > ; Java Core Libs dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > Hi Goetz, > > On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: > > Hi Dmitry, > > > > yes, new_jvmpath is consistent with the other variables. > > I also merged the ifs in SDE.c. > > > > new webrev: > > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ > > src/java.base/share/native/libjli/java.c > > As far as I can see the existing code is working perfectly fine. Given a > jvm.cfg with: > > -server KNOWN > -client IGNORE > -myvm KNOWN > -oldvm ALIASED_TO -server > > The usage text is: > > -server to select the "server" VM > -myvm to select the "myvm" VM > -oldvm is a synonym for the "server" VM [deprecated] > The default VM is server, > because you are running on a server-class machine. > > which is exactly what I would expect. Why do you think there is a bug? > > --- > > src/java.base/unix/native/libjli/java_md_solinux.c > > Again I'm not sure what the bug is here. On AIX the output string is > expanded with: > > "%s/lib/%s/jli:" > > so it needs to account for the extra "/lib//jli:" characters - and that > is exactly what the existing code does: > > + JLI_StrLen("/lib//jli:") > > The jvmpath -> jvm_newpath change wasn't really necessary - a comment on > the strdup would have sufficed IMO. > > Thanks, > David > ----- > > > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > >> Sent: Wednesday, December 07, 2016 2:43 PM > >> To: Lindenmaier, Goetz ; Java Core Libs > >> ; serviceability-dev (serviceability- > >> dev at openjdk.java.net) > >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > >> coding. > >> > >> Goetz, > >> > >> SDE.c: > >> > >> You might combine if at ll. 260 and 263 to one but it's just matter of test. > >> > >> if (sti == baseStratumIndex || sti < 0) { > >> return; /* Java stratum - return unchanged */ > >> } > >> > >>> I'm not sure what you mean. I tried to fix it, but please > >>> double-check the new webrev. > >> > >> if cnt is <= 0 loop at l.267 > >> > >> for (; cnt-- > 0; ++fromEntry) { > >> > >> is never run and we effectively do > >> > >> *entryCountPtr = 0; > >> > >> at l.283 > >> > >> So if we you suspect that cnt may become negative or 0: > >> (your v.01 changes) > >> > >> 260 if (sti < 0 && cnt > 0) { > >> 261 return; > >> 262 } > >> > >> it's better to check it early. > >> > >> But I'm not sure we have to care about negative/zero cnt here. > >> > >> -Dmitry > >> > >> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > >>> Hi Dmitry, > >>> > >>> thanks for looking at my change! > >>> Updated webrev: > >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 > >>> > >>>> * src/java.base/unix/native/libjli/java_md_solinux.c > >>>> Is this line correct? > >>>> 519 jvmpath = JLI_StringDup(jvmpath); > >>> > >>> It seems pointless. Should I remove it? (The whole file is a horror.) > >>> > >>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > >>>> It might be better to return immediately if cnt < 0, > >>>> regardless of value of sti. > >>> > >>> I'm not sure what you mean. I tried to fix it, but please > >>> double-check the new webrev. > >>> > >>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > >>>> It might be better to write > >>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; > >>>> and leave one copy of setsockopt() call > >>> > >>> Yes, looks better. > >>> > >>> Best regards, > >>> Goetz > >>> > >>> > >>>> > >>>> -Dmitry > >>>> > >>>> > >>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > >>>>> Hi, > >>>>> > >>>>> > >>>>> > >>>>> This change fixes some minor issues found in our code scans. > >>>>> > >>>>> I hope this correctly addresses corelib and serviceability issues. > >>>>> > >>>>> > >>>>> > >>>>> Please review: > >>>>> > >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >> corlib_s11y/webrev.01/ > >>>>> > >>>>> > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Goetz. > >>>>> > >>>>> > >>>>> > >>>>> Changes in detail: > >>>>> > >>>>> > >>>>> > >>>>> e_asin.c > >>>>> > >>>>> Code scan reports missing {}. > >>>>> > >>>>> > >>>>> The code "if (huge+x>one) {" is only there to set the inexact flag of > >>>>> the processor. > >>>>> It's a way to avoid the C compiler to optimize the code away. It is > >>>>> always true, > >>>>> so the parenthesis of the outer else don't matter. > >>>>> > >>>>> Although this basically just adds the {} I would like to submit this to > >>>>> > >>>>> avoid anybody else spends more the 30sec on understanding these > >>>>> > >>>>> if statements. > >>>>> > >>>>> > >>>>> k_standard.c > >>>>> > >>>>> exc.retval is returned below and thus should always be initialized. > >>>>> > >>>>> > >>>>> imageDecompressor.cpp > >>>>> > >>>>> Wrong destructor is used. Reported also by David CARLIER > >>>>> > >>>>> > >>>>> java.c > >>>>> > >>>>> in line 1865 'name' was used, it should be 'alias'. > >>>>> > >>>>> > >>>>> java_md_solinux.c > >>>>> > >>>>> "//" in path is useless. Further down a free is missing. > >>>>> > >>>>> > >>>>> SDE.c > >>>>> > >>>>> Call to stratumTableIndex can return negative value if defaultStratumId > >>>>> == null. > >>>>> > >>>>> > >>>>> socket_md.c > >>>>> > >>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in > >>>>> the macros. > >>>>> > >>>>> > >>>>> unpack.cpp > >>>>> > >>>>> n.slice should not get negative argument for end, which is passed from > >>>>> dollar1. > >>>>> But dollar1 can get negative where it is set to the result of > >>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > >>>>> > >>>> > >>>> > >>>> -- > >>>> Dmitry Samersoff > >>>> Oracle Java development team, Saint Petersburg, Russia > >>>> * I would love to change the world, but they won't give me the sources. > >> > >> > >> -- > >> 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 dmitry.samersoff at oracle.com Thu Dec 8 18:54:21 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 8 Dec 2016 21:54:21 +0300 Subject: RFR(S): JDK-8150563: LoadAgentDcmdTest.java can't find libinstrument.so Message-ID: Everybody, Please, review small test-only fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8150563/webrev.01/ Test changed to reflect changes for: JDK-8066474 Remove the lib/$ARCH directory from Linux and Solaris images Changes verified with rbt. -Dmitry -- 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 serguei.spitsyn at oracle.com Thu Dec 8 19:38:00 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 8 Dec 2016 11:38:00 -0800 Subject: RFR(S): JDK-8150563: LoadAgentDcmdTest.java can't find libinstrument.so In-Reply-To: References: Message-ID: <61706b39-193f-9ee7-9fa4-e75099790907@oracle.com> Dmitry, It looks good. Thanks, Serguei On 12/8/16 10:54, Dmitry Samersoff wrote: > Everybody, > > Please, review small test-only fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8150563/webrev.01/ > > Test changed to reflect changes for: > > JDK-8066474 Remove the lib/$ARCH directory from Linux and Solaris images > > Changes verified with rbt. > > -Dmitry > From david.holmes at oracle.com Thu Dec 8 20:59:07 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 9 Dec 2016 06:59:07 +1000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> Message-ID: <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: > Hi David, > > thanks for looking at the change. New webrev: > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ > >> src/java.base/share/native/libjli/java.c >> As far as I can see the existing code is working perfectly fine. > Ah, thanks for the explanation, now I got it! Removed. > >> Again I'm not sure what the bug is here. On AIX the output string is >> expanded with: >> "%s/lib/%s/jli:" > I first edited this against jdk9/hs, where the arch is gone since 8066474, > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc > but the // was not adapted. Then I moved the change to jdk9/dev because > I thought I have to push it there. And yes, in that coding // would be correct. > So I have to wait until hs is promoted ... So just based on the current file, the change proposed - to remove one / - is not correct until the arch directory is removed. David ----- >> The jvmpath -> jvm_newpath change wasn't really necessary - a comment on >> the strdup would have sufficed IMO. > Dmitry asked me to add it. But I think it's ok. > > Can I consider this reviewed now? I.e. could I push it once 8066474 is > promoted and Joe Darcy agreed? > > Best regards, > Goetz. > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 8. Dezember 2016 09:14 >> To: Lindenmaier, Goetz ; 'Dmitry Samersoff' >> ; Java Core Libs > dev at openjdk.java.net>; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >> coding. >> >> Hi Goetz, >> >> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: >>> Hi Dmitry, >>> >>> yes, new_jvmpath is consistent with the other variables. >>> I also merged the ifs in SDE.c. >>> >>> new webrev: >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ >> >> src/java.base/share/native/libjli/java.c >> >> As far as I can see the existing code is working perfectly fine. Given a >> jvm.cfg with: >> >> -server KNOWN >> -client IGNORE >> -myvm KNOWN >> -oldvm ALIASED_TO -server >> >> The usage text is: >> >> -server to select the "server" VM >> -myvm to select the "myvm" VM >> -oldvm is a synonym for the "server" VM [deprecated] >> The default VM is server, >> because you are running on a server-class machine. >> >> which is exactly what I would expect. Why do you think there is a bug? >> >> --- >> >> src/java.base/unix/native/libjli/java_md_solinux.c >> >> Again I'm not sure what the bug is here. On AIX the output string is >> expanded with: >> >> "%s/lib/%s/jli:" >> >> so it needs to account for the extra "/lib//jli:" characters - and that >> is exactly what the existing code does: >> >> + JLI_StrLen("/lib//jli:") >> >> The jvmpath -> jvm_newpath change wasn't really necessary - a comment on >> the strdup would have sufficed IMO. >> >> Thanks, >> David >> ----- >> >> >> >> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>> Sent: Wednesday, December 07, 2016 2:43 PM >>>> To: Lindenmaier, Goetz ; Java Core Libs >>>> ; serviceability-dev (serviceability- >>>> dev at openjdk.java.net) >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >>>> coding. >>>> >>>> Goetz, >>>> >>>> SDE.c: >>>> >>>> You might combine if at ll. 260 and 263 to one but it's just matter of test. >>>> >>>> if (sti == baseStratumIndex || sti < 0) { >>>> return; /* Java stratum - return unchanged */ >>>> } >>>> >>>>> I'm not sure what you mean. I tried to fix it, but please >>>>> double-check the new webrev. >>>> >>>> if cnt is <= 0 loop at l.267 >>>> >>>> for (; cnt-- > 0; ++fromEntry) { >>>> >>>> is never run and we effectively do >>>> >>>> *entryCountPtr = 0; >>>> >>>> at l.283 >>>> >>>> So if we you suspect that cnt may become negative or 0: >>>> (your v.01 changes) >>>> >>>> 260 if (sti < 0 && cnt > 0) { >>>> 261 return; >>>> 262 } >>>> >>>> it's better to check it early. >>>> >>>> But I'm not sure we have to care about negative/zero cnt here. >>>> >>>> -Dmitry >>>> >>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>>>> Hi Dmitry, >>>>> >>>>> thanks for looking at my change! >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 >>>>> >>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>>>> Is this line correct? >>>>>> 519 jvmpath = JLI_StringDup(jvmpath); >>>>> >>>>> It seems pointless. Should I remove it? (The whole file is a horror.) >>>>> >>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>>>> It might be better to return immediately if cnt < 0, >>>>>> regardless of value of sti. >>>>> >>>>> I'm not sure what you mean. I tried to fix it, but please >>>>> double-check the new webrev. >>>>> >>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>>>> It might be better to write >>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>>>> and leave one copy of setsockopt() call >>>>> >>>>> Yes, looks better. >>>>> >>>>> Best regards, >>>>> Goetz >>>>> >>>>> >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> >>>>>>> This change fixes some minor issues found in our code scans. >>>>>>> >>>>>>> I hope this correctly addresses corelib and serviceability issues. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please review: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>> corlib_s11y/webrev.01/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Changes in detail: >>>>>>> >>>>>>> >>>>>>> >>>>>>> e_asin.c >>>>>>> >>>>>>> Code scan reports missing {}. >>>>>>> >>>>>>> >>>>>>> The code "if (huge+x>one) {" is only there to set the inexact flag of >>>>>>> the processor. >>>>>>> It's a way to avoid the C compiler to optimize the code away. It is >>>>>>> always true, >>>>>>> so the parenthesis of the outer else don't matter. >>>>>>> >>>>>>> Although this basically just adds the {} I would like to submit this to >>>>>>> >>>>>>> avoid anybody else spends more the 30sec on understanding these >>>>>>> >>>>>>> if statements. >>>>>>> >>>>>>> >>>>>>> k_standard.c >>>>>>> >>>>>>> exc.retval is returned below and thus should always be initialized. >>>>>>> >>>>>>> >>>>>>> imageDecompressor.cpp >>>>>>> >>>>>>> Wrong destructor is used. Reported also by David CARLIER >>>>>>> >>>>>>> >>>>>>> java.c >>>>>>> >>>>>>> in line 1865 'name' was used, it should be 'alias'. >>>>>>> >>>>>>> >>>>>>> java_md_solinux.c >>>>>>> >>>>>>> "//" in path is useless. Further down a free is missing. >>>>>>> >>>>>>> >>>>>>> SDE.c >>>>>>> >>>>>>> Call to stratumTableIndex can return negative value if defaultStratumId >>>>>>> == null. >>>>>>> >>>>>>> >>>>>>> socket_md.c >>>>>>> >>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in >>>>>>> the macros. >>>>>>> >>>>>>> >>>>>>> unpack.cpp >>>>>>> >>>>>>> n.slice should not get negative argument for end, which is passed from >>>>>>> dollar1. >>>>>>> But dollar1 can get negative where it is set to the result of >>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Dmitry Samersoff >>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>> * I would love to change the world, but they won't give me the sources. >>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. From daniel.daugherty at oracle.com Thu Dec 8 21:31:11 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 8 Dec 2016 14:31:11 -0700 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> Message-ID: On 12/8/16 1:59 PM, David Holmes wrote: > On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: >> Hi David, >> >> thanks for looking at the change. New webrev: >> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ >> >>> src/java.base/share/native/libjli/java.c >>> As far as I can see the existing code is working perfectly fine. >> Ah, thanks for the explanation, now I got it! Removed. >> >>> Again I'm not sure what the bug is here. On AIX the output string is >>> expanded with: >>> "%s/lib/%s/jli:" >> I first edited this against jdk9/hs, where the arch is gone since >> 8066474, >> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc >> but the // was not adapted. Then I moved the change to jdk9/dev because >> I thought I have to push it there. And yes, in that coding // would >> be correct. >> So I have to wait until hs is promoted ... > > So just based on the current file, the change proposed - to remove one > / - is not correct until the arch directory is removed. That change is already in JDK9-hs: Changeset: c14f9a7b4cab Author: erikj Date: 2016-12-05 17:55 +0100 URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab 8066474: Remove the lib/ directory from Linux and Solaris images Reviewed-by: tbell, ihse along with changesets in the jdk and hotspot repos along with a few closed repos. Dan > > David > ----- > >>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>> comment on >>> the strdup would have sufficed IMO. >> Dmitry asked me to add it. But I think it's ok. >> >> Can I consider this reviewed now? I.e. could I push it once 8066474 is >> promoted and Joe Darcy agreed? >> >> Best regards, >> Goetz. >> >> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Donnerstag, 8. Dezember 2016 09:14 >>> To: Lindenmaier, Goetz ; 'Dmitry Samersoff' >>> ; Java Core Libs >> dev at openjdk.java.net>; serviceability-dev (serviceability- >>> dev at openjdk.java.net) >>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>> servicabilty >>> coding. >>> >>> Hi Goetz, >>> >>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: >>>> Hi Dmitry, >>>> >>>> yes, new_jvmpath is consistent with the other variables. >>>> I also merged the ifs in SDE.c. >>>> >>>> new webrev: >>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ >>> >>> src/java.base/share/native/libjli/java.c >>> >>> As far as I can see the existing code is working perfectly fine. >>> Given a >>> jvm.cfg with: >>> >>> -server KNOWN >>> -client IGNORE >>> -myvm KNOWN >>> -oldvm ALIASED_TO -server >>> >>> The usage text is: >>> >>> -server to select the "server" VM >>> -myvm to select the "myvm" VM >>> -oldvm is a synonym for the "server" VM [deprecated] >>> The default VM is server, >>> because you are running on a server-class machine. >>> >>> which is exactly what I would expect. Why do you think there is a bug? >>> >>> --- >>> >>> src/java.base/unix/native/libjli/java_md_solinux.c >>> >>> Again I'm not sure what the bug is here. On AIX the output string is >>> expanded with: >>> >>> "%s/lib/%s/jli:" >>> >>> so it needs to account for the extra "/lib//jli:" characters - and that >>> is exactly what the existing code does: >>> >>> + JLI_StrLen("/lib//jli:") >>> >>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>> comment on >>> the strdup would have sufficed IMO. >>> >>> Thanks, >>> David >>> ----- >>> >>> >>> >>> >>>> Best regards, >>>> Goetz. >>>> >>>>> -----Original Message----- >>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>> Sent: Wednesday, December 07, 2016 2:43 PM >>>>> To: Lindenmaier, Goetz ; Java Core Libs >>>>> ; serviceability-dev (serviceability- >>>>> dev at openjdk.java.net) >>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>> servicabilty >>>>> coding. >>>>> >>>>> Goetz, >>>>> >>>>> SDE.c: >>>>> >>>>> You might combine if at ll. 260 and 263 to one but it's just >>>>> matter of test. >>>>> >>>>> if (sti == baseStratumIndex || sti < 0) { >>>>> return; /* Java stratum - return unchanged */ >>>>> } >>>>> >>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>> double-check the new webrev. >>>>> >>>>> if cnt is <= 0 loop at l.267 >>>>> >>>>> for (; cnt-- > 0; ++fromEntry) { >>>>> >>>>> is never run and we effectively do >>>>> >>>>> *entryCountPtr = 0; >>>>> >>>>> at l.283 >>>>> >>>>> So if we you suspect that cnt may become negative or 0: >>>>> (your v.01 changes) >>>>> >>>>> 260 if (sti < 0 && cnt > 0) { >>>>> 261 return; >>>>> 262 } >>>>> >>>>> it's better to check it early. >>>>> >>>>> But I'm not sure we have to care about negative/zero cnt here. >>>>> >>>>> -Dmitry >>>>> >>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>>>>> Hi Dmitry, >>>>>> >>>>>> thanks for looking at my change! >>>>>> Updated webrev: >>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 >>>>>> >>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>> Is this line correct? >>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); >>>>>> >>>>>> It seems pointless. Should I remove it? (The whole file is a >>>>>> horror.) >>>>>> >>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>>>>> It might be better to return immediately if cnt < 0, >>>>>>> regardless of value of sti. >>>>>> >>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>> double-check the new webrev. >>>>>> >>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>>>>> It might be better to write >>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>>>>> and leave one copy of setsockopt() call >>>>>> >>>>>> Yes, looks better. >>>>>> >>>>>> Best regards, >>>>>> Goetz >>>>>> >>>>>> >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This change fixes some minor issues found in our code scans. >>>>>>>> >>>>>>>> I hope this correctly addresses corelib and serviceability issues. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please review: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>> corlib_s11y/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Changes in detail: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> e_asin.c >>>>>>>> >>>>>>>> Code scan reports missing {}. >>>>>>>> >>>>>>>> >>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact >>>>>>>> flag of >>>>>>>> the processor. >>>>>>>> It's a way to avoid the C compiler to optimize the code away. >>>>>>>> It is >>>>>>>> always true, >>>>>>>> so the parenthesis of the outer else don't matter. >>>>>>>> >>>>>>>> Although this basically just adds the {} I would like to submit >>>>>>>> this to >>>>>>>> >>>>>>>> avoid anybody else spends more the 30sec on understanding these >>>>>>>> >>>>>>>> if statements. >>>>>>>> >>>>>>>> >>>>>>>> k_standard.c >>>>>>>> >>>>>>>> exc.retval is returned below and thus should always be >>>>>>>> initialized. >>>>>>>> >>>>>>>> >>>>>>>> imageDecompressor.cpp >>>>>>>> >>>>>>>> Wrong destructor is used. Reported also by David CARLIER >>>>>>>> >>>>>>>> >>>>>>>> java.c >>>>>>>> >>>>>>>> in line 1865 'name' was used, it should be 'alias'. >>>>>>>> >>>>>>>> >>>>>>>> java_md_solinux.c >>>>>>>> >>>>>>>> "//" in path is useless. Further down a free is missing. >>>>>>>> >>>>>>>> >>>>>>>> SDE.c >>>>>>>> >>>>>>>> Call to stratumTableIndex can return negative value if >>>>>>>> defaultStratumId >>>>>>>> == null. >>>>>>>> >>>>>>>> >>>>>>>> socket_md.c >>>>>>>> >>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is >>>>>>>> hidden in >>>>>>>> the macros. >>>>>>>> >>>>>>>> >>>>>>>> unpack.cpp >>>>>>>> >>>>>>>> n.slice should not get negative argument for end, which is >>>>>>>> passed from >>>>>>>> dollar1. >>>>>>>> But dollar1 can get negative where it is set to the result of >>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Dmitry Samersoff >>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>> * I would love to change the world, but they won't give me the >>>>>>> sources. >>>>> >>>>> >>>>> -- >>>>> 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 Thu Dec 8 22:03:00 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 9 Dec 2016 08:03:00 +1000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> Message-ID: On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: > On 12/8/16 1:59 PM, David Holmes wrote: >> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> thanks for looking at the change. New webrev: >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ >>> >>>> src/java.base/share/native/libjli/java.c >>>> As far as I can see the existing code is working perfectly fine. >>> Ah, thanks for the explanation, now I got it! Removed. >>> >>>> Again I'm not sure what the bug is here. On AIX the output string is >>>> expanded with: >>>> "%s/lib/%s/jli:" >>> I first edited this against jdk9/hs, where the arch is gone since >>> 8066474, >>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc >>> but the // was not adapted. Then I moved the change to jdk9/dev because >>> I thought I have to push it there. And yes, in that coding // would >>> be correct. >>> So I have to wait until hs is promoted ... >> >> So just based on the current file, the change proposed - to remove one >> / - is not correct until the arch directory is removed. > > That change is already in JDK9-hs: > > Changeset: c14f9a7b4cab > Author: erikj > Date: 2016-12-05 17:55 +0100 > URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab > > 8066474: Remove the lib/ directory from Linux and Solaris images > Reviewed-by: tbell, ihse > > along with changesets in the jdk and hotspot repos along with a few > closed repos. Thanks Dan. So we need to see a webrev based on latest hs code - where removing the extra / would be correct. David ----- > Dan > > > >> >> David >> ----- >> >>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>> comment on >>>> the strdup would have sufficed IMO. >>> Dmitry asked me to add it. But I think it's ok. >>> >>> Can I consider this reviewed now? I.e. could I push it once 8066474 is >>> promoted and Joe Darcy agreed? >>> >>> Best regards, >>> Goetz. >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Donnerstag, 8. Dezember 2016 09:14 >>>> To: Lindenmaier, Goetz ; 'Dmitry Samersoff' >>>> ; Java Core Libs >>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>> dev at openjdk.java.net) >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>> servicabilty >>>> coding. >>>> >>>> Hi Goetz, >>>> >>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: >>>>> Hi Dmitry, >>>>> >>>>> yes, new_jvmpath is consistent with the other variables. >>>>> I also merged the ifs in SDE.c. >>>>> >>>>> new webrev: >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ >>>> >>>> src/java.base/share/native/libjli/java.c >>>> >>>> As far as I can see the existing code is working perfectly fine. >>>> Given a >>>> jvm.cfg with: >>>> >>>> -server KNOWN >>>> -client IGNORE >>>> -myvm KNOWN >>>> -oldvm ALIASED_TO -server >>>> >>>> The usage text is: >>>> >>>> -server to select the "server" VM >>>> -myvm to select the "myvm" VM >>>> -oldvm is a synonym for the "server" VM [deprecated] >>>> The default VM is server, >>>> because you are running on a server-class machine. >>>> >>>> which is exactly what I would expect. Why do you think there is a bug? >>>> >>>> --- >>>> >>>> src/java.base/unix/native/libjli/java_md_solinux.c >>>> >>>> Again I'm not sure what the bug is here. On AIX the output string is >>>> expanded with: >>>> >>>> "%s/lib/%s/jli:" >>>> >>>> so it needs to account for the extra "/lib//jli:" characters - and that >>>> is exactly what the existing code does: >>>> >>>> + JLI_StrLen("/lib//jli:") >>>> >>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>> comment on >>>> the strdup would have sufficed IMO. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> >>>> >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>>> -----Original Message----- >>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>> Sent: Wednesday, December 07, 2016 2:43 PM >>>>>> To: Lindenmaier, Goetz ; Java Core Libs >>>>>> ; serviceability-dev (serviceability- >>>>>> dev at openjdk.java.net) >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>> servicabilty >>>>>> coding. >>>>>> >>>>>> Goetz, >>>>>> >>>>>> SDE.c: >>>>>> >>>>>> You might combine if at ll. 260 and 263 to one but it's just >>>>>> matter of test. >>>>>> >>>>>> if (sti == baseStratumIndex || sti < 0) { >>>>>> return; /* Java stratum - return unchanged */ >>>>>> } >>>>>> >>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>> double-check the new webrev. >>>>>> >>>>>> if cnt is <= 0 loop at l.267 >>>>>> >>>>>> for (; cnt-- > 0; ++fromEntry) { >>>>>> >>>>>> is never run and we effectively do >>>>>> >>>>>> *entryCountPtr = 0; >>>>>> >>>>>> at l.283 >>>>>> >>>>>> So if we you suspect that cnt may become negative or 0: >>>>>> (your v.01 changes) >>>>>> >>>>>> 260 if (sti < 0 && cnt > 0) { >>>>>> 261 return; >>>>>> 262 } >>>>>> >>>>>> it's better to check it early. >>>>>> >>>>>> But I'm not sure we have to care about negative/zero cnt here. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> thanks for looking at my change! >>>>>>> Updated webrev: >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 >>>>>>> >>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>> Is this line correct? >>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); >>>>>>> >>>>>>> It seems pointless. Should I remove it? (The whole file is a >>>>>>> horror.) >>>>>>> >>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>>>>>> It might be better to return immediately if cnt < 0, >>>>>>>> regardless of value of sti. >>>>>>> >>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>> double-check the new webrev. >>>>>>> >>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>>>>>> It might be better to write >>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>>>>>> and leave one copy of setsockopt() call >>>>>>> >>>>>>> Yes, looks better. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> This change fixes some minor issues found in our code scans. >>>>>>>>> >>>>>>>>> I hope this correctly addresses corelib and serviceability issues. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Please review: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>> corlib_s11y/webrev.01/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Changes in detail: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> e_asin.c >>>>>>>>> >>>>>>>>> Code scan reports missing {}. >>>>>>>>> >>>>>>>>> >>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact >>>>>>>>> flag of >>>>>>>>> the processor. >>>>>>>>> It's a way to avoid the C compiler to optimize the code away. >>>>>>>>> It is >>>>>>>>> always true, >>>>>>>>> so the parenthesis of the outer else don't matter. >>>>>>>>> >>>>>>>>> Although this basically just adds the {} I would like to submit >>>>>>>>> this to >>>>>>>>> >>>>>>>>> avoid anybody else spends more the 30sec on understanding these >>>>>>>>> >>>>>>>>> if statements. >>>>>>>>> >>>>>>>>> >>>>>>>>> k_standard.c >>>>>>>>> >>>>>>>>> exc.retval is returned below and thus should always be >>>>>>>>> initialized. >>>>>>>>> >>>>>>>>> >>>>>>>>> imageDecompressor.cpp >>>>>>>>> >>>>>>>>> Wrong destructor is used. Reported also by David CARLIER >>>>>>>>> >>>>>>>>> >>>>>>>>> java.c >>>>>>>>> >>>>>>>>> in line 1865 'name' was used, it should be 'alias'. >>>>>>>>> >>>>>>>>> >>>>>>>>> java_md_solinux.c >>>>>>>>> >>>>>>>>> "//" in path is useless. Further down a free is missing. >>>>>>>>> >>>>>>>>> >>>>>>>>> SDE.c >>>>>>>>> >>>>>>>>> Call to stratumTableIndex can return negative value if >>>>>>>>> defaultStratumId >>>>>>>>> == null. >>>>>>>>> >>>>>>>>> >>>>>>>>> socket_md.c >>>>>>>>> >>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is >>>>>>>>> hidden in >>>>>>>>> the macros. >>>>>>>>> >>>>>>>>> >>>>>>>>> unpack.cpp >>>>>>>>> >>>>>>>>> n.slice should not get negative argument for end, which is >>>>>>>>> passed from >>>>>>>>> dollar1. >>>>>>>>> But dollar1 can get negative where it is set to the result of >>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Dmitry Samersoff >>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>> * I would love to change the world, but they won't give me the >>>>>>>> sources. >>>>>> >>>>>> >>>>>> -- >>>>>> 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 goetz.lindenmaier at sap.com Fri Dec 9 07:25:19 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 9 Dec 2016 07:25:19 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> Message-ID: <902a79e77ff240ed9c0d77dd00dd3482@DEROTE13DE08.global.corp.sap> Hi, I'll post a new webrev once the hs code has been propagated to dev. Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 8. Dezember 2016 23:03 > To: daniel.daugherty at oracle.com; Lindenmaier, Goetz > ; 'Dmitry Samersoff' > ; Java Core Libs dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: > > On 12/8/16 1:59 PM, David Holmes wrote: > >> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: > >>> Hi David, > >>> > >>> thanks for looking at the change. New webrev: > >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ > >>> > >>>> src/java.base/share/native/libjli/java.c > >>>> As far as I can see the existing code is working perfectly fine. > >>> Ah, thanks for the explanation, now I got it! Removed. > >>> > >>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>> expanded with: > >>>> "%s/lib/%s/jli:" > >>> I first edited this against jdk9/hs, where the arch is gone since > >>> 8066474, > >>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc > >>> but the // was not adapted. Then I moved the change to jdk9/dev because > >>> I thought I have to push it there. And yes, in that coding // would > >>> be correct. > >>> So I have to wait until hs is promoted ... > >> > >> So just based on the current file, the change proposed - to remove one > >> / - is not correct until the arch directory is removed. > > > > That change is already in JDK9-hs: > > > > Changeset: c14f9a7b4cab > > Author: erikj > > Date: 2016-12-05 17:55 +0100 > > URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab > > > > 8066474: Remove the lib/ directory from Linux and Solaris images > > Reviewed-by: tbell, ihse > > > > along with changesets in the jdk and hotspot repos along with a few > > closed repos. > > Thanks Dan. So we need to see a webrev based on latest hs code - where > removing the extra / would be correct. > > David > ----- > > > Dan > > > > > > > >> > >> David > >> ----- > >> > >>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>> comment on > >>>> the strdup would have sufficed IMO. > >>> Dmitry asked me to add it. But I think it's ok. > >>> > >>> Can I consider this reviewed now? I.e. could I push it once 8066474 is > >>> promoted and Joe Darcy agreed? > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Donnerstag, 8. Dezember 2016 09:14 > >>>> To: Lindenmaier, Goetz ; 'Dmitry > Samersoff' > >>>> ; Java Core Libs >>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>> dev at openjdk.java.net) > >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>> servicabilty > >>>> coding. > >>>> > >>>> Hi Goetz, > >>>> > >>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: > >>>>> Hi Dmitry, > >>>>> > >>>>> yes, new_jvmpath is consistent with the other variables. > >>>>> I also merged the ifs in SDE.c. > >>>>> > >>>>> new webrev: > >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ > >>>> > >>>> src/java.base/share/native/libjli/java.c > >>>> > >>>> As far as I can see the existing code is working perfectly fine. > >>>> Given a > >>>> jvm.cfg with: > >>>> > >>>> -server KNOWN > >>>> -client IGNORE > >>>> -myvm KNOWN > >>>> -oldvm ALIASED_TO -server > >>>> > >>>> The usage text is: > >>>> > >>>> -server to select the "server" VM > >>>> -myvm to select the "myvm" VM > >>>> -oldvm is a synonym for the "server" VM [deprecated] > >>>> The default VM is server, > >>>> because you are running on a server-class machine. > >>>> > >>>> which is exactly what I would expect. Why do you think there is a bug? > >>>> > >>>> --- > >>>> > >>>> src/java.base/unix/native/libjli/java_md_solinux.c > >>>> > >>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>> expanded with: > >>>> > >>>> "%s/lib/%s/jli:" > >>>> > >>>> so it needs to account for the extra "/lib//jli:" characters - and that > >>>> is exactly what the existing code does: > >>>> > >>>> + JLI_StrLen("/lib//jli:") > >>>> > >>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>> comment on > >>>> the strdup would have sufficed IMO. > >>>> > >>>> Thanks, > >>>> David > >>>> ----- > >>>> > >>>> > >>>> > >>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > >>>>>> Sent: Wednesday, December 07, 2016 2:43 PM > >>>>>> To: Lindenmaier, Goetz ; Java Core Libs > >>>>>> ; serviceability-dev (serviceability- > >>>>>> dev at openjdk.java.net) > >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>>>> servicabilty > >>>>>> coding. > >>>>>> > >>>>>> Goetz, > >>>>>> > >>>>>> SDE.c: > >>>>>> > >>>>>> You might combine if at ll. 260 and 263 to one but it's just > >>>>>> matter of test. > >>>>>> > >>>>>> if (sti == baseStratumIndex || sti < 0) { > >>>>>> return; /* Java stratum - return unchanged */ > >>>>>> } > >>>>>> > >>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>> double-check the new webrev. > >>>>>> > >>>>>> if cnt is <= 0 loop at l.267 > >>>>>> > >>>>>> for (; cnt-- > 0; ++fromEntry) { > >>>>>> > >>>>>> is never run and we effectively do > >>>>>> > >>>>>> *entryCountPtr = 0; > >>>>>> > >>>>>> at l.283 > >>>>>> > >>>>>> So if we you suspect that cnt may become negative or 0: > >>>>>> (your v.01 changes) > >>>>>> > >>>>>> 260 if (sti < 0 && cnt > 0) { > >>>>>> 261 return; > >>>>>> 262 } > >>>>>> > >>>>>> it's better to check it early. > >>>>>> > >>>>>> But I'm not sure we have to care about negative/zero cnt here. > >>>>>> > >>>>>> -Dmitry > >>>>>> > >>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > >>>>>>> Hi Dmitry, > >>>>>>> > >>>>>>> thanks for looking at my change! > >>>>>>> Updated webrev: > >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > corlib_s11y/webrev.02 > >>>>>>> > >>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>>>> Is this line correct? > >>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); > >>>>>>> > >>>>>>> It seems pointless. Should I remove it? (The whole file is a > >>>>>>> horror.) > >>>>>>> > >>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > >>>>>>>> It might be better to return immediately if cnt < 0, > >>>>>>>> regardless of value of sti. > >>>>>>> > >>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>> double-check the new webrev. > >>>>>>> > >>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > >>>>>>>> It might be better to write > >>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; > >>>>>>>> and leave one copy of setsockopt() call > >>>>>>> > >>>>>>> Yes, looks better. > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> -Dmitry > >>>>>>>> > >>>>>>>> > >>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> This change fixes some minor issues found in our code scans. > >>>>>>>>> > >>>>>>>>> I hope this correctly addresses corelib and serviceability issues. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Please review: > >>>>>>>>> > >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>>>> corlib_s11y/webrev.01/ > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> > >>>>>>>>> Goetz. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Changes in detail: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> e_asin.c > >>>>>>>>> > >>>>>>>>> Code scan reports missing {}. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact > >>>>>>>>> flag of > >>>>>>>>> the processor. > >>>>>>>>> It's a way to avoid the C compiler to optimize the code away. > >>>>>>>>> It is > >>>>>>>>> always true, > >>>>>>>>> so the parenthesis of the outer else don't matter. > >>>>>>>>> > >>>>>>>>> Although this basically just adds the {} I would like to submit > >>>>>>>>> this to > >>>>>>>>> > >>>>>>>>> avoid anybody else spends more the 30sec on understanding these > >>>>>>>>> > >>>>>>>>> if statements. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> k_standard.c > >>>>>>>>> > >>>>>>>>> exc.retval is returned below and thus should always be > >>>>>>>>> initialized. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> imageDecompressor.cpp > >>>>>>>>> > >>>>>>>>> Wrong destructor is used. Reported also by David CARLIER > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> java.c > >>>>>>>>> > >>>>>>>>> in line 1865 'name' was used, it should be 'alias'. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> java_md_solinux.c > >>>>>>>>> > >>>>>>>>> "//" in path is useless. Further down a free is missing. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> SDE.c > >>>>>>>>> > >>>>>>>>> Call to stratumTableIndex can return negative value if > >>>>>>>>> defaultStratumId > >>>>>>>>> == null. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> socket_md.c > >>>>>>>>> > >>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is > >>>>>>>>> hidden in > >>>>>>>>> the macros. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> unpack.cpp > >>>>>>>>> > >>>>>>>>> n.slice should not get negative argument for end, which is > >>>>>>>>> passed from > >>>>>>>>> dollar1. > >>>>>>>>> But dollar1 can get negative where it is set to the result of > >>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Dmitry Samersoff > >>>>>>>> Oracle Java development team, Saint Petersburg, Russia > >>>>>>>> * I would love to change the world, but they won't give me the > >>>>>>>> sources. > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> 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 Mon Dec 12 10:31:42 2016 From: jini.george at oracle.com (Jini Susan George) Date: Mon, 12 Dec 2016 02:31:42 -0800 (PST) Subject: RFR: JDK-8159127: hprof heap dumps broken for lambda classdata Message-ID: Could I please get a review done for the following SA defect? Bug: https://bugs.openjdk.java.net/browse/JDK-8159127 Webrev: http://cr.openjdk.java.net/~jgeorge/8159127/webrev.00/ Thanks, - Jini Susan George -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Mon Dec 12 11:36:23 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 12 Dec 2016 14:36:23 +0300 Subject: RFR: JDK-8159127: hprof heap dumps broken for lambda classdata In-Reply-To: References: Message-ID: <6c7dc3cd-1da1-37c2-a0ab-1cf0e1e418c8@oracle.com> Jini, Looks good to me! ClassLoaderData.java 85: Should we check klassField for null here? -Dmitry On 2016-12-12 13:31, Jini Susan George wrote: > Could I please get a review done for the following SA defect? > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159127 > > Webrev: http://cr.openjdk.java.net/~jgeorge/8159127/webrev.00/ > > > > Thanks, > > - Jini Susan George > > > -- 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 Tue Dec 13 04:39:24 2016 From: jini.george at oracle.com (Jini Susan George) Date: Mon, 12 Dec 2016 20:39:24 -0800 (PST) Subject: RFR: JDK-8159127: hprof heap dumps broken for lambda classdata In-Reply-To: <6c7dc3cd-1da1-37c2-a0ab-1cf0e1e418c8@oracle.com> References: <6c7dc3cd-1da1-37c2-a0ab-1cf0e1e418c8@oracle.com> Message-ID: <706cdf38-7fa4-46ed-9a38-5a657178a8b5@default> Thank you, Dmitry. I will add the null check. -jini > -----Original Message----- > From: Dmitry Samersoff > Sent: Monday, December 12, 2016 5:06 PM > To: Jini Susan George; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8159127: hprof heap dumps broken for lambda > classdata > > Jini, > > Looks good to me! > > ClassLoaderData.java > > 85: Should we check klassField for null here? > > -Dmitry > > On 2016-12-12 13:31, Jini Susan George wrote: > > Could I please get a review done for the following SA defect? > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159127 > > > > Webrev: http://cr.openjdk.java.net/~jgeorge/8159127/webrev.00/ > > > > > > > > Thanks, > > > > - Jini Susan George > > > > > > > > > -- > 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 Tue Dec 13 08:55:55 2016 From: jini.george at oracle.com (Jini Susan George) Date: Tue, 13 Dec 2016 00:55:55 -0800 (PST) Subject: RFR: JDK-8159127: hprof heap dumps broken for lambda classdata In-Reply-To: <706cdf38-7fa4-46ed-9a38-5a657178a8b5@default> References: <6c7dc3cd-1da1-37c2-a0ab-1cf0e1e418c8@oracle.com> <706cdf38-7fa4-46ed-9a38-5a657178a8b5@default> Message-ID: Modified webrev: http://cr.openjdk.java.net/~jgeorge/8159127/webrev.01/ Thanks, Jini. > -----Original Message----- > From: Jini Susan George > Sent: Tuesday, December 13, 2016 10:09 AM > To: Dmitry Samersoff; serviceability-dev at openjdk.java.net > Subject: RE: RFR: JDK-8159127: hprof heap dumps broken for lambda > classdata > > Thank you, Dmitry. I will add the null check. > -jini > > > -----Original Message----- > > From: Dmitry Samersoff > > Sent: Monday, December 12, 2016 5:06 PM > > To: Jini Susan George; serviceability-dev at openjdk.java.net > > Subject: Re: RFR: JDK-8159127: hprof heap dumps broken for lambda > > classdata > > > > Jini, > > > > Looks good to me! > > > > ClassLoaderData.java > > > > 85: Should we check klassField for null here? > > > > -Dmitry > > > > On 2016-12-12 13:31, Jini Susan George wrote: > > > Could I please get a review done for the following SA defect? > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159127 > > > > > > Webrev: http://cr.openjdk.java.net/~jgeorge/8159127/webrev.00/ > > > > > > > > > > > > Thanks, > > > > > > - Jini Susan George > > > > > > > > > > > > > > > -- > > 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 dmitry.samersoff at oracle.com Tue Dec 13 09:17:58 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 13 Dec 2016 12:17:58 +0300 Subject: RFR: JDK-8159127: hprof heap dumps broken for lambda classdata In-Reply-To: References: <6c7dc3cd-1da1-37c2-a0ab-1cf0e1e418c8@oracle.com> <706cdf38-7fa4-46ed-9a38-5a657178a8b5@default> Message-ID: <607c6591-2216-7596-9502-554a171da337@oracle.com> Jini, Looks good to me. -Dmitry On 2016-12-13 11:55, Jini Susan George wrote: > Modified webrev: > > http://cr.openjdk.java.net/~jgeorge/8159127/webrev.01/ > > Thanks, > Jini. > >> -----Original Message----- >> From: Jini Susan George >> Sent: Tuesday, December 13, 2016 10:09 AM >> To: Dmitry Samersoff; serviceability-dev at openjdk.java.net >> Subject: RE: RFR: JDK-8159127: hprof heap dumps broken for lambda >> classdata >> >> Thank you, Dmitry. I will add the null check. >> -jini >> >>> -----Original Message----- >>> From: Dmitry Samersoff >>> Sent: Monday, December 12, 2016 5:06 PM >>> To: Jini Susan George; serviceability-dev at openjdk.java.net >>> Subject: Re: RFR: JDK-8159127: hprof heap dumps broken for lambda >>> classdata >>> >>> Jini, >>> >>> Looks good to me! >>> >>> ClassLoaderData.java >>> >>> 85: Should we check klassField for null here? >>> >>> -Dmitry >>> >>> On 2016-12-12 13:31, Jini Susan George wrote: >>>> Could I please get a review done for the following SA defect? >>>> >>>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159127 >>>> >>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8159127/webrev.00/ >>>> >>>> >>>> >>>> Thanks, >>>> >>>> - Jini Susan George >>>> >>>> >>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. -- 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 Tue Dec 13 16:34:37 2016 From: jini.george at oracle.com (Jini Susan George) Date: Tue, 13 Dec 2016 08:34:37 -0800 (PST) Subject: RFR: JDK-8159127: hprof heap dumps broken for lambda classdata In-Reply-To: <607c6591-2216-7596-9502-554a171da337@oracle.com> References: <6c7dc3cd-1da1-37c2-a0ab-1cf0e1e418c8@oracle.com> <706cdf38-7fa4-46ed-9a38-5a657178a8b5@default> <607c6591-2216-7596-9502-554a171da337@oracle.com> Message-ID: <70429c0f-5ed9-4ee1-9f08-92e0ccc60899@default> Thank you, Dmitry. Could I get one more reviewer to take a look at this ? -Jini. > -----Original Message----- > From: Dmitry Samersoff > Sent: Tuesday, December 13, 2016 2:48 PM > To: Jini Susan George; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8159127: hprof heap dumps broken for lambda > classdata > > Jini, > > Looks good to me. > > -Dmitry > > On 2016-12-13 11:55, Jini Susan George wrote: > > Modified webrev: > > > > http://cr.openjdk.java.net/~jgeorge/8159127/webrev.01/ > > > > Thanks, > > Jini. > > > >> -----Original Message----- > >> From: Jini Susan George > >> Sent: Tuesday, December 13, 2016 10:09 AM > >> To: Dmitry Samersoff; serviceability-dev at openjdk.java.net > >> Subject: RE: RFR: JDK-8159127: hprof heap dumps broken for lambda > >> classdata > >> > >> Thank you, Dmitry. I will add the null check. > >> -jini > >> > >>> -----Original Message----- > >>> From: Dmitry Samersoff > >>> Sent: Monday, December 12, 2016 5:06 PM > >>> To: Jini Susan George; serviceability-dev at openjdk.java.net > >>> Subject: Re: RFR: JDK-8159127: hprof heap dumps broken for lambda > >>> classdata > >>> > >>> Jini, > >>> > >>> Looks good to me! > >>> > >>> ClassLoaderData.java > >>> > >>> 85: Should we check klassField for null here? > >>> > >>> -Dmitry > >>> > >>> On 2016-12-12 13:31, Jini Susan George wrote: > >>>> Could I please get a review done for the following SA defect? > >>>> > >>>> > >>>> > >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159127 > >>>> > >>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8159127/webrev.00/ > >>>> > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> - Jini Susan George > >>>> > >>>> > >>>> > >>> > >>> > >>> -- > >>> Dmitry Samersoff > >>> Oracle Java development team, Saint Petersburg, Russia > >>> * I would love to change the world, but they won't give me the sources. > > > -- > 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 jcbeyler at google.com Tue Dec 13 21:11:52 2016 From: jcbeyler at google.com (JC Beyler) Date: Tue, 13 Dec 2016 13:11:52 -0800 Subject: Low-Overhead Heap Profiling Message-ID: Hello all, This is a follow-up from Jeremy's initial email from last year: http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-June/017543.html I've gone ahead and started working on preparing this and Jeremy and I went down the route of actually writing it up in JEP form: https://bugs.openjdk.java.net/browse/JDK-8171119 I think original conversation that happened last year in that thread still holds true: - We have a patch at Google that we think others might be interested in - It provides a means to understand where the allocation hotspots are at a very low overhead - Since it is at a low overhead, we can leave it on by default So I come to the mailing list with Jeremy's initial question: "I thought I would ask if there is any interest / if I should write a JEP / if I should just forget it." A year ago, it seemed some thought it was a good idea, is this still true? Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Dec 14 06:47:30 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 13 Dec 2016 22:47:30 -0800 Subject: RFR: JDK-8159127: hprof heap dumps broken for lambda classdata In-Reply-To: <70429c0f-5ed9-4ee1-9f08-92e0ccc60899@default> References: <6c7dc3cd-1da1-37c2-a0ab-1cf0e1e418c8@oracle.com> <706cdf38-7fa4-46ed-9a38-5a657178a8b5@default> <607c6591-2216-7596-9502-554a171da337@oracle.com> <70429c0f-5ed9-4ee1-9f08-92e0ccc60899@default> Message-ID: <894fd024-7c74-abc6-667c-e5caf22362b0@oracle.com> Hi Jini, It looks good in general. Some minor comments though. http://cr.openjdk.java.net/~jgeorge/8159127/webrev.01/hotspot/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/classfile/ClassLoaderData.java.udiff.html + public ClassLoaderData next() { + Address classLoaderDataAddr = nextField.getValue(getAddress()); + if (classLoaderDataAddr == null) { + return null; + } + + return instantiateWrapperFor(classLoaderDataAddr); + } + + public Klass getKlasses() { + Address klassesFieldAddr = klassesField.getValue(getAddress()); + if (klassesFieldAddr == null) { + return null; + } + return (InstanceKlass)Metadata.instantiateWrapperFor(klassesFieldAddr); + } It seems there is no need to check address for null as it is done inside the instantiateWrapperFor call. ClassLoaderData.java: private static VirtualBaseConstructor metadataConstructor; . . . public static Metadata instantiateWrapperFor(Address addr) { return metadataConstructor.instantiateWrapperFor(addr); } VirtualBaseConstructor.java: public T instantiateWrapperFor(Address addr)throws WrongTypeException { if (addr ==null) { return null; } . . . http://cr.openjdk.java.net/~jgeorge/8159127/webrev.01/hotspot/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java.frames.html At the lines 522-547 it is possible to define and use the same callback class for traversing both the SystemDictionary classes and the anonymous classes. The same is applied to the lines 961-990. But I leave it up to you to decide if it needs to be updated. Thanks, Serguei On 12/13/16 08:34, Jini Susan George wrote: > Thank you, Dmitry. Could I get one more reviewer to take a look at this ? > > -Jini. > >> -----Original Message----- >> From: Dmitry Samersoff >> Sent: Tuesday, December 13, 2016 2:48 PM >> To: Jini Susan George; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8159127: hprof heap dumps broken for lambda >> classdata >> >> Jini, >> >> Looks good to me. >> >> -Dmitry >> >> On 2016-12-13 11:55, Jini Susan George wrote: >>> Modified webrev: >>> >>> http://cr.openjdk.java.net/~jgeorge/8159127/webrev.01/ >>> >>> Thanks, >>> Jini. >>> >>>> -----Original Message----- >>>> From: Jini Susan George >>>> Sent: Tuesday, December 13, 2016 10:09 AM >>>> To: Dmitry Samersoff; serviceability-dev at openjdk.java.net >>>> Subject: RE: RFR: JDK-8159127: hprof heap dumps broken for lambda >>>> classdata >>>> >>>> Thank you, Dmitry. I will add the null check. >>>> -jini >>>> >>>>> -----Original Message----- >>>>> From: Dmitry Samersoff >>>>> Sent: Monday, December 12, 2016 5:06 PM >>>>> To: Jini Susan George; serviceability-dev at openjdk.java.net >>>>> Subject: Re: RFR: JDK-8159127: hprof heap dumps broken for lambda >>>>> classdata >>>>> >>>>> Jini, >>>>> >>>>> Looks good to me! >>>>> >>>>> ClassLoaderData.java >>>>> >>>>> 85: Should we check klassField for null here? >>>>> >>>>> -Dmitry >>>>> >>>>> On 2016-12-12 13:31, Jini Susan George wrote: >>>>>> Could I please get a review done for the following SA defect? >>>>>> >>>>>> >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159127 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8159127/webrev.00/ >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> - Jini Susan George >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Dmitry Samersoff >>>>> Oracle Java development team, Saint Petersburg, Russia >>>>> * I would love to change the world, but they won't give me the sources. >> >> -- >> 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 goetz.lindenmaier at sap.com Wed Dec 14 09:48:30 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 14 Dec 2016 09:48:30 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> Message-ID: <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> Hi, 8066474 has not been promoted. I'll remove the strlen // fix for aix from this change and push it without it. I'd like to get this done. Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 8. Dezember 2016 23:03 > To: daniel.daugherty at oracle.com; Lindenmaier, Goetz > ; 'Dmitry Samersoff' > ; Java Core Libs dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: > > On 12/8/16 1:59 PM, David Holmes wrote: > >> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: > >>> Hi David, > >>> > >>> thanks for looking at the change. New webrev: > >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ > >>> > >>>> src/java.base/share/native/libjli/java.c > >>>> As far as I can see the existing code is working perfectly fine. > >>> Ah, thanks for the explanation, now I got it! Removed. > >>> > >>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>> expanded with: > >>>> "%s/lib/%s/jli:" > >>> I first edited this against jdk9/hs, where the arch is gone since > >>> 8066474, > >>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc > >>> but the // was not adapted. Then I moved the change to jdk9/dev because > >>> I thought I have to push it there. And yes, in that coding // would > >>> be correct. > >>> So I have to wait until hs is promoted ... > >> > >> So just based on the current file, the change proposed - to remove one > >> / - is not correct until the arch directory is removed. > > > > That change is already in JDK9-hs: > > > > Changeset: c14f9a7b4cab > > Author: erikj > > Date: 2016-12-05 17:55 +0100 > > URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab > > > > 8066474: Remove the lib/ directory from Linux and Solaris images > > Reviewed-by: tbell, ihse > > > > along with changesets in the jdk and hotspot repos along with a few > > closed repos. > > Thanks Dan. So we need to see a webrev based on latest hs code - where > removing the extra / would be correct. > > David > ----- > > > Dan > > > > > > > >> > >> David > >> ----- > >> > >>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>> comment on > >>>> the strdup would have sufficed IMO. > >>> Dmitry asked me to add it. But I think it's ok. > >>> > >>> Can I consider this reviewed now? I.e. could I push it once 8066474 is > >>> promoted and Joe Darcy agreed? > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Donnerstag, 8. Dezember 2016 09:14 > >>>> To: Lindenmaier, Goetz ; 'Dmitry > Samersoff' > >>>> ; Java Core Libs >>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>> dev at openjdk.java.net) > >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>> servicabilty > >>>> coding. > >>>> > >>>> Hi Goetz, > >>>> > >>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: > >>>>> Hi Dmitry, > >>>>> > >>>>> yes, new_jvmpath is consistent with the other variables. > >>>>> I also merged the ifs in SDE.c. > >>>>> > >>>>> new webrev: > >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ > >>>> > >>>> src/java.base/share/native/libjli/java.c > >>>> > >>>> As far as I can see the existing code is working perfectly fine. > >>>> Given a > >>>> jvm.cfg with: > >>>> > >>>> -server KNOWN > >>>> -client IGNORE > >>>> -myvm KNOWN > >>>> -oldvm ALIASED_TO -server > >>>> > >>>> The usage text is: > >>>> > >>>> -server to select the "server" VM > >>>> -myvm to select the "myvm" VM > >>>> -oldvm is a synonym for the "server" VM [deprecated] > >>>> The default VM is server, > >>>> because you are running on a server-class machine. > >>>> > >>>> which is exactly what I would expect. Why do you think there is a bug? > >>>> > >>>> --- > >>>> > >>>> src/java.base/unix/native/libjli/java_md_solinux.c > >>>> > >>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>> expanded with: > >>>> > >>>> "%s/lib/%s/jli:" > >>>> > >>>> so it needs to account for the extra "/lib//jli:" characters - and that > >>>> is exactly what the existing code does: > >>>> > >>>> + JLI_StrLen("/lib//jli:") > >>>> > >>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>> comment on > >>>> the strdup would have sufficed IMO. > >>>> > >>>> Thanks, > >>>> David > >>>> ----- > >>>> > >>>> > >>>> > >>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > >>>>>> Sent: Wednesday, December 07, 2016 2:43 PM > >>>>>> To: Lindenmaier, Goetz ; Java Core Libs > >>>>>> ; serviceability-dev (serviceability- > >>>>>> dev at openjdk.java.net) > >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>>>> servicabilty > >>>>>> coding. > >>>>>> > >>>>>> Goetz, > >>>>>> > >>>>>> SDE.c: > >>>>>> > >>>>>> You might combine if at ll. 260 and 263 to one but it's just > >>>>>> matter of test. > >>>>>> > >>>>>> if (sti == baseStratumIndex || sti < 0) { > >>>>>> return; /* Java stratum - return unchanged */ > >>>>>> } > >>>>>> > >>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>> double-check the new webrev. > >>>>>> > >>>>>> if cnt is <= 0 loop at l.267 > >>>>>> > >>>>>> for (; cnt-- > 0; ++fromEntry) { > >>>>>> > >>>>>> is never run and we effectively do > >>>>>> > >>>>>> *entryCountPtr = 0; > >>>>>> > >>>>>> at l.283 > >>>>>> > >>>>>> So if we you suspect that cnt may become negative or 0: > >>>>>> (your v.01 changes) > >>>>>> > >>>>>> 260 if (sti < 0 && cnt > 0) { > >>>>>> 261 return; > >>>>>> 262 } > >>>>>> > >>>>>> it's better to check it early. > >>>>>> > >>>>>> But I'm not sure we have to care about negative/zero cnt here. > >>>>>> > >>>>>> -Dmitry > >>>>>> > >>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > >>>>>>> Hi Dmitry, > >>>>>>> > >>>>>>> thanks for looking at my change! > >>>>>>> Updated webrev: > >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > corlib_s11y/webrev.02 > >>>>>>> > >>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>>>> Is this line correct? > >>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); > >>>>>>> > >>>>>>> It seems pointless. Should I remove it? (The whole file is a > >>>>>>> horror.) > >>>>>>> > >>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > >>>>>>>> It might be better to return immediately if cnt < 0, > >>>>>>>> regardless of value of sti. > >>>>>>> > >>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>> double-check the new webrev. > >>>>>>> > >>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > >>>>>>>> It might be better to write > >>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; > >>>>>>>> and leave one copy of setsockopt() call > >>>>>>> > >>>>>>> Yes, looks better. > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> -Dmitry > >>>>>>>> > >>>>>>>> > >>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> This change fixes some minor issues found in our code scans. > >>>>>>>>> > >>>>>>>>> I hope this correctly addresses corelib and serviceability issues. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Please review: > >>>>>>>>> > >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>>>> corlib_s11y/webrev.01/ > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> > >>>>>>>>> Goetz. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Changes in detail: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> e_asin.c > >>>>>>>>> > >>>>>>>>> Code scan reports missing {}. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact > >>>>>>>>> flag of > >>>>>>>>> the processor. > >>>>>>>>> It's a way to avoid the C compiler to optimize the code away. > >>>>>>>>> It is > >>>>>>>>> always true, > >>>>>>>>> so the parenthesis of the outer else don't matter. > >>>>>>>>> > >>>>>>>>> Although this basically just adds the {} I would like to submit > >>>>>>>>> this to > >>>>>>>>> > >>>>>>>>> avoid anybody else spends more the 30sec on understanding these > >>>>>>>>> > >>>>>>>>> if statements. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> k_standard.c > >>>>>>>>> > >>>>>>>>> exc.retval is returned below and thus should always be > >>>>>>>>> initialized. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> imageDecompressor.cpp > >>>>>>>>> > >>>>>>>>> Wrong destructor is used. Reported also by David CARLIER > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> java.c > >>>>>>>>> > >>>>>>>>> in line 1865 'name' was used, it should be 'alias'. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> java_md_solinux.c > >>>>>>>>> > >>>>>>>>> "//" in path is useless. Further down a free is missing. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> SDE.c > >>>>>>>>> > >>>>>>>>> Call to stratumTableIndex can return negative value if > >>>>>>>>> defaultStratumId > >>>>>>>>> == null. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> socket_md.c > >>>>>>>>> > >>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is > >>>>>>>>> hidden in > >>>>>>>>> the macros. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> unpack.cpp > >>>>>>>>> > >>>>>>>>> n.slice should not get negative argument for end, which is > >>>>>>>>> passed from > >>>>>>>>> dollar1. > >>>>>>>>> But dollar1 can get negative where it is set to the result of > >>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Dmitry Samersoff > >>>>>>>> Oracle Java development team, Saint Petersburg, Russia > >>>>>>>> * I would love to change the world, but they won't give me the > >>>>>>>> sources. > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> 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 serguei.spitsyn at oracle.com Wed Dec 14 10:01:20 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 14 Dec 2016 02:01:20 -0800 Subject: RFR(XS): 8139566 need proper sync for adding default read edges Message-ID: <409c2fd2-89b6-0fb5-b9d3-cb43780cadf1@oracle.com> Please, review a fix for the bug: https://bugs.openjdk.java.net/browse/JDK-8139566 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8139566-SyncDefReadEdges.hs1/ There are already two positive (preliminary) reviews from Harold and Lois. Summary: This is a follow-up issue after the fixes for: https://bugs.openjdk.java.net/browse/JDK-8134950 https://bugs.openjdk.java.net/browse/JDK-8072745 The webrevs for the issues above are: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8134950-JVMTI-jake-ana2.3/ http://cr.openjdk.java.net/%7Esspitsyn/webrevs/2015/hotspot/8072745-JVMTI-jake-ana1.5/ The issue is that there can be a race with another thread that checks the ModuleEntry::has_default_read_edges() and goes with its redefinition/retransformation while the upcall to the method jdk.internal.module.Modules.transformedByAgent() (that adds the default read edges to bootstrap and app class loaders) is still in progress. The instrumented code can execute while the upcall to transformedByAgent has not been completed yet. Please, refer to the bug description to get more details. The fix is to check the ModuleEntry::has_default_read_edges() in such a case. The check is added to the ModuleEntry::can_read as it is used in all class resolution cases, for instance: LinkResolver::check_klass_accessability() -> Reflection::verify_class_access() -> ModuleEntry::can_read() ClassFileParser::check_super_class_access() -> Reflection::verify_class_access() -> ModuleEntry::can_read() ClassFileParser::check_super_interface_access() -> Reflection::verify_class_access() -> ModuleEntry::can_read() Note that the ModuleEntry::_has_default_read_edges bit was added as a part of the 8144950 to avoid a bad recursion. One question is: Q1: Can we remove the upcall to the jdk.internal.module.Modules.transformedByAgent() as it would not be needed anymore? The implementation could me simplified. A1: I think, the real read edges established via an upcall to the Java runtime are still needed for the Java level based mechanisms that do not use the ModuleEntry::can_read(). These mechanisms, probably, can tolerate that the "adding to a module default read edges" signal arrives with some latency. Thanks, Serguei From david.holmes at oracle.com Wed Dec 14 10:03:53 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 Dec 2016 20:03:53 +1000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> Message-ID: <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote: > Hi, > > 8066474 has not been promoted. hs has not been able to push up to dev yet. > I'll remove the strlen // fix for aix from this change and > push it without it. I'd like to get this done. I've lost track of what is now left in this set of changes ?? David > Best regards, > Goetz. > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 8. Dezember 2016 23:03 >> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz >> ; 'Dmitry Samersoff' >> ; Java Core Libs > dev at openjdk.java.net>; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >> coding. >> >> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: >>> On 12/8/16 1:59 PM, David Holmes wrote: >>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> thanks for looking at the change. New webrev: >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ >>>>> >>>>>> src/java.base/share/native/libjli/java.c >>>>>> As far as I can see the existing code is working perfectly fine. >>>>> Ah, thanks for the explanation, now I got it! Removed. >>>>> >>>>>> Again I'm not sure what the bug is here. On AIX the output string is >>>>>> expanded with: >>>>>> "%s/lib/%s/jli:" >>>>> I first edited this against jdk9/hs, where the arch is gone since >>>>> 8066474, >>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc >>>>> but the // was not adapted. Then I moved the change to jdk9/dev because >>>>> I thought I have to push it there. And yes, in that coding // would >>>>> be correct. >>>>> So I have to wait until hs is promoted ... >>>> >>>> So just based on the current file, the change proposed - to remove one >>>> / - is not correct until the arch directory is removed. >>> >>> That change is already in JDK9-hs: >>> >>> Changeset: c14f9a7b4cab >>> Author: erikj >>> Date: 2016-12-05 17:55 +0100 >>> URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab >>> >>> 8066474: Remove the lib/ directory from Linux and Solaris images >>> Reviewed-by: tbell, ihse >>> >>> along with changesets in the jdk and hotspot repos along with a few >>> closed repos. >> >> Thanks Dan. So we need to see a webrev based on latest hs code - where >> removing the extra / would be correct. >> >> David >> ----- >> >>> Dan >>> >>> >>> >>>> >>>> David >>>> ----- >>>> >>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>>>> comment on >>>>>> the strdup would have sufficed IMO. >>>>> Dmitry asked me to add it. But I think it's ok. >>>>> >>>>> Can I consider this reviewed now? I.e. could I push it once 8066474 is >>>>> promoted and Joe Darcy agreed? >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14 >>>>>> To: Lindenmaier, Goetz ; 'Dmitry >> Samersoff' >>>>>> ; Java Core Libs >>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>> dev at openjdk.java.net) >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>> servicabilty >>>>>> coding. >>>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> yes, new_jvmpath is consistent with the other variables. >>>>>>> I also merged the ifs in SDE.c. >>>>>>> >>>>>>> new webrev: >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ >>>>>> >>>>>> src/java.base/share/native/libjli/java.c >>>>>> >>>>>> As far as I can see the existing code is working perfectly fine. >>>>>> Given a >>>>>> jvm.cfg with: >>>>>> >>>>>> -server KNOWN >>>>>> -client IGNORE >>>>>> -myvm KNOWN >>>>>> -oldvm ALIASED_TO -server >>>>>> >>>>>> The usage text is: >>>>>> >>>>>> -server to select the "server" VM >>>>>> -myvm to select the "myvm" VM >>>>>> -oldvm is a synonym for the "server" VM [deprecated] >>>>>> The default VM is server, >>>>>> because you are running on a server-class machine. >>>>>> >>>>>> which is exactly what I would expect. Why do you think there is a bug? >>>>>> >>>>>> --- >>>>>> >>>>>> src/java.base/unix/native/libjli/java_md_solinux.c >>>>>> >>>>>> Again I'm not sure what the bug is here. On AIX the output string is >>>>>> expanded with: >>>>>> >>>>>> "%s/lib/%s/jli:" >>>>>> >>>>>> so it needs to account for the extra "/lib//jli:" characters - and that >>>>>> is exactly what the existing code does: >>>>>> >>>>>> + JLI_StrLen("/lib//jli:") >>>>>> >>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>>>> comment on >>>>>> the strdup would have sufficed IMO. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM >>>>>>>> To: Lindenmaier, Goetz ; Java Core Libs >>>>>>>> ; serviceability-dev (serviceability- >>>>>>>> dev at openjdk.java.net) >>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>>>> servicabilty >>>>>>>> coding. >>>>>>>> >>>>>>>> Goetz, >>>>>>>> >>>>>>>> SDE.c: >>>>>>>> >>>>>>>> You might combine if at ll. 260 and 263 to one but it's just >>>>>>>> matter of test. >>>>>>>> >>>>>>>> if (sti == baseStratumIndex || sti < 0) { >>>>>>>> return; /* Java stratum - return unchanged */ >>>>>>>> } >>>>>>>> >>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>> double-check the new webrev. >>>>>>>> >>>>>>>> if cnt is <= 0 loop at l.267 >>>>>>>> >>>>>>>> for (; cnt-- > 0; ++fromEntry) { >>>>>>>> >>>>>>>> is never run and we effectively do >>>>>>>> >>>>>>>> *entryCountPtr = 0; >>>>>>>> >>>>>>>> at l.283 >>>>>>>> >>>>>>>> So if we you suspect that cnt may become negative or 0: >>>>>>>> (your v.01 changes) >>>>>>>> >>>>>>>> 260 if (sti < 0 && cnt > 0) { >>>>>>>> 261 return; >>>>>>>> 262 } >>>>>>>> >>>>>>>> it's better to check it early. >>>>>>>> >>>>>>>> But I'm not sure we have to care about negative/zero cnt here. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> thanks for looking at my change! >>>>>>>>> Updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >> corlib_s11y/webrev.02 >>>>>>>>> >>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>>>> Is this line correct? >>>>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); >>>>>>>>> >>>>>>>>> It seems pointless. Should I remove it? (The whole file is a >>>>>>>>> horror.) >>>>>>>>> >>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>>>>>>>> It might be better to return immediately if cnt < 0, >>>>>>>>>> regardless of value of sti. >>>>>>>>> >>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>> double-check the new webrev. >>>>>>>>> >>>>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>>>>>>>> It might be better to write >>>>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>>>>>>>> and leave one copy of setsockopt() call >>>>>>>>> >>>>>>>>> Yes, looks better. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This change fixes some minor issues found in our code scans. >>>>>>>>>>> >>>>>>>>>>> I hope this correctly addresses corelib and serviceability issues. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Please review: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>>>> corlib_s11y/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Changes in detail: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> e_asin.c >>>>>>>>>>> >>>>>>>>>>> Code scan reports missing {}. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact >>>>>>>>>>> flag of >>>>>>>>>>> the processor. >>>>>>>>>>> It's a way to avoid the C compiler to optimize the code away. >>>>>>>>>>> It is >>>>>>>>>>> always true, >>>>>>>>>>> so the parenthesis of the outer else don't matter. >>>>>>>>>>> >>>>>>>>>>> Although this basically just adds the {} I would like to submit >>>>>>>>>>> this to >>>>>>>>>>> >>>>>>>>>>> avoid anybody else spends more the 30sec on understanding these >>>>>>>>>>> >>>>>>>>>>> if statements. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> k_standard.c >>>>>>>>>>> >>>>>>>>>>> exc.retval is returned below and thus should always be >>>>>>>>>>> initialized. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> imageDecompressor.cpp >>>>>>>>>>> >>>>>>>>>>> Wrong destructor is used. Reported also by David CARLIER >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> java.c >>>>>>>>>>> >>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> java_md_solinux.c >>>>>>>>>>> >>>>>>>>>>> "//" in path is useless. Further down a free is missing. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> SDE.c >>>>>>>>>>> >>>>>>>>>>> Call to stratumTableIndex can return negative value if >>>>>>>>>>> defaultStratumId >>>>>>>>>>> == null. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> socket_md.c >>>>>>>>>>> >>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is >>>>>>>>>>> hidden in >>>>>>>>>>> the macros. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> unpack.cpp >>>>>>>>>>> >>>>>>>>>>> n.slice should not get negative argument for end, which is >>>>>>>>>>> passed from >>>>>>>>>>> dollar1. >>>>>>>>>>> But dollar1 can get negative where it is set to the result of >>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Dmitry Samersoff >>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>>>> * I would love to change the world, but they won't give me the >>>>>>>>>> sources. >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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 goetz.lindenmaier at sap.com Wed Dec 14 10:23:25 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 14 Dec 2016 10:23:25 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> Message-ID: <4834063ecbab4971bf4767e637e032a3@DEROTE13DE08.global.corp.sap> Hi David, I found "8169317: [s390] Various minor bug fixes and adaptions." in jdk9/dev this morning, so I thought it has been promoted based on some older change. I waited for that quite a while because tests in jdk9/dev kept failing on s390. How can I get the information when what was promoted? This always is a wild guess for me ... as well as when what will be promoted :) Do you think the promotion will happen tonight, or will it take another week? I removed - JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib//jli:") + + JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib/jli:") + from http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 14. Dezember 2016 11:04 > To: Lindenmaier, Goetz ; > daniel.daugherty at oracle.com; 'Dmitry Samersoff' > ; Java Core Libs dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > 8066474 has not been promoted. > > hs has not been able to push up to dev yet. > > > I'll remove the strlen // fix for aix from this change and > > push it without it. I'd like to get this done. > > I've lost track of what is now left in this set of changes ?? > > David > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Donnerstag, 8. Dezember 2016 23:03 > >> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz > >> ; 'Dmitry Samersoff' > >> ; Java Core Libs >> dev at openjdk.java.net>; serviceability-dev (serviceability- > >> dev at openjdk.java.net) > >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > >> coding. > >> > >> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: > >>> On 12/8/16 1:59 PM, David Holmes wrote: > >>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: > >>>>> Hi David, > >>>>> > >>>>> thanks for looking at the change. New webrev: > >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ > >>>>> > >>>>>> src/java.base/share/native/libjli/java.c > >>>>>> As far as I can see the existing code is working perfectly fine. > >>>>> Ah, thanks for the explanation, now I got it! Removed. > >>>>> > >>>>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>>>> expanded with: > >>>>>> "%s/lib/%s/jli:" > >>>>> I first edited this against jdk9/hs, where the arch is gone since > >>>>> 8066474, > >>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc > >>>>> but the // was not adapted. Then I moved the change to jdk9/dev > because > >>>>> I thought I have to push it there. And yes, in that coding // would > >>>>> be correct. > >>>>> So I have to wait until hs is promoted ... > >>>> > >>>> So just based on the current file, the change proposed - to remove one > >>>> / - is not correct until the arch directory is removed. > >>> > >>> That change is already in JDK9-hs: > >>> > >>> Changeset: c14f9a7b4cab > >>> Author: erikj > >>> Date: 2016-12-05 17:55 +0100 > >>> URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab > >>> > >>> 8066474: Remove the lib/ directory from Linux and Solaris images > >>> Reviewed-by: tbell, ihse > >>> > >>> along with changesets in the jdk and hotspot repos along with a few > >>> closed repos. > >> > >> Thanks Dan. So we need to see a webrev based on latest hs code - where > >> removing the extra / would be correct. > >> > >> David > >> ----- > >> > >>> Dan > >>> > >>> > >>> > >>>> > >>>> David > >>>> ----- > >>>> > >>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>>>> comment on > >>>>>> the strdup would have sufficed IMO. > >>>>> Dmitry asked me to add it. But I think it's ok. > >>>>> > >>>>> Can I consider this reviewed now? I.e. could I push it once 8066474 is > >>>>> promoted and Joe Darcy agreed? > >>>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14 > >>>>>> To: Lindenmaier, Goetz ; 'Dmitry > >> Samersoff' > >>>>>> ; Java Core Libs >>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>>>> dev at openjdk.java.net) > >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>>>> servicabilty > >>>>>> coding. > >>>>>> > >>>>>> Hi Goetz, > >>>>>> > >>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: > >>>>>>> Hi Dmitry, > >>>>>>> > >>>>>>> yes, new_jvmpath is consistent with the other variables. > >>>>>>> I also merged the ifs in SDE.c. > >>>>>>> > >>>>>>> new webrev: > >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > corlib_s11y/webrev.03/ > >>>>>> > >>>>>> src/java.base/share/native/libjli/java.c > >>>>>> > >>>>>> As far as I can see the existing code is working perfectly fine. > >>>>>> Given a > >>>>>> jvm.cfg with: > >>>>>> > >>>>>> -server KNOWN > >>>>>> -client IGNORE > >>>>>> -myvm KNOWN > >>>>>> -oldvm ALIASED_TO -server > >>>>>> > >>>>>> The usage text is: > >>>>>> > >>>>>> -server to select the "server" VM > >>>>>> -myvm to select the "myvm" VM > >>>>>> -oldvm is a synonym for the "server" VM [deprecated] > >>>>>> The default VM is server, > >>>>>> because you are running on a server-class machine. > >>>>>> > >>>>>> which is exactly what I would expect. Why do you think there is a bug? > >>>>>> > >>>>>> --- > >>>>>> > >>>>>> src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>> > >>>>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>>>> expanded with: > >>>>>> > >>>>>> "%s/lib/%s/jli:" > >>>>>> > >>>>>> so it needs to account for the extra "/lib//jli:" characters - and that > >>>>>> is exactly what the existing code does: > >>>>>> > >>>>>> + JLI_StrLen("/lib//jli:") > >>>>>> > >>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>>>> comment on > >>>>>> the strdup would have sufficed IMO. > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> ----- > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz. > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > >>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM > >>>>>>>> To: Lindenmaier, Goetz ; Java Core > Libs > >>>>>>>> ; serviceability-dev (serviceability- > >>>>>>>> dev at openjdk.java.net) > >>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>>>>>> servicabilty > >>>>>>>> coding. > >>>>>>>> > >>>>>>>> Goetz, > >>>>>>>> > >>>>>>>> SDE.c: > >>>>>>>> > >>>>>>>> You might combine if at ll. 260 and 263 to one but it's just > >>>>>>>> matter of test. > >>>>>>>> > >>>>>>>> if (sti == baseStratumIndex || sti < 0) { > >>>>>>>> return; /* Java stratum - return unchanged */ > >>>>>>>> } > >>>>>>>> > >>>>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>>>> double-check the new webrev. > >>>>>>>> > >>>>>>>> if cnt is <= 0 loop at l.267 > >>>>>>>> > >>>>>>>> for (; cnt-- > 0; ++fromEntry) { > >>>>>>>> > >>>>>>>> is never run and we effectively do > >>>>>>>> > >>>>>>>> *entryCountPtr = 0; > >>>>>>>> > >>>>>>>> at l.283 > >>>>>>>> > >>>>>>>> So if we you suspect that cnt may become negative or 0: > >>>>>>>> (your v.01 changes) > >>>>>>>> > >>>>>>>> 260 if (sti < 0 && cnt > 0) { > >>>>>>>> 261 return; > >>>>>>>> 262 } > >>>>>>>> > >>>>>>>> it's better to check it early. > >>>>>>>> > >>>>>>>> But I'm not sure we have to care about negative/zero cnt here. > >>>>>>>> > >>>>>>>> -Dmitry > >>>>>>>> > >>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > >>>>>>>>> Hi Dmitry, > >>>>>>>>> > >>>>>>>>> thanks for looking at my change! > >>>>>>>>> Updated webrev: > >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >> corlib_s11y/webrev.02 > >>>>>>>>> > >>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>>>>>> Is this line correct? > >>>>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); > >>>>>>>>> > >>>>>>>>> It seems pointless. Should I remove it? (The whole file is a > >>>>>>>>> horror.) > >>>>>>>>> > >>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > >>>>>>>>>> It might be better to return immediately if cnt < 0, > >>>>>>>>>> regardless of value of sti. > >>>>>>>>> > >>>>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>>>> double-check the new webrev. > >>>>>>>>> > >>>>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > >>>>>>>>>> It might be better to write > >>>>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; > >>>>>>>>>> and leave one copy of setsockopt() call > >>>>>>>>> > >>>>>>>>> Yes, looks better. > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Goetz > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -Dmitry > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> This change fixes some minor issues found in our code scans. > >>>>>>>>>>> > >>>>>>>>>>> I hope this correctly addresses corelib and serviceability issues. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Please review: > >>>>>>>>>>> > >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>>>>>> corlib_s11y/webrev.01/ > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Best regards, > >>>>>>>>>>> > >>>>>>>>>>> Goetz. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Changes in detail: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> e_asin.c > >>>>>>>>>>> > >>>>>>>>>>> Code scan reports missing {}. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact > >>>>>>>>>>> flag of > >>>>>>>>>>> the processor. > >>>>>>>>>>> It's a way to avoid the C compiler to optimize the code away. > >>>>>>>>>>> It is > >>>>>>>>>>> always true, > >>>>>>>>>>> so the parenthesis of the outer else don't matter. > >>>>>>>>>>> > >>>>>>>>>>> Although this basically just adds the {} I would like to submit > >>>>>>>>>>> this to > >>>>>>>>>>> > >>>>>>>>>>> avoid anybody else spends more the 30sec on understanding > these > >>>>>>>>>>> > >>>>>>>>>>> if statements. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> k_standard.c > >>>>>>>>>>> > >>>>>>>>>>> exc.retval is returned below and thus should always be > >>>>>>>>>>> initialized. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> imageDecompressor.cpp > >>>>>>>>>>> > >>>>>>>>>>> Wrong destructor is used. Reported also by David CARLIER > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> java.c > >>>>>>>>>>> > >>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> java_md_solinux.c > >>>>>>>>>>> > >>>>>>>>>>> "//" in path is useless. Further down a free is missing. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> SDE.c > >>>>>>>>>>> > >>>>>>>>>>> Call to stratumTableIndex can return negative value if > >>>>>>>>>>> defaultStratumId > >>>>>>>>>>> == null. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> socket_md.c > >>>>>>>>>>> > >>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is > >>>>>>>>>>> hidden in > >>>>>>>>>>> the macros. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> unpack.cpp > >>>>>>>>>>> > >>>>>>>>>>> n.slice should not get negative argument for end, which is > >>>>>>>>>>> passed from > >>>>>>>>>>> dollar1. > >>>>>>>>>>> But dollar1 can get negative where it is set to the result of > >>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Dmitry Samersoff > >>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia > >>>>>>>>>> * I would love to change the world, but they won't give me the > >>>>>>>>>> sources. > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> 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 serguei.spitsyn at oracle.com Wed Dec 14 10:30:33 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 14 Dec 2016 02:30:33 -0800 Subject: RFR (XXS): 8171226 simple typo in the JVMTI spec Message-ID: <16701c81-4061-2e98-fead-a77a138d5db3@oracle.com> Need one reviewer for a trivial typo fix in the JVMTI spec: https://bugs.openjdk.java.net/browse/JDK-8171226 The suggested fix is ("bot" => "not"): --- a/src/share/vm/prims/jvmti.xml Thu Dec 08 15:49:29 2016 +0100 +++ b/src/share/vm/prims/jvmti.xml Wed Dec 14 02:24:51 2016 -0800 @@ -3370,7 +3370,7 @@ Reference from a class to its superclass. - A callback is bot sent if the superclass is java.lang.Object. + A callback is not sent if the superclass is java.lang.Object. Note: loaded classes define superclasses via a constant pool reference, so the referenced superclass may also be reported with a JVMTI_HEAP_REFERENCE_CONSTANT_POOL reference kind. Thanks, Serguei From Alan.Bateman at oracle.com Wed Dec 14 10:33:37 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Dec 2016 10:33:37 +0000 Subject: RFR (XXS): 8171226 simple typo in the JVMTI spec In-Reply-To: <16701c81-4061-2e98-fead-a77a138d5db3@oracle.com> References: <16701c81-4061-2e98-fead-a77a138d5db3@oracle.com> Message-ID: <6689ab56-f340-e442-bb95-ec4abe66966b@oracle.com> On 14/12/2016 10:30, serguei.spitsyn at oracle.com wrote: > Need one reviewer for a trivial typo fix in the JVMTI spec: > https://bugs.openjdk.java.net/browse/JDK-8171226 > > > The suggested fix is ("bot" => "not"): > > --- a/src/share/vm/prims/jvmti.xml Thu Dec 08 15:49:29 2016 +0100 > +++ b/src/share/vm/prims/jvmti.xml Wed Dec 14 02:24:51 2016 -0800 > @@ -3370,7 +3370,7 @@ > > > Reference from a class to its superclass. > - A callback is bot sent if the superclass is > java.lang.Object. > + A callback is not sent if the superclass is > java.lang.Object. Looks fine. -Alan From serguei.spitsyn at oracle.com Wed Dec 14 10:34:24 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 14 Dec 2016 02:34:24 -0800 Subject: RFR (XXS): 8171226 simple typo in the JVMTI spec In-Reply-To: <6689ab56-f340-e442-bb95-ec4abe66966b@oracle.com> References: <16701c81-4061-2e98-fead-a77a138d5db3@oracle.com> <6689ab56-f340-e442-bb95-ec4abe66966b@oracle.com> Message-ID: <6188eb2d-aa85-a909-d091-d10f2114e7ff@oracle.com> On 12/14/16 02:33, Alan Bateman wrote: > > > On 14/12/2016 10:30, serguei.spitsyn at oracle.com wrote: >> Need one reviewer for a trivial typo fix in the JVMTI spec: >> https://bugs.openjdk.java.net/browse/JDK-8171226 >> >> >> The suggested fix is ("bot" => "not"): >> >> --- a/src/share/vm/prims/jvmti.xml Thu Dec 08 15:49:29 2016 +0100 >> +++ b/src/share/vm/prims/jvmti.xml Wed Dec 14 02:24:51 2016 -0800 >> @@ -3370,7 +3370,7 @@ >> >> >> Reference from a class to its superclass. >> - A callback is bot sent if the superclass is >> java.lang.Object. >> + A callback is not sent if the superclass is >> java.lang.Object. > Looks fine. Thank you, Alan! Serguei > > -Alan From david.holmes at oracle.com Wed Dec 14 10:42:26 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 Dec 2016 20:42:26 +1000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <4834063ecbab4971bf4767e637e032a3@DEROTE13DE08.global.corp.sap> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> <4834063ecbab4971bf4767e637e032a3@DEROTE13DE08.global.corp.sap> Message-ID: <78ebe654-8f75-3a30-dc0f-8a459aa59dbb@oracle.com> On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote: > Hi David, > > I found "8169317: [s390] Various minor bug fixes and adaptions." > in jdk9/dev this morning, so I thought it has been promoted based > on some older change. I waited for that quite a while because tests > in jdk9/dev kept failing on s390. > How can I get the information when what was promoted? This always > is a wild guess for me ... as well as when what will be promoted :) Yeah there's no notification in the bug report of when hs pushes up to dev. The changeset email is the only record of exactly when it happens. > Do you think the promotion will happen tonight, or will it take > another week? hs goes through Pre-Integration Testing (PIT) before it is pushed to dev. There have been delays in getting that started and so a delay in it finishing and being analyzed. It may still be a couple of days. > I removed > - JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib//jli:") + > + JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib/jli:") + > from > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ With that gone that file only has the jvmpath rename - which isn't fixing anything. Joe also asked for the fdlibm changes to dropped. Thanks, David > Best regards, > Goetz. > > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 14. Dezember 2016 11:04 >> To: Lindenmaier, Goetz ; >> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >> ; Java Core Libs > dev at openjdk.java.net>; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >> coding. >> >> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> 8066474 has not been promoted. >> >> hs has not been able to push up to dev yet. >> >>> I'll remove the strlen // fix for aix from this change and >>> push it without it. I'd like to get this done. >> >> I've lost track of what is now left in this set of changes ?? >> >> David >> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Donnerstag, 8. Dezember 2016 23:03 >>>> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz >>>> ; 'Dmitry Samersoff' >>>> ; Java Core Libs >>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>> dev at openjdk.java.net) >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >>>> coding. >>>> >>>> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: >>>>> On 12/8/16 1:59 PM, David Holmes wrote: >>>>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> thanks for looking at the change. New webrev: >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ >>>>>>> >>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>> As far as I can see the existing code is working perfectly fine. >>>>>>> Ah, thanks for the explanation, now I got it! Removed. >>>>>>> >>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is >>>>>>>> expanded with: >>>>>>>> "%s/lib/%s/jli:" >>>>>>> I first edited this against jdk9/hs, where the arch is gone since >>>>>>> 8066474, >>>>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc >>>>>>> but the // was not adapted. Then I moved the change to jdk9/dev >> because >>>>>>> I thought I have to push it there. And yes, in that coding // would >>>>>>> be correct. >>>>>>> So I have to wait until hs is promoted ... >>>>>> >>>>>> So just based on the current file, the change proposed - to remove one >>>>>> / - is not correct until the arch directory is removed. >>>>> >>>>> That change is already in JDK9-hs: >>>>> >>>>> Changeset: c14f9a7b4cab >>>>> Author: erikj >>>>> Date: 2016-12-05 17:55 +0100 >>>>> URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab >>>>> >>>>> 8066474: Remove the lib/ directory from Linux and Solaris images >>>>> Reviewed-by: tbell, ihse >>>>> >>>>> along with changesets in the jdk and hotspot repos along with a few >>>>> closed repos. >>>> >>>> Thanks Dan. So we need to see a webrev based on latest hs code - where >>>> removing the extra / would be correct. >>>> >>>> David >>>> ----- >>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>>>>>> comment on >>>>>>>> the strdup would have sufficed IMO. >>>>>>> Dmitry asked me to add it. But I think it's ok. >>>>>>> >>>>>>> Can I consider this reviewed now? I.e. could I push it once 8066474 is >>>>>>> promoted and Joe Darcy agreed? >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14 >>>>>>>> To: Lindenmaier, Goetz ; 'Dmitry >>>> Samersoff' >>>>>>>> ; Java Core Libs >>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>>>> dev at openjdk.java.net) >>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>>>> servicabilty >>>>>>>> coding. >>>>>>>> >>>>>>>> Hi Goetz, >>>>>>>> >>>>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> yes, new_jvmpath is consistent with the other variables. >>>>>>>>> I also merged the ifs in SDE.c. >>>>>>>>> >>>>>>>>> new webrev: >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >> corlib_s11y/webrev.03/ >>>>>>>> >>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>> >>>>>>>> As far as I can see the existing code is working perfectly fine. >>>>>>>> Given a >>>>>>>> jvm.cfg with: >>>>>>>> >>>>>>>> -server KNOWN >>>>>>>> -client IGNORE >>>>>>>> -myvm KNOWN >>>>>>>> -oldvm ALIASED_TO -server >>>>>>>> >>>>>>>> The usage text is: >>>>>>>> >>>>>>>> -server to select the "server" VM >>>>>>>> -myvm to select the "myvm" VM >>>>>>>> -oldvm is a synonym for the "server" VM [deprecated] >>>>>>>> The default VM is server, >>>>>>>> because you are running on a server-class machine. >>>>>>>> >>>>>>>> which is exactly what I would expect. Why do you think there is a bug? >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>> >>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is >>>>>>>> expanded with: >>>>>>>> >>>>>>>> "%s/lib/%s/jli:" >>>>>>>> >>>>>>>> so it needs to account for the extra "/lib//jli:" characters - and that >>>>>>>> is exactly what the existing code does: >>>>>>>> >>>>>>>> + JLI_StrLen("/lib//jli:") >>>>>>>> >>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>>>>>> comment on >>>>>>>> the strdup would have sufficed IMO. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM >>>>>>>>>> To: Lindenmaier, Goetz ; Java Core >> Libs >>>>>>>>>> ; serviceability-dev (serviceability- >>>>>>>>>> dev at openjdk.java.net) >>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>>>>>> servicabilty >>>>>>>>>> coding. >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>> SDE.c: >>>>>>>>>> >>>>>>>>>> You might combine if at ll. 260 and 263 to one but it's just >>>>>>>>>> matter of test. >>>>>>>>>> >>>>>>>>>> if (sti == baseStratumIndex || sti < 0) { >>>>>>>>>> return; /* Java stratum - return unchanged */ >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>>>> double-check the new webrev. >>>>>>>>>> >>>>>>>>>> if cnt is <= 0 loop at l.267 >>>>>>>>>> >>>>>>>>>> for (; cnt-- > 0; ++fromEntry) { >>>>>>>>>> >>>>>>>>>> is never run and we effectively do >>>>>>>>>> >>>>>>>>>> *entryCountPtr = 0; >>>>>>>>>> >>>>>>>>>> at l.283 >>>>>>>>>> >>>>>>>>>> So if we you suspect that cnt may become negative or 0: >>>>>>>>>> (your v.01 changes) >>>>>>>>>> >>>>>>>>>> 260 if (sti < 0 && cnt > 0) { >>>>>>>>>> 261 return; >>>>>>>>>> 262 } >>>>>>>>>> >>>>>>>>>> it's better to check it early. >>>>>>>>>> >>>>>>>>>> But I'm not sure we have to care about negative/zero cnt here. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> thanks for looking at my change! >>>>>>>>>>> Updated webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>> corlib_s11y/webrev.02 >>>>>>>>>>> >>>>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>>>>>> Is this line correct? >>>>>>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); >>>>>>>>>>> >>>>>>>>>>> It seems pointless. Should I remove it? (The whole file is a >>>>>>>>>>> horror.) >>>>>>>>>>> >>>>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>>>>>>>>>> It might be better to return immediately if cnt < 0, >>>>>>>>>>>> regardless of value of sti. >>>>>>>>>>> >>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>>>> double-check the new webrev. >>>>>>>>>>> >>>>>>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>>>>>>>>>> It might be better to write >>>>>>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>>>>>>>>>> and leave one copy of setsockopt() call >>>>>>>>>>> >>>>>>>>>>> Yes, looks better. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -Dmitry >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This change fixes some minor issues found in our code scans. >>>>>>>>>>>>> >>>>>>>>>>>>> I hope this correctly addresses corelib and serviceability issues. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Please review: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>>>>>> corlib_s11y/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Changes in detail: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> e_asin.c >>>>>>>>>>>>> >>>>>>>>>>>>> Code scan reports missing {}. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact >>>>>>>>>>>>> flag of >>>>>>>>>>>>> the processor. >>>>>>>>>>>>> It's a way to avoid the C compiler to optimize the code away. >>>>>>>>>>>>> It is >>>>>>>>>>>>> always true, >>>>>>>>>>>>> so the parenthesis of the outer else don't matter. >>>>>>>>>>>>> >>>>>>>>>>>>> Although this basically just adds the {} I would like to submit >>>>>>>>>>>>> this to >>>>>>>>>>>>> >>>>>>>>>>>>> avoid anybody else spends more the 30sec on understanding >> these >>>>>>>>>>>>> >>>>>>>>>>>>> if statements. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> k_standard.c >>>>>>>>>>>>> >>>>>>>>>>>>> exc.retval is returned below and thus should always be >>>>>>>>>>>>> initialized. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> imageDecompressor.cpp >>>>>>>>>>>>> >>>>>>>>>>>>> Wrong destructor is used. Reported also by David CARLIER >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> java.c >>>>>>>>>>>>> >>>>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> java_md_solinux.c >>>>>>>>>>>>> >>>>>>>>>>>>> "//" in path is useless. Further down a free is missing. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> SDE.c >>>>>>>>>>>>> >>>>>>>>>>>>> Call to stratumTableIndex can return negative value if >>>>>>>>>>>>> defaultStratumId >>>>>>>>>>>>> == null. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> socket_md.c >>>>>>>>>>>>> >>>>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is >>>>>>>>>>>>> hidden in >>>>>>>>>>>>> the macros. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> unpack.cpp >>>>>>>>>>>>> >>>>>>>>>>>>> n.slice should not get negative argument for end, which is >>>>>>>>>>>>> passed from >>>>>>>>>>>>> dollar1. >>>>>>>>>>>>> But dollar1 can get negative where it is set to the result of >>>>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Dmitry Samersoff >>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>>>>>> * I would love to change the world, but they won't give me the >>>>>>>>>>>> sources. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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 goetz.lindenmaier at sap.com Wed Dec 14 11:00:46 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 14 Dec 2016 11:00:46 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <78ebe654-8f75-3a30-dc0f-8a459aa59dbb@oracle.com> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> <4834063ecbab4971bf4767e637e032a3@DEROTE13DE08.global.corp.sap> <78ebe654-8f75-3a30-dc0f-8a459aa59dbb@oracle.com> Message-ID: <4f2ce01887c74725b9ede388daf707be@DEROTE13DE08.global.corp.sap> Hi, You're right, I had removed the change to e_asin.c. New webrev anyways: http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.05/ java_md_solinux.c adds JLI_MemFree(new_jvmpath) that was missing. Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 14. Dezember 2016 11:42 > To: Lindenmaier, Goetz ; > daniel.daugherty at oracle.com; 'Dmitry Samersoff' > ; Java Core Libs dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote: > > Hi David, > > > > I found "8169317: [s390] Various minor bug fixes and adaptions." > > in jdk9/dev this morning, so I thought it has been promoted based > > on some older change. I waited for that quite a while because tests > > in jdk9/dev kept failing on s390. > > How can I get the information when what was promoted? This always > > is a wild guess for me ... as well as when what will be promoted :) > > Yeah there's no notification in the bug report of when hs pushes up to > dev. The changeset email is the only record of exactly when it happens. > > > Do you think the promotion will happen tonight, or will it take > > another week? > > hs goes through Pre-Integration Testing (PIT) before it is pushed to > dev. There have been delays in getting that started and so a delay in it > finishing and being analyzed. It may still be a couple of days. > > > I removed > > - JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib//jli:") + > > + JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib/jli:") + > > from > > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ > > With that gone that file only has the jvmpath rename - which isn't > fixing anything. > > Joe also asked for the fdlibm changes to dropped. > > Thanks, > David > > > Best regards, > > Goetz. > > > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Mittwoch, 14. Dezember 2016 11:04 > >> To: Lindenmaier, Goetz ; > >> daniel.daugherty at oracle.com; 'Dmitry Samersoff' > >> ; Java Core Libs >> dev at openjdk.java.net>; serviceability-dev (serviceability- > >> dev at openjdk.java.net) > >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > >> coding. > >> > >> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> 8066474 has not been promoted. > >> > >> hs has not been able to push up to dev yet. > >> > >>> I'll remove the strlen // fix for aix from this change and > >>> push it without it. I'd like to get this done. > >> > >> I've lost track of what is now left in this set of changes ?? > >> > >> David > >> > >>> Best regards, > >>> Goetz. > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Donnerstag, 8. Dezember 2016 23:03 > >>>> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz > >>>> ; 'Dmitry Samersoff' > >>>> ; Java Core Libs >>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>> dev at openjdk.java.net) > >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > >>>> coding. > >>>> > >>>> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: > >>>>> On 12/8/16 1:59 PM, David Holmes wrote: > >>>>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: > >>>>>>> Hi David, > >>>>>>> > >>>>>>> thanks for looking at the change. New webrev: > >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > corlib_s11y/webrev.04/ > >>>>>>> > >>>>>>>> src/java.base/share/native/libjli/java.c > >>>>>>>> As far as I can see the existing code is working perfectly fine. > >>>>>>> Ah, thanks for the explanation, now I got it! Removed. > >>>>>>> > >>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>>>>>> expanded with: > >>>>>>>> "%s/lib/%s/jli:" > >>>>>>> I first edited this against jdk9/hs, where the arch is gone since > >>>>>>> 8066474, > >>>>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc > >>>>>>> but the // was not adapted. Then I moved the change to jdk9/dev > >> because > >>>>>>> I thought I have to push it there. And yes, in that coding // would > >>>>>>> be correct. > >>>>>>> So I have to wait until hs is promoted ... > >>>>>> > >>>>>> So just based on the current file, the change proposed - to remove one > >>>>>> / - is not correct until the arch directory is removed. > >>>>> > >>>>> That change is already in JDK9-hs: > >>>>> > >>>>> Changeset: c14f9a7b4cab > >>>>> Author: erikj > >>>>> Date: 2016-12-05 17:55 +0100 > >>>>> URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab > >>>>> > >>>>> 8066474: Remove the lib/ directory from Linux and Solaris images > >>>>> Reviewed-by: tbell, ihse > >>>>> > >>>>> along with changesets in the jdk and hotspot repos along with a few > >>>>> closed repos. > >>>> > >>>> Thanks Dan. So we need to see a webrev based on latest hs code - where > >>>> removing the extra / would be correct. > >>>> > >>>> David > >>>> ----- > >>>> > >>>>> Dan > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> David > >>>>>> ----- > >>>>>> > >>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>>>>>> comment on > >>>>>>>> the strdup would have sufficed IMO. > >>>>>>> Dmitry asked me to add it. But I think it's ok. > >>>>>>> > >>>>>>> Can I consider this reviewed now? I.e. could I push it once 8066474 is > >>>>>>> promoted and Joe Darcy agreed? > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz. > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14 > >>>>>>>> To: Lindenmaier, Goetz ; 'Dmitry > >>>> Samersoff' > >>>>>>>> ; Java Core Libs >>>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>>>>>> dev at openjdk.java.net) > >>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>>>>>> servicabilty > >>>>>>>> coding. > >>>>>>>> > >>>>>>>> Hi Goetz, > >>>>>>>> > >>>>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: > >>>>>>>>> Hi Dmitry, > >>>>>>>>> > >>>>>>>>> yes, new_jvmpath is consistent with the other variables. > >>>>>>>>> I also merged the ifs in SDE.c. > >>>>>>>>> > >>>>>>>>> new webrev: > >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >> corlib_s11y/webrev.03/ > >>>>>>>> > >>>>>>>> src/java.base/share/native/libjli/java.c > >>>>>>>> > >>>>>>>> As far as I can see the existing code is working perfectly fine. > >>>>>>>> Given a > >>>>>>>> jvm.cfg with: > >>>>>>>> > >>>>>>>> -server KNOWN > >>>>>>>> -client IGNORE > >>>>>>>> -myvm KNOWN > >>>>>>>> -oldvm ALIASED_TO -server > >>>>>>>> > >>>>>>>> The usage text is: > >>>>>>>> > >>>>>>>> -server to select the "server" VM > >>>>>>>> -myvm to select the "myvm" VM > >>>>>>>> -oldvm is a synonym for the "server" VM [deprecated] > >>>>>>>> The default VM is server, > >>>>>>>> because you are running on a server-class machine. > >>>>>>>> > >>>>>>>> which is exactly what I would expect. Why do you think there is a > bug? > >>>>>>>> > >>>>>>>> --- > >>>>>>>> > >>>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>>>> > >>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>>>>>> expanded with: > >>>>>>>> > >>>>>>>> "%s/lib/%s/jli:" > >>>>>>>> > >>>>>>>> so it needs to account for the extra "/lib//jli:" characters - and that > >>>>>>>> is exactly what the existing code does: > >>>>>>>> > >>>>>>>> + JLI_StrLen("/lib//jli:") > >>>>>>>> > >>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>>>>>> comment on > >>>>>>>> the strdup would have sufficed IMO. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> David > >>>>>>>> ----- > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Goetz. > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > >>>>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM > >>>>>>>>>> To: Lindenmaier, Goetz ; Java Core > >> Libs > >>>>>>>>>> ; serviceability-dev > (serviceability- > >>>>>>>>>> dev at openjdk.java.net) > >>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>>>>>>>> servicabilty > >>>>>>>>>> coding. > >>>>>>>>>> > >>>>>>>>>> Goetz, > >>>>>>>>>> > >>>>>>>>>> SDE.c: > >>>>>>>>>> > >>>>>>>>>> You might combine if at ll. 260 and 263 to one but it's just > >>>>>>>>>> matter of test. > >>>>>>>>>> > >>>>>>>>>> if (sti == baseStratumIndex || sti < 0) { > >>>>>>>>>> return; /* Java stratum - return unchanged */ > >>>>>>>>>> } > >>>>>>>>>> > >>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>>>>>> double-check the new webrev. > >>>>>>>>>> > >>>>>>>>>> if cnt is <= 0 loop at l.267 > >>>>>>>>>> > >>>>>>>>>> for (; cnt-- > 0; ++fromEntry) { > >>>>>>>>>> > >>>>>>>>>> is never run and we effectively do > >>>>>>>>>> > >>>>>>>>>> *entryCountPtr = 0; > >>>>>>>>>> > >>>>>>>>>> at l.283 > >>>>>>>>>> > >>>>>>>>>> So if we you suspect that cnt may become negative or 0: > >>>>>>>>>> (your v.01 changes) > >>>>>>>>>> > >>>>>>>>>> 260 if (sti < 0 && cnt > 0) { > >>>>>>>>>> 261 return; > >>>>>>>>>> 262 } > >>>>>>>>>> > >>>>>>>>>> it's better to check it early. > >>>>>>>>>> > >>>>>>>>>> But I'm not sure we have to care about negative/zero cnt here. > >>>>>>>>>> > >>>>>>>>>> -Dmitry > >>>>>>>>>> > >>>>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > >>>>>>>>>>> Hi Dmitry, > >>>>>>>>>>> > >>>>>>>>>>> thanks for looking at my change! > >>>>>>>>>>> Updated webrev: > >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>> corlib_s11y/webrev.02 > >>>>>>>>>>> > >>>>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>>>>>>>> Is this line correct? > >>>>>>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); > >>>>>>>>>>> > >>>>>>>>>>> It seems pointless. Should I remove it? (The whole file is a > >>>>>>>>>>> horror.) > >>>>>>>>>>> > >>>>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > >>>>>>>>>>>> It might be better to return immediately if cnt < 0, > >>>>>>>>>>>> regardless of value of sti. > >>>>>>>>>>> > >>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>>>>>> double-check the new webrev. > >>>>>>>>>>> > >>>>>>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > >>>>>>>>>>>> It might be better to write > >>>>>>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; > >>>>>>>>>>>> and leave one copy of setsockopt() call > >>>>>>>>>>> > >>>>>>>>>>> Yes, looks better. > >>>>>>>>>>> > >>>>>>>>>>> Best regards, > >>>>>>>>>>> Goetz > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> -Dmitry > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>> Hi, > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> This change fixes some minor issues found in our code scans. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I hope this correctly addresses corelib and serviceability issues. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Please review: > >>>>>>>>>>>>> > >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>>>>>>>> corlib_s11y/webrev.01/ > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Changes in detail: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> e_asin.c > >>>>>>>>>>>>> > >>>>>>>>>>>>> Code scan reports missing {}. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact > >>>>>>>>>>>>> flag of > >>>>>>>>>>>>> the processor. > >>>>>>>>>>>>> It's a way to avoid the C compiler to optimize the code away. > >>>>>>>>>>>>> It is > >>>>>>>>>>>>> always true, > >>>>>>>>>>>>> so the parenthesis of the outer else don't matter. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Although this basically just adds the {} I would like to submit > >>>>>>>>>>>>> this to > >>>>>>>>>>>>> > >>>>>>>>>>>>> avoid anybody else spends more the 30sec on understanding > >> these > >>>>>>>>>>>>> > >>>>>>>>>>>>> if statements. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> k_standard.c > >>>>>>>>>>>>> > >>>>>>>>>>>>> exc.retval is returned below and thus should always be > >>>>>>>>>>>>> initialized. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> imageDecompressor.cpp > >>>>>>>>>>>>> > >>>>>>>>>>>>> Wrong destructor is used. Reported also by David CARLIER > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> java.c > >>>>>>>>>>>>> > >>>>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> java_md_solinux.c > >>>>>>>>>>>>> > >>>>>>>>>>>>> "//" in path is useless. Further down a free is missing. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> SDE.c > >>>>>>>>>>>>> > >>>>>>>>>>>>> Call to stratumTableIndex can return negative value if > >>>>>>>>>>>>> defaultStratumId > >>>>>>>>>>>>> == null. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> socket_md.c > >>>>>>>>>>>>> > >>>>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is > >>>>>>>>>>>>> hidden in > >>>>>>>>>>>>> the macros. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> unpack.cpp > >>>>>>>>>>>>> > >>>>>>>>>>>>> n.slice should not get negative argument for end, which is > >>>>>>>>>>>>> passed from > >>>>>>>>>>>>> dollar1. > >>>>>>>>>>>>> But dollar1 can get negative where it is set to the result of > >>>>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> -- > >>>>>>>>>>>> Dmitry Samersoff > >>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia > >>>>>>>>>>>> * I would love to change the world, but they won't give me the > >>>>>>>>>>>> sources. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> 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 Dec 14 11:28:39 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 Dec 2016 21:28:39 +1000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <4f2ce01887c74725b9ede388daf707be@DEROTE13DE08.global.corp.sap> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> <4834063ecbab4971bf4767e637e032a3@DEROTE13DE08.global.corp.sap> <78ebe654-8f75-3a30-dc0f-8a459aa59dbb@oracle.com> <4f2ce01887c74725b9ede388daf707be@DEROTE13DE08.global.corp.sap> Message-ID: <1238bad1-1805-e57a-2360-196e44770521@oracle.com> On 14/12/2016 9:00 PM, Lindenmaier, Goetz wrote: > Hi, > > You're right, I had removed the change to e_asin.c. You only pointed Joe to that file AFAICS. I would expect he would also object to the change to k_standard.c for the same reason. > New webrev anyways: > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.05/ > > java_md_solinux.c adds JLI_MemFree(new_jvmpath) that was missing. Okay. Thanks. David > Best regards, > Goetz. > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 14. Dezember 2016 11:42 >> To: Lindenmaier, Goetz ; >> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >> ; Java Core Libs > dev at openjdk.java.net>; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >> coding. >> >> On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> I found "8169317: [s390] Various minor bug fixes and adaptions." >>> in jdk9/dev this morning, so I thought it has been promoted based >>> on some older change. I waited for that quite a while because tests >>> in jdk9/dev kept failing on s390. >>> How can I get the information when what was promoted? This always >>> is a wild guess for me ... as well as when what will be promoted :) >> >> Yeah there's no notification in the bug report of when hs pushes up to >> dev. The changeset email is the only record of exactly when it happens. >> >>> Do you think the promotion will happen tonight, or will it take >>> another week? >> >> hs goes through Pre-Integration Testing (PIT) before it is pushed to >> dev. There have been delays in getting that started and so a delay in it >> finishing and being analyzed. It may still be a couple of days. >> >>> I removed >>> - JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib//jli:") + >>> + JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib/jli:") + >>> from >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ >> >> With that gone that file only has the jvmpath rename - which isn't >> fixing anything. >> >> Joe also asked for the fdlibm changes to dropped. >> >> Thanks, >> David >> >>> Best regards, >>> Goetz. >>> >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Mittwoch, 14. Dezember 2016 11:04 >>>> To: Lindenmaier, Goetz ; >>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >>>> ; Java Core Libs >>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>> dev at openjdk.java.net) >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >>>> coding. >>>> >>>> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> 8066474 has not been promoted. >>>> >>>> hs has not been able to push up to dev yet. >>>> >>>>> I'll remove the strlen // fix for aix from this change and >>>>> push it without it. I'd like to get this done. >>>> >>>> I've lost track of what is now left in this set of changes ?? >>>> >>>> David >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Donnerstag, 8. Dezember 2016 23:03 >>>>>> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz >>>>>> ; 'Dmitry Samersoff' >>>>>> ; Java Core Libs >>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>> dev at openjdk.java.net) >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >>>>>> coding. >>>>>> >>>>>> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: >>>>>>> On 12/8/16 1:59 PM, David Holmes wrote: >>>>>>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> thanks for looking at the change. New webrev: >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >> corlib_s11y/webrev.04/ >>>>>>>>> >>>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>>> As far as I can see the existing code is working perfectly fine. >>>>>>>>> Ah, thanks for the explanation, now I got it! Removed. >>>>>>>>> >>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is >>>>>>>>>> expanded with: >>>>>>>>>> "%s/lib/%s/jli:" >>>>>>>>> I first edited this against jdk9/hs, where the arch is gone since >>>>>>>>> 8066474, >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc >>>>>>>>> but the // was not adapted. Then I moved the change to jdk9/dev >>>> because >>>>>>>>> I thought I have to push it there. And yes, in that coding // would >>>>>>>>> be correct. >>>>>>>>> So I have to wait until hs is promoted ... >>>>>>>> >>>>>>>> So just based on the current file, the change proposed - to remove one >>>>>>>> / - is not correct until the arch directory is removed. >>>>>>> >>>>>>> That change is already in JDK9-hs: >>>>>>> >>>>>>> Changeset: c14f9a7b4cab >>>>>>> Author: erikj >>>>>>> Date: 2016-12-05 17:55 +0100 >>>>>>> URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab >>>>>>> >>>>>>> 8066474: Remove the lib/ directory from Linux and Solaris images >>>>>>> Reviewed-by: tbell, ihse >>>>>>> >>>>>>> along with changesets in the jdk and hotspot repos along with a few >>>>>>> closed repos. >>>>>> >>>>>> Thanks Dan. So we need to see a webrev based on latest hs code - where >>>>>> removing the extra / would be correct. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>>>>>>>> comment on >>>>>>>>>> the strdup would have sufficed IMO. >>>>>>>>> Dmitry asked me to add it. But I think it's ok. >>>>>>>>> >>>>>>>>> Can I consider this reviewed now? I.e. could I push it once 8066474 is >>>>>>>>> promoted and Joe Darcy agreed? >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14 >>>>>>>>>> To: Lindenmaier, Goetz ; 'Dmitry >>>>>> Samersoff' >>>>>>>>>> ; Java Core Libs >>>>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>>>>>> dev at openjdk.java.net) >>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>>>>>> servicabilty >>>>>>>>>> coding. >>>>>>>>>> >>>>>>>>>> Hi Goetz, >>>>>>>>>> >>>>>>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> yes, new_jvmpath is consistent with the other variables. >>>>>>>>>>> I also merged the ifs in SDE.c. >>>>>>>>>>> >>>>>>>>>>> new webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>> corlib_s11y/webrev.03/ >>>>>>>>>> >>>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>>> >>>>>>>>>> As far as I can see the existing code is working perfectly fine. >>>>>>>>>> Given a >>>>>>>>>> jvm.cfg with: >>>>>>>>>> >>>>>>>>>> -server KNOWN >>>>>>>>>> -client IGNORE >>>>>>>>>> -myvm KNOWN >>>>>>>>>> -oldvm ALIASED_TO -server >>>>>>>>>> >>>>>>>>>> The usage text is: >>>>>>>>>> >>>>>>>>>> -server to select the "server" VM >>>>>>>>>> -myvm to select the "myvm" VM >>>>>>>>>> -oldvm is a synonym for the "server" VM [deprecated] >>>>>>>>>> The default VM is server, >>>>>>>>>> because you are running on a server-class machine. >>>>>>>>>> >>>>>>>>>> which is exactly what I would expect. Why do you think there is a >> bug? >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>>>> >>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is >>>>>>>>>> expanded with: >>>>>>>>>> >>>>>>>>>> "%s/lib/%s/jli:" >>>>>>>>>> >>>>>>>>>> so it needs to account for the extra "/lib//jli:" characters - and that >>>>>>>>>> is exactly what the existing code does: >>>>>>>>>> >>>>>>>>>> + JLI_StrLen("/lib//jli:") >>>>>>>>>> >>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>>>>>>>> comment on >>>>>>>>>> the strdup would have sufficed IMO. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM >>>>>>>>>>>> To: Lindenmaier, Goetz ; Java Core >>>> Libs >>>>>>>>>>>> ; serviceability-dev >> (serviceability- >>>>>>>>>>>> dev at openjdk.java.net) >>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>>>>>>>> servicabilty >>>>>>>>>>>> coding. >>>>>>>>>>>> >>>>>>>>>>>> Goetz, >>>>>>>>>>>> >>>>>>>>>>>> SDE.c: >>>>>>>>>>>> >>>>>>>>>>>> You might combine if at ll. 260 and 263 to one but it's just >>>>>>>>>>>> matter of test. >>>>>>>>>>>> >>>>>>>>>>>> if (sti == baseStratumIndex || sti < 0) { >>>>>>>>>>>> return; /* Java stratum - return unchanged */ >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>>>>>> double-check the new webrev. >>>>>>>>>>>> >>>>>>>>>>>> if cnt is <= 0 loop at l.267 >>>>>>>>>>>> >>>>>>>>>>>> for (; cnt-- > 0; ++fromEntry) { >>>>>>>>>>>> >>>>>>>>>>>> is never run and we effectively do >>>>>>>>>>>> >>>>>>>>>>>> *entryCountPtr = 0; >>>>>>>>>>>> >>>>>>>>>>>> at l.283 >>>>>>>>>>>> >>>>>>>>>>>> So if we you suspect that cnt may become negative or 0: >>>>>>>>>>>> (your v.01 changes) >>>>>>>>>>>> >>>>>>>>>>>> 260 if (sti < 0 && cnt > 0) { >>>>>>>>>>>> 261 return; >>>>>>>>>>>> 262 } >>>>>>>>>>>> >>>>>>>>>>>> it's better to check it early. >>>>>>>>>>>> >>>>>>>>>>>> But I'm not sure we have to care about negative/zero cnt here. >>>>>>>>>>>> >>>>>>>>>>>> -Dmitry >>>>>>>>>>>> >>>>>>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>> >>>>>>>>>>>>> thanks for looking at my change! >>>>>>>>>>>>> Updated webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>> corlib_s11y/webrev.02 >>>>>>>>>>>>> >>>>>>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>>>>>>>> Is this line correct? >>>>>>>>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); >>>>>>>>>>>>> >>>>>>>>>>>>> It seems pointless. Should I remove it? (The whole file is a >>>>>>>>>>>>> horror.) >>>>>>>>>>>>> >>>>>>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>>>>>>>>>>>> It might be better to return immediately if cnt < 0, >>>>>>>>>>>>>> regardless of value of sti. >>>>>>>>>>>>> >>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>>>>>> double-check the new webrev. >>>>>>>>>>>>> >>>>>>>>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>>>>>>>>>>>> It might be better to write >>>>>>>>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>>>>>>>>>>>> and leave one copy of setsockopt() call >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, looks better. >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This change fixes some minor issues found in our code scans. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I hope this correctly addresses corelib and serviceability issues. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>>>>>>>> corlib_s11y/webrev.01/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Changes in detail: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> e_asin.c >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Code scan reports missing {}. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact >>>>>>>>>>>>>>> flag of >>>>>>>>>>>>>>> the processor. >>>>>>>>>>>>>>> It's a way to avoid the C compiler to optimize the code away. >>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>> always true, >>>>>>>>>>>>>>> so the parenthesis of the outer else don't matter. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Although this basically just adds the {} I would like to submit >>>>>>>>>>>>>>> this to >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> avoid anybody else spends more the 30sec on understanding >>>> these >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> if statements. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> k_standard.c >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> exc.retval is returned below and thus should always be >>>>>>>>>>>>>>> initialized. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> imageDecompressor.cpp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Wrong destructor is used. Reported also by David CARLIER >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> java.c >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> java_md_solinux.c >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "//" in path is useless. Further down a free is missing. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> SDE.c >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Call to stratumTableIndex can return negative value if >>>>>>>>>>>>>>> defaultStratumId >>>>>>>>>>>>>>> == null. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> socket_md.c >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is >>>>>>>>>>>>>>> hidden in >>>>>>>>>>>>>>> the macros. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> unpack.cpp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> n.slice should not get negative argument for end, which is >>>>>>>>>>>>>>> passed from >>>>>>>>>>>>>>> dollar1. >>>>>>>>>>>>>>> But dollar1 can get negative where it is set to the result of >>>>>>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Dmitry Samersoff >>>>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>>>>>>>> * I would love to change the world, but they won't give me the >>>>>>>>>>>>>> sources. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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 goetz.lindenmaier at sap.com Wed Dec 14 11:46:23 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 14 Dec 2016 11:46:23 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <1238bad1-1805-e57a-2360-196e44770521@oracle.com> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> <4834063ecbab4971bf4767e637e032a3@DEROTE13DE08.global.corp.sap> <78ebe654-8f75-3a30-dc0f-8a459aa59dbb@oracle.com> <4f2ce01887c74725b9ede388daf707be@DEROTE13DE08.global.corp.sap> <1238bad1-1805-e57a-2360-196e44770521@oracle.com> Message-ID: > object to the change to k_standard.c for the same reason. Ok, I remove that too. Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 14. Dezember 2016 12:29 > To: Lindenmaier, Goetz ; > daniel.daugherty at oracle.com; 'Dmitry Samersoff' > ; Java Core Libs dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > On 14/12/2016 9:00 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > You're right, I had removed the change to e_asin.c. > > You only pointed Joe to that file AFAICS. I would expect he would also > object to the change to k_standard.c for the same reason. > > > New webrev anyways: > > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.05/ > > > > java_md_solinux.c adds JLI_MemFree(new_jvmpath) that was missing. > > Okay. Thanks. > > David > > > Best regards, > > Goetz. > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Mittwoch, 14. Dezember 2016 11:42 > >> To: Lindenmaier, Goetz ; > >> daniel.daugherty at oracle.com; 'Dmitry Samersoff' > >> ; Java Core Libs >> dev at openjdk.java.net>; serviceability-dev (serviceability- > >> dev at openjdk.java.net) > >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > >> coding. > >> > >> On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote: > >>> Hi David, > >>> > >>> I found "8169317: [s390] Various minor bug fixes and adaptions." > >>> in jdk9/dev this morning, so I thought it has been promoted based > >>> on some older change. I waited for that quite a while because tests > >>> in jdk9/dev kept failing on s390. > >>> How can I get the information when what was promoted? This always > >>> is a wild guess for me ... as well as when what will be promoted :) > >> > >> Yeah there's no notification in the bug report of when hs pushes up to > >> dev. The changeset email is the only record of exactly when it happens. > >> > >>> Do you think the promotion will happen tonight, or will it take > >>> another week? > >> > >> hs goes through Pre-Integration Testing (PIT) before it is pushed to > >> dev. There have been delays in getting that started and so a delay in it > >> finishing and being analyzed. It may still be a couple of days. > >> > >>> I removed > >>> - JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib//jli:") > + > >>> + JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib/jli:") + > >>> from > >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ > >> > >> With that gone that file only has the jvmpath rename - which isn't > >> fixing anything. > >> > >> Joe also asked for the fdlibm changes to dropped. > >> > >> Thanks, > >> David > >> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Mittwoch, 14. Dezember 2016 11:04 > >>>> To: Lindenmaier, Goetz ; > >>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff' > >>>> ; Java Core Libs >>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>> dev at openjdk.java.net) > >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > >>>> coding. > >>>> > >>>> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote: > >>>>> Hi, > >>>>> > >>>>> 8066474 has not been promoted. > >>>> > >>>> hs has not been able to push up to dev yet. > >>>> > >>>>> I'll remove the strlen // fix for aix from this change and > >>>>> push it without it. I'd like to get this done. > >>>> > >>>> I've lost track of what is now left in this set of changes ?? > >>>> > >>>> David > >>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>> Sent: Donnerstag, 8. Dezember 2016 23:03 > >>>>>> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz > >>>>>> ; 'Dmitry Samersoff' > >>>>>> ; Java Core Libs >>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>>>> dev at openjdk.java.net) > >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > servicabilty > >>>>>> coding. > >>>>>> > >>>>>> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: > >>>>>>> On 12/8/16 1:59 PM, David Holmes wrote: > >>>>>>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: > >>>>>>>>> Hi David, > >>>>>>>>> > >>>>>>>>> thanks for looking at the change. New webrev: > >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >> corlib_s11y/webrev.04/ > >>>>>>>>> > >>>>>>>>>> src/java.base/share/native/libjli/java.c > >>>>>>>>>> As far as I can see the existing code is working perfectly fine. > >>>>>>>>> Ah, thanks for the explanation, now I got it! Removed. > >>>>>>>>> > >>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>>>>>>>> expanded with: > >>>>>>>>>> "%s/lib/%s/jli:" > >>>>>>>>> I first edited this against jdk9/hs, where the arch is gone since > >>>>>>>>> 8066474, > >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc > >>>>>>>>> but the // was not adapted. Then I moved the change to jdk9/dev > >>>> because > >>>>>>>>> I thought I have to push it there. And yes, in that coding // would > >>>>>>>>> be correct. > >>>>>>>>> So I have to wait until hs is promoted ... > >>>>>>>> > >>>>>>>> So just based on the current file, the change proposed - to remove > one > >>>>>>>> / - is not correct until the arch directory is removed. > >>>>>>> > >>>>>>> That change is already in JDK9-hs: > >>>>>>> > >>>>>>> Changeset: c14f9a7b4cab > >>>>>>> Author: erikj > >>>>>>> Date: 2016-12-05 17:55 +0100 > >>>>>>> URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab > >>>>>>> > >>>>>>> 8066474: Remove the lib/ directory from Linux and Solaris images > >>>>>>> Reviewed-by: tbell, ihse > >>>>>>> > >>>>>>> along with changesets in the jdk and hotspot repos along with a few > >>>>>>> closed repos. > >>>>>> > >>>>>> Thanks Dan. So we need to see a webrev based on latest hs code - > where > >>>>>> removing the extra / would be correct. > >>>>>> > >>>>>> David > >>>>>> ----- > >>>>>> > >>>>>>> Dan > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> David > >>>>>>>> ----- > >>>>>>>> > >>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>>>>>>>> comment on > >>>>>>>>>> the strdup would have sufficed IMO. > >>>>>>>>> Dmitry asked me to add it. But I think it's ok. > >>>>>>>>> > >>>>>>>>> Can I consider this reviewed now? I.e. could I push it once 8066474 > is > >>>>>>>>> promoted and Joe Darcy agreed? > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Goetz. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14 > >>>>>>>>>> To: Lindenmaier, Goetz ; 'Dmitry > >>>>>> Samersoff' > >>>>>>>>>> ; Java Core Libs >>>>>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>>>>>>>> dev at openjdk.java.net) > >>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>>>>>>>> servicabilty > >>>>>>>>>> coding. > >>>>>>>>>> > >>>>>>>>>> Hi Goetz, > >>>>>>>>>> > >>>>>>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: > >>>>>>>>>>> Hi Dmitry, > >>>>>>>>>>> > >>>>>>>>>>> yes, new_jvmpath is consistent with the other variables. > >>>>>>>>>>> I also merged the ifs in SDE.c. > >>>>>>>>>>> > >>>>>>>>>>> new webrev: > >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>> corlib_s11y/webrev.03/ > >>>>>>>>>> > >>>>>>>>>> src/java.base/share/native/libjli/java.c > >>>>>>>>>> > >>>>>>>>>> As far as I can see the existing code is working perfectly fine. > >>>>>>>>>> Given a > >>>>>>>>>> jvm.cfg with: > >>>>>>>>>> > >>>>>>>>>> -server KNOWN > >>>>>>>>>> -client IGNORE > >>>>>>>>>> -myvm KNOWN > >>>>>>>>>> -oldvm ALIASED_TO -server > >>>>>>>>>> > >>>>>>>>>> The usage text is: > >>>>>>>>>> > >>>>>>>>>> -server to select the "server" VM > >>>>>>>>>> -myvm to select the "myvm" VM > >>>>>>>>>> -oldvm is a synonym for the "server" VM [deprecated] > >>>>>>>>>> The default VM is server, > >>>>>>>>>> because you are running on a server-class machine. > >>>>>>>>>> > >>>>>>>>>> which is exactly what I would expect. Why do you think there is a > >> bug? > >>>>>>>>>> > >>>>>>>>>> --- > >>>>>>>>>> > >>>>>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>>>>>> > >>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>>>>>>>> expanded with: > >>>>>>>>>> > >>>>>>>>>> "%s/lib/%s/jli:" > >>>>>>>>>> > >>>>>>>>>> so it needs to account for the extra "/lib//jli:" characters - and that > >>>>>>>>>> is exactly what the existing code does: > >>>>>>>>>> > >>>>>>>>>> + JLI_StrLen("/lib//jli:") > >>>>>>>>>> > >>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>>>>>>>> comment on > >>>>>>>>>> the strdup would have sufficed IMO. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> David > >>>>>>>>>> ----- > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Best regards, > >>>>>>>>>>> Goetz. > >>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > >>>>>>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM > >>>>>>>>>>>> To: Lindenmaier, Goetz ; Java > Core > >>>> Libs > >>>>>>>>>>>> ; serviceability-dev > >> (serviceability- > >>>>>>>>>>>> dev at openjdk.java.net) > >>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>>>>>>>>>> servicabilty > >>>>>>>>>>>> coding. > >>>>>>>>>>>> > >>>>>>>>>>>> Goetz, > >>>>>>>>>>>> > >>>>>>>>>>>> SDE.c: > >>>>>>>>>>>> > >>>>>>>>>>>> You might combine if at ll. 260 and 263 to one but it's just > >>>>>>>>>>>> matter of test. > >>>>>>>>>>>> > >>>>>>>>>>>> if (sti == baseStratumIndex || sti < 0) { > >>>>>>>>>>>> return; /* Java stratum - return unchanged */ > >>>>>>>>>>>> } > >>>>>>>>>>>> > >>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>>>>>>>> double-check the new webrev. > >>>>>>>>>>>> > >>>>>>>>>>>> if cnt is <= 0 loop at l.267 > >>>>>>>>>>>> > >>>>>>>>>>>> for (; cnt-- > 0; ++fromEntry) { > >>>>>>>>>>>> > >>>>>>>>>>>> is never run and we effectively do > >>>>>>>>>>>> > >>>>>>>>>>>> *entryCountPtr = 0; > >>>>>>>>>>>> > >>>>>>>>>>>> at l.283 > >>>>>>>>>>>> > >>>>>>>>>>>> So if we you suspect that cnt may become negative or 0: > >>>>>>>>>>>> (your v.01 changes) > >>>>>>>>>>>> > >>>>>>>>>>>> 260 if (sti < 0 && cnt > 0) { > >>>>>>>>>>>> 261 return; > >>>>>>>>>>>> 262 } > >>>>>>>>>>>> > >>>>>>>>>>>> it's better to check it early. > >>>>>>>>>>>> > >>>>>>>>>>>> But I'm not sure we have to care about negative/zero cnt here. > >>>>>>>>>>>> > >>>>>>>>>>>> -Dmitry > >>>>>>>>>>>> > >>>>>>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>> Hi Dmitry, > >>>>>>>>>>>>> > >>>>>>>>>>>>> thanks for looking at my change! > >>>>>>>>>>>>> Updated webrev: > >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>>>> corlib_s11y/webrev.02 > >>>>>>>>>>>>> > >>>>>>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>>>>>>>>>> Is this line correct? > >>>>>>>>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); > >>>>>>>>>>>>> > >>>>>>>>>>>>> It seems pointless. Should I remove it? (The whole file is a > >>>>>>>>>>>>> horror.) > >>>>>>>>>>>>> > >>>>>>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > >>>>>>>>>>>>>> It might be better to return immediately if cnt < 0, > >>>>>>>>>>>>>> regardless of value of sti. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>>>>>>>> double-check the new webrev. > >>>>>>>>>>>>> > >>>>>>>>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > >>>>>>>>>>>>>> It might be better to write > >>>>>>>>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; > >>>>>>>>>>>>>> and leave one copy of setsockopt() call > >>>>>>>>>>>>> > >>>>>>>>>>>>> Yes, looks better. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>> Goetz > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -Dmitry > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> This change fixes some minor issues found in our code > scans. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I hope this correctly addresses corelib and serviceability > issues. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Please review: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>>>>>>>>>> corlib_s11y/webrev.01/ > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Changes in detail: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> e_asin.c > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Code scan reports missing {}. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact > >>>>>>>>>>>>>>> flag of > >>>>>>>>>>>>>>> the processor. > >>>>>>>>>>>>>>> It's a way to avoid the C compiler to optimize the code > away. > >>>>>>>>>>>>>>> It is > >>>>>>>>>>>>>>> always true, > >>>>>>>>>>>>>>> so the parenthesis of the outer else don't matter. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Although this basically just adds the {} I would like to submit > >>>>>>>>>>>>>>> this to > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> avoid anybody else spends more the 30sec on understanding > >>>> these > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> if statements. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> k_standard.c > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> exc.retval is returned below and thus should always be > >>>>>>>>>>>>>>> initialized. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> imageDecompressor.cpp > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Wrong destructor is used. Reported also by David CARLIER > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> java.c > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> java_md_solinux.c > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> "//" in path is useless. Further down a free is missing. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> SDE.c > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Call to stratumTableIndex can return negative value if > >>>>>>>>>>>>>>> defaultStratumId > >>>>>>>>>>>>>>> == null. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> socket_md.c > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is > >>>>>>>>>>>>>>> hidden in > >>>>>>>>>>>>>>> the macros. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> unpack.cpp > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> n.slice should not get negative argument for end, which is > >>>>>>>>>>>>>>> passed from > >>>>>>>>>>>>>>> dollar1. > >>>>>>>>>>>>>>> But dollar1 can get negative where it is set to the result of > >>>>>>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -- > >>>>>>>>>>>>>> Dmitry Samersoff > >>>>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia > >>>>>>>>>>>>>> * I would love to change the world, but they won't give me > the > >>>>>>>>>>>>>> sources. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> -- > >>>>>>>>>>>> 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 lois.foltan at oracle.com Wed Dec 14 13:18:01 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 14 Dec 2016 08:18:01 -0500 Subject: RFR (XXS): 8171226 simple typo in the JVMTI spec In-Reply-To: <16701c81-4061-2e98-fead-a77a138d5db3@oracle.com> References: <16701c81-4061-2e98-fead-a77a138d5db3@oracle.com> Message-ID: <58514689.1040106@oracle.com> Looks good. Lois On 12/14/2016 5:30 AM, serguei.spitsyn at oracle.com wrote: > Need one reviewer for a trivial typo fix in the JVMTI spec: > https://bugs.openjdk.java.net/browse/JDK-8171226 > > > The suggested fix is ("bot" => "not"): > > --- a/src/share/vm/prims/jvmti.xml Thu Dec 08 15:49:29 2016 +0100 > +++ b/src/share/vm/prims/jvmti.xml Wed Dec 14 02:24:51 2016 -0800 > @@ -3370,7 +3370,7 @@ > > > Reference from a class to its superclass. > - A callback is bot sent if the superclass is > java.lang.Object. > + A callback is not sent if the superclass is > java.lang.Object. > Note: loaded classes define superclasses via a constant pool > reference, so the referenced superclass may also be > reported with > a JVMTI_HEAP_REFERENCE_CONSTANT_POOL > reference kind. > > > Thanks, > Serguei From serguei.spitsyn at oracle.com Wed Dec 14 17:00:51 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 14 Dec 2016 09:00:51 -0800 Subject: RFR (XXS): 8171226 simple typo in the JVMTI spec In-Reply-To: <58514689.1040106@oracle.com> References: <16701c81-4061-2e98-fead-a77a138d5db3@oracle.com> <58514689.1040106@oracle.com> Message-ID: <60cda9d2-94af-1224-f1aa-5e1b49bac4ba@oracle.com> Thank you, Lois! I can't add you as a reviewer as the fix has been already pushed by the trivial fix rule. Thanks, Serguei On 12/14/16 05:18, Lois Foltan wrote: > Looks good. > Lois > > On 12/14/2016 5:30 AM, serguei.spitsyn at oracle.com wrote: >> Need one reviewer for a trivial typo fix in the JVMTI spec: >> https://bugs.openjdk.java.net/browse/JDK-8171226 >> >> >> The suggested fix is ("bot" => "not"): >> >> --- a/src/share/vm/prims/jvmti.xml Thu Dec 08 15:49:29 2016 +0100 >> +++ b/src/share/vm/prims/jvmti.xml Wed Dec 14 02:24:51 2016 -0800 >> @@ -3370,7 +3370,7 @@ >> >> >> Reference from a class to its superclass. >> - A callback is bot sent if the superclass is >> java.lang.Object. >> + A callback is not sent if the superclass is >> java.lang.Object. >> Note: loaded classes define superclasses via a constant >> pool >> reference, so the referenced superclass may also be >> reported with >> a JVMTI_HEAP_REFERENCE_CONSTANT_POOL >> reference kind. >> >> >> Thanks, >> Serguei > From david.holmes at oracle.com Wed Dec 14 20:54:36 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Dec 2016 06:54:36 +1000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> <4834063ecbab4971bf4767e637e032a3@DEROTE13DE08.global.corp.sap> <78ebe654-8f75-3a30-dc0f-8a459aa59dbb@oracle.com> <4f2ce01887c74725b9ede388daf707be@DEROTE13DE08.global.corp.sap> <1238bad1-1805-e57a-2360-196e44770521@oracle.com> Message-ID: <3072c9a4-f810-4abf-0f8e-3b025af92b3e@oracle.com> Hi Goetz, On 14/12/2016 9:46 PM, Lindenmaier, Goetz wrote: > >> object to the change to k_standard.c for the same reason. > Ok, I remove that too. I had not realized this was to be pushed directly to jdk9/dev. It broke builds on Solaris and so was obviously not tested. David > Best regards, > Goetz. > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 14. Dezember 2016 12:29 >> To: Lindenmaier, Goetz ; >> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >> ; Java Core Libs > dev at openjdk.java.net>; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >> coding. >> >> On 14/12/2016 9:00 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> You're right, I had removed the change to e_asin.c. >> >> You only pointed Joe to that file AFAICS. I would expect he would also >> object to the change to k_standard.c for the same reason. >> >>> New webrev anyways: >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.05/ >>> >>> java_md_solinux.c adds JLI_MemFree(new_jvmpath) that was missing. >> >> Okay. Thanks. >> >> David >> >>> Best regards, >>> Goetz. >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Mittwoch, 14. Dezember 2016 11:42 >>>> To: Lindenmaier, Goetz ; >>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >>>> ; Java Core Libs >>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>> dev at openjdk.java.net) >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >>>> coding. >>>> >>>> On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> I found "8169317: [s390] Various minor bug fixes and adaptions." >>>>> in jdk9/dev this morning, so I thought it has been promoted based >>>>> on some older change. I waited for that quite a while because tests >>>>> in jdk9/dev kept failing on s390. >>>>> How can I get the information when what was promoted? This always >>>>> is a wild guess for me ... as well as when what will be promoted :) >>>> >>>> Yeah there's no notification in the bug report of when hs pushes up to >>>> dev. The changeset email is the only record of exactly when it happens. >>>> >>>>> Do you think the promotion will happen tonight, or will it take >>>>> another week? >>>> >>>> hs goes through Pre-Integration Testing (PIT) before it is pushed to >>>> dev. There have been delays in getting that started and so a delay in it >>>> finishing and being analyzed. It may still be a couple of days. >>>> >>>>> I removed >>>>> - JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib//jli:") >> + >>>>> + JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib/jli:") + >>>>> from >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ >>>> >>>> With that gone that file only has the jvmpath rename - which isn't >>>> fixing anything. >>>> >>>> Joe also asked for the fdlibm changes to dropped. >>>> >>>> Thanks, >>>> David >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Mittwoch, 14. Dezember 2016 11:04 >>>>>> To: Lindenmaier, Goetz ; >>>>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >>>>>> ; Java Core Libs >>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>> dev at openjdk.java.net) >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >>>>>> coding. >>>>>> >>>>>> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> 8066474 has not been promoted. >>>>>> >>>>>> hs has not been able to push up to dev yet. >>>>>> >>>>>>> I'll remove the strlen // fix for aix from this change and >>>>>>> push it without it. I'd like to get this done. >>>>>> >>>>>> I've lost track of what is now left in this set of changes ?? >>>>>> >>>>>> David >>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Donnerstag, 8. Dezember 2016 23:03 >>>>>>>> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz >>>>>>>> ; 'Dmitry Samersoff' >>>>>>>> ; Java Core Libs >>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>>>> dev at openjdk.java.net) >>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >> servicabilty >>>>>>>> coding. >>>>>>>> >>>>>>>> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: >>>>>>>>> On 12/8/16 1:59 PM, David Holmes wrote: >>>>>>>>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> thanks for looking at the change. New webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>> corlib_s11y/webrev.04/ >>>>>>>>>>> >>>>>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>>>>> As far as I can see the existing code is working perfectly fine. >>>>>>>>>>> Ah, thanks for the explanation, now I got it! Removed. >>>>>>>>>>> >>>>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is >>>>>>>>>>>> expanded with: >>>>>>>>>>>> "%s/lib/%s/jli:" >>>>>>>>>>> I first edited this against jdk9/hs, where the arch is gone since >>>>>>>>>>> 8066474, >>>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc >>>>>>>>>>> but the // was not adapted. Then I moved the change to jdk9/dev >>>>>> because >>>>>>>>>>> I thought I have to push it there. And yes, in that coding // would >>>>>>>>>>> be correct. >>>>>>>>>>> So I have to wait until hs is promoted ... >>>>>>>>>> >>>>>>>>>> So just based on the current file, the change proposed - to remove >> one >>>>>>>>>> / - is not correct until the arch directory is removed. >>>>>>>>> >>>>>>>>> That change is already in JDK9-hs: >>>>>>>>> >>>>>>>>> Changeset: c14f9a7b4cab >>>>>>>>> Author: erikj >>>>>>>>> Date: 2016-12-05 17:55 +0100 >>>>>>>>> URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab >>>>>>>>> >>>>>>>>> 8066474: Remove the lib/ directory from Linux and Solaris images >>>>>>>>> Reviewed-by: tbell, ihse >>>>>>>>> >>>>>>>>> along with changesets in the jdk and hotspot repos along with a few >>>>>>>>> closed repos. >>>>>>>> >>>>>>>> Thanks Dan. So we need to see a webrev based on latest hs code - >> where >>>>>>>> removing the extra / would be correct. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>>>>>>>>>> comment on >>>>>>>>>>>> the strdup would have sufficed IMO. >>>>>>>>>>> Dmitry asked me to add it. But I think it's ok. >>>>>>>>>>> >>>>>>>>>>> Can I consider this reviewed now? I.e. could I push it once 8066474 >> is >>>>>>>>>>> promoted and Joe Darcy agreed? >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14 >>>>>>>>>>>> To: Lindenmaier, Goetz ; 'Dmitry >>>>>>>> Samersoff' >>>>>>>>>>>> ; Java Core Libs >>>>>>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>>>>>>>> dev at openjdk.java.net) >>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>>>>>>>> servicabilty >>>>>>>>>>>> coding. >>>>>>>>>>>> >>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>> >>>>>>>>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>> >>>>>>>>>>>>> yes, new_jvmpath is consistent with the other variables. >>>>>>>>>>>>> I also merged the ifs in SDE.c. >>>>>>>>>>>>> >>>>>>>>>>>>> new webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>> corlib_s11y/webrev.03/ >>>>>>>>>>>> >>>>>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>>>>> >>>>>>>>>>>> As far as I can see the existing code is working perfectly fine. >>>>>>>>>>>> Given a >>>>>>>>>>>> jvm.cfg with: >>>>>>>>>>>> >>>>>>>>>>>> -server KNOWN >>>>>>>>>>>> -client IGNORE >>>>>>>>>>>> -myvm KNOWN >>>>>>>>>>>> -oldvm ALIASED_TO -server >>>>>>>>>>>> >>>>>>>>>>>> The usage text is: >>>>>>>>>>>> >>>>>>>>>>>> -server to select the "server" VM >>>>>>>>>>>> -myvm to select the "myvm" VM >>>>>>>>>>>> -oldvm is a synonym for the "server" VM [deprecated] >>>>>>>>>>>> The default VM is server, >>>>>>>>>>>> because you are running on a server-class machine. >>>>>>>>>>>> >>>>>>>>>>>> which is exactly what I would expect. Why do you think there is a >>>> bug? >>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>>>>>> >>>>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is >>>>>>>>>>>> expanded with: >>>>>>>>>>>> >>>>>>>>>>>> "%s/lib/%s/jli:" >>>>>>>>>>>> >>>>>>>>>>>> so it needs to account for the extra "/lib//jli:" characters - and that >>>>>>>>>>>> is exactly what the existing code does: >>>>>>>>>>>> >>>>>>>>>>>> + JLI_StrLen("/lib//jli:") >>>>>>>>>>>> >>>>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>>>>>>>>>> comment on >>>>>>>>>>>> the strdup would have sufficed IMO. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM >>>>>>>>>>>>>> To: Lindenmaier, Goetz ; Java >> Core >>>>>> Libs >>>>>>>>>>>>>> ; serviceability-dev >>>> (serviceability- >>>>>>>>>>>>>> dev at openjdk.java.net) >>>>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>>>>>>>>>> servicabilty >>>>>>>>>>>>>> coding. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Goetz, >>>>>>>>>>>>>> >>>>>>>>>>>>>> SDE.c: >>>>>>>>>>>>>> >>>>>>>>>>>>>> You might combine if at ll. 260 and 263 to one but it's just >>>>>>>>>>>>>> matter of test. >>>>>>>>>>>>>> >>>>>>>>>>>>>> if (sti == baseStratumIndex || sti < 0) { >>>>>>>>>>>>>> return; /* Java stratum - return unchanged */ >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>>>>>>>> double-check the new webrev. >>>>>>>>>>>>>> >>>>>>>>>>>>>> if cnt is <= 0 loop at l.267 >>>>>>>>>>>>>> >>>>>>>>>>>>>> for (; cnt-- > 0; ++fromEntry) { >>>>>>>>>>>>>> >>>>>>>>>>>>>> is never run and we effectively do >>>>>>>>>>>>>> >>>>>>>>>>>>>> *entryCountPtr = 0; >>>>>>>>>>>>>> >>>>>>>>>>>>>> at l.283 >>>>>>>>>>>>>> >>>>>>>>>>>>>> So if we you suspect that cnt may become negative or 0: >>>>>>>>>>>>>> (your v.01 changes) >>>>>>>>>>>>>> >>>>>>>>>>>>>> 260 if (sti < 0 && cnt > 0) { >>>>>>>>>>>>>> 261 return; >>>>>>>>>>>>>> 262 } >>>>>>>>>>>>>> >>>>>>>>>>>>>> it's better to check it early. >>>>>>>>>>>>>> >>>>>>>>>>>>>> But I'm not sure we have to care about negative/zero cnt here. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> thanks for looking at my change! >>>>>>>>>>>>>>> Updated webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>>>> corlib_s11y/webrev.02 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>>>>>>>>>> Is this line correct? >>>>>>>>>>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It seems pointless. Should I remove it? (The whole file is a >>>>>>>>>>>>>>> horror.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>>>>>>>>>>>>>> It might be better to return immediately if cnt < 0, >>>>>>>>>>>>>>>> regardless of value of sti. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>>>>>>>> double-check the new webrev. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>>>>>>>>>>>>>> It might be better to write >>>>>>>>>>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>>>>>>>>>>>>>> and leave one copy of setsockopt() call >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, looks better. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Goetz >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This change fixes some minor issues found in our code >> scans. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I hope this correctly addresses corelib and serviceability >> issues. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please review: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>>>>>>>>>> corlib_s11y/webrev.01/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Changes in detail: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> e_asin.c >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Code scan reports missing {}. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact >>>>>>>>>>>>>>>>> flag of >>>>>>>>>>>>>>>>> the processor. >>>>>>>>>>>>>>>>> It's a way to avoid the C compiler to optimize the code >> away. >>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>> always true, >>>>>>>>>>>>>>>>> so the parenthesis of the outer else don't matter. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Although this basically just adds the {} I would like to submit >>>>>>>>>>>>>>>>> this to >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> avoid anybody else spends more the 30sec on understanding >>>>>> these >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> if statements. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> k_standard.c >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> exc.retval is returned below and thus should always be >>>>>>>>>>>>>>>>> initialized. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> imageDecompressor.cpp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Wrong destructor is used. Reported also by David CARLIER >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> java.c >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> java_md_solinux.c >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> "//" in path is useless. Further down a free is missing. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> SDE.c >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Call to stratumTableIndex can return negative value if >>>>>>>>>>>>>>>>> defaultStratumId >>>>>>>>>>>>>>>>> == null. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> socket_md.c >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is >>>>>>>>>>>>>>>>> hidden in >>>>>>>>>>>>>>>>> the macros. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> unpack.cpp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> n.slice should not get negative argument for end, which is >>>>>>>>>>>>>>>>> passed from >>>>>>>>>>>>>>>>> dollar1. >>>>>>>>>>>>>>>>> But dollar1 can get negative where it is set to the result of >>>>>>>>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Dmitry Samersoff >>>>>>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>>>>>>>>>> * I would love to change the world, but they won't give me >> the >>>>>>>>>>>>>>>> sources. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 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 goetz.lindenmaier at sap.com Thu Dec 15 06:55:06 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 15 Dec 2016 06:55:06 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <3072c9a4-f810-4abf-0f8e-3b025af92b3e@oracle.com> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> <4834063ecbab4971bf4767e637e032a3@DEROTE13DE08.global.corp.sap> <78ebe654-8f75-3a30-dc0f-8a459aa59dbb@oracle.com> <4f2ce01887c74725b9ede388daf707be@DEROTE13DE08.global.corp.sap> <1238bad1-1805-e57a-2360-196e44770521@oracle.com> <3072c9a4-f810-4abf-0f8e-3b025af92b3e@oracle.com> Message-ID: <213d5bb18a90421f9e1fe2dbaa59db17@DEROTE13DE08.global.corp.sap> Hi, I'm sorry for that. Our solaris builds were fine. I saw the fix. Thanks Erik for fixing! I thought windows was the last platform not to support declarations in the code. Do you mind sharing what compiler choked on this? Maybe we can setup our build accordingly. And, is there a wiki page that describes which files are owned by which mailing list, and to which repo to push the corresponding changes? I've no idea on the jdk side where to post etc. Opening up jprt will be a great step forward! Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Wednesday, December 14, 2016 9:55 PM > To: Lindenmaier, Goetz ; > daniel.daugherty at oracle.com; 'Dmitry Samersoff' > ; Java Core Libs dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > Hi Goetz, > > On 14/12/2016 9:46 PM, Lindenmaier, Goetz wrote: > > > >> object to the change to k_standard.c for the same reason. > > Ok, I remove that too. > > I had not realized this was to be pushed directly to jdk9/dev. It broke > builds on Solaris and so was obviously not tested. > > David > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Mittwoch, 14. Dezember 2016 12:29 > >> To: Lindenmaier, Goetz ; > >> daniel.daugherty at oracle.com; 'Dmitry Samersoff' > >> ; Java Core Libs >> dev at openjdk.java.net>; serviceability-dev (serviceability- > >> dev at openjdk.java.net) > >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > >> coding. > >> > >> On 14/12/2016 9:00 PM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> You're right, I had removed the change to e_asin.c. > >> > >> You only pointed Joe to that file AFAICS. I would expect he would also > >> object to the change to k_standard.c for the same reason. > >> > >>> New webrev anyways: > >>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > corlib_s11y/webrev.05/ > >>> > >>> java_md_solinux.c adds JLI_MemFree(new_jvmpath) that was missing. > >> > >> Okay. Thanks. > >> > >> David > >> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Mittwoch, 14. Dezember 2016 11:42 > >>>> To: Lindenmaier, Goetz ; > >>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff' > >>>> ; Java Core Libs >>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>> dev at openjdk.java.net) > >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > servicabilty > >>>> coding. > >>>> > >>>> On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote: > >>>>> Hi David, > >>>>> > >>>>> I found "8169317: [s390] Various minor bug fixes and adaptions." > >>>>> in jdk9/dev this morning, so I thought it has been promoted based > >>>>> on some older change. I waited for that quite a while because tests > >>>>> in jdk9/dev kept failing on s390. > >>>>> How can I get the information when what was promoted? This always > >>>>> is a wild guess for me ... as well as when what will be promoted :) > >>>> > >>>> Yeah there's no notification in the bug report of when hs pushes up to > >>>> dev. The changeset email is the only record of exactly when it happens. > >>>> > >>>>> Do you think the promotion will happen tonight, or will it take > >>>>> another week? > >>>> > >>>> hs goes through Pre-Integration Testing (PIT) before it is pushed to > >>>> dev. There have been delays in getting that started and so a delay in it > >>>> finishing and being analyzed. It may still be a couple of days. > >>>> > >>>>> I removed > >>>>> - JLI_StrLen(jrepath) + JLI_StrLen(arch) + > JLI_StrLen("/lib//jli:") > >> + > >>>>> + JLI_StrLen(jrepath) + JLI_StrLen(arch) + > JLI_StrLen("/lib/jli:") + > >>>>> from > >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > corlib_s11y/webrev.04/ > >>>> > >>>> With that gone that file only has the jvmpath rename - which isn't > >>>> fixing anything. > >>>> > >>>> Joe also asked for the fdlibm changes to dropped. > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>> Sent: Mittwoch, 14. Dezember 2016 11:04 > >>>>>> To: Lindenmaier, Goetz ; > >>>>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff' > >>>>>> ; Java Core Libs >>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>>>> dev at openjdk.java.net) > >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > servicabilty > >>>>>> coding. > >>>>>> > >>>>>> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> 8066474 has not been promoted. > >>>>>> > >>>>>> hs has not been able to push up to dev yet. > >>>>>> > >>>>>>> I'll remove the strlen // fix for aix from this change and > >>>>>>> push it without it. I'd like to get this done. > >>>>>> > >>>>>> I've lost track of what is now left in this set of changes ?? > >>>>>> > >>>>>> David > >>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz. > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>> Sent: Donnerstag, 8. Dezember 2016 23:03 > >>>>>>>> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz > >>>>>>>> ; 'Dmitry Samersoff' > >>>>>>>> ; Java Core Libs >>>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>>>>>> dev at openjdk.java.net) > >>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >> servicabilty > >>>>>>>> coding. > >>>>>>>> > >>>>>>>> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: > >>>>>>>>> On 12/8/16 1:59 PM, David Holmes wrote: > >>>>>>>>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: > >>>>>>>>>>> Hi David, > >>>>>>>>>>> > >>>>>>>>>>> thanks for looking at the change. New webrev: > >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>> corlib_s11y/webrev.04/ > >>>>>>>>>>> > >>>>>>>>>>>> src/java.base/share/native/libjli/java.c > >>>>>>>>>>>> As far as I can see the existing code is working perfectly fine. > >>>>>>>>>>> Ah, thanks for the explanation, now I got it! Removed. > >>>>>>>>>>> > >>>>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output > string is > >>>>>>>>>>>> expanded with: > >>>>>>>>>>>> "%s/lib/%s/jli:" > >>>>>>>>>>> I first edited this against jdk9/hs, where the arch is gone since > >>>>>>>>>>> 8066474, > >>>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc > >>>>>>>>>>> but the // was not adapted. Then I moved the change to > jdk9/dev > >>>>>> because > >>>>>>>>>>> I thought I have to push it there. And yes, in that coding // > would > >>>>>>>>>>> be correct. > >>>>>>>>>>> So I have to wait until hs is promoted ... > >>>>>>>>>> > >>>>>>>>>> So just based on the current file, the change proposed - to > remove > >> one > >>>>>>>>>> / - is not correct until the arch directory is removed. > >>>>>>>>> > >>>>>>>>> That change is already in JDK9-hs: > >>>>>>>>> > >>>>>>>>> Changeset: c14f9a7b4cab > >>>>>>>>> Author: erikj > >>>>>>>>> Date: 2016-12-05 17:55 +0100 > >>>>>>>>> URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab > >>>>>>>>> > >>>>>>>>> 8066474: Remove the lib/ directory from Linux and Solaris > images > >>>>>>>>> Reviewed-by: tbell, ihse > >>>>>>>>> > >>>>>>>>> along with changesets in the jdk and hotspot repos along with a > few > >>>>>>>>> closed repos. > >>>>>>>> > >>>>>>>> Thanks Dan. So we need to see a webrev based on latest hs code - > >> where > >>>>>>>> removing the extra / would be correct. > >>>>>>>> > >>>>>>>> David > >>>>>>>> ----- > >>>>>>>> > >>>>>>>>> Dan > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> David > >>>>>>>>>> ----- > >>>>>>>>>> > >>>>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - > a > >>>>>>>>>>>> comment on > >>>>>>>>>>>> the strdup would have sufficed IMO. > >>>>>>>>>>> Dmitry asked me to add it. But I think it's ok. > >>>>>>>>>>> > >>>>>>>>>>> Can I consider this reviewed now? I.e. could I push it once > 8066474 > >> is > >>>>>>>>>>> promoted and Joe Darcy agreed? > >>>>>>>>>>> > >>>>>>>>>>> Best regards, > >>>>>>>>>>> Goetz. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14 > >>>>>>>>>>>> To: Lindenmaier, Goetz ; > 'Dmitry > >>>>>>>> Samersoff' > >>>>>>>>>>>> ; Java Core Libs >>>>>>>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>>>>>>>>>> dev at openjdk.java.net) > >>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>>>>>>>>>> servicabilty > >>>>>>>>>>>> coding. > >>>>>>>>>>>> > >>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>> > >>>>>>>>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>> Hi Dmitry, > >>>>>>>>>>>>> > >>>>>>>>>>>>> yes, new_jvmpath is consistent with the other variables. > >>>>>>>>>>>>> I also merged the ifs in SDE.c. > >>>>>>>>>>>>> > >>>>>>>>>>>>> new webrev: > >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>>>> corlib_s11y/webrev.03/ > >>>>>>>>>>>> > >>>>>>>>>>>> src/java.base/share/native/libjli/java.c > >>>>>>>>>>>> > >>>>>>>>>>>> As far as I can see the existing code is working perfectly fine. > >>>>>>>>>>>> Given a > >>>>>>>>>>>> jvm.cfg with: > >>>>>>>>>>>> > >>>>>>>>>>>> -server KNOWN > >>>>>>>>>>>> -client IGNORE > >>>>>>>>>>>> -myvm KNOWN > >>>>>>>>>>>> -oldvm ALIASED_TO -server > >>>>>>>>>>>> > >>>>>>>>>>>> The usage text is: > >>>>>>>>>>>> > >>>>>>>>>>>> -server to select the "server" VM > >>>>>>>>>>>> -myvm to select the "myvm" VM > >>>>>>>>>>>> -oldvm is a synonym for the "server" VM [deprecated] > >>>>>>>>>>>> The default VM is server, > >>>>>>>>>>>> because you are running on a server-class machine. > >>>>>>>>>>>> > >>>>>>>>>>>> which is exactly what I would expect. Why do you think there > is a > >>>> bug? > >>>>>>>>>>>> > >>>>>>>>>>>> --- > >>>>>>>>>>>> > >>>>>>>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>>>>>>>> > >>>>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output > string is > >>>>>>>>>>>> expanded with: > >>>>>>>>>>>> > >>>>>>>>>>>> "%s/lib/%s/jli:" > >>>>>>>>>>>> > >>>>>>>>>>>> so it needs to account for the extra "/lib//jli:" characters - > and that > >>>>>>>>>>>> is exactly what the existing code does: > >>>>>>>>>>>> > >>>>>>>>>>>> + JLI_StrLen("/lib//jli:") > >>>>>>>>>>>> > >>>>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - > a > >>>>>>>>>>>> comment on > >>>>>>>>>>>> the strdup would have sufficed IMO. > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks, > >>>>>>>>>>>> David > >>>>>>>>>>>> ----- > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>> > >>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>> From: Dmitry Samersoff > [mailto:dmitry.samersoff at oracle.com] > >>>>>>>>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM > >>>>>>>>>>>>>> To: Lindenmaier, Goetz ; > Java > >> Core > >>>>>> Libs > >>>>>>>>>>>>>> ; serviceability-dev > >>>> (serviceability- > >>>>>>>>>>>>>> dev at openjdk.java.net) dev at openjdk.java.net> > >>>>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib > and > >>>>>>>>>>>>>> servicabilty > >>>>>>>>>>>>>> coding. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Goetz, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> SDE.c: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> You might combine if at ll. 260 and 263 to one but it's just > >>>>>>>>>>>>>> matter of test. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> if (sti == baseStratumIndex || sti < 0) { > >>>>>>>>>>>>>> return; /* Java stratum - return unchanged */ > >>>>>>>>>>>>>> } > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>>>>>>>>>> double-check the new webrev. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> if cnt is <= 0 loop at l.267 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> for (; cnt-- > 0; ++fromEntry) { > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> is never run and we effectively do > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> *entryCountPtr = 0; > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> at l.283 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> So if we you suspect that cnt may become negative or 0: > >>>>>>>>>>>>>> (your v.01 changes) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 260 if (sti < 0 && cnt > 0) { > >>>>>>>>>>>>>> 261 return; > >>>>>>>>>>>>>> 262 } > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> it's better to check it early. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> But I'm not sure we have to care about negative/zero cnt > here. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -Dmitry > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>> Hi Dmitry, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> thanks for looking at my change! > >>>>>>>>>>>>>>> Updated webrev: > >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>>>>>> corlib_s11y/webrev.02 > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>>>>>>>>>>>> Is this line correct? > >>>>>>>>>>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> It seems pointless. Should I remove it? (The whole file is a > >>>>>>>>>>>>>>> horror.) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > >>>>>>>>>>>>>>>> It might be better to return immediately if cnt < 0, > >>>>>>>>>>>>>>>> regardless of value of sti. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>>>>>>>>>> double-check the new webrev. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> * > src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > >>>>>>>>>>>>>>>> It might be better to write > >>>>>>>>>>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; > >>>>>>>>>>>>>>>> and leave one copy of setsockopt() call > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Yes, looks better. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>> Goetz > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> -Dmitry > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> This change fixes some minor issues found in our code > >> scans. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I hope this correctly addresses corelib and serviceability > >> issues. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Please review: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>>>>>>>>>>>> corlib_s11y/webrev.01/ > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Changes in detail: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> e_asin.c > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Code scan reports missing {}. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the > inexact > >>>>>>>>>>>>>>>>> flag of > >>>>>>>>>>>>>>>>> the processor. > >>>>>>>>>>>>>>>>> It's a way to avoid the C compiler to optimize the code > >> away. > >>>>>>>>>>>>>>>>> It is > >>>>>>>>>>>>>>>>> always true, > >>>>>>>>>>>>>>>>> so the parenthesis of the outer else don't matter. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Although this basically just adds the {} I would like to > submit > >>>>>>>>>>>>>>>>> this to > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> avoid anybody else spends more the 30sec on > understanding > >>>>>> these > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> if statements. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> k_standard.c > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> exc.retval is returned below and thus should always be > >>>>>>>>>>>>>>>>> initialized. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> imageDecompressor.cpp > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Wrong destructor is used. Reported also by David > CARLIER > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> java.c > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> java_md_solinux.c > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> "//" in path is useless. Further down a free is missing. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> SDE.c > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Call to stratumTableIndex can return negative value if > >>>>>>>>>>>>>>>>> defaultStratumId > >>>>>>>>>>>>>>>>> == null. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> socket_md.c > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use > is > >>>>>>>>>>>>>>>>> hidden in > >>>>>>>>>>>>>>>>> the macros. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> unpack.cpp > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> n.slice should not get negative argument for end, which > is > >>>>>>>>>>>>>>>>> passed from > >>>>>>>>>>>>>>>>> dollar1. > >>>>>>>>>>>>>>>>> But dollar1 can get negative where it is set to the result > of > >>>>>>>>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>> Dmitry Samersoff > >>>>>>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia > >>>>>>>>>>>>>>>> * I would love to change the world, but they won't give > me > >> the > >>>>>>>>>>>>>>>> sources. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -- > >>>>>>>>>>>>>> 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 serguei.spitsyn at oracle.com Thu Dec 15 07:05:57 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 14 Dec 2016 23:05:57 -0800 Subject: RFR(XS): 8139566 need proper sync for adding default read edges In-Reply-To: <409c2fd2-89b6-0fb5-b9d3-cb43780cadf1@oracle.com> References: <409c2fd2-89b6-0fb5-b9d3-cb43780cadf1@oracle.com> Message-ID: <9012dccf-74ca-b182-9710-c340058b6c9d@oracle.com> On 12/14/16 02:01, serguei.spitsyn at oracle.com wrote: > Please, review a fix for the bug: > https://bugs.openjdk.java.net/browse/JDK-8139566 > > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8139566-SyncDefReadEdges.hs1/ > The webrev where a review comment from Lois has been resolved: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8139566-SyncDefReadEdges.hs2/ Thanks, Serguei > > > There are already two positive (preliminary) reviews from Harold and > Lois. > > > Summary: > This is a follow-up issue after the fixes for: > https://bugs.openjdk.java.net/browse/JDK-8134950 > https://bugs.openjdk.java.net/browse/JDK-8072745 > > The webrevs for the issues above are: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8134950-JVMTI-jake-ana2.3/ > > http://cr.openjdk.java.net/%7Esspitsyn/webrevs/2015/hotspot/8072745-JVMTI-jake-ana1.5/ > > > The issue is that there can be a race with another thread that > checks the > ModuleEntry::has_default_read_edges() and goes with its > redefinition/retransformation > while the upcall to the method > jdk.internal.module.Modules.transformedByAgent() > (that adds the default read edges to bootstrap and app class > loaders) is still in progress. > The instrumented code can execute while the upcall to > transformedByAgent has not been completed yet. > Please, refer to the bug description to get more details. > > The fix is to check the ModuleEntry::has_default_read_edges() in > such a case. > The check is added to the ModuleEntry::can_read as it is used in all > class resolution cases, for instance: > > LinkResolver::check_klass_accessability() -> > Reflection::verify_class_access() -> > ModuleEntry::can_read() > > ClassFileParser::check_super_class_access() -> > Reflection::verify_class_access() -> > ModuleEntry::can_read() > > ClassFileParser::check_super_interface_access() -> > Reflection::verify_class_access() -> > ModuleEntry::can_read() > > Note that the ModuleEntry::_has_default_read_edges bit was added as > a part > of the 8144950 to avoid a bad recursion. > > One question is: > Q1: Can we remove the upcall to the > jdk.internal.module.Modules.transformedByAgent() > as it would not be needed anymore? The implementation could me > simplified. > > A1: I think, the real read edges established via an upcall to the > Java runtime are still > needed for the Java level based mechanisms that do not use the > ModuleEntry::can_read(). > These mechanisms, probably, can tolerate that the "adding to a > module default read edges" > signal arrives with some latency. > > > Thanks, > Serguei From david.holmes at oracle.com Thu Dec 15 08:28:55 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Dec 2016 18:28:55 +1000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <213d5bb18a90421f9e1fe2dbaa59db17@DEROTE13DE08.global.corp.sap> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> <4834063ecbab4971bf4767e637e032a3@DEROTE13DE08.global.corp.sap> <78ebe654-8f75-3a30-dc0f-8a459aa59dbb@oracle.com> <4f2ce01887c74725b9ede388daf707be@DEROTE13DE08.global.corp.sap> <1238bad1-1805-e57a-2360-196e44770521@oracle.com> <3072c9a4-f810-4abf-0f8e-3b025af92b3e@oracle.com> <213d5bb18a90421f9e1fe2dbaa59db17@DEROTE13DE08.global.corp.sap> Message-ID: <6c59f87f-3cb9-c20c-4ff8-9beb62b72d90@oracle.com> Hi Goetz, On 15/12/2016 4:55 PM, Lindenmaier, Goetz wrote: > Hi, > > I'm sorry for that. Our solaris builds were fine. > I saw the fix. Thanks Erik for fixing! I thought > windows was the last platform not to support > declarations in the code. Me too! And I'm sure we have declarations all over the place in hotspot. But this isn't hotspot code ... > Do you mind sharing what compiler choked on this? > Maybe we can setup our build accordingly. Solaris Studio 12u4 is our official compiler for JDK 9. Seems the problem is caused by the use of -xc99=%none which generates a warning: warning: declaration can not follow a statement which warnings-as-errors seems to turn into: /scratch/dh198349/jdk9-dev/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", line 519: error: declaration can not follow a statement (E_DECLARATION_IN_CODE) > And, is there a wiki page that describes which > files are owned by which mailing list, and to which > repo to push the corresponding changes? I've no > idea on the jdk side where to post etc. Not in detail. Different files are owned by different OpenJDK groups - and each group has its mailing list(s). The main four would be: http://openjdk.java.net/groups/build http://openjdk.java.net/groups/core-libs http://openjdk.java.net/groups/hotspot http://openjdk.java.net/groups/serviceability > Opening up jprt will be a great step forward! Yes indeed! Thanks, David > Best regards, > Goetz. > > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Wednesday, December 14, 2016 9:55 PM >> To: Lindenmaier, Goetz ; >> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >> ; Java Core Libs > dev at openjdk.java.net>; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >> coding. >> >> Hi Goetz, >> >> On 14/12/2016 9:46 PM, Lindenmaier, Goetz wrote: >>> >>>> object to the change to k_standard.c for the same reason. >>> Ok, I remove that too. >> >> I had not realized this was to be pushed directly to jdk9/dev. It broke >> builds on Solaris and so was obviously not tested. >> >> David >> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Mittwoch, 14. Dezember 2016 12:29 >>>> To: Lindenmaier, Goetz ; >>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >>>> ; Java Core Libs >>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>> dev at openjdk.java.net) >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >>>> coding. >>>> >>>> On 14/12/2016 9:00 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> You're right, I had removed the change to e_asin.c. >>>> >>>> You only pointed Joe to that file AFAICS. I would expect he would also >>>> object to the change to k_standard.c for the same reason. >>>> >>>>> New webrev anyways: >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >> corlib_s11y/webrev.05/ >>>>> >>>>> java_md_solinux.c adds JLI_MemFree(new_jvmpath) that was missing. >>>> >>>> Okay. Thanks. >>>> >>>> David >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Mittwoch, 14. Dezember 2016 11:42 >>>>>> To: Lindenmaier, Goetz ; >>>>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >>>>>> ; Java Core Libs >>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>> dev at openjdk.java.net) >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >> servicabilty >>>>>> coding. >>>>>> >>>>>> On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> I found "8169317: [s390] Various minor bug fixes and adaptions." >>>>>>> in jdk9/dev this morning, so I thought it has been promoted based >>>>>>> on some older change. I waited for that quite a while because tests >>>>>>> in jdk9/dev kept failing on s390. >>>>>>> How can I get the information when what was promoted? This always >>>>>>> is a wild guess for me ... as well as when what will be promoted :) >>>>>> >>>>>> Yeah there's no notification in the bug report of when hs pushes up to >>>>>> dev. The changeset email is the only record of exactly when it happens. >>>>>> >>>>>>> Do you think the promotion will happen tonight, or will it take >>>>>>> another week? >>>>>> >>>>>> hs goes through Pre-Integration Testing (PIT) before it is pushed to >>>>>> dev. There have been delays in getting that started and so a delay in it >>>>>> finishing and being analyzed. It may still be a couple of days. >>>>>> >>>>>>> I removed >>>>>>> - JLI_StrLen(jrepath) + JLI_StrLen(arch) + >> JLI_StrLen("/lib//jli:") >>>> + >>>>>>> + JLI_StrLen(jrepath) + JLI_StrLen(arch) + >> JLI_StrLen("/lib/jli:") + >>>>>>> from >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >> corlib_s11y/webrev.04/ >>>>>> >>>>>> With that gone that file only has the jvmpath rename - which isn't >>>>>> fixing anything. >>>>>> >>>>>> Joe also asked for the fdlibm changes to dropped. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Mittwoch, 14. Dezember 2016 11:04 >>>>>>>> To: Lindenmaier, Goetz ; >>>>>>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >>>>>>>> ; Java Core Libs >>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>>>> dev at openjdk.java.net) >>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >> servicabilty >>>>>>>> coding. >>>>>>>> >>>>>>>> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> 8066474 has not been promoted. >>>>>>>> >>>>>>>> hs has not been able to push up to dev yet. >>>>>>>> >>>>>>>>> I'll remove the strlen // fix for aix from this change and >>>>>>>>> push it without it. I'd like to get this done. >>>>>>>> >>>>>>>> I've lost track of what is now left in this set of changes ?? >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Donnerstag, 8. Dezember 2016 23:03 >>>>>>>>>> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz >>>>>>>>>> ; 'Dmitry Samersoff' >>>>>>>>>> ; Java Core Libs >>>>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>>>>>> dev at openjdk.java.net) >>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>> servicabilty >>>>>>>>>> coding. >>>>>>>>>> >>>>>>>>>> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: >>>>>>>>>>> On 12/8/16 1:59 PM, David Holmes wrote: >>>>>>>>>>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> thanks for looking at the change. New webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>> corlib_s11y/webrev.04/ >>>>>>>>>>>>> >>>>>>>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>>>>>>> As far as I can see the existing code is working perfectly fine. >>>>>>>>>>>>> Ah, thanks for the explanation, now I got it! Removed. >>>>>>>>>>>>> >>>>>>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output >> string is >>>>>>>>>>>>>> expanded with: >>>>>>>>>>>>>> "%s/lib/%s/jli:" >>>>>>>>>>>>> I first edited this against jdk9/hs, where the arch is gone since >>>>>>>>>>>>> 8066474, >>>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc >>>>>>>>>>>>> but the // was not adapted. Then I moved the change to >> jdk9/dev >>>>>>>> because >>>>>>>>>>>>> I thought I have to push it there. And yes, in that coding // >> would >>>>>>>>>>>>> be correct. >>>>>>>>>>>>> So I have to wait until hs is promoted ... >>>>>>>>>>>> >>>>>>>>>>>> So just based on the current file, the change proposed - to >> remove >>>> one >>>>>>>>>>>> / - is not correct until the arch directory is removed. >>>>>>>>>>> >>>>>>>>>>> That change is already in JDK9-hs: >>>>>>>>>>> >>>>>>>>>>> Changeset: c14f9a7b4cab >>>>>>>>>>> Author: erikj >>>>>>>>>>> Date: 2016-12-05 17:55 +0100 >>>>>>>>>>> URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab >>>>>>>>>>> >>>>>>>>>>> 8066474: Remove the lib/ directory from Linux and Solaris >> images >>>>>>>>>>> Reviewed-by: tbell, ihse >>>>>>>>>>> >>>>>>>>>>> along with changesets in the jdk and hotspot repos along with a >> few >>>>>>>>>>> closed repos. >>>>>>>>>> >>>>>>>>>> Thanks Dan. So we need to see a webrev based on latest hs code - >>>> where >>>>>>>>>> removing the extra / would be correct. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> Dan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - >> a >>>>>>>>>>>>>> comment on >>>>>>>>>>>>>> the strdup would have sufficed IMO. >>>>>>>>>>>>> Dmitry asked me to add it. But I think it's ok. >>>>>>>>>>>>> >>>>>>>>>>>>> Can I consider this reviewed now? I.e. could I push it once >> 8066474 >>>> is >>>>>>>>>>>>> promoted and Joe Darcy agreed? >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14 >>>>>>>>>>>>>> To: Lindenmaier, Goetz ; >> 'Dmitry >>>>>>>>>> Samersoff' >>>>>>>>>>>>>> ; Java Core Libs >>>>>>>>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>>>>>>>>>> dev at openjdk.java.net) >>>>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>>>>>>>>>> servicabilty >>>>>>>>>>>>>> coding. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> yes, new_jvmpath is consistent with the other variables. >>>>>>>>>>>>>>> I also merged the ifs in SDE.c. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> new webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>>>> corlib_s11y/webrev.03/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>>>>>>> >>>>>>>>>>>>>> As far as I can see the existing code is working perfectly fine. >>>>>>>>>>>>>> Given a >>>>>>>>>>>>>> jvm.cfg with: >>>>>>>>>>>>>> >>>>>>>>>>>>>> -server KNOWN >>>>>>>>>>>>>> -client IGNORE >>>>>>>>>>>>>> -myvm KNOWN >>>>>>>>>>>>>> -oldvm ALIASED_TO -server >>>>>>>>>>>>>> >>>>>>>>>>>>>> The usage text is: >>>>>>>>>>>>>> >>>>>>>>>>>>>> -server to select the "server" VM >>>>>>>>>>>>>> -myvm to select the "myvm" VM >>>>>>>>>>>>>> -oldvm is a synonym for the "server" VM [deprecated] >>>>>>>>>>>>>> The default VM is server, >>>>>>>>>>>>>> because you are running on a server-class machine. >>>>>>>>>>>>>> >>>>>>>>>>>>>> which is exactly what I would expect. Why do you think there >> is a >>>>>> bug? >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> >>>>>>>>>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>>>>>>>> >>>>>>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output >> string is >>>>>>>>>>>>>> expanded with: >>>>>>>>>>>>>> >>>>>>>>>>>>>> "%s/lib/%s/jli:" >>>>>>>>>>>>>> >>>>>>>>>>>>>> so it needs to account for the extra "/lib//jli:" characters - >> and that >>>>>>>>>>>>>> is exactly what the existing code does: >>>>>>>>>>>>>> >>>>>>>>>>>>>> + JLI_StrLen("/lib//jli:") >>>>>>>>>>>>>> >>>>>>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - >> a >>>>>>>>>>>>>> comment on >>>>>>>>>>>>>> the strdup would have sufficed IMO. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: Dmitry Samersoff >> [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM >>>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; >> Java >>>> Core >>>>>>>> Libs >>>>>>>>>>>>>>>> ; serviceability-dev >>>>>> (serviceability- >>>>>>>>>>>>>>>> dev at openjdk.java.net) > dev at openjdk.java.net> >>>>>>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib >> and >>>>>>>>>>>>>>>> servicabilty >>>>>>>>>>>>>>>> coding. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Goetz, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> SDE.c: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You might combine if at ll. 260 and 263 to one but it's just >>>>>>>>>>>>>>>> matter of test. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> if (sti == baseStratumIndex || sti < 0) { >>>>>>>>>>>>>>>> return; /* Java stratum - return unchanged */ >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>>>>>>>>>> double-check the new webrev. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> if cnt is <= 0 loop at l.267 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> for (; cnt-- > 0; ++fromEntry) { >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> is never run and we effectively do >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *entryCountPtr = 0; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> at l.283 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So if we you suspect that cnt may become negative or 0: >>>>>>>>>>>>>>>> (your v.01 changes) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 260 if (sti < 0 && cnt > 0) { >>>>>>>>>>>>>>>> 261 return; >>>>>>>>>>>>>>>> 262 } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> it's better to check it early. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> But I'm not sure we have to care about negative/zero cnt >> here. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> thanks for looking at my change! >>>>>>>>>>>>>>>>> Updated webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>>>>>> corlib_s11y/webrev.02 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>>>>>>>>>>>> Is this line correct? >>>>>>>>>>>>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It seems pointless. Should I remove it? (The whole file is a >>>>>>>>>>>>>>>>> horror.) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>>>>>>>>>>>>>>>> It might be better to return immediately if cnt < 0, >>>>>>>>>>>>>>>>>> regardless of value of sti. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>>>>>>>>>> double-check the new webrev. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> * >> src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>>>>>>>>>>>>>>>> It might be better to write >>>>>>>>>>>>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>>>>>>>>>>>>>>>> and leave one copy of setsockopt() call >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yes, looks better. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>> Goetz >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This change fixes some minor issues found in our code >>>> scans. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I hope this correctly addresses corelib and serviceability >>>> issues. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Please review: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>>>>>>>>>>>> corlib_s11y/webrev.01/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Changes in detail: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> e_asin.c >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Code scan reports missing {}. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the >> inexact >>>>>>>>>>>>>>>>>>> flag of >>>>>>>>>>>>>>>>>>> the processor. >>>>>>>>>>>>>>>>>>> It's a way to avoid the C compiler to optimize the code >>>> away. >>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>>>> always true, >>>>>>>>>>>>>>>>>>> so the parenthesis of the outer else don't matter. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Although this basically just adds the {} I would like to >> submit >>>>>>>>>>>>>>>>>>> this to >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> avoid anybody else spends more the 30sec on >> understanding >>>>>>>> these >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> if statements. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> k_standard.c >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> exc.retval is returned below and thus should always be >>>>>>>>>>>>>>>>>>> initialized. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> imageDecompressor.cpp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Wrong destructor is used. Reported also by David >> CARLIER >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> java.c >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> java_md_solinux.c >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> "//" in path is useless. Further down a free is missing. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> SDE.c >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Call to stratumTableIndex can return negative value if >>>>>>>>>>>>>>>>>>> defaultStratumId >>>>>>>>>>>>>>>>>>> == null. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> socket_md.c >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use >> is >>>>>>>>>>>>>>>>>>> hidden in >>>>>>>>>>>>>>>>>>> the macros. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> unpack.cpp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> n.slice should not get negative argument for end, which >> is >>>>>>>>>>>>>>>>>>> passed from >>>>>>>>>>>>>>>>>>> dollar1. >>>>>>>>>>>>>>>>>>> But dollar1 can get negative where it is set to the result >> of >>>>>>>>>>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Dmitry Samersoff >>>>>>>>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>>>>>>>>>>>> * I would love to change the world, but they won't give >> me >>>> the >>>>>>>>>>>>>>>>>> sources. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> 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 Thu Dec 15 08:57:29 2016 From: jini.george at oracle.com (Jini Susan George) Date: Thu, 15 Dec 2016 00:57:29 -0800 (PST) Subject: RFR: JDK-8159127: hprof heap dumps broken for lambda classdata In-Reply-To: <894fd024-7c74-abc6-667c-e5caf22362b0@oracle.com> References: <6c7dc3cd-1da1-37c2-a0ab-1cf0e1e418c8@oracle.com> <706cdf38-7fa4-46ed-9a38-5a657178a8b5@default> <607c6591-2216-7596-9502-554a171da337@oracle.com> <70429c0f-5ed9-4ee1-9f08-92e0ccc60899@default> <894fd024-7c74-abc6-667c-e5caf22362b0@oracle.com> Message-ID: <5bde69bb-369b-4ba8-8bce-5b9256f9ab8b@default> Thank you, Serguei for the review. Comments inline. > -----Original Message----- > > > It seems there is no need to check address for null as it is done > inside the instantiateWrapperFor call. Makes sense. I have removed those. > At the lines 522-547 it is possible to define and use the same callback class > for traversing both the SystemDictionary classes and the anonymous classes. > The same is applied to the lines 961-990. > But I leave it up to you to decide if it needs to be updated. I have left this as it is. The modified webrev is at: http://cr.openjdk.java.net/~jgeorge/8159127/webrev.02/ Thanks, Jini. From serguei.spitsyn at oracle.com Thu Dec 15 09:27:56 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 15 Dec 2016 01:27:56 -0800 Subject: RFR: JDK-8159127: hprof heap dumps broken for lambda classdata In-Reply-To: <5bde69bb-369b-4ba8-8bce-5b9256f9ab8b@default> References: <6c7dc3cd-1da1-37c2-a0ab-1cf0e1e418c8@oracle.com> <706cdf38-7fa4-46ed-9a38-5a657178a8b5@default> <607c6591-2216-7596-9502-554a171da337@oracle.com> <70429c0f-5ed9-4ee1-9f08-92e0ccc60899@default> <894fd024-7c74-abc6-667c-e5caf22362b0@oracle.com> <5bde69bb-369b-4ba8-8bce-5b9256f9ab8b@default> Message-ID: <9908fdd1-8777-6052-d839-76a091e41a01@oracle.com> Jini, It looks good. Thank you for the update! Serguei On 12/15/16 00:57, Jini Susan George wrote: > Thank you, Serguei for the review. Comments inline. > >> -----Original Message----- >> >> >> It seems there is no need to check address for null as it is done >> inside the instantiateWrapperFor call. > Makes sense. I have removed those. > >> At the lines 522-547 it is possible to define and use the same callback class >> for traversing both the SystemDictionary classes and the anonymous classes. >> The same is applied to the lines 961-990. >> But I leave it up to you to decide if it needs to be updated. > I have left this as it is. The modified webrev is at: > > http://cr.openjdk.java.net/~jgeorge/8159127/webrev.02/ > > Thanks, > Jini. From dmitry.samersoff at oracle.com Thu Dec 15 10:29:31 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 15 Dec 2016 13:29:31 +0300 Subject: RFR: JDK-8159127: hprof heap dumps broken for lambda classdata In-Reply-To: <5bde69bb-369b-4ba8-8bce-5b9256f9ab8b@default> References: <6c7dc3cd-1da1-37c2-a0ab-1cf0e1e418c8@oracle.com> <706cdf38-7fa4-46ed-9a38-5a657178a8b5@default> <607c6591-2216-7596-9502-554a171da337@oracle.com> <70429c0f-5ed9-4ee1-9f08-92e0ccc60899@default> <894fd024-7c74-abc6-667c-e5caf22362b0@oracle.com> <5bde69bb-369b-4ba8-8bce-5b9256f9ab8b@default> Message-ID: <0f0e17ca-722f-b8b4-284e-c27f1d102790@oracle.com> Jini, I'm OK with removed null check. Looks good to me! -Dmitry On 2016-12-15 11:57, Jini Susan George wrote: > Thank you, Serguei for the review. Comments inline. > >> -----Original Message----- >> >> >> It seems there is no need to check address for null as it is done >> inside the instantiateWrapperFor call. > > Makes sense. I have removed those. > >> At the lines 522-547 it is possible to define and use the same callback class >> for traversing both the SystemDictionary classes and the anonymous classes. >> The same is applied to the lines 961-990. >> But I leave it up to you to decide if it needs to be updated. > > I have left this as it is. The modified webrev is at: > > http://cr.openjdk.java.net/~jgeorge/8159127/webrev.02/ > > 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 mandy.chung at oracle.com Mon Dec 19 21:41:55 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 19 Dec 2016 13:41:55 -0800 Subject: Review Request JDK-8171468: sun/management/jmxremote/bootstrap/CustomLauncherTest.java fails as lib/$ARCH no longer exists Message-ID: <750E9988-3C4D-4D5C-89E8-ABD704EDC250@oracle.com> Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8171468/webrev.00/ The test is updated to check the new location of shared libraries. lib/$ARCH has been removed. Mandy From Alan.Bateman at oracle.com Mon Dec 19 21:42:39 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Dec 2016 21:42:39 +0000 Subject: Review Request JDK-8171468: sun/management/jmxremote/bootstrap/CustomLauncherTest.java fails as lib/$ARCH no longer exists In-Reply-To: <750E9988-3C4D-4D5C-89E8-ABD704EDC250@oracle.com> References: <750E9988-3C4D-4D5C-89E8-ABD704EDC250@oracle.com> Message-ID: <402ed40d-fa18-c0bf-ea8f-62db4d281af4@oracle.com> On 19/12/2016 21:41, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8171468/webrev.00/ > > The test is updated to check the new location of shared libraries. lib/$ARCH has been removed. > This looks good. -Alan From claes.redestad at oracle.com Mon Dec 19 21:43:59 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 19 Dec 2016 22:43:59 +0100 Subject: Review Request JDK-8171468: sun/management/jmxremote/bootstrap/CustomLauncherTest.java fails as lib/$ARCH no longer exists In-Reply-To: <750E9988-3C4D-4D5C-89E8-ABD704EDC250@oracle.com> References: <750E9988-3C4D-4D5C-89E8-ABD704EDC250@oracle.com> Message-ID: <0dccc740-f1d1-19ca-a23a-ebf9d1e2d851@oracle.com> Hi, seems you forgot to remove the code using LIBARCH around line 82 /Claes On 2016-12-19 22:41, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8171468/webrev.00/ > > The test is updated to check the new location of shared libraries. lib/$ARCH has been removed. > > Mandy > From claes.redestad at oracle.com Mon Dec 19 21:45:26 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 19 Dec 2016 22:45:26 +0100 Subject: Review Request JDK-8171468: sun/management/jmxremote/bootstrap/CustomLauncherTest.java fails as lib/$ARCH no longer exists In-Reply-To: <0dccc740-f1d1-19ca-a23a-ebf9d1e2d851@oracle.com> References: <750E9988-3C4D-4D5C-89E8-ABD704EDC250@oracle.com> <0dccc740-f1d1-19ca-a23a-ebf9d1e2d851@oracle.com> Message-ID: <509aeb2a-ed79-5eaf-5e80-5cf63ce959c0@oracle.com> Oops, seems you fixed it, nevermind :-) /Claes On 2016-12-19 22:43, Claes Redestad wrote: > Hi, > > seems you forgot to remove the code using LIBARCH around line 82 > > /Claes > > On 2016-12-19 22:41, Mandy Chung wrote: >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8171468/webrev.00/ >> >> The test is updated to check the new location of shared libraries. >> lib/$ARCH has been removed. >> >> Mandy >> From mandy.chung at oracle.com Mon Dec 19 21:45:38 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 19 Dec 2016 13:45:38 -0800 Subject: Review Request JDK-8171468: sun/management/jmxremote/bootstrap/CustomLauncherTest.java fails as lib/$ARCH no longer exists In-Reply-To: <0dccc740-f1d1-19ca-a23a-ebf9d1e2d851@oracle.com> References: <750E9988-3C4D-4D5C-89E8-ABD704EDC250@oracle.com> <0dccc740-f1d1-19ca-a23a-ebf9d1e2d851@oracle.com> Message-ID: <51DB2B5E-5871-4D50-9A8D-7C4B9352FEA9@oracle.com> I did upload the right version a moment ago. Mandy > On Dec 19, 2016, at 1:43 PM, Claes Redestad wrote: > > Hi, > > seems you forgot to remove the code using LIBARCH around line 82 > > /Claes > > On 2016-12-19 22:41, Mandy Chung wrote: >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8171468/webrev.00/ >> >> The test is updated to check the new location of shared libraries. lib/$ARCH has been removed. >> >> Mandy >> From ujwal.vangapally at oracle.com Tue Dec 20 06:29:20 2016 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Tue, 20 Dec 2016 11:59:20 +0530 Subject: RFR: JDK-8170861 : Remove DcmdMBeanPermissionsTest.java from ProblemList Message-ID: <72c9d823-d0b2-770d-9afa-f488d19109a0@oracle.com> Please review this small change https://bugs.openjdk.java.net/browse/JDK-8170861 webrev: http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8170861/webrev.00/ Thanks, Ujwal. From david.holmes at oracle.com Tue Dec 20 06:52:13 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Dec 2016 16:52:13 +1000 Subject: RFR: JDK-8170861 : Remove DcmdMBeanPermissionsTest.java from ProblemList In-Reply-To: <72c9d823-d0b2-770d-9afa-f488d19109a0@oracle.com> References: <72c9d823-d0b2-770d-9afa-f488d19109a0@oracle.com> Message-ID: Looks fine. Thanks, David On 20/12/2016 4:29 PM, Ujwal Vangapally wrote: > Please review this small change > > https://bugs.openjdk.java.net/browse/JDK-8170861 > > webrev: > http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8170861/webrev.00/ > > > Thanks, > > Ujwal. > From frederic.parain at oracle.com Tue Dec 20 14:29:55 2016 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 20 Dec 2016 09:29:55 -0500 Subject: RFR: JDK-8170861 : Remove DcmdMBeanPermissionsTest.java from ProblemList In-Reply-To: <72c9d823-d0b2-770d-9afa-f488d19109a0@oracle.com> References: <72c9d823-d0b2-770d-9afa-f488d19109a0@oracle.com> Message-ID: Looks good to me. Thank you, Fred On 12/20/2016 01:29 AM, Ujwal Vangapally wrote: > Please review this small change > > https://bugs.openjdk.java.net/browse/JDK-8170861 > > webrev: > http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8170861/webrev.00/ > > > Thanks, > > Ujwal. > From ujwal.vangapally at oracle.com Wed Dec 21 05:08:26 2016 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Wed, 21 Dec 2016 10:38:26 +0530 Subject: RFR: JDK-8170861 : Remove DcmdMBeanPermissionsTest.java from ProblemList In-Reply-To: References: <72c9d823-d0b2-770d-9afa-f488d19109a0@oracle.com> Message-ID: <3344cc02-63ab-8c4c-3e76-b07c7b47fb61@oracle.com> Thanks for the review David, I hope this is good enough for me to push the changes. Ujwal On 12/20/2016 12:22 PM, David Holmes wrote: > Looks fine. > > Thanks, > David > > On 20/12/2016 4:29 PM, Ujwal Vangapally wrote: >> Please review this small change >> >> https://bugs.openjdk.java.net/browse/JDK-8170861 >> >> webrev: >> http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8170861/webrev.00/ >> >> >> >> Thanks, >> >> Ujwal. >> From david.holmes at oracle.com Wed Dec 21 05:17:18 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 21 Dec 2016 15:17:18 +1000 Subject: RFR: JDK-8170861 : Remove DcmdMBeanPermissionsTest.java from ProblemList In-Reply-To: <3344cc02-63ab-8c4c-3e76-b07c7b47fb61@oracle.com> References: <72c9d823-d0b2-770d-9afa-f488d19109a0@oracle.com> <3344cc02-63ab-8c4c-3e76-b07c7b47fb61@oracle.com> Message-ID: <6c52fbdc-b0a5-87ca-644a-8f5a7fbc1305@oracle.com> On 21/12/2016 3:08 PM, Ujwal Vangapally wrote: > Thanks for the review David, I hope this is good enough for me to push > the changes. It is enough for you to run "hg commit" to create the changeset, but you need an OpenJDK Committer to actually push it for you. (Yeah it is confusing that an Author can commit, but it takes a Commiter to push.) David > Ujwal > > > On 12/20/2016 12:22 PM, David Holmes wrote: >> Looks fine. >> >> Thanks, >> David >> >> On 20/12/2016 4:29 PM, Ujwal Vangapally wrote: >>> Please review this small change >>> >>> https://bugs.openjdk.java.net/browse/JDK-8170861 >>> >>> webrev: >>> http://cr.openjdk.java.net/~asapre/sponsorships/Ujwal/JDK-8170861/webrev.00/ >>> >>> >>> >>> Thanks, >>> >>> Ujwal. >>> > From markus.gronlund at oracle.com Fri Dec 23 11:29:41 2016 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Fri, 23 Dec 2016 03:29:41 -0800 (PST) Subject: RFR(XXS): 8171960: Event-based tracing needs separate flag representation for Method Message-ID: <00b431e9-7b1d-4885-8248-23fe504f7966@default> 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. Thank you Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: