From chris.plummer at oracle.com Fri Jan 3 20:12:17 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 3 Jan 2020 12:12:17 -0800 Subject: RFR (trivial): 8236552: Description of jmxremote.ssl.config.file in ManagementAgent.start is incorrect In-Reply-To: References: Message-ID: Hi Yasumasa, The change looks fine, but shouldn't there be a regression test for this feature? It looks like JMXStartStopTest covers some of the options, but most are not tested. Seems we should at least have a test to confirm that the correct property is set. thanks, Chris On 12/26/19 8:10 PM, Yasumasa Suenaga wrote: > Hi all, > > Please review this trivial fix: > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8236552 > ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8236552/webrev.00/ > > ManagementAgent.start dcmd provides jmxremote.ssl.config.file for SSL > configuration. We can see description as below: > > ``` > jmxremote.ssl.config.file : [optional] set > com.sun.management.jmxremote.ssl_config_file (STRING, no default value) > ``` > > This option would set com.sun.management.jmxremote.ssl.config.file, > not ssl_config_file. > > > Thanks, > > Yasumasa From suenaga at oss.nttdata.com Sat Jan 4 03:28:36 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Sat, 4 Jan 2020 12:28:36 +0900 Subject: RFR (trivial): 8236552: Description of jmxremote.ssl.config.file in ManagementAgent.start is incorrect In-Reply-To: References: Message-ID: <2c44bdcc-3ac3-2d7c-77db-d455d7ac3e95@oss.nttdata.com> Hi Chris, Thanks for your review! On 2020/01/04 5:12, Chris Plummer wrote: > Hi Yasumasa, > > The change looks fine, but shouldn't there be a regression test for this feature? It looks like JMXStartStopTest covers some of the options, but most are not tested. Seems we should at least have a test to confirm that the correct property is set. I agree with you, but it should be handled as another issue IMHO. All parameters in command line seem to be tested in test/jdk/sun/management/jmxremote/bootstrap. I guess we can port them to jcmd tests, but it might be hard. I will file it to JBS and will push 8236552 if you are ok. What do you think? Thanks, Yasumasa > thanks, > > Chris > > On 12/26/19 8:10 PM, Yasumasa Suenaga wrote: >> Hi all, >> >> Please review this trivial fix: >> >> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8236552 >> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8236552/webrev.00/ >> >> ManagementAgent.start dcmd provides jmxremote.ssl.config.file for SSL configuration. We can see description as below: >> >> ``` >> jmxremote.ssl.config.file : [optional] set com.sun.management.jmxremote.ssl_config_file (STRING, no default value) >> ``` >> >> This option would set com.sun.management.jmxremote.ssl.config.file, not ssl_config_file. >> >> >> Thanks, >> >> Yasumasa > > From chris.plummer at oracle.com Sat Jan 4 06:48:42 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 3 Jan 2020 22:48:42 -0800 Subject: RFR (trivial): 8236552: Description of jmxremote.ssl.config.file in ManagementAgent.start is incorrect In-Reply-To: <2c44bdcc-3ac3-2d7c-77db-d455d7ac3e95@oss.nttdata.com> References: <2c44bdcc-3ac3-2d7c-77db-d455d7ac3e95@oss.nttdata.com> Message-ID: <1bc7d166-8255-76b8-c322-aba1d85529e1@oracle.com> Hi Yasumasa, On 1/3/20 7:28 PM, Yasumasa Suenaga wrote: > Hi Chris, > > Thanks for your review! > > On 2020/01/04 5:12, Chris Plummer wrote: >> Hi Yasumasa, >> >> The change looks fine, but shouldn't there be a regression test for >> this feature? It looks like JMXStartStopTest covers some of the >> options, but most are not tested. Seems we should at least have a >> test to confirm that the correct property is set. > > I agree with you, but it should be handled as another issue IMHO. > All parameters in command line seem to be tested in > test/jdk/sun/management/jmxremote/bootstrap. I don't see them all being tested. For example, I don't see any jdb related properties being tested, and also noticed some jmxremote ones are missing. > I guess we can port them to jcmd tests, but it might be hard. I think as long as the bootstrap tests provide the coverage, the only thing the jcmd tests need to test for is that the property gets set. > > I will file it to JBS and will push 8236552 if you are ok. > What do you think? That sounds fine. thanks, Chris > > > Thanks, > > Yasumasa > > >> thanks, >> >> Chris >> >> On 12/26/19 8:10 PM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Please review this trivial fix: >>> >>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8236552 >>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8236552/webrev.00/ >>> >>> ManagementAgent.start dcmd provides jmxremote.ssl.config.file for >>> SSL configuration. We can see description as below: >>> >>> ``` >>> jmxremote.ssl.config.file : [optional] set >>> com.sun.management.jmxremote.ssl_config_file (STRING, no default value) >>> ``` >>> >>> This option would set com.sun.management.jmxremote.ssl.config.file, >>> not ssl_config_file. >>> >>> >>> Thanks, >>> >>> Yasumasa >> >> From suenaga at oss.nttdata.com Sat Jan 4 07:20:20 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Sat, 4 Jan 2020 16:20:20 +0900 Subject: RFR (trivial): 8236552: Description of jmxremote.ssl.config.file in ManagementAgent.start is incorrect In-Reply-To: <1bc7d166-8255-76b8-c322-aba1d85529e1@oracle.com> References: <2c44bdcc-3ac3-2d7c-77db-d455d7ac3e95@oss.nttdata.com> <1bc7d166-8255-76b8-c322-aba1d85529e1@oracle.com> Message-ID: On 2020/01/04 15:48, Chris Plummer wrote: > Hi Yasumasa, > > On 1/3/20 7:28 PM, Yasumasa Suenaga wrote: >> Hi Chris, >> >> Thanks for your review! >> >> On 2020/01/04 5:12, Chris Plummer wrote: >>> Hi Yasumasa, >>> >>> The change looks fine, but shouldn't there be a regression test for this feature? It looks like JMXStartStopTest covers some of the options, but most are not tested. Seems we should at least have a test to confirm that the correct property is set. >> >> I agree with you, but it should be handled as another issue IMHO. >> All parameters in command line seem to be tested in test/jdk/sun/management/jmxremote/bootstrap. > I don't see them all being tested. For example, I don't see any jdb related properties being tested, and also noticed some jmxremote ones are missing. >> I guess we can port them to jcmd tests, but it might be hard. > I think as long as the bootstrap tests provide the coverage, the only thing the jcmd tests need to test for is that the property gets set. >> >> I will file it to JBS and will push 8236552 if you are ok. >> What do you think? > That sounds fine. I file it to JBS: https://bugs.openjdk.java.net/browse/JDK-8236649 Thanks, Yasumasa > thanks, > > Chris >> >> >> Thanks, >> >> Yasumasa >> >> >>> thanks, >>> >>> Chris >>> >>> On 12/26/19 8:10 PM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Please review this trivial fix: >>>> >>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8236552 >>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8236552/webrev.00/ >>>> >>>> ManagementAgent.start dcmd provides jmxremote.ssl.config.file for SSL configuration. We can see description as below: >>>> >>>> ``` >>>> jmxremote.ssl.config.file : [optional] set com.sun.management.jmxremote.ssl_config_file (STRING, no default value) >>>> ``` >>>> >>>> This option would set com.sun.management.jmxremote.ssl.config.file, not ssl_config_file. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>> >>> > > From fairoz.matte at oracle.com Mon Jan 6 07:57:28 2020 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Sun, 5 Jan 2020 23:57:28 -0800 (PST) Subject: RFR: 8235637: jhsdb jmap from OpenJDK 11.0.5 doesn't work if prelink is enabled In-Reply-To: <3306a3c9-c26c-d72e-983d-3f7e4c890abe@oracle.com> References: <0c5f8a55-e7e6-ba87-58a8-e6a7edd55f01@oracle.com> <43fd053e-7fd4-41fe-8bf3-7382cf77ca33@default> <068d2c84-d865-3c78-1b53-eab3f3af660d@oracle.com> <3306a3c9-c26c-d72e-983d-3f7e4c890abe@oracle.com> Message-ID: Hi, I have created patches for jdk8u-dev and jdk11u-dev and attached to the bug report. As I am not a committer for both the projects, could some one please sponsor this push? Thanks, Fairoz -----Original Message----- From: Chris Plummer Sent: Tuesday, December 17, 2019 12:42 AM To: Kevin Walls ; Fairoz Matte ; serviceability-dev at openjdk.java.net Subject: Re: RFR: 8235637: jhsdb jmap from OpenJDK 11.0.5 doesn't work if prelink is enabled +1 On 12/16/19 8:35 AM, Kevin Walls wrote: > Great! 8-) > > On 16/12/2019 15:36, Fairoz Matte wrote: >> Oh yes, >> Thanks Kevin for the review. >> >> Corrected the same - >> http://cr.openjdk.java.net/~fmatte/8235637/webrev.02 >> >> Thanks, >> Fairoz >> From suenaga at oss.nttdata.com Mon Jan 6 08:04:22 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Mon, 6 Jan 2020 17:04:22 +0900 Subject: RFR: 8235637: jhsdb jmap from OpenJDK 11.0.5 doesn't work if prelink is enabled In-Reply-To: References: <0c5f8a55-e7e6-ba87-58a8-e6a7edd55f01@oracle.com> <43fd053e-7fd4-41fe-8bf3-7382cf77ca33@default> <068d2c84-d865-3c78-1b53-eab3f3af660d@oracle.com> <3306a3c9-c26c-d72e-983d-3f7e4c890abe@oracle.com> Message-ID: <0fcb3443-f36a-52e6-f291-47550ee3dcb5@oss.nttdata.com> Hi Fairoz, I can push them. Please share the patch if you have not yet found sponsor. Thanks, Yasumasa On 2020/01/06 16:57, Fairoz Matte wrote: > Hi, > > I have created patches for jdk8u-dev and jdk11u-dev and attached to the bug report. > As I am not a committer for both the projects, could some one please sponsor this push? > > Thanks, > Fairoz > > -----Original Message----- > From: Chris Plummer > Sent: Tuesday, December 17, 2019 12:42 AM > To: Kevin Walls ; Fairoz Matte ; serviceability-dev at openjdk.java.net > Subject: Re: RFR: 8235637: jhsdb jmap from OpenJDK 11.0.5 doesn't work if prelink is enabled > > +1 > > On 12/16/19 8:35 AM, Kevin Walls wrote: >> Great! 8-) >> >> On 16/12/2019 15:36, Fairoz Matte wrote: >>> Oh yes, >>> Thanks Kevin for the review. >>> >>> Corrected the same - >>> http://cr.openjdk.java.net/~fmatte/8235637/webrev.02 >>> >>> Thanks, >>> Fairoz >>> > From serguei.spitsyn at oracle.com Tue Jan 7 02:18:41 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Jan 2020 18:18:41 -0800 Subject: RFR(XXS): 8236124: Minimal VM slowdebug build failed after JDK-8212160 Message-ID: <984d18bf-0011-9895-e8e6-0c9f7e3427b6@oracle.com> Please, review a trivial fix for bug: ? https://bugs.openjdk.java.net/browse/JDK-8236124 Patch suggested by A. Shipilev: diff --git a/src/hotspot/share/code/nmethod.cpp b/src/hotspot/share/code/nmethod.cpp --- a/src/hotspot/share/code/nmethod.cpp +++ b/src/hotspot/share/code/nmethod.cpp @@ -1601,7 +1601,7 @@ ?????? ServiceThread::enqueue_deferred_event(&event); ???? } else { ?????? // This enters the nmethod barrier outside in the caller. -????? state->enqueue_event(&event); +????? JVMTI_ONLY(state->enqueue_event(&event)); ???? } ?? } ?} Summary: ? The slowdebug build was broken by the fix of JDK-8212160 which introduced new function: enqueue_event(). ? The fix is to call it only if the JVM TI is enabled. Testing: ? Ran slowdebug build locally. Thanks, Serguei From coleen.phillimore at oracle.com Tue Jan 7 02:29:36 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 6 Jan 2020 21:29:36 -0500 Subject: RFR(XXS): 8236124: Minimal VM slowdebug build failed after JDK-8212160 In-Reply-To: <984d18bf-0011-9895-e8e6-0c9f7e3427b6@oracle.com> References: <984d18bf-0011-9895-e8e6-0c9f7e3427b6@oracle.com> Message-ID: This looks trivial.? Thank you for fixing it. Coleen On 1/6/20 9:18 PM, serguei.spitsyn at oracle.com wrote: > Please, review a trivial fix for bug: > ? https://bugs.openjdk.java.net/browse/JDK-8236124 > > Patch suggested by A. Shipilev: > > diff --git a/src/hotspot/share/code/nmethod.cpp > b/src/hotspot/share/code/nmethod.cpp > --- a/src/hotspot/share/code/nmethod.cpp > +++ b/src/hotspot/share/code/nmethod.cpp > @@ -1601,7 +1601,7 @@ > ?????? ServiceThread::enqueue_deferred_event(&event); > ???? } else { > ?????? // This enters the nmethod barrier outside in the caller. > -????? state->enqueue_event(&event); > +????? JVMTI_ONLY(state->enqueue_event(&event)); > ???? } > ?? } > ?} > > > Summary: > ? The slowdebug build was broken by the fix of JDK-8212160 which > introduced new function: enqueue_event(). > ? The fix is to call it only if the JVM TI is enabled. > > Testing: > ? Ran slowdebug build locally. > > Thanks, > Serguei From chris.plummer at oracle.com Tue Jan 7 02:35:16 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Jan 2020 18:35:16 -0800 Subject: RFR(XXS): 8236124: Minimal VM slowdebug build failed after JDK-8212160 In-Reply-To: References: <984d18bf-0011-9895-e8e6-0c9f7e3427b6@oracle.com> Message-ID: <83d721d6-bcfa-a492-eb88-3c02391ad3d4@oracle.com> Hold your horses. I have questions. Working on them now. Please don't push. thanks, Chris On 1/6/20 6:29 PM, coleen.phillimore at oracle.com wrote: > This looks trivial.? Thank you for fixing it. > Coleen > > On 1/6/20 9:18 PM, serguei.spitsyn at oracle.com wrote: >> Please, review a trivial fix for bug: >> ? https://bugs.openjdk.java.net/browse/JDK-8236124 >> >> Patch suggested by A. Shipilev: >> >> diff --git a/src/hotspot/share/code/nmethod.cpp >> b/src/hotspot/share/code/nmethod.cpp >> --- a/src/hotspot/share/code/nmethod.cpp >> +++ b/src/hotspot/share/code/nmethod.cpp >> @@ -1601,7 +1601,7 @@ >> ?????? ServiceThread::enqueue_deferred_event(&event); >> ???? } else { >> ?????? // This enters the nmethod barrier outside in the caller. >> -????? state->enqueue_event(&event); >> +????? JVMTI_ONLY(state->enqueue_event(&event)); >> ???? } >> ?? } >> ?} >> >> >> Summary: >> ? The slowdebug build was broken by the fix of JDK-8212160 which >> introduced new function: enqueue_event(). >> ? The fix is to call it only if the JVM TI is enabled. >> >> Testing: >> ? Ran slowdebug build locally. >> >> Thanks, >> Serguei > From chris.plummer at oracle.com Tue Jan 7 02:39:52 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Jan 2020 18:39:52 -0800 Subject: RFR(XXS): 8236124: Minimal VM slowdebug build failed after JDK-8212160 In-Reply-To: <83d721d6-bcfa-a492-eb88-3c02391ad3d4@oracle.com> References: <984d18bf-0011-9895-e8e6-0c9f7e3427b6@oracle.com> <83d721d6-bcfa-a492-eb88-3c02391ad3d4@oracle.com> Message-ID: <15945b0e-3cb7-e836-3199-d9c9c93bd5da@oracle.com> Hi Serguei, JvmtiDeferredEventQueue::enqueue() is a NOP for minimal builds, so it can be called even for minimalVM builds: ? void enqueue(JvmtiDeferredEvent event) NOT_JVMTI_RETURN; The changes for JDK-8212160 seem to have put some wrapper code around its use, resulting in ServiceThread::enqueue_deferred_event() and JvmtiThreadState::enqueue_event() being added. Shouldn't NOP implementations also have been done for them? thanks, Chris On 1/6/20 6:35 PM, Chris Plummer wrote: > Hold your horses. I have questions. Working on them now. Please don't > push. > > thanks, > > Chris > > On 1/6/20 6:29 PM, coleen.phillimore at oracle.com wrote: >> This looks trivial.? Thank you for fixing it. >> Coleen >> >> On 1/6/20 9:18 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review a trivial fix for bug: >>> ? https://bugs.openjdk.java.net/browse/JDK-8236124 >>> >>> Patch suggested by A. Shipilev: >>> >>> diff --git a/src/hotspot/share/code/nmethod.cpp >>> b/src/hotspot/share/code/nmethod.cpp >>> --- a/src/hotspot/share/code/nmethod.cpp >>> +++ b/src/hotspot/share/code/nmethod.cpp >>> @@ -1601,7 +1601,7 @@ >>> ?????? ServiceThread::enqueue_deferred_event(&event); >>> ???? } else { >>> ?????? // This enters the nmethod barrier outside in the caller. >>> -????? state->enqueue_event(&event); >>> +????? JVMTI_ONLY(state->enqueue_event(&event)); >>> ???? } >>> ?? } >>> ?} >>> >>> >>> Summary: >>> ? The slowdebug build was broken by the fix of JDK-8212160 which >>> introduced new function: enqueue_event(). >>> ? The fix is to call it only if the JVM TI is enabled. >>> >>> Testing: >>> ? Ran slowdebug build locally. >>> >>> Thanks, >>> Serguei >> > > From serguei.spitsyn at oracle.com Tue Jan 7 04:05:25 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Jan 2020 20:05:25 -0800 Subject: RFR(XXS): 8236124: Minimal VM slowdebug build failed after JDK-8212160 In-Reply-To: <15945b0e-3cb7-e836-3199-d9c9c93bd5da@oracle.com> References: <984d18bf-0011-9895-e8e6-0c9f7e3427b6@oracle.com> <83d721d6-bcfa-a492-eb88-3c02391ad3d4@oracle.com> <15945b0e-3cb7-e836-3199-d9c9c93bd5da@oracle.com> Message-ID: <59537f7a-e523-87ec-08f2-3abd364d8d39@oracle.com> Hi Chris, Good catch. I agree, for consistency the enqueue_event() is better to follow the JvmtiDeferredEventQueue::enqueue() to avoid slowdebug minimal build failures. New patch is: diff --git a/src/hotspot/share/prims/jvmtiThreadState.hpp b/src/hotspot/share/prims/jvmtiThreadState.hpp --- a/src/hotspot/share/prims/jvmtiThreadState.hpp +++ b/src/hotspot/share/prims/jvmtiThreadState.hpp @@ -396,7 +396,7 @@ ?? void set_should_post_on_exceptions(bool val) { _thread->set_should_post_on_exceptions_flag(val ? JNI_TRUE : JNI_FALSE); } ?? // Thread local event queue, which doesn't require taking the Service_lock. -? void enqueue_event(JvmtiDeferredEvent* event); +? void enqueue_event(JvmtiDeferredEvent* event) NOT_JVMTI_RETURN; ?? void post_events(JvmtiEnv* env); ?? void run_nmethod_entry_barriers(); ?}; Thanks, Serguei On 1/6/20 6:39 PM, Chris Plummer wrote: > Hi Serguei, > > JvmtiDeferredEventQueue::enqueue() is a NOP for minimal builds, so it > can be called even for minimalVM builds: > > ? void enqueue(JvmtiDeferredEvent event) NOT_JVMTI_RETURN; > > The changes for JDK-8212160 seem to have put some wrapper code around > its use, resulting in ServiceThread::enqueue_deferred_event() and > JvmtiThreadState::enqueue_event() being added. Shouldn't NOP > implementations also have been done for them? > > thanks, > > Chris > > On 1/6/20 6:35 PM, Chris Plummer wrote: >> Hold your horses. I have questions. Working on them now. Please don't >> push. >> >> thanks, >> >> Chris >> >> On 1/6/20 6:29 PM, coleen.phillimore at oracle.com wrote: >>> This looks trivial.? Thank you for fixing it. >>> Coleen >>> >>> On 1/6/20 9:18 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review a trivial fix for bug: >>>> ? https://bugs.openjdk.java.net/browse/JDK-8236124 >>>> >>>> Patch suggested by A. Shipilev: >>>> >>>> diff --git a/src/hotspot/share/code/nmethod.cpp >>>> b/src/hotspot/share/code/nmethod.cpp >>>> --- a/src/hotspot/share/code/nmethod.cpp >>>> +++ b/src/hotspot/share/code/nmethod.cpp >>>> @@ -1601,7 +1601,7 @@ >>>> ?????? ServiceThread::enqueue_deferred_event(&event); >>>> ???? } else { >>>> ?????? // This enters the nmethod barrier outside in the caller. >>>> -????? state->enqueue_event(&event); >>>> +????? JVMTI_ONLY(state->enqueue_event(&event)); >>>> ???? } >>>> ?? } >>>> ?} >>>> >>>> >>>> Summary: >>>> ? The slowdebug build was broken by the fix of JDK-8212160 which >>>> introduced new function: enqueue_event(). >>>> ? The fix is to call it only if the JVM TI is enabled. >>>> >>>> Testing: >>>> ? Ran slowdebug build locally. >>>> >>>> Thanks, >>>> Serguei >>> >> >> > > From serguei.spitsyn at oracle.com Tue Jan 7 04:09:43 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Jan 2020 20:09:43 -0800 Subject: RFR(XXS): 8236124: Minimal VM slowdebug build failed after JDK-8212160 In-Reply-To: References: <984d18bf-0011-9895-e8e6-0c9f7e3427b6@oracle.com> Message-ID: <008c7e11-9aa0-1ead-3b7f-2a03b24b4d0c@oracle.com> Hi Coleen, Thank you for reviewing it! I've sent another trivial patch as suggested by Chris. It is for better consistency. Thanks, Seguei On 1/6/20 6:29 PM, coleen.phillimore at oracle.com wrote: > This looks trivial.? Thank you for fixing it. > Coleen > > On 1/6/20 9:18 PM, serguei.spitsyn at oracle.com wrote: >> Please, review a trivial fix for bug: >> ? https://bugs.openjdk.java.net/browse/JDK-8236124 >> >> Patch suggested by A. Shipilev: >> >> diff --git a/src/hotspot/share/code/nmethod.cpp >> b/src/hotspot/share/code/nmethod.cpp >> --- a/src/hotspot/share/code/nmethod.cpp >> +++ b/src/hotspot/share/code/nmethod.cpp >> @@ -1601,7 +1601,7 @@ >> ?????? ServiceThread::enqueue_deferred_event(&event); >> ???? } else { >> ?????? // This enters the nmethod barrier outside in the caller. >> -????? state->enqueue_event(&event); >> +????? JVMTI_ONLY(state->enqueue_event(&event)); >> ???? } >> ?? } >> ?} >> >> >> Summary: >> ? The slowdebug build was broken by the fix of JDK-8212160 which >> introduced new function: enqueue_event(). >> ? The fix is to call it only if the JVM TI is enabled. >> >> Testing: >> ? Ran slowdebug build locally. >> >> Thanks, >> Serguei > From coleen.phillimore at oracle.com Tue Jan 7 04:26:56 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 6 Jan 2020 23:26:56 -0500 Subject: RFR(XXS): 8236124: Minimal VM slowdebug build failed after JDK-8212160 In-Reply-To: <008c7e11-9aa0-1ead-3b7f-2a03b24b4d0c@oracle.com> References: <984d18bf-0011-9895-e8e6-0c9f7e3427b6@oracle.com> <008c7e11-9aa0-1ead-3b7f-2a03b24b4d0c@oracle.com> Message-ID: <5f678026-5c43-d55a-405b-ad41114ff60e@oracle.com> On 1/6/20 11:09 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > Thank you for reviewing it! > I've sent another trivial patch as suggested by Chris. > It is for better consistency. Yes, Chris's suggestion is better. thanks! Coleen > > Thanks, > Seguei > > > On 1/6/20 6:29 PM, coleen.phillimore at oracle.com wrote: >> This looks trivial.? Thank you for fixing it. >> Coleen >> >> On 1/6/20 9:18 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review a trivial fix for bug: >>> ? https://bugs.openjdk.java.net/browse/JDK-8236124 >>> >>> Patch suggested by A. Shipilev: >>> >>> diff --git a/src/hotspot/share/code/nmethod.cpp >>> b/src/hotspot/share/code/nmethod.cpp >>> --- a/src/hotspot/share/code/nmethod.cpp >>> +++ b/src/hotspot/share/code/nmethod.cpp >>> @@ -1601,7 +1601,7 @@ >>> ?????? ServiceThread::enqueue_deferred_event(&event); >>> ???? } else { >>> ?????? // This enters the nmethod barrier outside in the caller. >>> -????? state->enqueue_event(&event); >>> +????? JVMTI_ONLY(state->enqueue_event(&event)); >>> ???? } >>> ?? } >>> ?} >>> >>> >>> Summary: >>> ? The slowdebug build was broken by the fix of JDK-8212160 which >>> introduced new function: enqueue_event(). >>> ? The fix is to call it only if the JVM TI is enabled. >>> >>> Testing: >>> ? Ran slowdebug build locally. >>> >>> Thanks, >>> Serguei >> > From serguei.spitsyn at oracle.com Tue Jan 7 04:28:57 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Jan 2020 20:28:57 -0800 Subject: RFR(XXS): 8236124: Minimal VM slowdebug build failed after JDK-8212160 In-Reply-To: <5f678026-5c43-d55a-405b-ad41114ff60e@oracle.com> References: <984d18bf-0011-9895-e8e6-0c9f7e3427b6@oracle.com> <008c7e11-9aa0-1ead-3b7f-2a03b24b4d0c@oracle.com> <5f678026-5c43-d55a-405b-ad41114ff60e@oracle.com> Message-ID: Thanks, Coleen! Serguei On 1/6/20 8:26 PM, coleen.phillimore at oracle.com wrote: > > On 1/6/20 11:09 PM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> Thank you for reviewing it! >> I've sent another trivial patch as suggested by Chris. >> It is for better consistency. > > Yes, Chris's suggestion is better. > thanks! > Coleen >> >> Thanks, >> Seguei >> >> >> On 1/6/20 6:29 PM, coleen.phillimore at oracle.com wrote: >>> This looks trivial.? Thank you for fixing it. >>> Coleen >>> >>> On 1/6/20 9:18 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review a trivial fix for bug: >>>> ? https://bugs.openjdk.java.net/browse/JDK-8236124 >>>> >>>> Patch suggested by A. Shipilev: >>>> >>>> diff --git a/src/hotspot/share/code/nmethod.cpp >>>> b/src/hotspot/share/code/nmethod.cpp >>>> --- a/src/hotspot/share/code/nmethod.cpp >>>> +++ b/src/hotspot/share/code/nmethod.cpp >>>> @@ -1601,7 +1601,7 @@ >>>> ?????? ServiceThread::enqueue_deferred_event(&event); >>>> ???? } else { >>>> ?????? // This enters the nmethod barrier outside in the caller. >>>> -????? state->enqueue_event(&event); >>>> +????? JVMTI_ONLY(state->enqueue_event(&event)); >>>> ???? } >>>> ?? } >>>> ?} >>>> >>>> >>>> Summary: >>>> ? The slowdebug build was broken by the fix of JDK-8212160 which >>>> introduced new function: enqueue_event(). >>>> ? The fix is to call it only if the JVM TI is enabled. >>>> >>>> Testing: >>>> ? Ran slowdebug build locally. >>>> >>>> Thanks, >>>> Serguei >>> >> > From david.holmes at oracle.com Tue Jan 7 04:54:43 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 Jan 2020 14:54:43 +1000 Subject: RFR(XXS): 8236124: Minimal VM slowdebug build failed after JDK-8212160 In-Reply-To: <008c7e11-9aa0-1ead-3b7f-2a03b24b4d0c@oracle.com> References: <984d18bf-0011-9895-e8e6-0c9f7e3427b6@oracle.com> <008c7e11-9aa0-1ead-3b7f-2a03b24b4d0c@oracle.com> Message-ID: <03ee3cb6-203c-b69f-fcd6-1b7527911f34@oracle.com> On 7/01/2020 2:09 pm, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > Thank you for reviewing it! > I've sent another trivial patch as suggested by Chris. > It is for better consistency. Yes much better. It makes little sense having a JVMTI_ONLY macro inside a method that is littered with JVMTI code. Thanks, David > Thanks, > Seguei > > > On 1/6/20 6:29 PM, coleen.phillimore at oracle.com wrote: >> This looks trivial.? Thank you for fixing it. >> Coleen >> >> On 1/6/20 9:18 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review a trivial fix for bug: >>> ? https://bugs.openjdk.java.net/browse/JDK-8236124 >>> >>> Patch suggested by A. Shipilev: >>> >>> diff --git a/src/hotspot/share/code/nmethod.cpp >>> b/src/hotspot/share/code/nmethod.cpp >>> --- a/src/hotspot/share/code/nmethod.cpp >>> +++ b/src/hotspot/share/code/nmethod.cpp >>> @@ -1601,7 +1601,7 @@ >>> ?????? ServiceThread::enqueue_deferred_event(&event); >>> ???? } else { >>> ?????? // This enters the nmethod barrier outside in the caller. >>> -????? state->enqueue_event(&event); >>> +????? JVMTI_ONLY(state->enqueue_event(&event)); >>> ???? } >>> ?? } >>> ?} >>> >>> >>> Summary: >>> ? The slowdebug build was broken by the fix of JDK-8212160 which >>> introduced new function: enqueue_event(). >>> ? The fix is to call it only if the JVM TI is enabled. >>> >>> Testing: >>> ? Ran slowdebug build locally. >>> >>> Thanks, >>> Serguei >> > From serguei.spitsyn at oracle.com Tue Jan 7 05:15:50 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Jan 2020 21:15:50 -0800 Subject: RFR(XXS): 8236124: Minimal VM slowdebug build failed after JDK-8212160 In-Reply-To: <03ee3cb6-203c-b69f-fcd6-1b7527911f34@oracle.com> References: <984d18bf-0011-9895-e8e6-0c9f7e3427b6@oracle.com> <008c7e11-9aa0-1ead-3b7f-2a03b24b4d0c@oracle.com> <03ee3cb6-203c-b69f-fcd6-1b7527911f34@oracle.com> Message-ID: <55855ea7-afed-8673-ef9d-99b7a29c66f6@oracle.com> Thank you for review, David! Serguei On 1/6/20 8:54 PM, David Holmes wrote: > On 7/01/2020 2:09 pm, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> Thank you for reviewing it! >> I've sent another trivial patch as suggested by Chris. >> It is for better consistency. > > Yes much better. It makes little sense having a JVMTI_ONLY macro > inside a method that is littered with JVMTI code. > > Thanks, > David > >> Thanks, >> Seguei >> >> >> On 1/6/20 6:29 PM, coleen.phillimore at oracle.com wrote: >>> This looks trivial.? Thank you for fixing it. >>> Coleen >>> >>> On 1/6/20 9:18 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review a trivial fix for bug: >>>> ? https://bugs.openjdk.java.net/browse/JDK-8236124 >>>> >>>> Patch suggested by A. Shipilev: >>>> >>>> diff --git a/src/hotspot/share/code/nmethod.cpp >>>> b/src/hotspot/share/code/nmethod.cpp >>>> --- a/src/hotspot/share/code/nmethod.cpp >>>> +++ b/src/hotspot/share/code/nmethod.cpp >>>> @@ -1601,7 +1601,7 @@ >>>> ?????? ServiceThread::enqueue_deferred_event(&event); >>>> ???? } else { >>>> ?????? // This enters the nmethod barrier outside in the caller. >>>> -????? state->enqueue_event(&event); >>>> +????? JVMTI_ONLY(state->enqueue_event(&event)); >>>> ???? } >>>> ?? } >>>> ?} >>>> >>>> >>>> Summary: >>>> ? The slowdebug build was broken by the fix of JDK-8212160 which >>>> introduced new function: enqueue_event(). >>>> ? The fix is to call it only if the JVM TI is enabled. >>>> >>>> Testing: >>>> ? Ran slowdebug build locally. >>>> >>>> Thanks, >>>> Serguei >>> >> From serguei.spitsyn at oracle.com Tue Jan 7 17:16:32 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 7 Jan 2020 09:16:32 -0800 Subject: RFR(XXS): 8236124: Minimal VM slowdebug build failed after JDK-8212160 In-Reply-To: <59537f7a-e523-87ec-08f2-3abd364d8d39@oracle.com> References: <984d18bf-0011-9895-e8e6-0c9f7e3427b6@oracle.com> <83d721d6-bcfa-a492-eb88-3c02391ad3d4@oracle.com> <15945b0e-3cb7-e836-3199-d9c9c93bd5da@oracle.com> <59537f7a-e523-87ec-08f2-3abd364d8d39@oracle.com> Message-ID: Hi Chris, The slowdebug minimal build does not fail without NOT_JVMTI_RETURN in the ServiceThread::enqueue_deferred_event(). I'm curious why and will check if it is really needed. If so, will add it as well. Thanks, Serguei On 1/6/20 8:05 PM, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > Good catch. > I agree, for consistency the enqueue_event() is better to follow the > JvmtiDeferredEventQueue::enqueue() to avoid slowdebug minimal build > failures. > > New patch is: > > diff --git a/src/hotspot/share/prims/jvmtiThreadState.hpp > b/src/hotspot/share/prims/jvmtiThreadState.hpp > --- a/src/hotspot/share/prims/jvmtiThreadState.hpp > +++ b/src/hotspot/share/prims/jvmtiThreadState.hpp > @@ -396,7 +396,7 @@ > ?? void set_should_post_on_exceptions(bool val) { > _thread->set_should_post_on_exceptions_flag(val ? JNI_TRUE : > JNI_FALSE); } > > ?? // Thread local event queue, which doesn't require taking the > Service_lock. > -? void enqueue_event(JvmtiDeferredEvent* event); > +? void enqueue_event(JvmtiDeferredEvent* event) NOT_JVMTI_RETURN; > ?? void post_events(JvmtiEnv* env); > ?? void run_nmethod_entry_barriers(); > ?}; > > Thanks, > Serguei > > On 1/6/20 6:39 PM, Chris Plummer wrote: >> Hi Serguei, >> >> JvmtiDeferredEventQueue::enqueue() is a NOP for minimal builds, so it >> can be called even for minimalVM builds: >> >> ? void enqueue(JvmtiDeferredEvent event) NOT_JVMTI_RETURN; >> >> The changes for JDK-8212160 seem to have put some wrapper code around >> its use, resulting in ServiceThread::enqueue_deferred_event() and >> JvmtiThreadState::enqueue_event() being added. Shouldn't NOP >> implementations also have been done for them? >> >> thanks, >> >> Chris >> >> On 1/6/20 6:35 PM, Chris Plummer wrote: >>> Hold your horses. I have questions. Working on them now. Please >>> don't push. >>> >>> thanks, >>> >>> Chris >>> >>> On 1/6/20 6:29 PM, coleen.phillimore at oracle.com wrote: >>>> This looks trivial.? Thank you for fixing it. >>>> Coleen >>>> >>>> On 1/6/20 9:18 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review a trivial fix for bug: >>>>> ? https://bugs.openjdk.java.net/browse/JDK-8236124 >>>>> >>>>> Patch suggested by A. Shipilev: >>>>> >>>>> diff --git a/src/hotspot/share/code/nmethod.cpp >>>>> b/src/hotspot/share/code/nmethod.cpp >>>>> --- a/src/hotspot/share/code/nmethod.cpp >>>>> +++ b/src/hotspot/share/code/nmethod.cpp >>>>> @@ -1601,7 +1601,7 @@ >>>>> ?????? ServiceThread::enqueue_deferred_event(&event); >>>>> ???? } else { >>>>> ?????? // This enters the nmethod barrier outside in the caller. >>>>> -????? state->enqueue_event(&event); >>>>> +????? JVMTI_ONLY(state->enqueue_event(&event)); >>>>> ???? } >>>>> ?? } >>>>> ?} >>>>> >>>>> >>>>> Summary: >>>>> ? The slowdebug build was broken by the fix of JDK-8212160 which >>>>> introduced new function: enqueue_event(). >>>>> ? The fix is to call it only if the JVM TI is enabled. >>>>> >>>>> Testing: >>>>> ? Ran slowdebug build locally. >>>>> >>>>> Thanks, >>>>> Serguei >>>> >>> >>> >> >> > From chris.plummer at oracle.com Tue Jan 7 18:04:26 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 7 Jan 2020 10:04:26 -0800 Subject: RFR(XXS): 8236124: Minimal VM slowdebug build failed after JDK-8212160 In-Reply-To: References: <984d18bf-0011-9895-e8e6-0c9f7e3427b6@oracle.com> <83d721d6-bcfa-a492-eb88-3c02391ad3d4@oracle.com> <15945b0e-3cb7-e836-3199-d9c9c93bd5da@oracle.com> <59537f7a-e523-87ec-08f2-3abd364d8d39@oracle.com> Message-ID: Hi Serguei, The reason you don't see a build failure is because the implementation of ServiceThread::enqueue_deferred_event() is not in a JVMTI file that gets excluded from minimalVM builds, thus it is still callable and linkable. If you choose to use NOT_JVMTI_RETURN for it in the header file, then you will also need to #ifdef around the implementation. Chris On 1/7/20 9:16 AM, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > The slowdebug minimal build does not fail without NOT_JVMTI_RETURN in > the ServiceThread::enqueue_deferred_event(). > I'm curious why and will check if it is really needed. > If so, will add it as well. > > Thanks, > Serguei > > On 1/6/20 8:05 PM, serguei.spitsyn at oracle.com wrote: >> Hi Chris, >> >> Good catch. >> I agree, for consistency the enqueue_event() is better to follow the >> JvmtiDeferredEventQueue::enqueue() to avoid slowdebug minimal build >> failures. >> >> New patch is: >> >> diff --git a/src/hotspot/share/prims/jvmtiThreadState.hpp >> b/src/hotspot/share/prims/jvmtiThreadState.hpp >> --- a/src/hotspot/share/prims/jvmtiThreadState.hpp >> +++ b/src/hotspot/share/prims/jvmtiThreadState.hpp >> @@ -396,7 +396,7 @@ >> ?? void set_should_post_on_exceptions(bool val) { >> _thread->set_should_post_on_exceptions_flag(val ? JNI_TRUE : >> JNI_FALSE); } >> >> ?? // Thread local event queue, which doesn't require taking the >> Service_lock. >> -? void enqueue_event(JvmtiDeferredEvent* event); >> +? void enqueue_event(JvmtiDeferredEvent* event) NOT_JVMTI_RETURN; >> ?? void post_events(JvmtiEnv* env); >> ?? void run_nmethod_entry_barriers(); >> ?}; >> >> Thanks, >> Serguei >> >> On 1/6/20 6:39 PM, Chris Plummer wrote: >>> Hi Serguei, >>> >>> JvmtiDeferredEventQueue::enqueue() is a NOP for minimal builds, so >>> it can be called even for minimalVM builds: >>> >>> ? void enqueue(JvmtiDeferredEvent event) NOT_JVMTI_RETURN; >>> >>> The changes for JDK-8212160 seem to have put some wrapper code >>> around its use, resulting in ServiceThread::enqueue_deferred_event() >>> and JvmtiThreadState::enqueue_event() being added. Shouldn't NOP >>> implementations also have been done for them? >>> >>> thanks, >>> >>> Chris >>> >>> On 1/6/20 6:35 PM, Chris Plummer wrote: >>>> Hold your horses. I have questions. Working on them now. Please >>>> don't push. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 1/6/20 6:29 PM, coleen.phillimore at oracle.com wrote: >>>>> This looks trivial.? Thank you for fixing it. >>>>> Coleen >>>>> >>>>> On 1/6/20 9:18 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review a trivial fix for bug: >>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8236124 >>>>>> >>>>>> Patch suggested by A. Shipilev: >>>>>> >>>>>> diff --git a/src/hotspot/share/code/nmethod.cpp >>>>>> b/src/hotspot/share/code/nmethod.cpp >>>>>> --- a/src/hotspot/share/code/nmethod.cpp >>>>>> +++ b/src/hotspot/share/code/nmethod.cpp >>>>>> @@ -1601,7 +1601,7 @@ >>>>>> ServiceThread::enqueue_deferred_event(&event); >>>>>> ???? } else { >>>>>> ?????? // This enters the nmethod barrier outside in the caller. >>>>>> -????? state->enqueue_event(&event); >>>>>> +????? JVMTI_ONLY(state->enqueue_event(&event)); >>>>>> ???? } >>>>>> ?? } >>>>>> ?} >>>>>> >>>>>> >>>>>> Summary: >>>>>> ? The slowdebug build was broken by the fix of JDK-8212160 which >>>>>> introduced new function: enqueue_event(). >>>>>> ? The fix is to call it only if the JVM TI is enabled. >>>>>> >>>>>> Testing: >>>>>> ? Ran slowdebug build locally. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>> >>>> >>>> >>> >>> >> > From serguei.spitsyn at oracle.com Tue Jan 7 19:25:42 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 7 Jan 2020 11:25:42 -0800 Subject: RFR(XXS): 8236124: Minimal VM slowdebug build failed after JDK-8212160 In-Reply-To: References: <984d18bf-0011-9895-e8e6-0c9f7e3427b6@oracle.com> <83d721d6-bcfa-a492-eb88-3c02391ad3d4@oracle.com> <15945b0e-3cb7-e836-3199-d9c9c93bd5da@oracle.com> <59537f7a-e523-87ec-08f2-3abd364d8d39@oracle.com> Message-ID: <49af3fea-f8b5-0bcc-af49-5967de4537e4@oracle.com> Chris, The macro NOT_JVMTI_RETURN is never used outside of the prims/ folder. Also, there is more work to get rid of the JVMTI code in the ServiceThread. I don't know how important is this for the minimal build. So, I'd leave it alone for now and just fix the build issue. Thanks, Serguei On 1/7/20 10:04 AM, Chris Plummer wrote: > Hi Serguei, > > The reason you don't see a build failure is because the implementation > of ServiceThread::enqueue_deferred_event() is not in a JVMTI file that > gets excluded from minimalVM builds, thus it is still callable and > linkable. If you choose to use NOT_JVMTI_RETURN for it in the header > file, then you will also need to #ifdef around the implementation. > > Chris > > On 1/7/20 9:16 AM, serguei.spitsyn at oracle.com wrote: >> Hi Chris, >> >> The slowdebug minimal build does not fail without NOT_JVMTI_RETURN in >> the ServiceThread::enqueue_deferred_event(). >> I'm curious why and will check if it is really needed. >> If so, will add it as well. >> >> Thanks, >> Serguei >> >> On 1/6/20 8:05 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Chris, >>> >>> Good catch. >>> I agree, for consistency the enqueue_event() is better to follow the >>> JvmtiDeferredEventQueue::enqueue() to avoid slowdebug minimal build >>> failures. >>> >>> New patch is: >>> >>> diff --git a/src/hotspot/share/prims/jvmtiThreadState.hpp >>> b/src/hotspot/share/prims/jvmtiThreadState.hpp >>> --- a/src/hotspot/share/prims/jvmtiThreadState.hpp >>> +++ b/src/hotspot/share/prims/jvmtiThreadState.hpp >>> @@ -396,7 +396,7 @@ >>> ?? void set_should_post_on_exceptions(bool val) { >>> _thread->set_should_post_on_exceptions_flag(val ? JNI_TRUE : >>> JNI_FALSE); } >>> >>> ?? // Thread local event queue, which doesn't require taking the >>> Service_lock. >>> -? void enqueue_event(JvmtiDeferredEvent* event); >>> +? void enqueue_event(JvmtiDeferredEvent* event) NOT_JVMTI_RETURN; >>> ?? void post_events(JvmtiEnv* env); >>> ?? void run_nmethod_entry_barriers(); >>> ?}; >>> >>> Thanks, >>> Serguei >>> >>> On 1/6/20 6:39 PM, Chris Plummer wrote: >>>> Hi Serguei, >>>> >>>> JvmtiDeferredEventQueue::enqueue() is a NOP for minimal builds, so >>>> it can be called even for minimalVM builds: >>>> >>>> ? void enqueue(JvmtiDeferredEvent event) NOT_JVMTI_RETURN; >>>> >>>> The changes for JDK-8212160 seem to have put some wrapper code >>>> around its use, resulting in >>>> ServiceThread::enqueue_deferred_event() and >>>> JvmtiThreadState::enqueue_event() being added. Shouldn't NOP >>>> implementations also have been done for them? >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 1/6/20 6:35 PM, Chris Plummer wrote: >>>>> Hold your horses. I have questions. Working on them now. Please >>>>> don't push. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 1/6/20 6:29 PM, coleen.phillimore at oracle.com wrote: >>>>>> This looks trivial.? Thank you for fixing it. >>>>>> Coleen >>>>>> >>>>>> On 1/6/20 9:18 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review a trivial fix for bug: >>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8236124 >>>>>>> >>>>>>> Patch suggested by A. Shipilev: >>>>>>> >>>>>>> diff --git a/src/hotspot/share/code/nmethod.cpp >>>>>>> b/src/hotspot/share/code/nmethod.cpp >>>>>>> --- a/src/hotspot/share/code/nmethod.cpp >>>>>>> +++ b/src/hotspot/share/code/nmethod.cpp >>>>>>> @@ -1601,7 +1601,7 @@ >>>>>>> ServiceThread::enqueue_deferred_event(&event); >>>>>>> ???? } else { >>>>>>> ?????? // This enters the nmethod barrier outside in the caller. >>>>>>> -????? state->enqueue_event(&event); >>>>>>> + JVMTI_ONLY(state->enqueue_event(&event)); >>>>>>> ???? } >>>>>>> ?? } >>>>>>> ?} >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> ? The slowdebug build was broken by the fix of JDK-8212160 which >>>>>>> introduced new function: enqueue_event(). >>>>>>> ? The fix is to call it only if the JVM TI is enabled. >>>>>>> >>>>>>> Testing: >>>>>>> ? Ran slowdebug build locally. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>> >>>>> >>>>> >>>> >>>> >>> >> > > From coleen.phillimore at oracle.com Tue Jan 7 19:45:36 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 7 Jan 2020 14:45:36 -0500 Subject: RFR(XXS): 8236124: Minimal VM slowdebug build failed after JDK-8212160 In-Reply-To: <49af3fea-f8b5-0bcc-af49-5967de4537e4@oracle.com> References: <984d18bf-0011-9895-e8e6-0c9f7e3427b6@oracle.com> <83d721d6-bcfa-a492-eb88-3c02391ad3d4@oracle.com> <15945b0e-3cb7-e836-3199-d9c9c93bd5da@oracle.com> <59537f7a-e523-87ec-08f2-3abd364d8d39@oracle.com> <49af3fea-f8b5-0bcc-af49-5967de4537e4@oracle.com> Message-ID: <69968d07-7788-2e8e-e825-24ab00b11f09@oracle.com> On 1/7/20 2:25 PM, serguei.spitsyn at oracle.com wrote: > Chris, > > The macro NOT_JVMTI_RETURN is never used outside of the prims/ folder. > Also, there is more work to get rid of the JVMTI code in the > ServiceThread. > I don't know how important is this for the minimal build. > So, I'd leave it alone for now and just fix the build issue. I think minimal vm should to exclude code at a larger granularity than this, ie. jvmtiThreadState.cpp isn't compiled at all.? We want to avoid as many #ifdef INCLUDE_JVMTI as possible.?? I don't think you should add it to serviceThread.cpp. thanks, Coleen > > Thanks, > Serguei > > On 1/7/20 10:04 AM, Chris Plummer wrote: >> Hi Serguei, >> >> The reason you don't see a build failure is because the >> implementation of ServiceThread::enqueue_deferred_event() is not in a >> JVMTI file that gets excluded from minimalVM builds, thus it is still >> callable and linkable. If you choose to use NOT_JVMTI_RETURN for it >> in the header file, then you will also need to #ifdef around the >> implementation. >> >> Chris >> >> On 1/7/20 9:16 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Chris, >>> >>> The slowdebug minimal build does not fail without NOT_JVMTI_RETURN >>> in the ServiceThread::enqueue_deferred_event(). >>> I'm curious why and will check if it is really needed. >>> If so, will add it as well. >>> >>> Thanks, >>> Serguei >>> >>> On 1/6/20 8:05 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Chris, >>>> >>>> Good catch. >>>> I agree, for consistency the enqueue_event() is better to follow >>>> the JvmtiDeferredEventQueue::enqueue() to avoid slowdebug minimal >>>> build failures. >>>> >>>> New patch is: >>>> >>>> diff --git a/src/hotspot/share/prims/jvmtiThreadState.hpp >>>> b/src/hotspot/share/prims/jvmtiThreadState.hpp >>>> --- a/src/hotspot/share/prims/jvmtiThreadState.hpp >>>> +++ b/src/hotspot/share/prims/jvmtiThreadState.hpp >>>> @@ -396,7 +396,7 @@ >>>> ?? void set_should_post_on_exceptions(bool val) { >>>> _thread->set_should_post_on_exceptions_flag(val ? JNI_TRUE : >>>> JNI_FALSE); } >>>> >>>> ?? // Thread local event queue, which doesn't require taking the >>>> Service_lock. >>>> -? void enqueue_event(JvmtiDeferredEvent* event); >>>> +? void enqueue_event(JvmtiDeferredEvent* event) NOT_JVMTI_RETURN; >>>> ?? void post_events(JvmtiEnv* env); >>>> ?? void run_nmethod_entry_barriers(); >>>> ?}; >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 1/6/20 6:39 PM, Chris Plummer wrote: >>>>> Hi Serguei, >>>>> >>>>> JvmtiDeferredEventQueue::enqueue() is a NOP for minimal builds, so >>>>> it can be called even for minimalVM builds: >>>>> >>>>> ? void enqueue(JvmtiDeferredEvent event) NOT_JVMTI_RETURN; >>>>> >>>>> The changes for JDK-8212160 seem to have put some wrapper code >>>>> around its use, resulting in >>>>> ServiceThread::enqueue_deferred_event() and >>>>> JvmtiThreadState::enqueue_event() being added. Shouldn't NOP >>>>> implementations also have been done for them? >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 1/6/20 6:35 PM, Chris Plummer wrote: >>>>>> Hold your horses. I have questions. Working on them now. Please >>>>>> don't push. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> On 1/6/20 6:29 PM, coleen.phillimore at oracle.com wrote: >>>>>>> This looks trivial.? Thank you for fixing it. >>>>>>> Coleen >>>>>>> >>>>>>> On 1/6/20 9:18 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Please, review a trivial fix for bug: >>>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8236124 >>>>>>>> >>>>>>>> Patch suggested by A. Shipilev: >>>>>>>> >>>>>>>> diff --git a/src/hotspot/share/code/nmethod.cpp >>>>>>>> b/src/hotspot/share/code/nmethod.cpp >>>>>>>> --- a/src/hotspot/share/code/nmethod.cpp >>>>>>>> +++ b/src/hotspot/share/code/nmethod.cpp >>>>>>>> @@ -1601,7 +1601,7 @@ >>>>>>>> ServiceThread::enqueue_deferred_event(&event); >>>>>>>> ???? } else { >>>>>>>> ?????? // This enters the nmethod barrier outside in the caller. >>>>>>>> -????? state->enqueue_event(&event); >>>>>>>> + JVMTI_ONLY(state->enqueue_event(&event)); >>>>>>>> ???? } >>>>>>>> ?? } >>>>>>>> ?} >>>>>>>> >>>>>>>> >>>>>>>> Summary: >>>>>>>> ? The slowdebug build was broken by the fix of JDK-8212160 >>>>>>>> which introduced new function: enqueue_event(). >>>>>>>> ? The fix is to call it only if the JVM TI is enabled. >>>>>>>> >>>>>>>> Testing: >>>>>>>> ? Ran slowdebug build locally. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> > From serguei.spitsyn at oracle.com Tue Jan 7 19:49:20 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 7 Jan 2020 11:49:20 -0800 Subject: RFR(XXS): 8236124: Minimal VM slowdebug build failed after JDK-8212160 In-Reply-To: <69968d07-7788-2e8e-e825-24ab00b11f09@oracle.com> References: <984d18bf-0011-9895-e8e6-0c9f7e3427b6@oracle.com> <83d721d6-bcfa-a492-eb88-3c02391ad3d4@oracle.com> <15945b0e-3cb7-e836-3199-d9c9c93bd5da@oracle.com> <59537f7a-e523-87ec-08f2-3abd364d8d39@oracle.com> <49af3fea-f8b5-0bcc-af49-5967de4537e4@oracle.com> <69968d07-7788-2e8e-e825-24ab00b11f09@oracle.com> Message-ID: <4bed8383-335b-ca25-57ed-f42533f136f9@oracle.com> On 1/7/20 11:45 AM, coleen.phillimore at oracle.com wrote: > > On 1/7/20 2:25 PM, serguei.spitsyn at oracle.com wrote: >> Chris, >> >> The macro NOT_JVMTI_RETURN is never used outside of the prims/ folder. >> Also, there is more work to get rid of the JVMTI code in the >> ServiceThread. >> I don't know how important is this for the minimal build. >> So, I'd leave it alone for now and just fix the build issue. > > I think minimal vm should to exclude code at a larger granularity than > this, ie. jvmtiThreadState.cpp isn't compiled at all.? We want to > avoid as many #ifdef INCLUDE_JVMTI as possible.?? I don't think you > should add it to serviceThread.cpp. Thanks, Coleen. I've checked with Chris, and he is also okay with this. So, I'll push the latest (2nd) patch. Thanks, Serguei > thanks, > Coleen > >> >> Thanks, >> Serguei >> >> On 1/7/20 10:04 AM, Chris Plummer wrote: >>> Hi Serguei, >>> >>> The reason you don't see a build failure is because the >>> implementation of ServiceThread::enqueue_deferred_event() is not in >>> a JVMTI file that gets excluded from minimalVM builds, thus it is >>> still callable and linkable. If you choose to use NOT_JVMTI_RETURN >>> for it in the header file, then you will also need to #ifdef around >>> the implementation. >>> >>> Chris >>> >>> On 1/7/20 9:16 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi Chris, >>>> >>>> The slowdebug minimal build does not fail without NOT_JVMTI_RETURN >>>> in the ServiceThread::enqueue_deferred_event(). >>>> I'm curious why and will check if it is really needed. >>>> If so, will add it as well. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 1/6/20 8:05 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Chris, >>>>> >>>>> Good catch. >>>>> I agree, for consistency the enqueue_event() is better to follow >>>>> the JvmtiDeferredEventQueue::enqueue() to avoid slowdebug minimal >>>>> build failures. >>>>> >>>>> New patch is: >>>>> >>>>> diff --git a/src/hotspot/share/prims/jvmtiThreadState.hpp >>>>> b/src/hotspot/share/prims/jvmtiThreadState.hpp >>>>> --- a/src/hotspot/share/prims/jvmtiThreadState.hpp >>>>> +++ b/src/hotspot/share/prims/jvmtiThreadState.hpp >>>>> @@ -396,7 +396,7 @@ >>>>> ?? void set_should_post_on_exceptions(bool val) { >>>>> _thread->set_should_post_on_exceptions_flag(val ? JNI_TRUE : >>>>> JNI_FALSE); } >>>>> >>>>> ?? // Thread local event queue, which doesn't require taking the >>>>> Service_lock. >>>>> -? void enqueue_event(JvmtiDeferredEvent* event); >>>>> +? void enqueue_event(JvmtiDeferredEvent* event) NOT_JVMTI_RETURN; >>>>> ?? void post_events(JvmtiEnv* env); >>>>> ?? void run_nmethod_entry_barriers(); >>>>> ?}; >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 1/6/20 6:39 PM, Chris Plummer wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> JvmtiDeferredEventQueue::enqueue() is a NOP for minimal builds, >>>>>> so it can be called even for minimalVM builds: >>>>>> >>>>>> ? void enqueue(JvmtiDeferredEvent event) NOT_JVMTI_RETURN; >>>>>> >>>>>> The changes for JDK-8212160 seem to have put some wrapper code >>>>>> around its use, resulting in >>>>>> ServiceThread::enqueue_deferred_event() and >>>>>> JvmtiThreadState::enqueue_event() being added. Shouldn't NOP >>>>>> implementations also have been done for them? >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> On 1/6/20 6:35 PM, Chris Plummer wrote: >>>>>>> Hold your horses. I have questions. Working on them now. Please >>>>>>> don't push. >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 1/6/20 6:29 PM, coleen.phillimore at oracle.com wrote: >>>>>>>> This looks trivial.? Thank you for fixing it. >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 1/6/20 9:18 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Please, review a trivial fix for bug: >>>>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8236124 >>>>>>>>> >>>>>>>>> Patch suggested by A. Shipilev: >>>>>>>>> >>>>>>>>> diff --git a/src/hotspot/share/code/nmethod.cpp >>>>>>>>> b/src/hotspot/share/code/nmethod.cpp >>>>>>>>> --- a/src/hotspot/share/code/nmethod.cpp >>>>>>>>> +++ b/src/hotspot/share/code/nmethod.cpp >>>>>>>>> @@ -1601,7 +1601,7 @@ >>>>>>>>> ServiceThread::enqueue_deferred_event(&event); >>>>>>>>> ???? } else { >>>>>>>>> ?????? // This enters the nmethod barrier outside in the caller. >>>>>>>>> -????? state->enqueue_event(&event); >>>>>>>>> + JVMTI_ONLY(state->enqueue_event(&event)); >>>>>>>>> ???? } >>>>>>>>> ?? } >>>>>>>>> ?} >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> ? The slowdebug build was broken by the fix of JDK-8212160 >>>>>>>>> which introduced new function: enqueue_event(). >>>>>>>>> ? The fix is to call it only if the JVM TI is enabled. >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> ? Ran slowdebug build locally. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >> > From alexey.menkov at oracle.com Wed Jan 8 01:57:37 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 7 Jan 2020 17:57:37 -0800 Subject: PING: RFR: JDK-8235846: Improve WindbgDebuggerLocal implementation In-Reply-To: <8ca073bf-0f82-46d5-7fd1-0a5b5757bfa4@oracle.com> References: <8ca073bf-0f82-46d5-7fd1-0a5b5757bfa4@oracle.com> Message-ID: <70fddba4-465e-8df3-a2e3-8a24b1be3cd1@oracle.com> Ping. Updated copyright header (to 2020) in place. --alex On 12/19/2019 15:34, Alex Menkov wrote: > Hi all, > > Please review a fix for > https://bugs.openjdk.java.net/browse/JDK-8235846 > webrev: > http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.01/ > > Main goal of the change is to improve error reporting (we have several > bugs and need at least COM error codes for WinDbg calls). > Also the fix improves/rearranges this quite old code. > > --alex From serguei.spitsyn at oracle.com Wed Jan 8 21:42:00 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 8 Jan 2020 13:42:00 -0800 Subject: JDK 14 RFR(XXS): 8229847: AttachProvider javadoc page needs an update Message-ID: <816ef6a4-fc6a-deb6-ce1d-3b8e3b2f9c78@oracle.com> Please, review a trivial fix for the doc bug: ? https://bugs.openjdk.java.net/browse/JDK-8229847 The patch is: diff --git a/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java b/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java --- a/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java +++ b/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java @@ -46,16 +46,16 @@ ? *

An attach provider implementation is typically tied to a Java virtual ? * machine implementation, version, or even mode of operation. That is, a specific ? * provider implementation will typically only be capable of attaching to - * a specific Java virtual machine implementation or version. For example, Sun's + * a specific Java virtual machine implementation or version. For example, Oracle's ? * JDK implementation ships with provider implementations that can only attach to - * Sun's HotSpot virtual machine. In general, if an environment + * Oracle's HotSpot virtual machine. In general, if an environment ? * consists of Java virtual machines of different versions and from different ? * vendors then there will be an attach provider implementation for each ? * family of implementations or versions. ? * ? *

An attach provider is identified by its {@link #name name} and ? * {@link #type type}. The name is typically, but not required to - * be, a name that corresponds to the VM vendor. The Sun JDK implementation, + * be, a name that corresponds to the VM vendor. The Oracle JDK implementation, ? * for example, ships with attach providers that use the name "sun". The ? * type typically corresponds to the attach mechanism. For example, an ? * implementation that uses the Doors inter-process communication mechanism Summary: ? The AttachProvider spec became a little obsolete. ? It should not refer to Sun implementation. ? The fix is to replace 'Sun' with 'Oracle' in 3 places. ? I don't think we need a CSR for this doc change. Thanks, Serguei From david.holmes at oracle.com Wed Jan 8 22:54:37 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 Jan 2020 08:54:37 +1000 Subject: JDK 14 RFR(XXS): 8229847: AttachProvider javadoc page needs an update In-Reply-To: <816ef6a4-fc6a-deb6-ce1d-3b8e3b2f9c78@oracle.com> References: <816ef6a4-fc6a-deb6-ce1d-3b8e3b2f9c78@oracle.com> Message-ID: Hi Serguei, On 9/01/2020 7:42 am, serguei.spitsyn at oracle.com wrote: > Please, review a trivial fix for the doc bug: > ? https://bugs.openjdk.java.net/browse/JDK-8229847 > > The patch is: > > diff --git > a/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java > b/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java > --- > a/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java > +++ > b/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java > @@ -46,16 +46,16 @@ > ? *

An attach provider implementation is typically tied to a Java > virtual > ? * machine implementation, version, or even mode of operation. That > is, a specific > ? * provider implementation will typically only be capable of attaching to > - * a specific Java virtual machine implementation or version. For > example, Sun's > + * a specific Java virtual machine implementation or version. For > example, Oracle's > ? * JDK implementation ships with provider implementations that can > only attach to > - * Sun's HotSpot virtual machine. In general, if an environment > + * Oracle's HotSpot virtual machine. In general, if an environment > ? * consists of Java virtual machines of different versions and from > different > ? * vendors then there will be an attach provider implementation for each > ? * family of implementations or versions. > ? * > ? *

An attach provider is identified by its {@link #name > name} and > ? * {@link #type type}. The name is typically, but not > required to > - * be, a name that corresponds to the VM vendor. The Sun JDK > implementation, > + * be, a name that corresponds to the VM vendor. The Oracle JDK > implementation, > ? * for example, ships with attach providers that use the name > "sun". The Perhaps clarify with that use the name "sun" (for historical reasons). ? > ? * type typically corresponds to the attach mechanism. For > example, an > ? * implementation that uses the Doors inter-process communication > mechanism > > > Summary: > ? The AttachProvider spec became a little obsolete. > ? It should not refer to Sun implementation. > ? The fix is to replace 'Sun' with 'Oracle' in 3 places. > ? I don't think we need a CSR for this doc change. I agree no CSR request is needed. Thanks, David > > Thanks, > Serguei From serguei.spitsyn at oracle.com Wed Jan 8 23:50:25 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 8 Jan 2020 15:50:25 -0800 Subject: JDK 14 RFR(XXS): 8229847: AttachProvider javadoc page needs an update In-Reply-To: References: <816ef6a4-fc6a-deb6-ce1d-3b8e3b2f9c78@oracle.com> Message-ID: <7c2c8b32-e646-88bf-87e3-3fdae2febfd8@oracle.com> Hi David, On 1/8/20 14:54, David Holmes wrote: > Hi Serguei, > > On 9/01/2020 7:42 am, serguei.spitsyn at oracle.com wrote: >> Please, review a trivial fix for the doc bug: >> ?? https://bugs.openjdk.java.net/browse/JDK-8229847 >> >> The patch is: >> >> diff --git >> a/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >> b/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >> >> --- >> a/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >> +++ >> b/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >> @@ -46,16 +46,16 @@ >> ?? *

An attach provider implementation is typically tied to a >> Java virtual >> ?? * machine implementation, version, or even mode of operation. That >> is, a specific >> ?? * provider implementation will typically only be capable of >> attaching to >> - * a specific Java virtual machine implementation or version. For >> example, Sun's >> + * a specific Java virtual machine implementation or version. For >> example, Oracle's >> ?? * JDK implementation ships with provider implementations that can >> only attach to >> - * Sun's HotSpot virtual machine. In general, if an environment >> + * Oracle's HotSpot virtual machine. In general, if an >> environment >> ?? * consists of Java virtual machines of different versions and from >> different >> ?? * vendors then there will be an attach provider implementation for >> each >> ?? * family of implementations or versions. >> ?? * >> ?? *

An attach provider is identified by its {@link #name >> name} and >> ?? * {@link #type type}. The name is typically, but not >> required to >> - * be, a name that corresponds to the VM vendor. The Sun JDK >> implementation, >> + * be, a name that corresponds to the VM vendor. The Oracle JDK >> implementation, >> ?? * for example, ships with attach providers that use the name >> "sun". The > > Perhaps clarify with > > that use the name "sun" (for historical reasons). Good suggestion, will update it. I also think about this tweak: ? that use the package name "sun" (for historical reasons). as it is used for the package name only. > > ? > >> ?? * type typically corresponds to the attach mechanism. For >> example, an >> ?? * implementation that uses the Doors inter-process communication >> mechanism >> >> >> Summary: >> ?? The AttachProvider spec became a little obsolete. >> ?? It should not refer to Sun implementation. >> ?? The fix is to replace 'Sun' with 'Oracle' in 3 places. >> ?? I don't think we need a CSR for this doc change. > > I agree no CSR request is needed. Good. Thank you for review, David! Serguei > Thanks, > David > >> >> Thanks, >> Serguei From serguei.spitsyn at oracle.com Thu Jan 9 21:54:42 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 9 Jan 2020 13:54:42 -0800 Subject: JDK 14 RFR(XXS): 8229847: AttachProvider javadoc page needs an update In-Reply-To: <7c2c8b32-e646-88bf-87e3-3fdae2febfd8@oracle.com> References: <816ef6a4-fc6a-deb6-ce1d-3b8e3b2f9c78@oracle.com> <7c2c8b32-e646-88bf-87e3-3fdae2febfd8@oracle.com> Message-ID: Hi David and Alex, The updated webrev is: http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/AttachProvider-doc.1/ Thanks, Serguei On 1/8/20 3:50 PM, serguei.spitsyn at oracle.com wrote: > Hi David, > > > On 1/8/20 14:54, David Holmes wrote: >> Hi Serguei, >> >> On 9/01/2020 7:42 am, serguei.spitsyn at oracle.com wrote: >>> Please, review a trivial fix for the doc bug: >>> ?? https://bugs.openjdk.java.net/browse/JDK-8229847 >>> >>> The patch is: >>> >>> diff --git >>> a/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>> b/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>> >>> --- >>> a/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>> +++ >>> b/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>> @@ -46,16 +46,16 @@ >>> ?? *

An attach provider implementation is typically tied to a >>> Java virtual >>> ?? * machine implementation, version, or even mode of operation. >>> That is, a specific >>> ?? * provider implementation will typically only be capable of >>> attaching to >>> - * a specific Java virtual machine implementation or version. For >>> example, Sun's >>> + * a specific Java virtual machine implementation or version. For >>> example, Oracle's >>> ?? * JDK implementation ships with provider implementations that can >>> only attach to >>> - * Sun's HotSpot virtual machine. In general, if an environment >>> + * Oracle's HotSpot virtual machine. In general, if an >>> environment >>> ?? * consists of Java virtual machines of different versions and >>> from different >>> ?? * vendors then there will be an attach provider implementation >>> for each >>> ?? * family of implementations or versions. >>> ?? * >>> ?? *

An attach provider is identified by its {@link #name >>> name} and >>> ?? * {@link #type type}. The name is typically, but >>> not required to >>> - * be, a name that corresponds to the VM vendor. The Sun JDK >>> implementation, >>> + * be, a name that corresponds to the VM vendor. The Oracle JDK >>> implementation, >>> ?? * for example, ships with attach providers that use the name >>> "sun". The >> >> Perhaps clarify with >> >> that use the name "sun" (for historical reasons). > > Good suggestion, will update it. > > I also think about this tweak: > ? that use the package name "sun" (for historical reasons). > > as it is used for the package name only. > >> >> ? >> >>> ?? * type typically corresponds to the attach mechanism. For >>> example, an >>> ?? * implementation that uses the Doors inter-process communication >>> mechanism >>> >>> >>> Summary: >>> ?? The AttachProvider spec became a little obsolete. >>> ?? It should not refer to Sun implementation. >>> ?? The fix is to replace 'Sun' with 'Oracle' in 3 places. >>> ?? I don't think we need a CSR for this doc change. >> >> I agree no CSR request is needed. > > Good. > > Thank you for review, David! > Serguei > > >> Thanks, >> David >> >>> >>> Thanks, >>> Serguei > From alexey.menkov at oracle.com Thu Jan 9 23:51:37 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 9 Jan 2020 15:51:37 -0800 Subject: JDK 14 RFR(XXS): 8229847: AttachProvider javadoc page needs an update In-Reply-To: References: <816ef6a4-fc6a-deb6-ce1d-3b8e3b2f9c78@oracle.com> <7c2c8b32-e646-88bf-87e3-3fdae2febfd8@oracle.com> Message-ID: <29bfea53-5e3a-ab62-e238-55e9d506b627@oracle.com> LGTM --alex On 01/09/2020 13:54, serguei.spitsyn at oracle.com wrote: > Hi David and Alex, > > The updated webrev is: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/AttachProvider-doc.1/ > > > Thanks, > Serguei > > On 1/8/20 3:50 PM, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> >> On 1/8/20 14:54, David Holmes wrote: >>> Hi Serguei, >>> >>> On 9/01/2020 7:42 am, serguei.spitsyn at oracle.com wrote: >>>> Please, review a trivial fix for the doc bug: >>>> ?? https://bugs.openjdk.java.net/browse/JDK-8229847 >>>> >>>> The patch is: >>>> >>>> diff --git >>>> a/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>>> b/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>>> >>>> --- >>>> a/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>>> >>>> +++ >>>> b/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>>> >>>> @@ -46,16 +46,16 @@ >>>> ?? *

An attach provider implementation is typically tied to a >>>> Java virtual >>>> ?? * machine implementation, version, or even mode of operation. >>>> That is, a specific >>>> ?? * provider implementation will typically only be capable of >>>> attaching to >>>> - * a specific Java virtual machine implementation or version. For >>>> example, Sun's >>>> + * a specific Java virtual machine implementation or version. For >>>> example, Oracle's >>>> ?? * JDK implementation ships with provider implementations that can >>>> only attach to >>>> - * Sun's HotSpot virtual machine. In general, if an environment >>>> + * Oracle's HotSpot virtual machine. In general, if an >>>> environment >>>> ?? * consists of Java virtual machines of different versions and >>>> from different >>>> ?? * vendors then there will be an attach provider implementation >>>> for each >>>> ?? * family of implementations or versions. >>>> ?? * >>>> ?? *

An attach provider is identified by its {@link #name >>>> name} and >>>> ?? * {@link #type type}. The name is typically, but >>>> not required to >>>> - * be, a name that corresponds to the VM vendor. The Sun JDK >>>> implementation, >>>> + * be, a name that corresponds to the VM vendor. The Oracle JDK >>>> implementation, >>>> ?? * for example, ships with attach providers that use the name >>>> "sun". The >>> >>> Perhaps clarify with >>> >>> that use the name "sun" (for historical reasons). >> >> Good suggestion, will update it. >> >> I also think about this tweak: >> ? that use the package name "sun" (for historical reasons). >> >> as it is used for the package name only. >> >>> >>> ? >>> >>>> ?? * type typically corresponds to the attach mechanism. For >>>> example, an >>>> ?? * implementation that uses the Doors inter-process communication >>>> mechanism >>>> >>>> >>>> Summary: >>>> ?? The AttachProvider spec became a little obsolete. >>>> ?? It should not refer to Sun implementation. >>>> ?? The fix is to replace 'Sun' with 'Oracle' in 3 places. >>>> ?? I don't think we need a CSR for this doc change. >>> >>> I agree no CSR request is needed. >> >> Good. >> >> Thank you for review, David! >> Serguei >> >> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> Serguei >> > From serguei.spitsyn at oracle.com Fri Jan 10 00:34:10 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 9 Jan 2020 16:34:10 -0800 Subject: JDK 14 RFR(XXS): 8229847: AttachProvider javadoc page needs an update In-Reply-To: <29bfea53-5e3a-ab62-e238-55e9d506b627@oracle.com> References: <816ef6a4-fc6a-deb6-ce1d-3b8e3b2f9c78@oracle.com> <7c2c8b32-e646-88bf-87e3-3fdae2febfd8@oracle.com> <29bfea53-5e3a-ab62-e238-55e9d506b627@oracle.com> Message-ID: Thanks, Alex! Serguei On 1/9/20 3:51 PM, Alex Menkov wrote: > LGTM > > --alex > > On 01/09/2020 13:54, serguei.spitsyn at oracle.com wrote: >> Hi David and Alex, >> >> The updated webrev is: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/AttachProvider-doc.1/ >> >> >> Thanks, >> Serguei >> >> On 1/8/20 3:50 PM, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> >>> On 1/8/20 14:54, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> On 9/01/2020 7:42 am, serguei.spitsyn at oracle.com wrote: >>>>> Please, review a trivial fix for the doc bug: >>>>> ?? https://bugs.openjdk.java.net/browse/JDK-8229847 >>>>> >>>>> The patch is: >>>>> >>>>> diff --git >>>>> a/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>>>> b/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>>>> >>>>> --- >>>>> a/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>>>> >>>>> +++ >>>>> b/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>>>> >>>>> @@ -46,16 +46,16 @@ >>>>> ?? *

An attach provider implementation is typically tied to a >>>>> Java virtual >>>>> ?? * machine implementation, version, or even mode of operation. >>>>> That is, a specific >>>>> ?? * provider implementation will typically only be capable of >>>>> attaching to >>>>> - * a specific Java virtual machine implementation or version. For >>>>> example, Sun's >>>>> + * a specific Java virtual machine implementation or version. For >>>>> example, Oracle's >>>>> ?? * JDK implementation ships with provider implementations that >>>>> can only attach to >>>>> - * Sun's HotSpot virtual machine. In general, if an >>>>> environment >>>>> + * Oracle's HotSpot virtual machine. In general, if an >>>>> environment >>>>> ?? * consists of Java virtual machines of different versions and >>>>> from different >>>>> ?? * vendors then there will be an attach provider implementation >>>>> for each >>>>> ?? * family of implementations or versions. >>>>> ?? * >>>>> ?? *

An attach provider is identified by its {@link #name >>>>> name} and >>>>> ?? * {@link #type type}. The name is typically, but >>>>> not required to >>>>> - * be, a name that corresponds to the VM vendor. The Sun JDK >>>>> implementation, >>>>> + * be, a name that corresponds to the VM vendor. The Oracle JDK >>>>> implementation, >>>>> ?? * for example, ships with attach providers that use the name >>>>> "sun". The >>>> >>>> Perhaps clarify with >>>> >>>> that use the name "sun" (for historical reasons). >>> >>> Good suggestion, will update it. >>> >>> I also think about this tweak: >>> ? that use the package name "sun" (for historical reasons). >>> >>> as it is used for the package name only. >>> >>>> >>>> ? >>>> >>>>> ?? * type typically corresponds to the attach mechanism. >>>>> For example, an >>>>> ?? * implementation that uses the Doors inter-process >>>>> communication mechanism >>>>> >>>>> >>>>> Summary: >>>>> ?? The AttachProvider spec became a little obsolete. >>>>> ?? It should not refer to Sun implementation. >>>>> ?? The fix is to replace 'Sun' with 'Oracle' in 3 places. >>>>> ?? I don't think we need a CSR for this doc change. >>>> >>>> I agree no CSR request is needed. >>> >>> Good. >>> >>> Thank you for review, David! >>> Serguei >>> >>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>> >> From david.holmes at oracle.com Fri Jan 10 01:22:40 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 Jan 2020 11:22:40 +1000 Subject: JDK 14 RFR(XXS): 8229847: AttachProvider javadoc page needs an update In-Reply-To: <29bfea53-5e3a-ab62-e238-55e9d506b627@oracle.com> References: <816ef6a4-fc6a-deb6-ce1d-3b8e3b2f9c78@oracle.com> <7c2c8b32-e646-88bf-87e3-3fdae2febfd8@oracle.com> <29bfea53-5e3a-ab62-e238-55e9d506b627@oracle.com> Message-ID: +1 Thanks, David On 10/01/2020 9:51 am, Alex Menkov wrote: > LGTM > > --alex > > On 01/09/2020 13:54, serguei.spitsyn at oracle.com wrote: >> Hi David and Alex, >> >> The updated webrev is: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/AttachProvider-doc.1/ >> >> >> Thanks, >> Serguei >> >> On 1/8/20 3:50 PM, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> >>> On 1/8/20 14:54, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> On 9/01/2020 7:42 am, serguei.spitsyn at oracle.com wrote: >>>>> Please, review a trivial fix for the doc bug: >>>>> ?? https://bugs.openjdk.java.net/browse/JDK-8229847 >>>>> >>>>> The patch is: >>>>> >>>>> diff --git >>>>> a/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>>>> b/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>>>> >>>>> --- >>>>> a/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>>>> >>>>> +++ >>>>> b/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>>>> >>>>> @@ -46,16 +46,16 @@ >>>>> ?? *

An attach provider implementation is typically tied to a >>>>> Java virtual >>>>> ?? * machine implementation, version, or even mode of operation. >>>>> That is, a specific >>>>> ?? * provider implementation will typically only be capable of >>>>> attaching to >>>>> - * a specific Java virtual machine implementation or version. For >>>>> example, Sun's >>>>> + * a specific Java virtual machine implementation or version. For >>>>> example, Oracle's >>>>> ?? * JDK implementation ships with provider implementations that >>>>> can only attach to >>>>> - * Sun's HotSpot virtual machine. In general, if an >>>>> environment >>>>> + * Oracle's HotSpot virtual machine. In general, if an >>>>> environment >>>>> ?? * consists of Java virtual machines of different versions and >>>>> from different >>>>> ?? * vendors then there will be an attach provider implementation >>>>> for each >>>>> ?? * family of implementations or versions. >>>>> ?? * >>>>> ?? *

An attach provider is identified by its {@link #name >>>>> name} and >>>>> ?? * {@link #type type}. The name is typically, but >>>>> not required to >>>>> - * be, a name that corresponds to the VM vendor. The Sun JDK >>>>> implementation, >>>>> + * be, a name that corresponds to the VM vendor. The Oracle JDK >>>>> implementation, >>>>> ?? * for example, ships with attach providers that use the name >>>>> "sun". The >>>> >>>> Perhaps clarify with >>>> >>>> that use the name "sun" (for historical reasons). >>> >>> Good suggestion, will update it. >>> >>> I also think about this tweak: >>> ? that use the package name "sun" (for historical reasons). >>> >>> as it is used for the package name only. >>> >>>> >>>> ? >>>> >>>>> ?? * type typically corresponds to the attach mechanism. For >>>>> example, an >>>>> ?? * implementation that uses the Doors inter-process communication >>>>> mechanism >>>>> >>>>> >>>>> Summary: >>>>> ?? The AttachProvider spec became a little obsolete. >>>>> ?? It should not refer to Sun implementation. >>>>> ?? The fix is to replace 'Sun' with 'Oracle' in 3 places. >>>>> ?? I don't think we need a CSR for this doc change. >>>> >>>> I agree no CSR request is needed. >>> >>> Good. >>> >>> Thank you for review, David! >>> Serguei >>> >>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>> >> From serguei.spitsyn at oracle.com Fri Jan 10 01:28:37 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 9 Jan 2020 17:28:37 -0800 Subject: JDK 14 RFR(XXS): 8229847: AttachProvider javadoc page needs an update In-Reply-To: References: <816ef6a4-fc6a-deb6-ce1d-3b8e3b2f9c78@oracle.com> <7c2c8b32-e646-88bf-87e3-3fdae2febfd8@oracle.com> <29bfea53-5e3a-ab62-e238-55e9d506b627@oracle.com> Message-ID: <2fe4be63-0e25-5563-7a68-3a9e447f52d4@oracle.com> Thanks, David! Serguei On 1/9/20 5:22 PM, David Holmes wrote: > +1 > > Thanks, > David > > On 10/01/2020 9:51 am, Alex Menkov wrote: >> LGTM >> >> --alex >> >> On 01/09/2020 13:54, serguei.spitsyn at oracle.com wrote: >>> Hi David and Alex, >>> >>> The updated webrev is: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/AttachProvider-doc.1/ >>> >>> >>> Thanks, >>> Serguei >>> >>> On 1/8/20 3:50 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi David, >>>> >>>> >>>> On 1/8/20 14:54, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> On 9/01/2020 7:42 am, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review a trivial fix for the doc bug: >>>>>> ?? https://bugs.openjdk.java.net/browse/JDK-8229847 >>>>>> >>>>>> The patch is: >>>>>> >>>>>> diff --git >>>>>> a/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>>>>> b/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>>>>> >>>>>> --- >>>>>> a/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>>>>> >>>>>> +++ >>>>>> b/src/jdk.attach/share/classes/com/sun/tools/attach/spi/AttachProvider.java >>>>>> >>>>>> @@ -46,16 +46,16 @@ >>>>>> ?? *

An attach provider implementation is typically tied to a >>>>>> Java virtual >>>>>> ?? * machine implementation, version, or even mode of operation. >>>>>> That is, a specific >>>>>> ?? * provider implementation will typically only be capable of >>>>>> attaching to >>>>>> - * a specific Java virtual machine implementation or version. >>>>>> For example, Sun's >>>>>> + * a specific Java virtual machine implementation or version. >>>>>> For example, Oracle's >>>>>> ?? * JDK implementation ships with provider implementations that >>>>>> can only attach to >>>>>> - * Sun's HotSpot virtual machine. In general, if an >>>>>> environment >>>>>> + * Oracle's HotSpot virtual machine. In general, if an >>>>>> environment >>>>>> ?? * consists of Java virtual machines of different versions and >>>>>> from different >>>>>> ?? * vendors then there will be an attach provider implementation >>>>>> for each >>>>>> ?? * family of implementations or versions. >>>>>> ?? * >>>>>> ?? *

An attach provider is identified by its {@link #name >>>>>> name} and >>>>>> ?? * {@link #type type}. The name is typically, but >>>>>> not required to >>>>>> - * be, a name that corresponds to the VM vendor. The Sun JDK >>>>>> implementation, >>>>>> + * be, a name that corresponds to the VM vendor. The Oracle JDK >>>>>> implementation, >>>>>> ?? * for example, ships with attach providers that use the name >>>>>> "sun". The >>>>> >>>>> Perhaps clarify with >>>>> >>>>> that use the name "sun" (for historical reasons). >>>> >>>> Good suggestion, will update it. >>>> >>>> I also think about this tweak: >>>> ? that use the package name "sun" (for historical reasons). >>>> >>>> as it is used for the package name only. >>>> >>>>> >>>>> ? >>>>> >>>>>> ?? * type typically corresponds to the attach mechanism. >>>>>> For example, an >>>>>> ?? * implementation that uses the Doors inter-process >>>>>> communication mechanism >>>>>> >>>>>> >>>>>> Summary: >>>>>> ?? The AttachProvider spec became a little obsolete. >>>>>> ?? It should not refer to Sun implementation. >>>>>> ?? The fix is to replace 'Sun' with 'Oracle' in 3 places. >>>>>> ?? I don't think we need a CSR for this doc change. >>>>> >>>>> I agree no CSR request is needed. >>>> >>>> Good. >>>> >>>> Thank you for review, David! >>>> Serguei >>>> >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>> >>> From matthias.baesken at sap.com Fri Jan 10 10:01:47 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 10 Jan 2020 10:01:47 +0000 Subject: serviceability agent : problems when using gcc LTO (link time optimization) Message-ID: Hello, I recently looked into the gcc lto optimization mode (see for some details https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html and http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html ). This mode can lead to more compact binaries (~10% smaller) , it also might bring small performance improvements but that wasn't my (main) goal . The changes for this are rather small , one needs to use a recent gcc , add -flto to the compile flags , for example --- a/make/autoconf/flags-cflags.m4 Wed Jan 01 03:08:45 2020 +0100 +++ b/make/autoconf/flags-cflags.m4 Wed Jan 08 17:39:10 2020 +0100 @@ -530,8 +530,13 @@ fi if test "x$TOOLCHAIN_TYPE" = xgcc; then - TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new -fstack-protector" - TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector" + TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new -fstack-protector -flto" + TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector -flto" .... and you have to make sure to use gcc-ar and gcc-nm instead of ar / nm . Build and test(s) work, however with one exception. The serviceability tests like serviceability/sa seems to rely heavily on the "normal" structure of libjvm.so (from what I understand e.g. in LinuxVtblAccess it is attempted to access internal symbols like _ZTV ). Errors in the sa tests look like : java.lang.InternalError: Metadata does not appear to be polymorphic at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:279) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:102) at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:74) at jdk.hotspot.agent/sun.jvm.hotspot.memory.SystemDictionary.getClassLoaderKlass(SystemDictionary.java:96) at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:93) at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:115) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:262) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:225) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:176) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:321) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:406) Has anyone experimented with LTO optimization ? And to the serviceability agent experts - any idea how to make the jdk.hotspot.agent more independent from optimization settings ? Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Jan 10 19:27:36 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 10 Jan 2020 11:27:36 -0800 Subject: RFR(M): 8236913: debug agent's jdwp command logging should include the command set name and command name Message-ID: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> Hello, Please review the following https://bugs.openjdk.java.net/browse/JDK-8236913 http://cr.openjdk.java.net/~cjplummer/8236913/webrev.00/ The debug agent has logging support that will trace all jdwp commands coming in. Currently all it traces is the command set number and the command number within that command set. So you see something like: [#|10.01.2020 06:27:24.366 GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command set 1, command 9|#] I've added support for including the name of the command set and command, so now you see: [#|10.01.2020 06:27:24.366 GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command set VirtualMachine(1), command Resume(9)|#] So in this case command set 1 represents VirtualMachine and command 9 is the Resume command. I was initially going to leverage jdwp.spec which is already processed by build.tools.jdwpgen.Main to produce JDWP.java and JDWPCommands.h. However, I could see it was more of a challenge than I initially hoped. Also, the main advantage would have been not having to hard code arrays of command names, but we already have harded coded arrays of function pointers to handle the various jdwp commands, so I just replaced these with a more specialized arrays that also include the names of the commands. As an example, we used to have: void *ArrayReference_Cmds[] = { (void *)0x3 ??? ,(void *)length ??? ,(void *)getValues ??? ,(void *)setValues}; Now we have: CommandSet ArrayReference_Cmds = { ??? 3, "ArrayReference", ??? { ??????? {length, "Length"}, ??????? {getValues, "GetValues"}, ??????? {setValues, "SetValues"} ??? } }; So no worse w.r.t. hard coding things that could be generated off the spec, and it cleans up some ugly casts also. The CommandSet typedef can be found in debugDispatch.h. All the header files except for debugDispatch.h have the same pattern for changes, so they are pretty easy to review All .c files except debugDispatch.c and debugLoop.c also have the same pattern. Note some command handler function names are not the same as the command name. If you want to double check command set names and command names, you can find the spec here: https://docs.oracle.com/javase/9/docs/specs/jdwp/jdwp-protocol.html In ReferenceTypeImpl.c I fixed a typo in the method() prototype. It had an extra argument which I think was a very old copy-n-paste bug from the method1() prototype. This was caught because the command handler functions are now directly assigned to a CommandHandler type rather than cast. The cast was hiding this bug. I tested by doing a test run where MISC logging was enabled by default. All jdwp, jdb, and jdi tests were run in this way and passed. thanks, Chris From chris.plummer at oracle.com Fri Jan 10 19:52:24 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 10 Jan 2020 11:52:24 -0800 Subject: serviceability agent : problems when using gcc LTO (link time optimization) In-Reply-To: References: Message-ID: <62d26da1-f717-d94b-dccf-c860136a17cb@oracle.com> An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Fri Jan 10 22:12:00 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 10 Jan 2020 14:12:00 -0800 Subject: RFR(M): 8236913: debug agent's jdwp command logging should include the command set name and command name In-Reply-To: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> References: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> Message-ID: <9babaeab-f9ec-57c7-ad32-69d7051dffba@oracle.com> Hi Chris, Thanks for making the code more "typed" (this "void*" arrays are error prone). Looks good in general, some minor comments: MethodImpl.c - command names starts with lower case letters ReferenceTypeImpl.c - please fix indentation for command definitions debugDispatch.h/.c +debugDispatch_getHandler(int cmdSetNum, int cmdNum, const char **cmdSetName_p, const char **cmdName_p) What are the "_p" suffixes for? to show that this are pointers? To me this doesn't make much sense. --alex On 01/10/2020 11:27, Chris Plummer wrote: > Hello, > > Please review the following > > https://bugs.openjdk.java.net/browse/JDK-8236913 > http://cr.openjdk.java.net/~cjplummer/8236913/webrev.00/ > > The debug agent has logging support that will trace all jdwp commands > coming in. Currently all it traces is the command set number and the > command number within that command set. So you see something like: > > [#|10.01.2020 06:27:24.366 > GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command > set 1, command 9|#] > > I've added support for including the name of the command set and > command, so now you see: > > [#|10.01.2020 06:27:24.366 > GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command > set VirtualMachine(1), command Resume(9)|#] > > So in this case command set 1 represents VirtualMachine and command 9 is > the Resume command. > > I was initially going to leverage jdwp.spec which is already processed > by build.tools.jdwpgen.Main to produce JDWP.java and JDWPCommands.h. > However, I could see it was more of a challenge than I initially hoped. > Also, the main advantage would have been not having to hard code arrays > of command names, but we already have harded coded arrays of function > pointers to handle the various jdwp commands, so I just replaced these > with a more specialized arrays that also include the names of the > commands. As an example, we used to have: > > void *ArrayReference_Cmds[] = { (void *)0x3 > ??? ,(void *)length > ??? ,(void *)getValues > ??? ,(void *)setValues}; > > Now we have: > > CommandSet ArrayReference_Cmds = { > ??? 3, "ArrayReference", > ??? { > ??????? {length, "Length"}, > ??????? {getValues, "GetValues"}, > ??????? {setValues, "SetValues"} > ??? } > }; > > So no worse w.r.t. hard coding things that could be generated off the > spec, and it cleans up some ugly casts also. The CommandSet typedef can > be found in debugDispatch.h. > > All the header files except for debugDispatch.h have the same pattern > for changes, so they are pretty easy to review > > All .c files except debugDispatch.c and debugLoop.c also have the same > pattern. Note some command handler function names are not the same as > the command name. If you want to double check command set names and > command names, you can find the spec here: > > https://docs.oracle.com/javase/9/docs/specs/jdwp/jdwp-protocol.html > > In ReferenceTypeImpl.c I fixed a typo in the method() prototype. It had > an extra argument which I think was a very old copy-n-paste bug from the > method1() prototype. This was caught because the command handler > functions are now directly assigned to a CommandHandler type rather than > cast. The cast was hiding this bug. > > I tested by doing a test run where MISC logging was enabled by default. > All jdwp, jdb, and jdi tests were run in this way and passed. > > thanks, > > Chris > From chris.plummer at oracle.com Fri Jan 10 23:00:20 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 10 Jan 2020 15:00:20 -0800 Subject: RFR(M): 8236913: debug agent's jdwp command logging should include the command set name and command name In-Reply-To: <9babaeab-f9ec-57c7-ad32-69d7051dffba@oracle.com> References: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> <9babaeab-f9ec-57c7-ad32-69d7051dffba@oracle.com> Message-ID: Hi Alex, I'll fix the mistakes in MethodImpl.c and ReferenceTypeImpl.c. As for the "_p" suffix, it means the argument is a pointer type that a value will be returned in. I've seen this used elsewhere in hotspot. For example VM_RedefineClasses::merge_constant_pools() and ObjectSynchronizer::deflate_monitor_list(). bool VM_RedefineClasses::merge_constant_pools(const constantPoolHandle& old_cp, ?????? const constantPoolHandle& scratch_cp, constantPoolHandle *merge_cp_p, ?????? int *merge_cp_length_p, TRAPS) { int ObjectSynchronizer::deflate_monitor_list(ObjectMonitor** list_p, ???????????????????????????????????????????? ObjectMonitor** free_head_p, ???????????????????????????????????????????? ObjectMonitor** free_tail_p) { thanks, Chris On 1/10/20 2:12 PM, Alex Menkov wrote: > Hi Chris, > > Thanks for making the code more "typed" (this "void*" arrays are error > prone). > Looks good in general, some minor comments: > > MethodImpl.c > - command names starts with lower case letters > > > ReferenceTypeImpl.c > - please fix indentation for command definitions > > > debugDispatch.h/.c > > +debugDispatch_getHandler(int cmdSetNum, int cmdNum, const char > **cmdSetName_p, const char **cmdName_p) > > What are the "_p" suffixes for? to show that this are pointers? > To me this doesn't make much sense. > > --alex > > On 01/10/2020 11:27, Chris Plummer wrote: >> Hello, >> >> Please review the following >> >> https://bugs.openjdk.java.net/browse/JDK-8236913 >> http://cr.openjdk.java.net/~cjplummer/8236913/webrev.00/ >> >> The debug agent has logging support that will trace all jdwp commands >> coming in. Currently all it traces is the command set number and the >> command number within that command set. So you see something like: >> >> [#|10.01.2020 06:27:24.366 >> GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command >> set 1, command 9|#] >> >> I've added support for including the name of the command set and >> command, so now you see: >> >> [#|10.01.2020 06:27:24.366 >> GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command >> set VirtualMachine(1), command Resume(9)|#] >> >> So in this case command set 1 represents VirtualMachine and command 9 >> is the Resume command. >> >> I was initially going to leverage jdwp.spec which is already >> processed by build.tools.jdwpgen.Main to produce JDWP.java and >> JDWPCommands.h. However, I could see it was more of a challenge than >> I initially hoped. Also, the main advantage would have been not >> having to hard code arrays of command names, but we already have >> harded coded arrays of function pointers to handle the various jdwp >> commands, so I just replaced these with a more specialized arrays >> that also include the names of the commands. As an example, we used >> to have: >> >> void *ArrayReference_Cmds[] = { (void *)0x3 >> ???? ,(void *)length >> ???? ,(void *)getValues >> ???? ,(void *)setValues}; >> >> Now we have: >> >> CommandSet ArrayReference_Cmds = { >> ???? 3, "ArrayReference", >> ???? { >> ???????? {length, "Length"}, >> ???????? {getValues, "GetValues"}, >> ???????? {setValues, "SetValues"} >> ???? } >> }; >> >> So no worse w.r.t. hard coding things that could be generated off the >> spec, and it cleans up some ugly casts also. The CommandSet typedef >> can be found in debugDispatch.h. >> >> All the header files except for debugDispatch.h have the same pattern >> for changes, so they are pretty easy to review >> >> All .c files except debugDispatch.c and debugLoop.c also have the >> same pattern. Note some command handler function names are not the >> same as the command name. If you want to double check command set >> names and command names, you can find the spec here: >> >> https://docs.oracle.com/javase/9/docs/specs/jdwp/jdwp-protocol.html >> >> In ReferenceTypeImpl.c I fixed a typo in the method() prototype. It >> had an extra argument which I think was a very old copy-n-paste bug >> from the method1() prototype. This was caught because the command >> handler functions are now directly assigned to a CommandHandler type >> rather than cast. The cast was hiding this bug. >> >> I tested by doing a test run where MISC logging was enabled by >> default. All jdwp, jdb, and jdi tests were run in this way and passed. >> >> thanks, >> >> Chris >> From daniil.x.titov at oracle.com Sat Jan 11 04:52:14 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 10 Jan 2020 20:52:14 -0800 Subject: RFR: 8213222: remove RMIConnectorServer.CREDENTIAL_TYPES Message-ID: <82023921-2274-48F8-BC8F-8DC8A420580E@oracle.com> Please review a change [1] that removes constant javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE. This constant represents the name of the attribute that specifies a list of class names acceptable to the RMIServer.newClient() remote method call. This constant was superseded by RMIConnectorServer.CREDENTIALS_FILTER_PATTERN and marked as deprecated for removal in JDK 10 [3]. A new CRS [4] and a release note sub-task [5] were also created. Please review the CSR [4] as well. Text search over the repository didn't find any other usage of this constant. Tier1 - tier3 Mach5 tests succeeded. [1] Webrev: http://cr.openjdk.java.net/~dtitov/8213222/webrev.01/ [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8213222 [3] https://bugs.openjdk.java.net/browse/JDK-8191313 [4] CSR: https://bugs.openjdk.java.net/browse/JDK-8236954 [5] Release Note sub-task: https://bugs.openjdk.java.net/browse/JDK-8236955 Thank you, Daniil From Alan.Bateman at oracle.com Sat Jan 11 07:17:36 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 11 Jan 2020 07:17:36 +0000 Subject: jmx-dev RFR: 8213222: remove RMIConnectorServer.CREDENTIAL_TYPES In-Reply-To: <82023921-2274-48F8-BC8F-8DC8A420580E@oracle.com> References: <82023921-2274-48F8-BC8F-8DC8A420580E@oracle.com> Message-ID: <1861b33d-2659-c177-af24-52bbdbc5b317@oracle.com> On 11/01/2020 04:52, Daniil Titov wrote: > Please review a change [1] that removes constant javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE. > This constant represents the name of the attribute that specifies a list of class names acceptable to the RMIServer.newClient() > remote method call. This constant was superseded by RMIConnectorServer.CREDENTIALS_FILTER_PATTERN and marked as > deprecated for removal in JDK 10 [3]. > > A new CRS [4] and a release note sub-task [5] were also created. Please review the CSR [4] as well. > Looks good. I changed the scope of the CSR to "SE" and added myself as Reviewer. -Alan From volker.simonis at gmail.com Sat Jan 11 13:38:12 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 11 Jan 2020 14:38:12 +0100 Subject: serviceability agent : problems when using gcc LTO (link time optimization) In-Reply-To: References: Message-ID: SA pretends to know the exact types of objects in the JVM and for polymorphic objects it wants to read their vtable from the shared library. If LTO de-virtulizes methods and thus changes polymorphic to non-polymorphic types, this won't work. But if LTO can de-virtulizes a type, maybe you can do that manually (and update the corresponding representation in the SA), because it doesn't seem to be needed. Notice that other places in the VM may also rely on this. E.g. CDS stores Metadata objects in the CDS archive and restores their vtable pointers when they are loaded. On the other hand, if the CDS tests have passed, this doesn't seem to be a problem. Baesken, Matthias schrieb am Fr., 10. Jan. 2020, 11:03: > Hello, I recently looked into the gcc lto optimization mode (see for > some details https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html > and > http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html > ). > This mode can lead to more compact binaries (~10% smaller) , it also > might bring small performance improvements but that wasn't my (main) > goal . > > The changes for this are rather small , one needs to use a recent gcc , > add -flto to the compile flags , for example > > --- a/make/autoconf/flags-cflags.m4 Wed Jan 01 03:08:45 2020 +0100 > +++ b/make/autoconf/flags-cflags.m4 Wed Jan 08 17:39:10 2020 +0100 > @@ -530,8 +530,13 @@ > fi > if test "x$TOOLCHAIN_TYPE" = xgcc; then > - TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new > -fstack-protector" > - TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector" > + TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new > -fstack-protector -flto" > + TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector -flto" > > .... and you have to make sure to use gcc-ar and gcc-nm instead > of ar / nm . > Build and test(s) work, however with one exception. > The serviceability tests like serviceability/sa seems to rely > heavily on the "normal" structure of libjvm.so (from what I > understand e.g. in LinuxVtblAccess it is attempted to access internal > symbols like _ZTV ). > > Errors in the sa tests look like : > > > java.lang.InternalError: Metadata does not appear to be polymorphic > at > jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:279) > at > jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:102) > at > jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:74) > at > jdk.hotspot.agent/sun.jvm.hotspot.memory.SystemDictionary.getClassLoaderKlass(SystemDictionary.java:96) > at > jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:93) > at > jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:115) > at > jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:262) > at > jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:225) > at > jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) > at > jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:176) > at > jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:321) > at > jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:406) > > Has anyone experimented with LTO optimization ? > > And to the serviceability agent experts - any idea how to make the > jdk.hotspot.agent more independent from optimization settings ? > > > Best regards, Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Sat Jan 11 18:27:03 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Sat, 11 Jan 2020 10:27:03 -0800 Subject: serviceability agent : problems when using gcc LTO (link time optimization) In-Reply-To: References: Message-ID: <00f43a29-1000-e5b7-1e36-c6b9b6177d21@oracle.com> cds is also disabled for minimalVM so testing of cds with LTO probably has not been done. There are a number of features that minimalVM excludes such as jvmti, cds and SA (which I think falls under "services"), and there was very little testing done with these features individually disabled. They would all at least build (if any one was disabled) and I think heartbeat testing was done, but probably no more than that. Also various combinations were not tested, other than the one combination that minimalVM used. Search for NON_MINIMAL_FEATURES in hotspot.m4 to see which features are disabled for minimalVM. Chris On 1/11/20 5:38 AM, Volker Simonis wrote: > SA pretends to know the exact types of objects in the JVM and for > polymorphic objects it wants to read their vtable from the shared library. > If LTO de-virtulizes methods and thus changes polymorphic to > non-polymorphic types, this won't work. But if LTO can de-virtulizes a > type, maybe you can do that manually (and update the corresponding > representation in the SA), because it doesn't seem to be needed. > > Notice that other places in the VM may also rely on this. E.g. CDS stores > Metadata objects in the CDS archive and restores their vtable pointers when > they are loaded. On the other hand, if the CDS tests have passed, this > doesn't seem to be a problem. > > Baesken, Matthias schrieb am Fr., 10. Jan. 2020, > 11:03: > >> Hello, I recently looked into the gcc lto optimization mode (see for >> some details https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html >> and >> http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html >> ). >> This mode can lead to more compact binaries (~10% smaller) , it also >> might bring small performance improvements but that wasn't my (main) >> goal . >> >> The changes for this are rather small , one needs to use a recent gcc , >> add -flto to the compile flags , for example >> >> --- a/make/autoconf/flags-cflags.m4 Wed Jan 01 03:08:45 2020 +0100 >> +++ b/make/autoconf/flags-cflags.m4 Wed Jan 08 17:39:10 2020 +0100 >> @@ -530,8 +530,13 @@ >> fi >> if test "x$TOOLCHAIN_TYPE" = xgcc; then >> - TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new >> -fstack-protector" >> - TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector" >> + TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new >> -fstack-protector -flto" >> + TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector -flto" >> >> .... and you have to make sure to use gcc-ar and gcc-nm instead >> of ar / nm . >> Build and test(s) work, however with one exception. >> The serviceability tests like serviceability/sa seems to rely >> heavily on the "normal" structure of libjvm.so (from what I >> understand e.g. in LinuxVtblAccess it is attempted to access internal >> symbols like _ZTV ). >> >> Errors in the sa tests look like : >> >> >> java.lang.InternalError: Metadata does not appear to be polymorphic >> at >> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:279) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:102) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:74) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.memory.SystemDictionary.getClassLoaderKlass(SystemDictionary.java:96) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:93) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78) >> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:115) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:262) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:225) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:176) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:321) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:406) >> >> Has anyone experimented with LTO optimization ? >> >> And to the serviceability agent experts - any idea how to make the >> jdk.hotspot.agent more independent from optimization settings ? >> >> >> Best regards, Matthias >> From will.sargent at gmail.com Sun Jan 12 19:25:50 2020 From: will.sargent at gmail.com (Will Sargent) Date: Sun, 12 Jan 2020 11:25:50 -0800 Subject: Wrote a fluent builder library for JMX MBean creation Message-ID: Hi all, I've written a library that uses Java 8 functions and some type inference to create MBeans in a single statement: class UserExample { static final MBeanServer mBeanServer = ManagementFactory.getPlatformMBeanServer(); public static void registerUser() throws Exception { Address address = new Address("street1", "city", "state"); final User user = new User("name", 12, address); final DynamicMBean userBean = DynamicBean.builder() .withSimpleAttribute(String.class, "name", user::getName, user::setName) .withSimpleAttribute(Integer.TYPE, "age", user::getAge, user::setAge) .build(); ObjectName objectName = new ObjectName("com.tersesystems.jmxbuilder:type=UserBean,name=User"); mBeanServer.registerMBean(userBean, objectName); } } The code's available at https://github.com/tersesystems/jmxbuilder I wrote a blog post as well explaining the use case -- OpenMBean API restrictions, no need for annotations or interface/class creation, and being able build up CompositeData and TabularData so that more complex MBeans can be created. Blog post is here https://tersesystems.com/blog/2019/12/24/controlling-logging-in-a-running-jvm/ I've also got an MBeanServerInterceptor put together at https://github.com/tersesystems/jmxmvc although that's a lot more fiddly and I'm not sure I have the details worked out. I am probably going to work on automatic registration using using Guice and Sangria https://tavianator.com/announcing-sangria/ next, so anything implementing an interface can have a JMX bean created for it, without tying the interface directly to JMX implementation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Mon Jan 13 09:28:22 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 13 Jan 2020 09:28:22 +0000 Subject: serviceability agent : problems when using gcc LTO (link time optimization) In-Reply-To: <00f43a29-1000-e5b7-1e36-c6b9b6177d21@oracle.com> References: <00f43a29-1000-e5b7-1e36-c6b9b6177d21@oracle.com> Message-ID: Hello, thanks for the info - seems that for the minimal VM , lto is fine but currently not for the other (server/...) VM builds . Btw. I noticed similar issues with the SA when using link-time-gc . Looks like this eliminates the vtable info too that tha SA-coding ( LinuxVtblAccess class ?) wants to look into . Best regards, Matthias > cds is also disabled for minimalVM so testing of cds with LTO probably > has not been done. There are a number of features that minimalVM > excludes such as jvmti, cds and SA (which I think falls under > "services"), and there was very little testing done with these features > individually disabled. They would all at least build (if any one was > disabled) and I think heartbeat testing was done, but probably no more > than that. Also various combinations were not tested, other than the one > combination that minimalVM used. Search for NON_MINIMAL_FEATURES in > hotspot.m4 to see which features are disabled for minimalVM. > > Chris > > On 1/11/20 5:38 AM, Volker Simonis wrote: > > SA pretends to know the exact types of objects in the JVM and for > > polymorphic objects it wants to read their vtable from the shared library. > > If LTO de-virtulizes methods and thus changes polymorphic to > > non-polymorphic types, this won't work. But if LTO can de-virtulizes a > > type, maybe you can do that manually (and update the corresponding > > representation in the SA), because it doesn't seem to be needed. > > > > Notice that other places in the VM may also rely on this. E.g. CDS stores > > Metadata objects in the CDS archive and restores their vtable pointers > when > > they are loaded. On the other hand, if the CDS tests have passed, this > > doesn't seem to be a problem. > > > > Baesken, Matthias schrieb am Fr., 10. Jan. > 2020, > > 11:03: > > > >> Hello, I recently looked into the gcc lto optimization mode (see for > >> some details https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html > >> and > >> http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter- > procedural.html > >> ). > >> This mode can lead to more compact binaries (~10% smaller) , it also > >> might bring small performance improvements but that wasn't my (main) > >> goal . > >> > >> The changes for this are rather small , one needs to use a recent gcc , > >> add -flto to the compile flags , for example > >> > >> --- a/make/autoconf/flags-cflags.m4 Wed Jan 01 03:08:45 2020 +0100 > >> +++ b/make/autoconf/flags-cflags.m4 Wed Jan 08 17:39:10 2020 +0100 > >> @@ -530,8 +530,13 @@ > >> fi > >> if test "x$TOOLCHAIN_TYPE" = xgcc; then > >> - TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new > >> -fstack-protector" > >> - TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector" > >> + TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new > >> -fstack-protector -flto" > >> + TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector -flto" > >> > >> .... and you have to make sure to use gcc-ar and gcc-nm instead > >> of ar / nm . > >> Build and test(s) work, however with one exception. > >> The serviceability tests like serviceability/sa seems to rely > >> heavily on the "normal" structure of libjvm.so (from what I > >> understand e.g. in LinuxVtblAccess it is attempted to access internal > >> symbols like _ZTV ). > >> > >> Errors in the sa tests look like : > >> > >> > >> java.lang.InternalError: Metadata does not appear to be polymorphic > >> at > >> > jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDyna > micTypeForAddress(BasicTypeDataBase.java:279) > >> at > >> > jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instanti > ateWrapperFor(VirtualBaseConstructor.java:102) > >> at > >> > jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor( > Metadata.java:74) > >> at > >> > jdk.hotspot.agent/sun.jvm.hotspot.memory.SystemDictionary.getClassLoad > erKlass(SystemDictionary.java:96) > >> at > >> > jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderS > tatistics(ClassLoaderStats.java:93) > >> at > >> > jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderS > tats.java:78) > >> at > jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:115) > >> at > >> jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:262) > >> at > >> jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:225) > >> at > >> jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) > >> at > >> jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:176) > >> at > >> > jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:3 > 21) > >> at > >> > jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:406) > >> > >> Has anyone experimented with LTO optimization ? > >> > >> And to the serviceability agent experts - any idea how to make the > >> jdk.hotspot.agent more independent from optimization settings ? > >> > >> > >> Best regards, Matthias > >> From christoph.langer at sap.com Mon Jan 13 10:23:38 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 13 Jan 2020 10:23:38 +0000 Subject: RFR (XS): 8237008: Exclude serviceability/sa/TestInstanceKlassSizeForInterface.java on linuxppc64 and linuxppc64le Message-ID: Hi, after JDK-8232759 "Remove GC.class_stats" [0] was pushed, we see the test "serviceability/sa/TestInstanceKlassSizeForInterface.java" failing on linuxppc64 and linuxppc64le the same way as "serviceability/sa/TestInstanceKlassSize.java". Hence, I'm requesting the same exclusion of TestInstanceKlassSizeForInterface (referring to JDK-8230664 [1] for resolution). Bug: https://bugs.openjdk.java.net/browse/JDK-8237008 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8237008.0/ Thanks Christoph [0] https://hg.openjdk.java.net/jdk/jdk/rev/d8f6e926cedc [1] https://bugs.openjdk.java.net/browse/JDK-8230664 -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Mon Jan 13 10:36:34 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 13 Jan 2020 10:36:34 +0000 Subject: RFR (XS): 8237008: Exclude serviceability/sa/TestInstanceKlassSizeForInterface.java on linuxppc64 and linuxppc64le In-Reply-To: References: Message-ID: Hi Christoph, looks good to me. Thanks, Martin From: Langer, Christoph Sent: Montag, 13. Januar 2020 11:24 To: hotspot-dev at openjdk.java.net; Doerr, Martin Cc: OpenJDK Serviceability Subject: RFR (XS): 8237008: Exclude serviceability/sa/TestInstanceKlassSizeForInterface.java on linuxppc64 and linuxppc64le Hi, after JDK-8232759 "Remove GC.class_stats" [0] was pushed, we see the test "serviceability/sa/TestInstanceKlassSizeForInterface.java" failing on linuxppc64 and linuxppc64le the same way as "serviceability/sa/TestInstanceKlassSize.java". Hence, I'm requesting the same exclusion of TestInstanceKlassSizeForInterface (referring to JDK-8230664 [1] for resolution). Bug: https://bugs.openjdk.java.net/browse/JDK-8237008 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8237008.0/ Thanks Christoph [0] https://hg.openjdk.java.net/jdk/jdk/rev/d8f6e926cedc [1] https://bugs.openjdk.java.net/browse/JDK-8230664 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Jan 13 12:57:00 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Jan 2020 22:57:00 +1000 Subject: RFR (XS): 8237008: Exclude serviceability/sa/TestInstanceKlassSizeForInterface.java on linuxppc64 and linuxppc64le In-Reply-To: References: Message-ID: <8a6a9f3d-88ab-9733-7c7f-f822da148d1e@oracle.com> Hi Christoph, I think those tests are currnetly failing on all platforms - see JDK-8236917. The failures after GC.class_stats removal are unrelated to the failures reported in 8230664 AFAICS. David On 13/01/2020 8:23 pm, Langer, Christoph wrote: > Hi, > > after JDK-8232759 ?Remove GC.class_stats? [0] was pushed, we see the > test ?serviceability/sa/TestInstanceKlassSizeForInterface.java? failing > on linuxppc64 and linuxppc64le the same way as > ?serviceability/sa/TestInstanceKlassSize.java?. Hence, I?m requesting > the same exclusion of TestInstanceKlassSizeForInterface (referring to > JDK-8230664 [1] for resolution). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8237008 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8237008.0/ > > Thanks > > Christoph > > [0] https://hg.openjdk.java.net/jdk/jdk/rev/d8f6e926cedc > > [1] https://bugs.openjdk.java.net/browse/JDK-8230664 > From christoph.langer at sap.com Mon Jan 13 13:26:46 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 13 Jan 2020 13:26:46 +0000 Subject: RFR (XS): 8237008: Exclude serviceability/sa/TestInstanceKlassSizeForInterface.java on linuxppc64 and linuxppc64le In-Reply-To: <8a6a9f3d-88ab-9733-7c7f-f822da148d1e@oracle.com> References: <8a6a9f3d-88ab-9733-7c7f-f822da148d1e@oracle.com> Message-ID: Hi David, thanks for the heads up. However, in our CI, these tests pass on all platforms except linuxppc64/linuxppc64le consistently. I think I'll push the exclusion and once JDK-8236917 has been resolved I'll try on the ppc linuxes again... Best regards Christoph > -----Original Message----- > From: David Holmes > Sent: Montag, 13. Januar 2020 13:57 > To: Langer, Christoph ; hotspot- > dev at openjdk.java.net; Doerr, Martin > Cc: OpenJDK Serviceability > Subject: Re: RFR (XS): 8237008: Exclude > serviceability/sa/TestInstanceKlassSizeForInterface.java on linuxppc64 and > linuxppc64le > > Hi Christoph, > > I think those tests are currnetly failing on all platforms - see > JDK-8236917. The failures after GC.class_stats removal are unrelated to > the failures reported in 8230664 AFAICS. > > David > > On 13/01/2020 8:23 pm, Langer, Christoph wrote: > > Hi, > > > > after JDK-8232759 "Remove GC.class_stats" [0] was pushed, we see the > > test "serviceability/sa/TestInstanceKlassSizeForInterface.java" failing > > on linuxppc64 and linuxppc64le the same way as > > "serviceability/sa/TestInstanceKlassSize.java". Hence, I'm requesting > > the same exclusion of TestInstanceKlassSizeForInterface (referring to > > JDK-8230664 [1] for resolution). > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8237008 > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8237008.0/ > > > > Thanks > > > > Christoph > > > > [0] https://hg.openjdk.java.net/jdk/jdk/rev/d8f6e926cedc > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8230664 > > From coleen.phillimore at oracle.com Mon Jan 13 14:22:07 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 13 Jan 2020 09:22:07 -0500 Subject: RFR (XS): 8237008: Exclude serviceability/sa/TestInstanceKlassSizeForInterface.java on linuxppc64 and linuxppc64le In-Reply-To: References: <8a6a9f3d-88ab-9733-7c7f-f822da148d1e@oracle.com> Message-ID: <60869e5e-d0ae-86e7-b514-897b5ae0bdc4@oracle.com> Hi, I didn't see this with my filtering.? Do you know why it fails for ppcle? It fails for us on all platforms because test.vm.opts isn't set in our CI jobs. Thanks, Coleen On 1/13/20 8:26 AM, Langer, Christoph wrote: > Hi David, > > thanks for the heads up. However, in our CI, these tests pass on all platforms except linuxppc64/linuxppc64le consistently. > > I think I'll push the exclusion and once JDK-8236917 has been resolved I'll try on the ppc linuxes again... > > Best regards > Christoph > >> -----Original Message----- >> From: David Holmes >> Sent: Montag, 13. Januar 2020 13:57 >> To: Langer, Christoph ; hotspot- >> dev at openjdk.java.net; Doerr, Martin >> Cc: OpenJDK Serviceability >> Subject: Re: RFR (XS): 8237008: Exclude >> serviceability/sa/TestInstanceKlassSizeForInterface.java on linuxppc64 and >> linuxppc64le >> >> Hi Christoph, >> >> I think those tests are currnetly failing on all platforms - see >> JDK-8236917. The failures after GC.class_stats removal are unrelated to >> the failures reported in 8230664 AFAICS. >> >> David >> >> On 13/01/2020 8:23 pm, Langer, Christoph wrote: >>> Hi, >>> >>> after JDK-8232759 "Remove GC.class_stats" [0] was pushed, we see the >>> test "serviceability/sa/TestInstanceKlassSizeForInterface.java" failing >>> on linuxppc64 and linuxppc64le the same way as >>> "serviceability/sa/TestInstanceKlassSize.java". Hence, I'm requesting >>> the same exclusion of TestInstanceKlassSizeForInterface (referring to >>> JDK-8230664 [1] for resolution). >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237008 >>> >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8237008.0/ >>> >>> Thanks >>> >>> Christoph >>> >>> [0] https://hg.openjdk.java.net/jdk/jdk/rev/d8f6e926cedc >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8230664 >>> From christoph.langer at sap.com Mon Jan 13 14:49:34 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 13 Jan 2020 14:49:34 +0000 Subject: RFR (XS): 8237008: Exclude serviceability/sa/TestInstanceKlassSizeForInterface.java on linuxppc64 and linuxppc64le In-Reply-To: <60869e5e-d0ae-86e7-b514-897b5ae0bdc4@oracle.com> References: <8a6a9f3d-88ab-9733-7c7f-f822da148d1e@oracle.com> <60869e5e-d0ae-86e7-b514-897b5ae0bdc4@oracle.com> Message-ID: Hi Coleen, why it's failing on ppc or ppcle was analyzed in https://bugs.openjdk.java.net/browse/JDK-8230664. You can read in the description: The test retrieves the size of Java classes by 2 different APIs and expects the result to be equal: - SA reports the size of the reserved memory. Rounded up to a multiple of 16 on PPC64. - Jcmd GC.class_stats reports the size of the space needed for a number of 8 Byte blocks. (The number is from an internal statistic.) So there may be a difference of 8 Bytes on platforms which reserve memory 16 Byte wise. I assume that the functionality from Jcmd GC.class_stats was replaced in your change but goes back to the same statistics. In our tests we set test.vm.opts, so I guess that's why we don't see failures on other platforms. Best regards Christoph > -----Original Message----- > From: coleen.phillimore at oracle.com > Sent: Montag, 13. Januar 2020 15:22 > To: Langer, Christoph ; David Holmes > ; hotspot-dev at openjdk.java.net; Doerr, Martin > > Cc: OpenJDK Serviceability > Subject: Re: RFR (XS): 8237008: Exclude > serviceability/sa/TestInstanceKlassSizeForInterface.java on linuxppc64 and > linuxppc64le > > Hi, I didn't see this with my filtering.? Do you know why it fails for > ppcle? > > It fails for us on all platforms because test.vm.opts isn't set in our > CI jobs. > > Thanks, > Coleen > > On 1/13/20 8:26 AM, Langer, Christoph wrote: > > Hi David, > > > > thanks for the heads up. However, in our CI, these tests pass on all > platforms except linuxppc64/linuxppc64le consistently. > > > > I think I'll push the exclusion and once JDK-8236917 has been resolved I'll > try on the ppc linuxes again... > > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: David Holmes > >> Sent: Montag, 13. Januar 2020 13:57 > >> To: Langer, Christoph ; hotspot- > >> dev at openjdk.java.net; Doerr, Martin > >> Cc: OpenJDK Serviceability > >> Subject: Re: RFR (XS): 8237008: Exclude > >> serviceability/sa/TestInstanceKlassSizeForInterface.java on linuxppc64 > and > >> linuxppc64le > >> > >> Hi Christoph, > >> > >> I think those tests are currnetly failing on all platforms - see > >> JDK-8236917. The failures after GC.class_stats removal are unrelated to > >> the failures reported in 8230664 AFAICS. > >> > >> David > >> > >> On 13/01/2020 8:23 pm, Langer, Christoph wrote: > >>> Hi, > >>> > >>> after JDK-8232759 "Remove GC.class_stats" [0] was pushed, we see the > >>> test "serviceability/sa/TestInstanceKlassSizeForInterface.java" failing > >>> on linuxppc64 and linuxppc64le the same way as > >>> "serviceability/sa/TestInstanceKlassSize.java". Hence, I'm requesting > >>> the same exclusion of TestInstanceKlassSizeForInterface (referring to > >>> JDK-8230664 [1] for resolution). > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237008 > >>> > >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8237008.0/ > >>> > >>> Thanks > >>> > >>> Christoph > >>> > >>> [0] https://hg.openjdk.java.net/jdk/jdk/rev/d8f6e926cedc > >>> > >>> [1] https://bugs.openjdk.java.net/browse/JDK-8230664 > >>> From daniel.fuchs at oracle.com Mon Jan 13 15:10:56 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 13 Jan 2020 15:10:56 +0000 Subject: jmx-dev RFR(S): 8234484: Add ability to configure third port for remote JMX In-Reply-To: References: <18fcf60c-b342-40c6-e97e-d00563566b9c@oracle.com> Message-ID: <135d431c-6f1a-999c-efc5-71ab106953ee@oracle.com> Hi Felix, On 11/01/2020 07:37, Yangfei (Felix) wrote: > Hi Daniel, > > Thanks for the suggestions. > I modified the patch making the third port also configurable via the management.properties file. > New webrev: http://cr.openjdk.java.net/~fyang/8234484/webrev.01/ I think I would prefer the try catch NumberFormatException to be just around the call to Integer.parseInt(), as it is done elsewhere in this file (e.g. line 337). > > Previously, we test the effectiveness of the patch by checking the port usage with -Dsun.rmi.transport.tcp.logLevel=VERBOSE. > Is it good to modify the following test case specifying the third port for the testing purpose? Please don't do that. That test is not appropriate for this - as it opens a remote connector, not a local connector. Also please get someone from serviceability-dev to also look at changes (added in cc:). best regards, -- daniel > > diff -r d630c0a63222 test/jdk/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java > --- a/test/jdk/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java Wed Jan 08 08:53:28 2020 +0900 > +++ b/test/jdk/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java Sat Jan 11 15:30:25 2020 +0000 > @@ -31,6 +31,7 @@ > > import jdk.test.lib.process.OutputAnalyzer; > import jdk.test.lib.process.ProcessTools; > +import jdk.test.lib.Utils; > > /** > * @test > @@ -203,6 +204,12 @@ > args.add("-Dcom.sun.management.jmxremote.host=" + address); > args.add("-Dcom.sun.management.jmxremote.port=" + jmxPort); > args.add("-Dcom.sun.management.jmxremote.rmi.port=" + rmiPort); > + try { > + int port = Utils.getFreePort(); > + args.add("-Dcom.sun.management.jmxlocal.port=" + port); > + } catch (Exception e) { > + System.out.println(e); > + } > args.add("-Dcom.sun.management.jmxremote.authenticate=false"); > args.add("-Dcom.sun.management.jmxremote.ssl=" + Boolean.toString(useSSL)); > // This is needed for testing on loopback > > Felix > >> >> Hi Felix, >> >> Shouldn't this be configurable via the management.properties file, like all other >> JMX properties? >> >> Also on the one hand - it would be good to have a test. >> On the other hand - writing a stable test will be problematic as there is no way >> to ensure that any particular port number will be available for the agent to bind >> to. >> >> best regards, >> >> -- daniel >> >> On 08/01/2020 01:09, Yangfei (Felix) wrote: >>> Hi, >>> >>> Please review this patch adding a way to configure the third port for >>> remote JMX. >>> >>> Currently, it is possible to configure two of the three ports for JMX >>> with com.sun.management.jmxremote.port and >>> com.sun.management.jmxremote.rmi.port. >>> >>> However, there is no way to configure the third port. This can cause >>> problems if the randomly assigned port conflicts with another service >>> that has not yet acquired its port. >>> >>> ?? Bug: https://bugs.openjdk.java.net/browse/JDK-8234484 >>> >>> ??Webrev: http://cr.openjdk.java.net/~fyang/8234484/webrev.00/ >>> >>> ? Passed tiered-1 test. >>> >>> Thanks, >>> >>> Felix >>> > From daniel.fuchs at oracle.com Mon Jan 13 15:36:17 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 13 Jan 2020 15:36:17 +0000 Subject: jmx-dev RFR: 8213222: remove RMIConnectorServer.CREDENTIAL_TYPES In-Reply-To: <82023921-2274-48F8-BC8F-8DC8A420580E@oracle.com> References: <82023921-2274-48F8-BC8F-8DC8A420580E@oracle.com> Message-ID: Hi Daniil, Looks good to me as well. I wonder however if the release note should point to the replacement? Something like: The terminally deprecated constant `javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE` has been removed. A filter pattern can be specified instead using `RMIConnectorServer.CREDENTIALS_FILTER_PATTERN`. best regards, -- daniel On 11/01/2020 04:52, Daniil Titov wrote: > Please review a change [1] that removes constant javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE. > This constant represents the name of the attribute that specifies a list of class names acceptable to the RMIServer.newClient() > remote method call. This constant was superseded by RMIConnectorServer.CREDENTIALS_FILTER_PATTERN and marked as > deprecated for removal in JDK 10 [3]. > > A new CRS [4] and a release note sub-task [5] were also created. Please review the CSR [4] as well. > > Text search over the repository didn't find any other usage of this constant. Tier1 - tier3 Mach5 tests succeeded. > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8213222/webrev.01/ > [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8213222 > [3] https://bugs.openjdk.java.net/browse/JDK-8191313 > [4] CSR: https://bugs.openjdk.java.net/browse/JDK-8236954 > [5] Release Note sub-task: https://bugs.openjdk.java.net/browse/JDK-8236955 > > Thank you, > Daniil > > From david.holmes at oracle.com Mon Jan 13 21:35:56 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jan 2020 07:35:56 +1000 Subject: RFR (XS): 8237008: Exclude serviceability/sa/TestInstanceKlassSizeForInterface.java on linuxppc64 and linuxppc64le In-Reply-To: References: <8a6a9f3d-88ab-9733-7c7f-f822da148d1e@oracle.com> Message-ID: <0d2c6e0c-9f68-c478-ebfd-69de072d0e80@oracle.com> On 13/01/2020 11:26 pm, Langer, Christoph wrote: > Hi David, > > thanks for the heads up. However, in our CI, these tests pass on all platforms except linuxppc64/linuxppc64le consistently. Sorry I wasn't specific enough. This test fails on all platforms in some configuration due to a problem with test.vm.opts/test.java.opts not getting passed through as expected and causing a problem when CDS is disabled. All in all the failure behaviour is very confusing. :( David > I think I'll push the exclusion and once JDK-8236917 has been resolved I'll try on the ppc linuxes again... > > Best regards > Christoph > >> -----Original Message----- >> From: David Holmes >> Sent: Montag, 13. Januar 2020 13:57 >> To: Langer, Christoph ; hotspot- >> dev at openjdk.java.net; Doerr, Martin >> Cc: OpenJDK Serviceability >> Subject: Re: RFR (XS): 8237008: Exclude >> serviceability/sa/TestInstanceKlassSizeForInterface.java on linuxppc64 and >> linuxppc64le >> >> Hi Christoph, >> >> I think those tests are currnetly failing on all platforms - see >> JDK-8236917. The failures after GC.class_stats removal are unrelated to >> the failures reported in 8230664 AFAICS. >> >> David >> >> On 13/01/2020 8:23 pm, Langer, Christoph wrote: >>> Hi, >>> >>> after JDK-8232759 "Remove GC.class_stats" [0] was pushed, we see the >>> test "serviceability/sa/TestInstanceKlassSizeForInterface.java" failing >>> on linuxppc64 and linuxppc64le the same way as >>> "serviceability/sa/TestInstanceKlassSize.java". Hence, I'm requesting >>> the same exclusion of TestInstanceKlassSizeForInterface (referring to >>> JDK-8230664 [1] for resolution). >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237008 >>> >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8237008.0/ >>> >>> Thanks >>> >>> Christoph >>> >>> [0] https://hg.openjdk.java.net/jdk/jdk/rev/d8f6e926cedc >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8230664 >>> From serguei.spitsyn at oracle.com Tue Jan 14 00:39:14 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 13 Jan 2020 16:39:14 -0800 Subject: RFR: JDK-8235846: Improve WindbgDebuggerLocal implementation In-Reply-To: <8ca073bf-0f82-46d5-7fd1-0a5b5757bfa4@oracle.com> References: <8ca073bf-0f82-46d5-7fd1-0a5b5757bfa4@oracle.com> Message-ID: <6ed9a23f-3ba4-cbf2-8156-26b4e3731eeb@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Tue Jan 14 04:11:48 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 13 Jan 2020 20:11:48 -0800 Subject: RFR(M): 8236913: debug agent's jdwp command logging should include the command set name and command name In-Reply-To: References: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> <9babaeab-f9ec-57c7-ad32-69d7051dffba@oracle.com> Message-ID: <00f114f1-78e9-cae0-d7ad-022406ac522a@oracle.com> Hi Alex, Are you ok with the _p arguments? Also, can I get a second reviewer please. thanks, Chris On 1/10/20 3:00 PM, Chris Plummer wrote: > Hi Alex, > > I'll fix the mistakes in MethodImpl.c and ReferenceTypeImpl.c. As for > the "_p" suffix, it means the argument is a pointer type that a value > will be returned in. I've seen this used elsewhere in hotspot. For > example VM_RedefineClasses::merge_constant_pools() and > ObjectSynchronizer::deflate_monitor_list(). > > bool VM_RedefineClasses::merge_constant_pools(const > constantPoolHandle& old_cp, > ?????? const constantPoolHandle& scratch_cp, constantPoolHandle > *merge_cp_p, > ?????? int *merge_cp_length_p, TRAPS) { > > int ObjectSynchronizer::deflate_monitor_list(ObjectMonitor** list_p, > ???????????????????????????????????????????? ObjectMonitor** free_head_p, > ???????????????????????????????????????????? ObjectMonitor** > free_tail_p) { > > thanks, > > Chris > > On 1/10/20 2:12 PM, Alex Menkov wrote: >> Hi Chris, >> >> Thanks for making the code more "typed" (this "void*" arrays are >> error prone). >> Looks good in general, some minor comments: >> >> MethodImpl.c >> - command names starts with lower case letters >> >> >> ReferenceTypeImpl.c >> - please fix indentation for command definitions >> >> >> debugDispatch.h/.c >> >> +debugDispatch_getHandler(int cmdSetNum, int cmdNum, const char >> **cmdSetName_p, const char **cmdName_p) >> >> What are the "_p" suffixes for? to show that this are pointers? >> To me this doesn't make much sense. >> >> --alex >> >> On 01/10/2020 11:27, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following >>> >>> https://bugs.openjdk.java.net/browse/JDK-8236913 >>> http://cr.openjdk.java.net/~cjplummer/8236913/webrev.00/ >>> >>> The debug agent has logging support that will trace all jdwp >>> commands coming in. Currently all it traces is the command set >>> number and the command number within that command set. So you see >>> something like: >>> >>> [#|10.01.2020 06:27:24.366 >>> GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command >>> set 1, command 9|#] >>> >>> I've added support for including the name of the command set and >>> command, so now you see: >>> >>> [#|10.01.2020 06:27:24.366 >>> GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command >>> set VirtualMachine(1), command Resume(9)|#] >>> >>> So in this case command set 1 represents VirtualMachine and command >>> 9 is the Resume command. >>> >>> I was initially going to leverage jdwp.spec which is already >>> processed by build.tools.jdwpgen.Main to produce JDWP.java and >>> JDWPCommands.h. However, I could see it was more of a challenge than >>> I initially hoped. Also, the main advantage would have been not >>> having to hard code arrays of command names, but we already have >>> harded coded arrays of function pointers to handle the various jdwp >>> commands, so I just replaced these with a more specialized arrays >>> that also include the names of the commands. As an example, we used >>> to have: >>> >>> void *ArrayReference_Cmds[] = { (void *)0x3 >>> ???? ,(void *)length >>> ???? ,(void *)getValues >>> ???? ,(void *)setValues}; >>> >>> Now we have: >>> >>> CommandSet ArrayReference_Cmds = { >>> ???? 3, "ArrayReference", >>> ???? { >>> ???????? {length, "Length"}, >>> ???????? {getValues, "GetValues"}, >>> ???????? {setValues, "SetValues"} >>> ???? } >>> }; >>> >>> So no worse w.r.t. hard coding things that could be generated off >>> the spec, and it cleans up some ugly casts also. The CommandSet >>> typedef can be found in debugDispatch.h. >>> >>> All the header files except for debugDispatch.h have the same >>> pattern for changes, so they are pretty easy to review >>> >>> All .c files except debugDispatch.c and debugLoop.c also have the >>> same pattern. Note some command handler function names are not the >>> same as the command name. If you want to double check command set >>> names and command names, you can find the spec here: >>> >>> https://docs.oracle.com/javase/9/docs/specs/jdwp/jdwp-protocol.html >>> >>> In ReferenceTypeImpl.c I fixed a typo in the method() prototype. It >>> had an extra argument which I think was a very old copy-n-paste bug >>> from the method1() prototype. This was caught because the command >>> handler functions are now directly assigned to a CommandHandler type >>> rather than cast. The cast was hiding this bug. >>> >>> I tested by doing a test run where MISC logging was enabled by >>> default. All jdwp, jdb, and jdi tests were run in this way and passed. >>> >>> thanks, >>> >>> Chris >>> > > From serguei.spitsyn at oracle.com Tue Jan 14 09:40:10 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 Jan 2020 01:40:10 -0800 Subject: RFR(M): 8236913: debug agent's jdwp command logging should include the command set name and command name In-Reply-To: <00f114f1-78e9-cae0-d7ad-022406ac522a@oracle.com> References: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> <9babaeab-f9ec-57c7-ad32-69d7051dffba@oracle.com> <00f114f1-78e9-cae0-d7ad-022406ac522a@oracle.com> Message-ID: <7cc6ac73-3401-55ef-ee64-26cf27b566c7@oracle.com> An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Tue Jan 14 11:27:52 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 14 Jan 2020 12:27:52 +0100 Subject: serviceability agent : problems when using gcc LTO (link time optimization) In-Reply-To: References: Message-ID: <131b1189-d0e8-3d3e-6137-81ffc8eeeb84@oracle.com> On 2020-01-10 11:01, Baesken, Matthias wrote: > Hello, I recently looked into the gcc lto optimization mode (see for some details https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html and http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html ). > This mode can lead to more compact binaries (~10% smaller) , it also might bring small performance improvements but that wasn't my (main) goal . > > The changes for this are rather small , one needs to use a recent gcc , add -flto to the compile flags , for example > > --- a/make/autoconf/flags-cflags.m4 Wed Jan 01 03:08:45 2020 +0100 > +++ b/make/autoconf/flags-cflags.m4 Wed Jan 08 17:39:10 2020 +0100 > @@ -530,8 +530,13 @@ > fi > if test "x$TOOLCHAIN_TYPE" = xgcc; then > - TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new -fstack-protector" > - TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector" > + TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new -fstack-protector -flto" > + TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector -flto" > > .... and you have to make sure to use gcc-ar and gcc-nm instead of ar / nm . > Build and test(s) work, however with one exception. > The serviceability tests like serviceability/sa seems to rely heavily on the "normal" structure of libjvm.so (from what I understand e.g. in LinuxVtblAccess it is attempted to access internal symbols like _ZTV ). > > Errors in the sa tests look like : > > > java.lang.InternalError: Metadata does not appear to be polymorphic > at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:279) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:102) > at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:74) > at jdk.hotspot.agent/sun.jvm.hotspot.memory.SystemDictionary.getClassLoaderKlass(SystemDictionary.java:96) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:93) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:115) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:262) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:225) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:176) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:321) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:406) > > Has anyone experimented with LTO optimization ? Hi Matthias, We used to have LTO enabled on the old, closed-source Oracle arm-32 builds. There is still a "link-time-opt" JVM feature present; afaik it still works and adds the -flto flag. The main drawback of this is the *extremely* long link times of libjvm.so. I don't think servicability was ever supported for that platform, so I'm not surprised this does not work. /Magnus > > And to the serviceability agent experts - any idea how to make the jdk.hotspot.agent more independent from optimization settings ? > > > Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Tue Jan 14 12:49:43 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 14 Jan 2020 12:49:43 +0000 Subject: serviceability agent : problems when using gcc LTO (link time optimization) In-Reply-To: <131b1189-d0e8-3d3e-6137-81ffc8eeeb84@oracle.com> References: <131b1189-d0e8-3d3e-6137-81ffc8eeeb84@oracle.com> Message-ID: Hi Magnus, thanks for the info , I already noticed yesterday the setting for arm-32 in the minimal build . Do you think we could set it too for the other Linux platforms in the minimal build ( serviceability agent is not supported there as well so the observed issue wouldn?t be a problem). Best regards, Matthias On 2020-01-10 11:01, Baesken, Matthias wrote: Hello, I recently looked into the gcc lto optimization mode (see for some details https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html and http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html ). This mode can lead to more compact binaries (~10% smaller) , it also might bring small performance improvements but that wasn't my (main) goal . The changes for this are rather small , one needs to use a recent gcc , add -flto to the compile flags , for example --- a/make/autoconf/flags-cflags.m4 Wed Jan 01 03:08:45 2020 +0100 +++ b/make/autoconf/flags-cflags.m4 Wed Jan 08 17:39:10 2020 +0100 @@ -530,8 +530,13 @@ fi if test "x$TOOLCHAIN_TYPE" = xgcc; then - TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new -fstack-protector" - TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector" + TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new -fstack-protector -flto" + TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector -flto" .... and you have to make sure to use gcc-ar and gcc-nm instead of ar / nm . Build and test(s) work, however with one exception. The serviceability tests like serviceability/sa seems to rely heavily on the "normal" structure of libjvm.so (from what I understand e.g. in LinuxVtblAccess it is attempted to access internal symbols like _ZTV ). Errors in the sa tests look like : java.lang.InternalError: Metadata does not appear to be polymorphic at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:279) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:102) at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:74) at jdk.hotspot.agent/sun.jvm.hotspot.memory.SystemDictionary.getClassLoaderKlass(SystemDictionary.java:96) at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:93) at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:115) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:262) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:225) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:176) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:321) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:406) Has anyone experimented with LTO optimization ? Hi Matthias, We used to have LTO enabled on the old, closed-source Oracle arm-32 builds. There is still a "link-time-opt" JVM feature present; afaik it still works and adds the -flto flag. The main drawback of this is the *extremely* long link times of libjvm.so. I don't think servicability was ever supported for that platform, so I'm not surprised this does not work. /Magnus And to the serviceability agent experts - any idea how to make the jdk.hotspot.agent more independent from optimization settings ? Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Tue Jan 14 14:04:11 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 14 Jan 2020 15:04:11 +0100 Subject: serviceability agent : problems when using gcc LTO (link time optimization) In-Reply-To: References: <131b1189-d0e8-3d3e-6137-81ffc8eeeb84@oracle.com> Message-ID: <4fdc39f0-9ed3-5878-93b2-b536b8779125@oracle.com> On 2020-01-14 13:49, Baesken, Matthias wrote: > > Hi Magnus, thanks for the info , I already noticed yesterday the > setting for arm-32 in the minimal build . > > Do you think? we could set it too for the other Linux platforms? in > the minimal build? ( serviceability agent is not supported there as > well so the? observed issue wouldn?t be a problem). > You mean if you could enable it on your builds without any issues? I'd guess so, but I don't know. Just try it: --with-jvm-features="link-time-opt". If you mean that it should be turned on by default on minimal builds for all platforms? No, I don't think that's a good idea. The link time is really a killer. I remember arm-32 going from like a couple of minutes to half an hour for linking libjvm.so. Things might be different with gold, though. I know they have done work with at least some kind of "lightweight" LTO, that might be worth at least looking into. /Magnus > Best regards, Matthias > > On 2020-01-10 11:01, Baesken, Matthias wrote: > > Hello,?? I recently looked into? the? gcc? lto? optimization mode (see for some detailshttps://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html ? andhttp://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html ? ). > > This mode can lead to more compact binaries (~10% smaller)? , it also might bring? small performance improvements? but that wasn't my (main)? goal? . > > The changes for this are rather small , one needs to use a recent gcc? , add? -flto?? to the compile flags? , for example > > --- a/make/autoconf/flags-cflags.m4????? Wed Jan 01 03:08:45 2020 +0100 > > +++ b/make/autoconf/flags-cflags.m4?? Wed Jan 08 17:39:10 2020 +0100 > > @@ -530,8 +530,13 @@ > > ?? fi > > ?? if test "x$TOOLCHAIN_TYPE" = xgcc; then > > -??? TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new -fstack-protector" > > -??? TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector" > > +??? TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new -fstack-protector -flto" > > +??? TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector -flto" > > ? .... and you have to make sure? to use? gcc-ar? and? gcc-nm instead?? of? ar / nm . > > Build and test(s)? work,? however with? one exception. > > The? serviceability?? tests like? serviceability/sa?? seems to rely?? heavily? on the "normal"?? structure? of?? libjvm.so?? (from what I?? understand? e.g. in? LinuxVtblAccess? it is attempted to access? internal symbols? like? _ZTV ). > > Errors in the sa? tests look like : > > java.lang.InternalError: Metadata does not appear to be polymorphic > > ???????? at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:279) > > ???????? at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:102) > > ???? ????at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:74) > > ???????? at jdk.hotspot.agent/sun.jvm.hotspot.memory.SystemDictionary.getClassLoaderKlass(SystemDictionary.java:96) > > ???????? at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:93) > > ???????? at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78) > > ???????? at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:115) > > ??? ?????at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:262) > > ???????? at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:225) > > ???????? at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) > > ???????? at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:176) > > ???????? at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:321) > > ???????? at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:406) > > Has anyone experimented with LTO optimization ? > > > Hi Matthias, > > We used to have LTO enabled on the old, closed-source Oracle arm-32 > builds. There is still a "link-time-opt" JVM feature present; afaik it > still works and adds the -flto flag. The main drawback of this is the > *extremely* long link times of libjvm.so. > > I don't think servicability was ever supported for that platform, so > I'm not surprised this does not work. > > /Magnus > > > And to the? serviceability?? agent experts -? any idea? how to make the? jdk.hotspot.agent?? more independent from? optimization settings ? > > Best regards, Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksei.voitylov at bell-sw.com Tue Jan 14 15:15:14 2020 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Tue, 14 Jan 2020 18:15:14 +0300 Subject: serviceability agent : problems when using gcc LTO (link time optimization) In-Reply-To: <4fdc39f0-9ed3-5878-93b2-b536b8779125@oracle.com> References: <131b1189-d0e8-3d3e-6137-81ffc8eeeb84@oracle.com> <4fdc39f0-9ed3-5878-93b2-b536b8779125@oracle.com> Message-ID: <249cba82-1469-03f8-d205-e5895eab2cc3@bell-sw.com> Magnus, Matthias, for me, lto is a little heavyweight for development. x86_64 build time with gcc 7: Server 1m32.484s Server+Minimal 1m42.166s Server+Minimal (--with-jvm-features="link-time-opt") 5m29.422s If the change to enable lto by default is proposed, what would be the recommended strategy for development? For ARM32 Minimal, please keep in mind that it's not uncommon to disable LTO plugin in commodity ARM32 gcc compiler distributions, so for some it does not matter what settings we have in OpenJDK. I believe there could be other reasons for that on top of build time (bugs?). -Aleksei On 14/01/2020 17:04, Magnus Ihse Bursie wrote: > On 2020-01-14 13:49, Baesken, Matthias wrote: >> >> Hi Magnus, thanks for the info , I already noticed yesterday the >> setting for arm-32 in the minimal build . >> >> Do you think? we could set it too for the other Linux platforms? in >> the minimal build? ( serviceability agent is not supported there as >> well so the? observed issue wouldn?t be a problem). >> > > You mean if you could enable it on your builds without any issues? I'd > guess so, but I don't know. Just try it: > --with-jvm-features="link-time-opt". > > If you mean that it should be turned on by default on minimal builds > for all platforms? No, I don't think that's a good idea. The link time > is really a killer. I remember arm-32 going from like a couple of > minutes to half an hour for linking libjvm.so. > > Things might be different with gold, though. I know they have done > work with at least some kind of "lightweight" LTO, that might be worth > at least looking into. > > /Magnus > > >> Best regards, Matthias >> >> On 2020-01-10 11:01, Baesken, Matthias wrote: >> >> ??? Hello,?? I recently looked into? the? gcc? lto? optimization mode >> (see for some >> detailshttps://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html ? >> andhttp://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html >> ? ). >> >> ??? This mode can lead to more compact binaries (~10% smaller)? , it >> also might bring? small performance improvements? but that wasn't my >> (main)? goal? . >> >> ??? The changes for this are rather small , one needs to use a recent >> gcc? , add? -flto?? to the compile flags? , for example >> >> ??? --- a/make/autoconf/flags-cflags.m4????? Wed Jan 01 03:08:45 2020 >> +0100 >> >> ??? +++ b/make/autoconf/flags-cflags.m4?? Wed Jan 08 17:39:10 2020 +0100 >> >> ??? @@ -530,8 +530,13 @@ >> >> ???? ?? fi >> >> ???? ?? if test "x$TOOLCHAIN_TYPE" = xgcc; then >> >> ??? -??? TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new >> -fstack-protector" >> >> ??? -??? TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector" >> >> ??? +??? TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new >> -fstack-protector -flto" >> >> ??? +??? TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector -flto" >> >> ???? ? .... and you have to make sure? to use? gcc-ar? and? gcc-nm >> instead?? of? ar / nm . >> >> ??? Build and test(s)? work,? however with? one exception. >> >> ??? The? serviceability?? tests like? serviceability/sa?? seems to >> rely?? heavily? on the "normal"?? structure? of?? libjvm.so?? (from >> what I?? understand? e.g. in? LinuxVtblAccess? it is attempted to >> access? internal symbols? like? _ZTV ). >> >> ??? Errors in the sa? tests look like : >> >> ??? java.lang.InternalError: Metadata does not appear to be polymorphic >> >> ???? ???????? at >> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:279) >> >> ???? ???????? at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:102) >> >> ???? ???? ????at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:74) >> >> ???? ???????? at >> jdk.hotspot.agent/sun.jvm.hotspot.memory.SystemDictionary.getClassLoaderKlass(SystemDictionary.java:96) >> >> ???? ???????? at >> jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:93) >> >> ???? ???????? at >> jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78) >> >> ???? ???????? at >> jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:115) >> >> ???? ??? ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:262) >> >> ???? ???????? at >> jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:225) >> >> ???? ???????? at >> jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) >> >> ???? ???????? at >> jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:176) >> >> ???? ???????? at >> jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:321) >> >> ???? ???????? at >> jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:406) >> >> ??? Has anyone experimented with LTO optimization ? >> >> >> Hi Matthias, >> >> We used to have LTO enabled on the old, closed-source Oracle arm-32 >> builds. There is still a "link-time-opt" JVM feature present; afaik >> it still works and adds the -flto flag. The main drawback of this is >> the *extremely* long link times of libjvm.so. >> >> I don't think servicability was ever supported for that platform, so >> I'm not surprised this does not work. >> >> /Magnus >> >> >> ??? And to the? serviceability?? agent experts -? any idea? how to >> make the? jdk.hotspot.agent?? more independent from? optimization >> settings ? >> >> ??? Best regards, Matthias >> > From matthias.baesken at sap.com Tue Jan 14 16:57:33 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 14 Jan 2020 16:57:33 +0000 Subject: serviceability agent : problems when using gcc LTO (link time optimization) In-Reply-To: <249cba82-1469-03f8-d205-e5895eab2cc3@bell-sw.com> References: <131b1189-d0e8-3d3e-6137-81ffc8eeeb84@oracle.com> <4fdc39f0-9ed3-5878-93b2-b536b8779125@oracle.com> <249cba82-1469-03f8-d205-e5895eab2cc3@bell-sw.com> Message-ID: Hello Magnus and Aleksei, thanks for the input . The times you provided really look like they make a big difference at least for people often building minimal-vm . Guess I have to measure myself a bit (maybe the difference is not that big on our linux s390x / ppc64(le) ) . > > If the change to enable lto by default is proposed, what would be the > recommended strategy for development? > Probably we should a) do not enable it by default but just make sure it can be enabled easily and works for the minimal-vm or b) take it easy to disable it for local development. Best regards, Matthias > > Magnus, Matthias, > > for me, lto is a little heavyweight for development. x86_64 build time > with gcc 7: > > Server 1m32.484s > Server+Minimal 1m42.166s > Server+Minimal (--with-jvm-features="link-time-opt") 5m29.422s > > If the change to enable lto by default is proposed, what would be the > recommended strategy for development? > > For ARM32 Minimal, please keep in mind that it's not uncommon to disable > LTO plugin in commodity ARM32 gcc compiler distributions, so for some it > does not matter what settings we have in OpenJDK. I believe there could > be other reasons for that on top of build time (bugs?). > From aleksei.voitylov at bell-sw.com Tue Jan 14 17:54:36 2020 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Tue, 14 Jan 2020 20:54:36 +0300 Subject: serviceability agent : problems when using gcc LTO (link time optimization) In-Reply-To: References: <131b1189-d0e8-3d3e-6137-81ffc8eeeb84@oracle.com> <4fdc39f0-9ed3-5878-93b2-b536b8779125@oracle.com> <249cba82-1469-03f8-d205-e5895eab2cc3@bell-sw.com> Message-ID: <9908f346-f376-5bfc-8d5b-bc250e336032@bell-sw.com> On 14/01/2020 19:57, Baesken, Matthias wrote: > Hello Magnus and Aleksei, thanks for the input . > > The times you provided really look like they make a big difference at least for people often building minimal-vm . > Guess I have to measure myself a bit (maybe the difference is not that big on our linux s390x / ppc64(le) ) . > >> If the change to enable lto by default is proposed, what would be the >> recommended strategy for development? >> > Probably we should a) do not enable it by default but just make sure it can be enabled easily and works for the minimal-vm That would be welcome. I have high hopes to LTO the VM some time by default, and the tendency observed is that the compiler time overhead for GCC becomes smaller. At the same time there is no reason why vendors that invested in testing and can absorb the build time hit could provide binaries with LTO built VMs by passing an additional option flag. > or b) take it easy to disable it for local development. > > Best regards, Matthias > > > >> Magnus, Matthias, >> >> for me, lto is a little heavyweight for development. x86_64 build time >> with gcc 7: >> >> Server 1m32.484s >> Server+Minimal 1m42.166s >> Server+Minimal (--with-jvm-features="link-time-opt") 5m29.422s >> >> If the change to enable lto by default is proposed, what would be the >> recommended strategy for development? >> >> For ARM32 Minimal, please keep in mind that it's not uncommon to disable >> LTO plugin in commodity ARM32 gcc compiler distributions, so for some it >> does not matter what settings we have in OpenJDK. I believe there could >> be other reasons for that on top of build time (bugs?). >> From alexey.menkov at oracle.com Tue Jan 14 18:03:39 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 14 Jan 2020 10:03:39 -0800 Subject: RFR(M): 8236913: debug agent's jdwp command logging should include the command set name and command name In-Reply-To: <00f114f1-78e9-cae0-d7ad-022406ac522a@oracle.com> References: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> <9babaeab-f9ec-57c7-ad32-69d7051dffba@oracle.com> <00f114f1-78e9-cae0-d7ad-022406ac522a@oracle.com> Message-ID: <249a92a2-a19d-22b0-edb1-bc69172f8dac@oracle.com> Hi Chris, On 01/13/2020 20:11, Chris Plummer wrote: > Hi Alex, > > Are you ok with the _p arguments? Yes, LGTM. --alex > > Also, can I get a second reviewer please. > > thanks, > > Chris > > On 1/10/20 3:00 PM, Chris Plummer wrote: >> Hi Alex, >> >> I'll fix the mistakes in MethodImpl.c and ReferenceTypeImpl.c. As for >> the "_p" suffix, it means the argument is a pointer type that a value >> will be returned in. I've seen this used elsewhere in hotspot. For >> example VM_RedefineClasses::merge_constant_pools() and >> ObjectSynchronizer::deflate_monitor_list(). >> >> bool VM_RedefineClasses::merge_constant_pools(const >> constantPoolHandle& old_cp, >> ?????? const constantPoolHandle& scratch_cp, constantPoolHandle >> *merge_cp_p, >> ?????? int *merge_cp_length_p, TRAPS) { >> >> int ObjectSynchronizer::deflate_monitor_list(ObjectMonitor** list_p, >> ???????????????????????????????????????????? ObjectMonitor** free_head_p, >> ???????????????????????????????????????????? ObjectMonitor** >> free_tail_p) { >> >> thanks, >> >> Chris >> >> On 1/10/20 2:12 PM, Alex Menkov wrote: >>> Hi Chris, >>> >>> Thanks for making the code more "typed" (this "void*" arrays are >>> error prone). >>> Looks good in general, some minor comments: >>> >>> MethodImpl.c >>> - command names starts with lower case letters >>> >>> >>> ReferenceTypeImpl.c >>> - please fix indentation for command definitions >>> >>> >>> debugDispatch.h/.c >>> >>> +debugDispatch_getHandler(int cmdSetNum, int cmdNum, const char >>> **cmdSetName_p, const char **cmdName_p) >>> >>> What are the "_p" suffixes for? to show that this are pointers? >>> To me this doesn't make much sense. >>> >>> --alex >>> >>> On 01/10/2020 11:27, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review the following >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8236913 >>>> http://cr.openjdk.java.net/~cjplummer/8236913/webrev.00/ >>>> >>>> The debug agent has logging support that will trace all jdwp >>>> commands coming in. Currently all it traces is the command set >>>> number and the command number within that command set. So you see >>>> something like: >>>> >>>> [#|10.01.2020 06:27:24.366 >>>> GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command >>>> set 1, command 9|#] >>>> >>>> I've added support for including the name of the command set and >>>> command, so now you see: >>>> >>>> [#|10.01.2020 06:27:24.366 >>>> GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command >>>> set VirtualMachine(1), command Resume(9)|#] >>>> >>>> So in this case command set 1 represents VirtualMachine and command >>>> 9 is the Resume command. >>>> >>>> I was initially going to leverage jdwp.spec which is already >>>> processed by build.tools.jdwpgen.Main to produce JDWP.java and >>>> JDWPCommands.h. However, I could see it was more of a challenge than >>>> I initially hoped. Also, the main advantage would have been not >>>> having to hard code arrays of command names, but we already have >>>> harded coded arrays of function pointers to handle the various jdwp >>>> commands, so I just replaced these with a more specialized arrays >>>> that also include the names of the commands. As an example, we used >>>> to have: >>>> >>>> void *ArrayReference_Cmds[] = { (void *)0x3 >>>> ???? ,(void *)length >>>> ???? ,(void *)getValues >>>> ???? ,(void *)setValues}; >>>> >>>> Now we have: >>>> >>>> CommandSet ArrayReference_Cmds = { >>>> ???? 3, "ArrayReference", >>>> ???? { >>>> ???????? {length, "Length"}, >>>> ???????? {getValues, "GetValues"}, >>>> ???????? {setValues, "SetValues"} >>>> ???? } >>>> }; >>>> >>>> So no worse w.r.t. hard coding things that could be generated off >>>> the spec, and it cleans up some ugly casts also. The CommandSet >>>> typedef can be found in debugDispatch.h. >>>> >>>> All the header files except for debugDispatch.h have the same >>>> pattern for changes, so they are pretty easy to review >>>> >>>> All .c files except debugDispatch.c and debugLoop.c also have the >>>> same pattern. Note some command handler function names are not the >>>> same as the command name. If you want to double check command set >>>> names and command names, you can find the spec here: >>>> >>>> https://docs.oracle.com/javase/9/docs/specs/jdwp/jdwp-protocol.html >>>> >>>> In ReferenceTypeImpl.c I fixed a typo in the method() prototype. It >>>> had an extra argument which I think was a very old copy-n-paste bug >>>> from the method1() prototype. This was caught because the command >>>> handler functions are now directly assigned to a CommandHandler type >>>> rather than cast. The cast was hiding this bug. >>>> >>>> I tested by doing a test run where MISC logging was enabled by >>>> default. All jdwp, jdb, and jdi tests were run in this way and passed. >>>> >>>> thanks, >>>> >>>> Chris >>>> >> >> > > From chris.plummer at oracle.com Tue Jan 14 18:39:12 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 14 Jan 2020 10:39:12 -0800 Subject: RFR(M): 8236913: debug agent's jdwp command logging should include the command set name and command name In-Reply-To: <7cc6ac73-3401-55ef-ee64-26cf27b566c7@oracle.com> References: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> <9babaeab-f9ec-57c7-ad32-69d7051dffba@oracle.com> <00f114f1-78e9-cae0-d7ad-022406ac522a@oracle.com> <7cc6ac73-3401-55ef-ee64-26cf27b566c7@oracle.com> Message-ID: <8836c77d-6b52-e8d4-eb20-85de8dcfbe85@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Jan 14 18:47:18 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 Jan 2020 10:47:18 -0800 Subject: RFR(M): 8236913: debug agent's jdwp command logging should include the command set name and command name In-Reply-To: <8836c77d-6b52-e8d4-eb20-85de8dcfbe85@oracle.com> References: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> <9babaeab-f9ec-57c7-ad32-69d7051dffba@oracle.com> <00f114f1-78e9-cae0-d7ad-022406ac522a@oracle.com> <7cc6ac73-3401-55ef-ee64-26cf27b566c7@oracle.com> <8836c77d-6b52-e8d4-eb20-85de8dcfbe85@oracle.com> Message-ID: <14b741a9-6247-6b6a-e6e4-ed297a92c232@oracle.com> Hi Chris, Okay, thanks! Serguei On 1/14/20 10:39 AM, Chris Plummer wrote: > Hi Serguei, > > I didn't want to return a Command because then the cmdSetNum and > cmdNum would need to be checked by the caller before calling > debugDispatch_getHandler()or have special handling for NULL being > returned. > > Thanks for the review. > > Chris > > On 1/14/20 1:40 AM, serguei.spitsyn at oracle.com wrote: >> Hi Chris, >> >> It looks good to me modulo the comments from Alex. >> I'm ok with the _p arguments. >> Probably, you've already considered to return Command (instead >> ofCommandHandler) from the debugDispatch_getHandler(). >> It allows to get rid of the cmdName_pargument but gives a >> non-symmetry in getting names. >> I think, it would not give any real advantage, so I'm ok with current >> approach. >> >> Thanks, >> Serguei >> >> >> On 1/13/20 20:11, Chris Plummer wrote: >>> Hi Alex, >>> >>> Are you ok with the _p arguments? >>> >>> Also, can I get a second reviewer please. >>> >>> thanks, >>> >>> Chris >>> >>> On 1/10/20 3:00 PM, Chris Plummer wrote: >>>> Hi Alex, >>>> >>>> I'll fix the mistakes in MethodImpl.c and ReferenceTypeImpl.c. As >>>> for the "_p" suffix, it means the argument is a pointer type that a >>>> value will be returned in. I've seen this used elsewhere in >>>> hotspot. For example VM_RedefineClasses::merge_constant_pools() and >>>> ObjectSynchronizer::deflate_monitor_list(). >>>> >>>> bool VM_RedefineClasses::merge_constant_pools(const >>>> constantPoolHandle& old_cp, >>>> ?????? const constantPoolHandle& scratch_cp, constantPoolHandle >>>> *merge_cp_p, >>>> ?????? int *merge_cp_length_p, TRAPS) { >>>> >>>> int ObjectSynchronizer::deflate_monitor_list(ObjectMonitor** list_p, >>>> ???????????????????????????????????????????? ObjectMonitor** >>>> free_head_p, >>>> ???????????????????????????????????????????? ObjectMonitor** >>>> free_tail_p) { >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 1/10/20 2:12 PM, Alex Menkov wrote: >>>>> Hi Chris, >>>>> >>>>> Thanks for making the code more "typed" (this "void*" arrays are >>>>> error prone). >>>>> Looks good in general, some minor comments: >>>>> >>>>> MethodImpl.c >>>>> - command names starts with lower case letters >>>>> >>>>> >>>>> ReferenceTypeImpl.c >>>>> - please fix indentation for command definitions >>>>> >>>>> >>>>> debugDispatch.h/.c >>>>> >>>>> +debugDispatch_getHandler(int cmdSetNum, int cmdNum, const char >>>>> **cmdSetName_p, const char **cmdName_p) >>>>> >>>>> What are the "_p" suffixes for? to show that this are pointers? >>>>> To me this doesn't make much sense. >>>>> >>>>> --alex >>>>> >>>>> On 01/10/2020 11:27, Chris Plummer wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the following >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8236913 >>>>>> http://cr.openjdk.java.net/~cjplummer/8236913/webrev.00/ >>>>>> >>>>>> The debug agent has logging support that will trace all jdwp >>>>>> commands coming in. Currently all it traces is the command set >>>>>> number and the command number within that command set. So you see >>>>>> something like: >>>>>> >>>>>> [#|10.01.2020 06:27:24.366 >>>>>> GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command >>>>>> set 1, command 9|#] >>>>>> >>>>>> I've added support for including the name of the command set and >>>>>> command, so now you see: >>>>>> >>>>>> [#|10.01.2020 06:27:24.366 >>>>>> GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command >>>>>> set VirtualMachine(1), command Resume(9)|#] >>>>>> >>>>>> So in this case command set 1 represents VirtualMachine and >>>>>> command 9 is the Resume command. >>>>>> >>>>>> I was initially going to leverage jdwp.spec which is already >>>>>> processed by build.tools.jdwpgen.Main to produce JDWP.java and >>>>>> JDWPCommands.h. However, I could see it was more of a challenge >>>>>> than I initially hoped. Also, the main advantage would have been >>>>>> not having to hard code arrays of command names, but we already >>>>>> have harded coded arrays of function pointers to handle the >>>>>> various jdwp commands, so I just replaced these with a more >>>>>> specialized arrays that also include the names of the commands. >>>>>> As an example, we used to have: >>>>>> >>>>>> void *ArrayReference_Cmds[] = { (void *)0x3 >>>>>> ???? ,(void *)length >>>>>> ???? ,(void *)getValues >>>>>> ???? ,(void *)setValues}; >>>>>> >>>>>> Now we have: >>>>>> >>>>>> CommandSet ArrayReference_Cmds = { >>>>>> ???? 3, "ArrayReference", >>>>>> ???? { >>>>>> ???????? {length, "Length"}, >>>>>> ???????? {getValues, "GetValues"}, >>>>>> ???????? {setValues, "SetValues"} >>>>>> ???? } >>>>>> }; >>>>>> >>>>>> So no worse w.r.t. hard coding things that could be generated off >>>>>> the spec, and it cleans up some ugly casts also. The CommandSet >>>>>> typedef can be found in debugDispatch.h. >>>>>> >>>>>> All the header files except for debugDispatch.h have the same >>>>>> pattern for changes, so they are pretty easy to review >>>>>> >>>>>> All .c files except debugDispatch.c and debugLoop.c also have the >>>>>> same pattern. Note some command handler function names are not >>>>>> the same as the command name. If you want to double check command >>>>>> set names and command names, you can find the spec here: >>>>>> >>>>>> https://docs.oracle.com/javase/9/docs/specs/jdwp/jdwp-protocol.html >>>>>> >>>>>> In ReferenceTypeImpl.c I fixed a typo in the method() prototype. >>>>>> It had an extra argument which I think was a very old >>>>>> copy-n-paste bug from the method1() prototype. This was caught >>>>>> because the command handler functions are now directly assigned >>>>>> to a CommandHandler type rather than cast. The cast was hiding >>>>>> this bug. >>>>>> >>>>>> I tested by doing a test run where MISC logging was enabled by >>>>>> default. All jdwp, jdb, and jdi tests were run in this way and >>>>>> passed. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>> >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Tue Jan 14 19:38:46 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 14 Jan 2020 14:38:46 -0500 Subject: RFR (XS) 8236917: TestInstanceKlassSize.java fails with "The size computed by SA for java.lang.Object does not match" Message-ID: <82c47d9a-80fb-e465-f9f9-dac9dc3c469b@oracle.com> Summary: Use getTestJavaOpts() instead of getVmOptions() because of mach5 configuration settings. Tested with hs-tier3 with no failures anymore. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8236917.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8236917 Thanks, Coleen From coleen.phillimore at oracle.com Tue Jan 14 20:37:24 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 14 Jan 2020 15:37:24 -0500 Subject: RFR (XS) 8236968: jmap -clstats fails to work after JDK-8232759 Message-ID: Summary: Make jmap -clstats call jcmd VM.classloader_stats instead which better matches the documentation Tested with tier1 and * jtreg:open/test/jdk/sun/tools/jmap/BasicJMapTest.java ?locally. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8236968.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8236968 Thanks, Coleen From leonid.mesnik at oracle.com Tue Jan 14 20:45:33 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Tue, 14 Jan 2020 12:45:33 -0800 Subject: RFR (XS) 8236917: TestInstanceKlassSize.java fails with "The size computed by SA for java.lang.Object does not match" In-Reply-To: <82c47d9a-80fb-e465-f9f9-dac9dc3c469b@oracle.com> References: <82c47d9a-80fb-e465-f9f9-dac9dc3c469b@oracle.com> Message-ID: Hi The fix looks good itself (you still need 'R'eview). However I see about 20 other SA/ tests where lingeredApp is still executed with vm.opts only. Even it doesn't cause any failures it means that tests silently ignore java.opts set by user. I think it makes sense to fix them also or file new issue for this activity. Leonid On 1/14/20 11:38 AM, coleen.phillimore at oracle.com wrote: > Summary: Use getTestJavaOpts() instead of getVmOptions() because of > mach5 configuration settings. > > Tested with hs-tier3 with no failures anymore. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8236917.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8236917 > > Thanks, > Coleen From alexey.menkov at oracle.com Tue Jan 14 20:39:12 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 14 Jan 2020 12:39:12 -0800 Subject: RFR: JDK-8235846: Improve WindbgDebuggerLocal implementation In-Reply-To: <6ed9a23f-3ba4-cbf2-8156-26b4e3731eeb@oracle.com> References: <8ca073bf-0f82-46d5-7fd1-0a5b5757bfa4@oracle.com> <6ed9a23f-3ba4-cbf2-8156-26b4e3731eeb@oracle.com> Message-ID: <2bac872a-e538-83e9-1448-dcd788de2cee@oracle.com> Hi Serguei, Thank you for the review. updated webrev: http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.02/ On 01/13/2020 16:39, serguei.spitsyn at oracle.com wrote: > Hi Alex, > > It looks pretty good. > Just some minor comments below. > > The class AutoCOMPtr has unfixed indents. > I guess, the function AutoArrayPtr.asPtr() is not used anymore and can > be deleted. fixed. > > I'd suggest to remove first level '()' brackets in the comment to avoid > brackets nesting: 74 // manage COM 'auto' pointers (to avoid multiple > Release 75 // calls at every early (exception) returns). => 74 // manage > COM 'auto' pointers to avoid multiple Release > 75 // calls at every early (exception) returns. done. > I'd suggest to reformat it as it was originally formatted: > > 297 if (IsEqualIID(interfaceId, __uuidof(IUnknown)) > 298 || IsEqualIID(interfaceId, __uuidof(IDebugOutputCallbacks))) { => > 297 if (IsEqualIID(interfaceId, __uuidof(IUnknown)) || > 298 IsEqualIID(interfaceId, __uuidof(IDebugOutputCallbacks))) { done. > The comment about S_FALSE is not that clear as S_FALSE is not really used > (better to use consistently just one value: S_FALSE or false): > > 418 // S_FALSE means timeout > 419 COM_VERIFY_OK_(ptrIDebugControl->WaitForEvent(DEBUG_WAIT_DEFAULT, > INFINITE), > 420 "Windbg Error: WaitForEvent failed!", false); S_FALSE is a possible result of ptrIDebugControl->WaitForEvent call. In the case we wait infinitely, so S_FALSE is not possible and we don't handle it separately. I removed the comment. > NULL is used in some placesand nullptr in others. There is some mess with 0/NULL/nullptr in the file I fixed all NULLs and some (most likely not all) 0s. BTW it immediately discovered misuse of NULL/0: - if (ptrIDebugSymbols->GetModuleParameters(loaded, 0, NULL, params.asPtr()) != S_OK) { - THROW_NEW_DEBUGGER_EXCEPTION_("Windbg Error: GetModuleParameters failed!", false); - } + COM_VERIFY_OK_(ptrIDebugSymbols->GetModuleParameters(loaded, nullptr, 0, params), + "Windbg Error: GetModuleParameters failed!", false); 2nd arg of GetModuleParameters is a pointer and 3rd is ulong --alex > > Thanks, > Serguei > > > On 12/19/19 15:34, Alex Menkov wrote: >> Hi all, >> >> Please review a fix for >> https://bugs.openjdk.java.net/browse/JDK-8235846 >> webrev: >> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.01/ >> >> Main goal of the change is to improve error reporting (we have several >> bugs and need at least COM error codes for WinDbg calls). >> Also the fix improves/rearranges this quite old code. >> >> --alex > From chris.plummer at oracle.com Tue Jan 14 20:57:20 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 14 Jan 2020 12:57:20 -0800 Subject: RFR (XS) 8236917: TestInstanceKlassSize.java fails with "The size computed by SA for java.lang.Object does not match" In-Reply-To: <82c47d9a-80fb-e465-f9f9-dac9dc3c469b@oracle.com> References: <82c47d9a-80fb-e465-f9f9-dac9dc3c469b@oracle.com> Message-ID: <5323dd0a-cc3f-97dc-6baf-41d86be00007@oracle.com> Looks good. Thanks for fixing! Chris On 1/14/20 11:38 AM, coleen.phillimore at oracle.com wrote: > Summary: Use getTestJavaOpts() instead of getVmOptions() because of > mach5 configuration settings. > > Tested with hs-tier3 with no failures anymore. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8236917.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8236917 > > Thanks, > Coleen From daniil.x.titov at oracle.com Tue Jan 14 21:05:10 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 14 Jan 2020 13:05:10 -0800 Subject: RFR: 8213222: remove RMIConnectorServer.CREDENTIAL_TYPES Message-ID: Hi Alan and Daniel, Thank you for reviewing this change and the CSR. I updated the release note as Daniel suggested. Best regards, Daniil ?On 1/13/20, 7:36 AM, "Daniel Fuchs" wrote: Hi Daniil, Looks good to me as well. I wonder however if the release note should point to the replacement? Something like: The terminally deprecated constant `javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE` has been removed. A filter pattern can be specified instead using `RMIConnectorServer.CREDENTIALS_FILTER_PATTERN`. best regards, -- daniel On 11/01/2020 04:52, Daniil Titov wrote: > Please review a change [1] that removes constant javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE. > This constant represents the name of the attribute that specifies a list of class names acceptable to the RMIServer.newClient() > remote method call. This constant was superseded by RMIConnectorServer.CREDENTIALS_FILTER_PATTERN and marked as > deprecated for removal in JDK 10 [3]. > > A new CRS [4] and a release note sub-task [5] were also created. Please review the CSR [4] as well. > > Text search over the repository didn't find any other usage of this constant. Tier1 - tier3 Mach5 tests succeeded. > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8213222/webrev.01/ > [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8213222 > [3] https://bugs.openjdk.java.net/browse/JDK-8191313 > [4] CSR: https://bugs.openjdk.java.net/browse/JDK-8236954 > [5] Release Note sub-task: https://bugs.openjdk.java.net/browse/JDK-8236955 > > Thank you, > Daniil > > From coleen.phillimore at oracle.com Tue Jan 14 21:09:04 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 14 Jan 2020 16:09:04 -0500 Subject: RFR (XS) 8236917: TestInstanceKlassSize.java fails with "The size computed by SA for java.lang.Object does not match" In-Reply-To: References: <82c47d9a-80fb-e465-f9f9-dac9dc3c469b@oracle.com> Message-ID: On 1/14/20 3:45 PM, Leonid Mesnik wrote: > Hi > > The fix looks good itself (you still need 'R'eview). However I see > about 20 other SA/ tests where lingeredApp is still executed with > vm.opts only. Even it doesn't cause any failures it means that tests > silently ignore java.opts set by user. > > I think it makes sense to fix them also or file new issue for this > activity. I'll file another bug for the other instances.? I'm not sure that maybe we want to remove getVmOptions() with that bug, so as not to trick anyone else. Thanks, Coleen > > Leonid > > On 1/14/20 11:38 AM, coleen.phillimore at oracle.com wrote: >> Summary: Use getTestJavaOpts() instead of getVmOptions() because of >> mach5 configuration settings. >> >> Tested with hs-tier3 with no failures anymore. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8236917.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8236917 >> >> Thanks, >> Coleen From serguei.spitsyn at oracle.com Tue Jan 14 21:10:14 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 Jan 2020 13:10:14 -0800 Subject: RFR: JDK-8235846: Improve WindbgDebuggerLocal implementation In-Reply-To: <2bac872a-e538-83e9-1448-dcd788de2cee@oracle.com> References: <8ca073bf-0f82-46d5-7fd1-0a5b5757bfa4@oracle.com> <6ed9a23f-3ba4-cbf2-8156-26b4e3731eeb@oracle.com> <2bac872a-e538-83e9-1448-dcd788de2cee@oracle.com> Message-ID: <2a7a52f8-aaea-2124-faaf-d371d8bcbb8e@oracle.com> Hi Alex, Thank you for the update! It looks good. Still incorrect indent: 103 ~AutoJavaString() { 104 if (m_buf) { 105 m_env->ReleaseStringUTFChars(m_str, m_buf); 106 } 107 } 108 109 operator const char* () const { 110 return m_buf; 111 } ... 133 void setReleaseMode(jint mode) { 134 releaseMode = mode; 135 } 136 137 operator jbyte* () const { 138 return bytePtr; 139 } The comment shout start from a capital letter: 177 // verifies COM call result is S_OK, throws DebuggerException and exits otherwise. No need for another webrev. Thanks, Serguei On 1/14/20 12:39 PM, Alex Menkov wrote: > Hi Serguei, > > Thank you for the review. > updated webrev: > http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.02/ > > On 01/13/2020 16:39, serguei.spitsyn at oracle.com wrote: >> Hi Alex, >> >> It looks pretty good. >> Just some minor comments below. >> >> The class AutoCOMPtr has unfixed indents. >> I guess, the function AutoArrayPtr.asPtr() is not used anymore and >> can be deleted. > > fixed. > >> >> I'd suggest to remove first level '()' brackets in the comment to >> avoid brackets nesting: 74 // manage COM 'auto' pointers (to avoid >> multiple Release 75 // calls at every early (exception) returns). => >> 74 // manage COM 'auto' pointers to avoid multiple Release >> 75 // calls at every early (exception) returns. > > done. > >> I'd suggest to reformat it as it was originally formatted: >> >> 297 if (IsEqualIID(interfaceId, __uuidof(IUnknown)) >> 298 || IsEqualIID(interfaceId, __uuidof(IDebugOutputCallbacks))) { => >> 297 if (IsEqualIID(interfaceId, __uuidof(IUnknown))? || >> 298 IsEqualIID(interfaceId, __uuidof(IDebugOutputCallbacks))) { > > done. > >> The comment about S_FALSE is not that clear as S_FALSE is not really >> used >> (better to use consistently just one value: S_FALSE or false): >> >> 418 // S_FALSE means timeout >> 419 COM_VERIFY_OK_(ptrIDebugControl->WaitForEvent(DEBUG_WAIT_DEFAULT, >> INFINITE), >> 420 "Windbg Error: WaitForEvent failed!", false); > > S_FALSE is a possible result of ptrIDebugControl->WaitForEvent call. > In the case we wait infinitely, so S_FALSE is not possible and we > don't handle it separately. > I removed the comment. > > >> NULL is used in some placesand nullptr in others. > > There is some mess with 0/NULL/nullptr in the file > I fixed all NULLs and some (most likely not all) 0s. > BTW it immediately discovered misuse of NULL/0: > > -? if (ptrIDebugSymbols->GetModuleParameters(loaded, 0, NULL, > params.asPtr()) != S_OK) { > -???? THROW_NEW_DEBUGGER_EXCEPTION_("Windbg Error: GetModuleParameters > failed!", false); > -? } > +? COM_VERIFY_OK_(ptrIDebugSymbols->GetModuleParameters(loaded, > nullptr, 0, params), > +???????????????? "Windbg Error: GetModuleParameters failed!", false); > > 2nd arg of GetModuleParameters is a pointer and 3rd is ulong > > --alex >> >> Thanks, >> Serguei >> >> >> On 12/19/19 15:34, Alex Menkov wrote: >>> Hi all, >>> >>> Please review a fix for >>> https://bugs.openjdk.java.net/browse/JDK-8235846 >>> webrev: >>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.01/ >>> >>> Main goal of the change is to improve error reporting (we have >>> several bugs and need at least COM error codes for WinDbg calls). >>> Also the fix improves/rearranges this quite old code. >>> >>> --alex >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Tue Jan 14 21:13:45 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 14 Jan 2020 16:13:45 -0500 Subject: RFR (XS) 8236917: TestInstanceKlassSize.java fails with "The size computed by SA for java.lang.Object does not match" In-Reply-To: <5323dd0a-cc3f-97dc-6baf-41d86be00007@oracle.com> References: <82c47d9a-80fb-e465-f9f9-dac9dc3c469b@oracle.com> <5323dd0a-cc3f-97dc-6baf-41d86be00007@oracle.com> Message-ID: Thanks Chris! Coleen On 1/14/20 3:57 PM, Chris Plummer wrote: > Looks good. Thanks for fixing! > > Chris > > On 1/14/20 11:38 AM, coleen.phillimore at oracle.com wrote: >> Summary: Use getTestJavaOpts() instead of getVmOptions() because of >> mach5 configuration settings. >> >> Tested with hs-tier3 with no failures anymore. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8236917.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8236917 >> >> Thanks, >> Coleen > From david.holmes at oracle.com Tue Jan 14 21:56:14 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Jan 2020 07:56:14 +1000 Subject: RFR (XS) 8236917: TestInstanceKlassSize.java fails with "The size computed by SA for java.lang.Object does not match" In-Reply-To: <82c47d9a-80fb-e465-f9f9-dac9dc3c469b@oracle.com> References: <82c47d9a-80fb-e465-f9f9-dac9dc3c469b@oracle.com> Message-ID: <03858f3d-d5f8-5295-374d-a893cc2bcd3d@oracle.com> Fix looks good - thanks Coleen. This one certainly had us scratching our heads for a while! I agree there should be a follow up issue about use of getVmOptions() in tests. David On 15/01/2020 5:38 am, coleen.phillimore at oracle.com wrote: > Summary: Use getTestJavaOpts() instead of getVmOptions() because of > mach5 configuration settings. > > Tested with hs-tier3 with no failures anymore. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8236917.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8236917 > > Thanks, > Coleen From coleen.phillimore at oracle.com Tue Jan 14 21:58:56 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 14 Jan 2020 16:58:56 -0500 Subject: RFR (XS) 8236917: TestInstanceKlassSize.java fails with "The size computed by SA for java.lang.Object does not match" In-Reply-To: <03858f3d-d5f8-5295-374d-a893cc2bcd3d@oracle.com> References: <82c47d9a-80fb-e465-f9f9-dac9dc3c469b@oracle.com> <03858f3d-d5f8-5295-374d-a893cc2bcd3d@oracle.com> Message-ID: Thanks David.? The follow up issue is: https://bugs.openjdk.java.net/browse/JDK-8237111 But there are more than the LingeredApps that use getVmOptions(). Somebody should make sure all these tests are getting the right values. thanks, Coleen On 1/14/20 4:56 PM, David Holmes wrote: > Fix looks good - thanks Coleen. This one certainly had us scratching > our heads for a while! > > I agree there should be a follow up issue about use of getVmOptions() > in tests. > > David > > On 15/01/2020 5:38 am, coleen.phillimore at oracle.com wrote: >> Summary: Use getTestJavaOpts() instead of getVmOptions() because of >> mach5 configuration settings. >> >> Tested with hs-tier3 with no failures anymore. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8236917.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8236917 >> >> Thanks, >> Coleen From david.holmes at oracle.com Tue Jan 14 23:11:17 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Jan 2020 09:11:17 +1000 Subject: RFR (XS) 8236968: jmap -clstats fails to work after JDK-8232759 In-Reply-To: References: Message-ID: <5aee7f85-bb76-9a28-2f71-e2e5dca6a581@oracle.com> Hi Coleen, I concur with the discussion in the bug report. This change looks good. Thanks, David On 15/01/2020 6:37 am, coleen.phillimore at oracle.com wrote: > Summary: Make jmap -clstats call jcmd VM.classloader_stats instead which > better matches the documentation > > Tested with tier1 and * > jtreg:open/test/jdk/sun/tools/jmap/BasicJMapTest.java > ?locally. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8236968.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8236968 > > Thanks, > Coleen From chris.plummer at oracle.com Tue Jan 14 23:11:34 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 14 Jan 2020 15:11:34 -0800 Subject: RFR (XS) 8236968: jmap -clstats fails to work after JDK-8232759 In-Reply-To: References: Message-ID: Hi Coleen, Looks good. Please update the copyright. thanks, Chris On 1/14/20 12:37 PM, coleen.phillimore at oracle.com wrote: > Summary: Make jmap -clstats call jcmd VM.classloader_stats instead > which better matches the documentation > > Tested with tier1 and * > jtreg:open/test/jdk/sun/tools/jmap/BasicJMapTest.java > ?locally. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8236968.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8236968 > > Thanks, > Coleen From coleen.phillimore at oracle.com Tue Jan 14 23:18:52 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 14 Jan 2020 18:18:52 -0500 Subject: RFR (XS) 8236968: jmap -clstats fails to work after JDK-8232759 In-Reply-To: References: Message-ID: <2b09f3b6-c7ca-b12b-9ee5-d5ff1dc254c6@oracle.com> Thanks Chris, I'll fix the copyrights on commit. Coleen On 1/14/20 6:11 PM, Chris Plummer wrote: > Hi Coleen, > > Looks good. Please update the copyright. > > thanks, > > Chris > > On 1/14/20 12:37 PM, coleen.phillimore at oracle.com wrote: >> Summary: Make jmap -clstats call jcmd VM.classloader_stats instead >> which better matches the documentation >> >> Tested with tier1 and * >> jtreg:open/test/jdk/sun/tools/jmap/BasicJMapTest.java >> ?locally. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8236968.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8236968 >> >> Thanks, >> Coleen > > From hohensee at amazon.com Wed Jan 15 00:00:42 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 15 Jan 2020 00:00:42 +0000 Subject: RFR 8235300: VM_HeapDumper hits assert with bad dump_len Message-ID: <7271C378-98AF-406A-8628-1A6ADDCF7A39@amazon.com> Please review this CSR for a backport of JDK-8144732 to jdk8u. JBS issue: https://bugs.openjdk.java.net/browse/JDK-8144732 JBS release note issue: https://bugs.openjdk.java.net/browse/JDK-8174881 8u backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8235299 8u backport CSR: https://bugs.openjdk.java.net/browse/JDK-8235300 The original patch went through the Oracle CCC process prior to the creation of the public CSR process, so there?s no public CSR issue, hence the release note JBS issue reference. Thanks, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Jan 15 01:12:24 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Jan 2020 11:12:24 +1000 Subject: RFR 8235300: VM_HeapDumper hits assert with bad dump_len In-Reply-To: <7271C378-98AF-406A-8628-1A6ADDCF7A39@amazon.com> References: <7271C378-98AF-406A-8628-1A6ADDCF7A39@amazon.com> Message-ID: <75ab359d-e556-849d-1bda-eedd9e32c09d@oracle.com> Hi Paul, I made some minor updates to the CSR request and added myself as a reviewer. Thanks, David On 15/01/2020 10:00 am, Hohensee, Paul wrote: > Please review this CSR for a backport of JDK-8144732 to jdk8u. > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8144732 > > JBS release note issue: https://bugs.openjdk.java.net/browse/JDK-8174881 > > 8u backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8235299 > > 8u backport CSR: https://bugs.openjdk.java.net/browse/JDK-8235300 > > The original patch went through the Oracle CCC process prior to the > creation of the public CSR process, so there?s no public CSR issue, > hence the release note JBS issue reference. > > Thanks, > > Paul > From coleen.phillimore at oracle.com Wed Jan 15 13:14:35 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 Jan 2020 08:14:35 -0500 Subject: RFR (XS) 8236968: jmap -clstats fails to work after JDK-8232759 In-Reply-To: <5aee7f85-bb76-9a28-2f71-e2e5dca6a581@oracle.com> References: <5aee7f85-bb76-9a28-2f71-e2e5dca6a581@oracle.com> Message-ID: Thanks David and thanks for the discussion. Coleen On 1/14/20 6:11 PM, David Holmes wrote: > Hi Coleen, > > I concur with the discussion in the bug report. This change looks good. > > Thanks, > David > > On 15/01/2020 6:37 am, coleen.phillimore at oracle.com wrote: >> Summary: Make jmap -clstats call jcmd VM.classloader_stats instead >> which better matches the documentation >> >> Tested with tier1 and * >> jtreg:open/test/jdk/sun/tools/jmap/BasicJMapTest.java >> ??locally. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8236968.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8236968 >> >> Thanks, >> Coleen From volker.simonis at gmail.com Wed Jan 15 13:40:02 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2020 05:40:02 -0800 Subject: serviceability agent : problems when using gcc LTO (link time optimization) In-Reply-To: <9908f346-f376-5bfc-8d5b-bc250e336032@bell-sw.com> References: <131b1189-d0e8-3d3e-6137-81ffc8eeeb84@oracle.com> <4fdc39f0-9ed3-5878-93b2-b536b8779125@oracle.com> <249cba82-1469-03f8-d205-e5895eab2cc3@bell-sw.com> <9908f346-f376-5bfc-8d5b-bc250e336032@bell-sw.com> Message-ID: While we are speaking about all the drawbacks of LTO, it's still not clear what the benefits are? In the very first mail Matthias mentioned that there might be performance improvements but that performance is not the main driving factor behind this initiative. So is it the reduced code size (Matthias mentioned something around ~10%)? It would be nice to see some real numbers on various platform for both, the performance improvements for native parts like JIT/GC as well as for the size reduction. Aleksei Voitylov schrieb am Di., 14. Jan. 2020, 09:54: > > On 14/01/2020 19:57, Baesken, Matthias wrote: > > Hello Magnus and Aleksei, thanks for the input . > > > > The times you provided really look like they make a big difference at > least for people often building minimal-vm . > > Guess I have to measure myself a bit (maybe the difference is not that > big on our linux s390x / ppc64(le) ) . > > > >> If the change to enable lto by default is proposed, what would be the > >> recommended strategy for development? > >> > > Probably we should a) do not enable it by default but just make sure > it can be enabled easily and works for the minimal-vm > That would be welcome. I have high hopes to LTO the VM some time by > default, and the tendency observed is that the compiler time overhead > for GCC becomes smaller. At the same time there is no reason why vendors > that invested in testing and can absorb the build time hit could provide > binaries with LTO built VMs by passing an additional option flag. > > or b) take it easy to disable it for local development. > > > > Best regards, Matthias > > > > > > > >> Magnus, Matthias, > >> > >> for me, lto is a little heavyweight for development. x86_64 build time > >> with gcc 7: > >> > >> Server 1m32.484s > >> Server+Minimal 1m42.166s > >> Server+Minimal (--with-jvm-features="link-time-opt") 5m29.422s > >> > >> If the change to enable lto by default is proposed, what would be the > >> recommended strategy for development? > >> > >> For ARM32 Minimal, please keep in mind that it's not uncommon to disable > >> LTO plugin in commodity ARM32 gcc compiler distributions, so for some it > >> does not matter what settings we have in OpenJDK. I believe there could > >> be other reasons for that on top of build time (bugs?). > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksei.voitylov at bell-sw.com Wed Jan 15 14:57:11 2020 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Wed, 15 Jan 2020 17:57:11 +0300 Subject: serviceability agent : problems when using gcc LTO (link time optimization) In-Reply-To: References: <131b1189-d0e8-3d3e-6137-81ffc8eeeb84@oracle.com> <4fdc39f0-9ed3-5878-93b2-b536b8779125@oracle.com> <249cba82-1469-03f8-d205-e5895eab2cc3@bell-sw.com> <9908f346-f376-5bfc-8d5b-bc250e336032@bell-sw.com> Message-ID: <58b2c73c-c49e-49cf-71fc-7d6c2225b880@bell-sw.com> Volker, not a full answer, but here is some static size stats: Server ??? x86_64? AArch64 regular ??? 23M ?? ?? 20M lto ??? ??? ?? 17M ? ??? 14M Minimal?? x86_64? AArch64 regular???? 4.9M????? 3.9M lto??????????? 4.7M????? 3.6M -Aleksei On 15/01/2020 16:40, Volker Simonis wrote: > While we are speaking about all the drawbacks of LTO, it's still not > clear what the benefits are? In the very first mail Matthias mentioned > that there might be performance improvements but that performance is > not the main driving factor behind this initiative. So is it the > reduced code size (Matthias mentioned something around ~10%)? > > It would be nice to see some real numbers on various platform for > both, the performance improvements for native parts like JIT/GC as > well as for the size reduction. > > Aleksei Voitylov > schrieb am Di., 14. Jan. 2020, > 09:54: > > > On 14/01/2020 19:57, Baesken, Matthias wrote: > > Hello? Magnus and Aleksei,? thanks for the input . > > > > The times you? provided really look like they make a big > difference? at least for people? often? building? ?minimal-vm? . > > Guess I have to measure myself a bit? (maybe the difference is > not that big on our linux s390x / ppc64(le) ) . > > > >> If the change to enable lto by default is proposed, what would > be the > >> recommended strategy for development? > >> > > Probably? we should a)? ?do not enable it by default but just > make sure it can be enabled easily and works? for? the minimal-vm? ? > That would be welcome. I have high hopes to LTO the VM some time by > default, and the tendency observed is that the compiler time overhead > for GCC becomes smaller. At the same time there is no reason why > vendors > that invested in testing and can absorb the build time hit could > provide > binaries with LTO built VMs by passing an additional option flag. > >? ?or? b)? take it easy to disable it for local development. > > > > Best regards, Matthias > > > > > > > >> Magnus, Matthias, > >> > >> for me, lto is a little heavyweight for development. x86_64 > build time > >> with gcc 7: > >> > >> Server 1m32.484s > >> Server+Minimal 1m42.166s > >> Server+Minimal (--with-jvm-features="link-time-opt") 5m29.422s > >> > >> If the change to enable lto by default is proposed, what would > be the > >> recommended strategy for development? > >> > >> For ARM32 Minimal, please keep in mind that it's not uncommon > to disable > >> LTO plugin in commodity ARM32 gcc compiler distributions, so > for some it > >> does not matter what settings we have in OpenJDK. I believe > there could > >> be other reasons for that on top of build time (bugs?). > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Wed Jan 15 15:02:37 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 15 Jan 2020 15:02:37 +0000 Subject: serviceability agent : problems when using gcc LTO (link time optimization) In-Reply-To: References: <131b1189-d0e8-3d3e-6137-81ffc8eeeb84@oracle.com> <4fdc39f0-9ed3-5878-93b2-b536b8779125@oracle.com> <249cba82-1469-03f8-d205-e5895eab2cc3@bell-sw.com> <9908f346-f376-5bfc-8d5b-bc250e336032@bell-sw.com> Message-ID: Hello , I can comment on the code size . This is what I get when comparing a build without and with -flto . gcc7 linux x86_64 product build, normal / with -flto ---------------------------------------------------------------------------------- du -sh on the *.so files gives : 16K / 16K ./lib/libattach.so 48K / 44K ./lib/libawt_headless.so 752K / 760K ./lib/libawt.so <------------------ this one gets a bit larger with flto 472K / 456K ./lib/libawt_xawt.so <------------------ small gain 36K / 32K ./lib/libdt_socket.so 16K /16K ./lib/libextnet.so 1.5M / 824K ./lib/libfontmanager.so <------------------ HUGE gain 784K / 792K ./lib/libfreetype.so <------------------ this one gets a bit larger with flto 56K / 56K ./lib/libinstrument.so 52K / 52K ./lib/libj2gss.so 20K / 20K ./lib/libj2pcsc.so 92K / 84K ./lib/libj2pkcs11.so 12K / 12k ./lib/libjaas.so 260K / 244K ./lib/libjavajpeg.so <----------------- small gain 196K / 188K ./lib/libjava.so 12K / 12K ./lib/libjawt.so 280K / 256K ./lib/libjdwp.so <----------------- small gain 144K / 140K ./lib/libjimage.so 84K / 76K ./lib/libjli.so 16K / 16K ./lib/libjsig.so 88K / 80K ./lib/libjsound.so 564K / 420K ./lib/liblcms.so <----------------- large gain 12K / 12K ./lib/libmanagement_agent.so 40K / 36K ./lib/libmanagement_ext.so 36K / 32K ./lib/libmanagement.so 576K / 496K ./lib/libmlib_image.so <----------------- large gain 112K / 108K ./lib/libnet.so 100K / 100K ./lib/libnio.so 16K / 16K ./lib/libprefs.so 8.0K / 8.0K ./lib/librmi.so 60K / 60K ./lib/libsaproc.so 36K / 32K ./lib/libsctp.so 368K / 212K ./lib/libsplashscreen.so <----------------- large gain 320K / 296K ./lib/libsunec.so <----------------- medium gain 72K / 72K ./lib/libverify.so 44K / 44K ./lib/libzip.so 16K / 16K ./lib/server/libjsig.so 23M / 17M ./lib/server/libjvm.so <----------------- big gain maybe because it is C++ ? So for some libs you see 10% and more , but not for all . But most large libs like libjvm.so, libfontmanager.so or liblcms.so we see good results regarding reduced code size. I Cannot say much about performance improvements , probably it would be small . For SPEC you find something at http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html (not that these results would say too much about JVM performance ). Best regards, Matthias From: Volker Simonis Sent: Mittwoch, 15. Januar 2020 14:40 To: Aleksei Voitylov Cc: Baesken, Matthias ; Magnus Ihse Bursie ; serviceability-dev at openjdk.java.net; build-dev ; hotspot-dev at openjdk.java.net Subject: Re: serviceability agent : problems when using gcc LTO (link time optimization) While we are speaking about all the drawbacks of LTO, it's still not clear what the benefits are? In the very first mail Matthias mentioned that there might be performance improvements but that performance is not the main driving factor behind this initiative. So is it the reduced code size (Matthias mentioned something around ~10%)? It would be nice to see some real numbers on various platform for both, the performance improvements for native parts like JIT/GC as well as for the size reduction. Aleksei Voitylov > schrieb am Di., 14. Jan. 2020, 09:54: On 14/01/2020 19:57, Baesken, Matthias wrote: > Hello Magnus and Aleksei, thanks for the input . > > The times you provided really look like they make a big difference at least for people often building minimal-vm . > Guess I have to measure myself a bit (maybe the difference is not that big on our linux s390x / ppc64(le) ) . > >> If the change to enable lto by default is proposed, what would be the >> recommended strategy for development? >> > Probably we should a) do not enable it by default but just make sure it can be enabled easily and works for the minimal-vm That would be welcome. I have high hopes to LTO the VM some time by default, and the tendency observed is that the compiler time overhead for GCC becomes smaller. At the same time there is no reason why vendors that invested in testing and can absorb the build time hit could provide binaries with LTO built VMs by passing an additional option flag. > or b) take it easy to disable it for local development. > > Best regards, Matthias > > > >> Magnus, Matthias, >> >> for me, lto is a little heavyweight for development. x86_64 build time >> with gcc 7: >> >> Server 1m32.484s >> Server+Minimal 1m42.166s >> Server+Minimal (--with-jvm-features="link-time-opt") 5m29.422s >> >> If the change to enable lto by default is proposed, what would be the >> recommended strategy for development? >> >> For ARM32 Minimal, please keep in mind that it's not uncommon to disable >> LTO plugin in commodity ARM32 gcc compiler distributions, so for some it >> does not matter what settings we have in OpenJDK. I believe there could >> be other reasons for that on top of build time (bugs?). >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Wed Jan 15 15:29:48 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2020 07:29:48 -0800 Subject: serviceability agent : problems when using gcc LTO (link time optimization) In-Reply-To: References: <131b1189-d0e8-3d3e-6137-81ffc8eeeb84@oracle.com> <4fdc39f0-9ed3-5878-93b2-b536b8779125@oracle.com> <249cba82-1469-03f8-d205-e5895eab2cc3@bell-sw.com> <9908f346-f376-5bfc-8d5b-bc250e336032@bell-sw.com> Message-ID: Aleksei, Matthias, thanks for the numbers. The size reduction on libjvm.so looks not bad, indeed. Do you know if newer versions of GCC use the gold linker by default? I remember from some experiments which I did many years ago that gold was considerably faster compared to the default ld linker. Unfortunately, the documentation I found about LTO/ld/gold [1,2] seems to be quite old and not very precise. Do you have gained any experience with LTO/gold and know if gold could maybe improve linking times with LTO? [1] https://gcc.gnu.org/wiki/LinkTimeOptimization [2] https://stackoverflow.com/questions/31688069/requirements-to-use-flto Baesken, Matthias schrieb am Mi., 15. Jan. 2020, 07:02: > Hello , I can comment on the code size . This is what I get when > comparing a build without and with -flto . > > > > gcc7 linux x86_64 product build, normal / with -flto > > > ---------------------------------------------------------------------------------- > > > > du -sh on the *.so files gives : > > > > 16K / 16K ./lib/libattach.so > > 48K / 44K ./lib/libawt_headless.so > > 752K / 760K ./lib/libawt.so <------------------ this one > gets a bit larger with flto > > 472K / 456K ./lib/libawt_xawt.so <------------------ small gain > > 36K / 32K ./lib/libdt_socket.so > > 16K /16K ./lib/libextnet.so > > 1.5M / 824K ./lib/libfontmanager.so <------------------ HUGE gain > > 784K / 792K ./lib/libfreetype.so <------------------ this one > gets a bit larger with flto > > 56K / 56K ./lib/libinstrument.so > > 52K / 52K ./lib/libj2gss.so > > 20K / 20K ./lib/libj2pcsc.so > > 92K / 84K ./lib/libj2pkcs11.so > > 12K / 12k ./lib/libjaas.so > > 260K / 244K ./lib/libjavajpeg.so <----------------- small gain > > 196K / 188K ./lib/libjava.so > > 12K / 12K ./lib/libjawt.so > > 280K / 256K ./lib/libjdwp.so <----------------- small gain > > 144K / 140K ./lib/libjimage.so > > 84K / 76K ./lib/libjli.so > > 16K / 16K ./lib/libjsig.so > > 88K / 80K ./lib/libjsound.so > > 564K / 420K ./lib/liblcms.so <----------------- large gain > > 12K / 12K ./lib/libmanagement_agent.so > > 40K / 36K ./lib/libmanagement_ext.so > > 36K / 32K ./lib/libmanagement.so > > 576K / 496K ./lib/libmlib_image.so <----------------- large gain > > 112K / 108K ./lib/libnet.so > > 100K / 100K ./lib/libnio.so > > 16K / 16K ./lib/libprefs.so > > 8.0K / 8.0K ./lib/librmi.so > > 60K / 60K ./lib/libsaproc.so > > 36K / 32K ./lib/libsctp.so > > 368K / 212K ./lib/libsplashscreen.so <----------------- large gain > > 320K / 296K ./lib/libsunec.so <----------------- medium gain > > 72K / 72K ./lib/libverify.so > > 44K / 44K ./lib/libzip.so > > 16K / 16K ./lib/server/libjsig.so > > 23M / 17M ./lib/server/libjvm.so <----------------- big gain > maybe because it is C++ ? > > > > > > So for some libs you see 10% and more , but not for all . But most > large libs like libjvm.so, libfontmanager.so or liblcms.so > we see good results regarding reduced code size. > > > > I Cannot say much about performance improvements , probably it would be > small . > > > > For SPEC you find something at > > > > > http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html > > > > (not that these results would say too much about JVM performance ). > > > > > > Best regards, Matthias > > > > *From:* Volker Simonis > *Sent:* Mittwoch, 15. Januar 2020 14:40 > *To:* Aleksei Voitylov > *Cc:* Baesken, Matthias ; Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com>; serviceability-dev at openjdk.java.net; > build-dev ; hotspot-dev at openjdk.java.net > *Subject:* Re: serviceability agent : problems when using gcc LTO (link > time optimization) > > > > While we are speaking about all the drawbacks of LTO, it's still not clear > what the benefits are? In the very first mail Matthias mentioned that there > might be performance improvements but that performance is not the main > driving factor behind this initiative. So is it the reduced code size > (Matthias mentioned something around ~10%)? > > > > It would be nice to see some real numbers on various platform for both, > the performance improvements for native parts like JIT/GC as well as for > the size reduction. > > Aleksei Voitylov schrieb am Di., 14. Jan. > 2020, 09:54: > > > On 14/01/2020 19:57, Baesken, Matthias wrote: > > Hello Magnus and Aleksei, thanks for the input . > > > > The times you provided really look like they make a big difference at > least for people often building minimal-vm . > > Guess I have to measure myself a bit (maybe the difference is not that > big on our linux s390x / ppc64(le) ) . > > > >> If the change to enable lto by default is proposed, what would be the > >> recommended strategy for development? > >> > > Probably we should a) do not enable it by default but just make sure > it can be enabled easily and works for the minimal-vm > That would be welcome. I have high hopes to LTO the VM some time by > default, and the tendency observed is that the compiler time overhead > for GCC becomes smaller. At the same time there is no reason why vendors > that invested in testing and can absorb the build time hit could provide > binaries with LTO built VMs by passing an additional option flag. > > or b) take it easy to disable it for local development. > > > > Best regards, Matthias > > > > > > > >> Magnus, Matthias, > >> > >> for me, lto is a little heavyweight for development. x86_64 build time > >> with gcc 7: > >> > >> Server 1m32.484s > >> Server+Minimal 1m42.166s > >> Server+Minimal (--with-jvm-features="link-time-opt") 5m29.422s > >> > >> If the change to enable lto by default is proposed, what would be the > >> recommended strategy for development? > >> > >> For ARM32 Minimal, please keep in mind that it's not uncommon to disable > >> LTO plugin in commodity ARM32 gcc compiler distributions, so for some it > >> does not matter what settings we have in OpenJDK. I believe there could > >> be other reasons for that on top of build time (bugs?). > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Wed Jan 15 15:47:57 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 15 Jan 2020 07:47:57 -0800 Subject: serviceability agent : problems when using gcc LTO (link time optimization) In-Reply-To: References: <131b1189-d0e8-3d3e-6137-81ffc8eeeb84@oracle.com> <4fdc39f0-9ed3-5878-93b2-b536b8779125@oracle.com> <249cba82-1469-03f8-d205-e5895eab2cc3@bell-sw.com> <9908f346-f376-5bfc-8d5b-bc250e336032@bell-sw.com> Message-ID: <824316f1-43f6-b61b-c764-ad0c0996b325@oracle.com> On 2020-01-15 07:29, Volker Simonis wrote: > Do you know if newer versions of GCC use the gold linker by default? I > remember from some experiments which I did many years ago that gold was > considerably faster compared to the default ld linker. The default linker is system configured so it depends on your Linux distro. The devkits generated by the current devkit makefiles configures gold as default. /Erik From matthias.baesken at sap.com Wed Jan 15 16:00:38 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 15 Jan 2020 16:00:38 +0000 Subject: serviceability agent : problems when using gcc LTO (link time optimization) In-Reply-To: <824316f1-43f6-b61b-c764-ad0c0996b325@oracle.com> References: <131b1189-d0e8-3d3e-6137-81ffc8eeeb84@oracle.com> <4fdc39f0-9ed3-5878-93b2-b536b8779125@oracle.com> <249cba82-1469-03f8-d205-e5895eab2cc3@bell-sw.com> <9908f346-f376-5bfc-8d5b-bc250e336032@bell-sw.com> <824316f1-43f6-b61b-c764-ad0c0996b325@oracle.com> Message-ID: Hello, I used the "normal" linker so I think what https://stackoverflow.com/questions/31688069/requirements-to-use-flto says is true , one can use also the "normal" linker . Haven't checked for any performance (or other) improvements when using gold instead . Best regards, Matthias > On 2020-01-15 07:29, Volker Simonis wrote: > > Do you know if newer versions of GCC use the gold linker by default? I > > remember from some experiments which I did many years ago that gold > was > > considerably faster compared to the default ld linker. > > The default linker is system configured so it depends on your Linux > distro. The devkits generated by the current devkit makefiles configures > gold as default. > > /Erik > From matthias.baesken at sap.com Wed Jan 15 16:11:03 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 15 Jan 2020 16:11:03 +0000 Subject: serviceability agent : problems when using gcc LTO (link time optimization) In-Reply-To: References: <131b1189-d0e8-3d3e-6137-81ffc8eeeb84@oracle.com> <4fdc39f0-9ed3-5878-93b2-b536b8779125@oracle.com> <249cba82-1469-03f8-d205-e5895eab2cc3@bell-sw.com> <9908f346-f376-5bfc-8d5b-bc250e336032@bell-sw.com> Message-ID: Hello, here is another comparison for the larger JDK shared libs, this time with the sizes of build with linktime-gc (--gc-sections) added . ( just for the larger libs ) ( I had not enabled linktime-gc for libjvm in our test build , just for the JDK libs . ) Linuxx86_64 / gcc7 normal / with -flto / with linktime-gc (--gc-sections) ----------------------------------------------------------- 752K / 760K / 752K ./lib/libawt.so <------------------ this one gets a bit larger but only with flto 472K / 456K / 468K ./lib/libawt_xawt.so <------------------ small gain 1.5M / 824K / 900K ./lib/libfontmanager.so <------------------ HUGE gain , not as good with ltgc but still good 784K / 792K / 784K ./lib/libfreetype.so <------------------ this one gets a bit larger (but not with ltgc) 260K / 244K / 252K ./lib/libjavajpeg.so <----------------- small gain 196K / 188K / 196K ./lib/libjava.so 280K / 256K / 276K ./lib/libjdwp.so <----------------- small gain 144K / 140K / 136K ./lib/libjimage.so 564K / 420K / 404K ./lib/liblcms.so <----------------- large gain , even better with ltgc 576K / 496K / 556K ./lib/libmlib_image.so <----------------- large gain with flto , small one with ltgc 368K / 212K / 236K ./lib/libsplashscreen.so <----------------- large gain 320K / 296K / 300K ./lib/libsunec.so <----------------- medium gain 23M / 17M / --not enabled--- ./lib/server/libjvm.so <----------------- big gain maybe because it is C++ ? So one can see, that flto is usually a bit better than link-time-gc when it comes to improving lib sizes, but not always . However linktime-gc seems to be faster when comparing build times , I did not really notice much build time slowdown because of it . ( we have it enabled for linux s390x for some time in OpenJDK ). The linktime-gc also offers a nice feature to print out the eliminated stuff , that can be used to remove unused code cross-platform . e.g. the removed symbols from https://bugs.openjdk.java.net/browse/JDK-8234629 has been found this way . Best regards, Matthias Aleksei, Matthias, thanks for the numbers. The size reduction on libjvm.so looks not bad, indeed. Do you know if newer versions of GCC use the gold linker by default? I remember from some experiments which I did many years ago that gold was considerably faster compared to the default ld linker. Unfortunately, the documentation I found about LTO/ld/gold [1,2] seems to be quite old and not very precise. Do you have gained any experience with LTO/gold and know if gold could maybe improve linking times with LTO? [1] https://gcc.gnu.org/wiki/LinkTimeOptimization [2] https://stackoverflow.com/questions/31688069/requirements-to-use-flto Baesken, Matthias > schrieb am Mi., 15. Jan. 2020, 07:02: Hello , I can comment on the code size . This is what I get when comparing a build without and with -flto . gcc7 linux x86_64 product build, normal / with -flto ---------------------------------------------------------------------------------- du -sh on the *.so files gives : 16K / 16K ./lib/libattach.so 48K / 44K ./lib/libawt_headless.so 752K / 760K ./lib/libawt.so <------------------ this one gets a bit larger with flto 472K / 456K ./lib/libawt_xawt.so <------------------ small gain 36K / 32K ./lib/libdt_socket.so 16K /16K ./lib/libextnet.so 1.5M / 824K ./lib/libfontmanager.so <------------------ HUGE gain 784K / 792K ./lib/libfreetype.so <------------------ this one gets a bit larger with flto 56K / 56K ./lib/libinstrument.so 52K / 52K ./lib/libj2gss.so 20K / 20K ./lib/libj2pcsc.so 92K / 84K ./lib/libj2pkcs11.so 12K / 12k ./lib/libjaas.so 260K / 244K ./lib/libjavajpeg.so <----------------- small gain 196K / 188K ./lib/libjava.so 12K / 12K ./lib/libjawt.so 280K / 256K ./lib/libjdwp.so <----------------- small gain 144K / 140K ./lib/libjimage.so 84K / 76K ./lib/libjli.so 16K / 16K ./lib/libjsig.so 88K / 80K ./lib/libjsound.so 564K / 420K ./lib/liblcms.so <----------------- large gain 12K / 12K ./lib/libmanagement_agent.so 40K / 36K ./lib/libmanagement_ext.so 36K / 32K ./lib/libmanagement.so 576K / 496K ./lib/libmlib_image.so <----------------- large gain 112K / 108K ./lib/libnet.so 100K / 100K ./lib/libnio.so 16K / 16K ./lib/libprefs.so 8.0K / 8.0K ./lib/librmi.so 60K / 60K ./lib/libsaproc.so 36K / 32K ./lib/libsctp.so 368K / 212K ./lib/libsplashscreen.so <----------------- large gain 320K / 296K ./lib/libsunec.so <----------------- medium gain 72K / 72K ./lib/libverify.so 44K / 44K ./lib/libzip.so 16K / 16K ./lib/server/libjsig.so 23M / 17M ./lib/server/libjvm.so <----------------- big gain maybe because it is C++ ? So for some libs you see 10% and more , but not for all . But most large libs like libjvm.so, libfontmanager.so or liblcms.so we see good results regarding reduced code size. I Cannot say much about performance improvements , probably it would be small . For SPEC you find something at http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html (not that these results would say too much about JVM performance ). Best regards, Matthias From: Volker Simonis > Sent: Mittwoch, 15. Januar 2020 14:40 To: Aleksei Voitylov > Cc: Baesken, Matthias >; Magnus Ihse Bursie >; serviceability-dev at openjdk.java.net; build-dev >; hotspot-dev at openjdk.java.net Subject: Re: serviceability agent : problems when using gcc LTO (link time optimization) While we are speaking about all the drawbacks of LTO, it's still not clear what the benefits are? In the very first mail Matthias mentioned that there might be performance improvements but that performance is not the main driving factor behind this initiative. So is it the reduced code size (Matthias mentioned something around ~10%)? It would be nice to see some real numbers on various platform for both, the performance improvements for native parts like JIT/GC as well as for the size reduction. Aleksei Voitylov > schrieb am Di., 14. Jan. 2020, 09:54: On 14/01/2020 19:57, Baesken, Matthias wrote: > Hello Magnus and Aleksei, thanks for the input . > > The times you provided really look like they make a big difference at least for people often building minimal-vm . > Guess I have to measure myself a bit (maybe the difference is not that big on our linux s390x / ppc64(le) ) . > >> If the change to enable lto by default is proposed, what would be the >> recommended strategy for development? >> > Probably we should a) do not enable it by default but just make sure it can be enabled easily and works for the minimal-vm That would be welcome. I have high hopes to LTO the VM some time by default, and the tendency observed is that the compiler time overhead for GCC becomes smaller. At the same time there is no reason why vendors that invested in testing and can absorb the build time hit could provide binaries with LTO built VMs by passing an additional option flag. > or b) take it easy to disable it for local development. > > Best regards, Matthias > > > >> Magnus, Matthias, >> >> for me, lto is a little heavyweight for development. x86_64 build time >> with gcc 7: >> >> Server 1m32.484s >> Server+Minimal 1m42.166s >> Server+Minimal (--with-jvm-features="link-time-opt") 5m29.422s >> >> If the change to enable lto by default is proposed, what would be the >> recommended strategy for development? >> >> For ARM32 Minimal, please keep in mind that it's not uncommon to disable >> LTO plugin in commodity ARM32 gcc compiler distributions, so for some it >> does not matter what settings we have in OpenJDK. I believe there could >> be other reasons for that on top of build time (bugs?). >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Wed Jan 15 18:15:55 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 15 Jan 2020 10:15:55 -0800 Subject: RFR: 8236873: Worker has a deadlock bug Message-ID: Please review a change [1] that fixes a deadlock issue [2] in sun.tools.jconsole.Worker class. There is no need in guarding "stopped" flag by a lock. The fix removes this excessive locking and instead makes the flag volatile. Mach5 tier1-tier3 tests passed. [1] Webrev : http://cr.openjdk.java.net/~dtitov/8236873/webrev.01/ [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8236873 Best regards, Daniil From daniel.fuchs at oracle.com Wed Jan 15 18:41:11 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 15 Jan 2020 18:41:11 +0000 Subject: RFR: 8236873: Worker has a deadlock bug In-Reply-To: References: Message-ID: <89fbc550-e780-835a-e133-338d75af418b@oracle.com> Hi Daniil, That looks fine to me. best regards, -- daniel On 15/01/2020 18:15, Daniil Titov wrote: > Please review a change [1] that fixes a deadlock issue [2] in sun.tools.jconsole.Worker class. > > There is no need in guarding "stopped" flag by a lock. The fix removes this excessive locking and > instead makes the flag volatile. > > Mach5 tier1-tier3 tests passed. > > [1] Webrev : http://cr.openjdk.java.net/~dtitov/8236873/webrev.01/ > [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8236873 > > Best regards, > Daniil > > From sangheon.kim at oracle.com Wed Jan 15 19:57:51 2020 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Wed, 15 Jan 2020 11:57:51 -0800 Subject: [14] RFR(s) : 8234173: assert(loader != __null && oopDesc::is_oop(loader)) failed: loader must be oop Message-ID: <9d55d28b-0812-7a28-2c3f-74196fab6430@oracle.com> Hi all, Could I have some reviews for changing mark value of ObjectSampleMarker (part of JFR Leak Profiler)? The assertion is fired because the leak profiler(ObjectSampleMarker::mark()) puts an invalid mark word (0, INFLATING) into the oop and a concurrent user of oopDesc::is_oop() is reading the mark word which may diagnose the given object is not oop. In addition, there is a comment at oopDesc::is_oop() which supports that mark word shouldn't be zero at safepoint. ? // Header verification: the mark is typically non-zero. If we're ? // at a safepoint, it must not be zero. ? // Outside of a safepoint, the header could be changing (for example, ? // another thread could be inflating a lock on this object). Nobody writes to the mark word concurrently. Other GCs which support JFR have the same issue, but at the moment the test is only run with G1. In the patch, I am proposing to set mark word with 3 (mark bit value) instead of 0. CR: https://bugs.openjdk.java.net/browse/JDK-8234173 webrev: http://cr.openjdk.java.net/~sangheki/8234173/webrev.0/ Testing: hs-tier1 ~ 5, jdk-tier1 ~ 3, test/jdk/jdk/jfr and test/jdk/jdk/jfr/events/oldobject for 1200 iterations Thanks, Sangheon From sangheon.kim at oracle.com Wed Jan 15 20:01:39 2020 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Wed, 15 Jan 2020 12:01:39 -0800 Subject: [14] RFR(s) : 8234173: assert(loader != __null && oopDesc::is_oop(loader)) failed: loader must be oop In-Reply-To: <9d55d28b-0812-7a28-2c3f-74196fab6430@oracle.com> References: <9d55d28b-0812-7a28-2c3f-74196fab6430@oracle.com> Message-ID: Sorry, I sent to wrong alias. Resent to runtime. Thanks, Sangheon On 1/15/20 11:57 AM, sangheon.kim at oracle.com wrote: > Hi all, > > Could I have some reviews for changing mark value of > ObjectSampleMarker (part of JFR Leak Profiler)? > > The assertion is fired because the leak > profiler(ObjectSampleMarker::mark()) puts an invalid mark word (0, > INFLATING) into the oop and a concurrent user of oopDesc::is_oop() is > reading the mark word which may diagnose the given object is not oop. > > In addition, there is a comment at oopDesc::is_oop() which supports > that mark word shouldn't be zero at safepoint. > > ? // Header verification: the mark is typically non-zero. If we're > ? // at a safepoint, it must not be zero. > ? // Outside of a safepoint, the header could be changing (for example, > ? // another thread could be inflating a lock on this object). > > Nobody writes to the mark word concurrently. > Other GCs which support JFR have the same issue, but at the moment the > test is only run with G1. > > In the patch, I am proposing to set mark word with 3 (mark bit value) > instead of 0. > > CR: https://bugs.openjdk.java.net/browse/JDK-8234173 > webrev: http://cr.openjdk.java.net/~sangheki/8234173/webrev.0/ > Testing: hs-tier1 ~ 5, jdk-tier1 ~ 3, test/jdk/jdk/jfr and > test/jdk/jdk/jfr/events/oldobject for 1200 iterations > > Thanks, > Sangheon > > > From chris.plummer at oracle.com Wed Jan 15 21:09:35 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 15 Jan 2020 13:09:35 -0800 Subject: RFR(M): 8236913: debug agent's jdwp command logging should include the command set name and command name In-Reply-To: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> References: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> Message-ID: Hi, Unfortunately I'm going to have to redo this fix. I ran into compilation problems on Solaris: error: too many struct/union initializers (E_TOO_MANY_STRUCT_UNION_INIT) This turns up on the first initializer of the cmds[] array: CommandSet ArrayReference_Cmds = { ??? 3, "ArrayReference", ??? { ??????? {length, "Length"},?? <---------- ??????? {getValues, "GetValues"}, ??????? {setValues, "SetValues"} ??? } }; It turns out that statically initializing a variable length array that is a field of a struct is not valid C syntax. You can statically initialize a variable length array, which is what the code was originally doing, but not a variable length array within a struct. I can fix this issue by giving the array a fixed size. For example: typedef struct CommandSet { ??? int num_cmds; ??? const char *cmd_set_name; ??? const Command cmds[20]; } CommandSet; The catch here is that the array size needs to be at least as big as the largest use, and for all the other static uses extra space will be allocated but never used. In other words, all the arrays would be size 20, even those that initialize fewer than 20 elements. So the choice here pretty much keep what I have, but waste some space with the fixed array size, or use parallel arrays to store the function pointers and command names separately. We used to have: void *ArrayReference_Cmds[] = { (void *)0x3 ??? ,(void *)length ??? ,(void *)getValues ??? ,(void *)setValues}; I could just keep this as-is and add: char *ArrayReference_CmdNames[] = { ??? "Length", ??? "GetValues", ??? "SetValues" }; A further improvement might be to change to original array to be: const CommandHandler ArrayReference_Cmds[] = { ??? length, ??? getValues, ??? setValues }; And then I can add a #define for the array size: #define ArrayReference_NumCmds (sizeof(ArrayReference_Cmds) / sizeof(CommandHandler)) char *ArrayReference_CmdNames[ArrayReference_NumCmds] = { ??? "Length", ??? "GetValues", ??? "SetValues" }; Then I can either access these arrays in parallel, meaning instead of: ??? cmdSetsArray[JDWP_COMMAND_SET(ArrayReference)] = &ArrayReference_Cmds; I would have (not I need an array for the sizes also for the second option abov): ??? cmdSetsCmdsArraySize[JDWP_COMMAND_SET(ArrayReference)] = ArrayReference_NumCmds; ??? cmdSetsCmdsArray[JDWP_COMMAND_SET(ArrayReference)] = &ArrayReference_Cmds; ??? cmdSetsCmdNamesArray[JDWP_COMMAND_SET(ArrayReference)] = &ArrayReference_CmdNames; Or I could change the CommandSet definition to be: typedef struct CommandSet { ??? int num_cmds; ??? const char *cmd_set_name; ??? CommandHandler cmd_handler[]; ??? const char *cmd_name[]; } CommandSet; And then add: const CommandSet ArrayReference_CommandSet = { ??? ArrayReference_NumCmds, ??? "ArrayReference", ??? &ArrayReference_Cmds, ??? &ArrayReference_CmdNames } Then I would just have the array of CommandSets rather than 3 arrays to deal with. Lasty, I could use a macro that declares a new type for each CommandSet, and then when the array of CommandSets is initialized, I would cast that type to a CommandSet. I think the invocation of the macro would look something like: DEFINE_COMMAND_SET (3, ArrayReference, ??????? {length, "Length"}, ??????? {getValues, "GetValues"}, ??????? {setValues, "SetValues"} ) However, I'm a bit unsure of this since I haven't made any attempt to implement it yet. There might be more issues that pop up with this one, where-as doing the parallel arrays is pretty straight forward (although not pretty). thoughts? Chris On 1/10/20 11:27 AM, Chris Plummer wrote: > Hello, > > Please review the following > > https://bugs.openjdk.java.net/browse/JDK-8236913 > http://cr.openjdk.java.net/~cjplummer/8236913/webrev.00/ > > The debug agent has logging support that will trace all jdwp commands > coming in. Currently all it traces is the command set number and the > command number within that command set. So you see something like: > > [#|10.01.2020 06:27:24.366 > GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command > set 1, command 9|#] > > I've added support for including the name of the command set and > command, so now you see: > > [#|10.01.2020 06:27:24.366 > GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command > set VirtualMachine(1), command Resume(9)|#] > > So in this case command set 1 represents VirtualMachine and command 9 > is the Resume command. > > I was initially going to leverage jdwp.spec which is already processed > by build.tools.jdwpgen.Main to produce JDWP.java and JDWPCommands.h. > However, I could see it was more of a challenge than I initially > hoped. Also, the main advantage would have been not having to hard > code arrays of command names, but we already have harded coded arrays > of function pointers to handle the various jdwp commands, so I just > replaced these with a more specialized arrays that also include the > names of the commands. As an example, we used to have: > > void *ArrayReference_Cmds[] = { (void *)0x3 > ??? ,(void *)length > ??? ,(void *)getValues > ??? ,(void *)setValues}; > > Now we have: > > CommandSet ArrayReference_Cmds = { > ??? 3, "ArrayReference", > ??? { > ??????? {length, "Length"}, > ??????? {getValues, "GetValues"}, > ??????? {setValues, "SetValues"} > ??? } > }; > > So no worse w.r.t. hard coding things that could be generated off the > spec, and it cleans up some ugly casts also. The CommandSet typedef > can be found in debugDispatch.h. > > All the header files except for debugDispatch.h have the same pattern > for changes, so they are pretty easy to review > > All .c files except debugDispatch.c and debugLoop.c also have the same > pattern. Note some command handler function names are not the same as > the command name. If you want to double check command set names and > command names, you can find the spec here: > > https://docs.oracle.com/javase/9/docs/specs/jdwp/jdwp-protocol.html > > In ReferenceTypeImpl.c I fixed a typo in the method() prototype. It > had an extra argument which I think was a very old copy-n-paste bug > from the method1() prototype. This was caught because the command > handler functions are now directly assigned to a CommandHandler type > rather than cast. The cast was hiding this bug. > > I tested by doing a test run where MISC logging was enabled by > default. All jdwp, jdb, and jdi tests were run in this way and passed. > > thanks, > > Chris > From alexey.menkov at oracle.com Wed Jan 15 22:05:00 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 15 Jan 2020 14:05:00 -0800 Subject: RFR(M): 8236913: debug agent's jdwp command logging should include the command set name and command name In-Reply-To: References: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> Message-ID: <9cca7543-d647-5737-6de4-56e07f9831e4@oracle.com> Hi Chris, I'd prefer to not separate command handlers and names. maybe something like static Command ArrayReference_Commands[] = { {length, "Length"}, {getValues, "GetValues"}, {setValues, "SetValues"} }; CommandSet ArrayReference_CommandSet = { 3, "ArrayReference", &ArrayReference_Commands }; --alex On 01/15/2020 13:09, Chris Plummer wrote: > Hi, > > Unfortunately I'm going to have to redo this fix. I ran into compilation > problems on Solaris: > > error: too many struct/union initializers (E_TOO_MANY_STRUCT_UNION_INIT) > > This turns up on the first initializer of the cmds[] array: > > CommandSet ArrayReference_Cmds = { > ??? 3, "ArrayReference", > ??? { > ??????? {length, "Length"},?? <---------- > ??????? {getValues, "GetValues"}, > ??????? {setValues, "SetValues"} > ??? } > }; > > It turns out that statically initializing a variable length array that > is a field of a struct is not valid C syntax. You can statically > initialize a variable length array, which is what the code was > originally doing, but not a variable length array within a struct. > > I can fix this issue by giving the array a fixed size. For example: > > typedef struct CommandSet { > ??? int num_cmds; > ??? const char *cmd_set_name; > ??? const Command cmds[20]; > } CommandSet; > > The catch here is that the array size needs to be at least as big as the > largest use, and for all the other static uses extra space will be > allocated but never used. In other words, all the arrays would be size > 20, even those that initialize fewer than 20 elements. > > So the choice here pretty much keep what I have, but waste some space > with the fixed array size, or use parallel arrays to store the function > pointers and command names separately. We used to have: > > void *ArrayReference_Cmds[] = { (void *)0x3 > ??? ,(void *)length > ??? ,(void *)getValues > ??? ,(void *)setValues}; > > I could just keep this as-is and add: > > char *ArrayReference_CmdNames[] = { > ??? "Length", > ??? "GetValues", > ??? "SetValues" > }; > > A further improvement might be to change to original array to be: > > const CommandHandler ArrayReference_Cmds[] = { > ??? length, > ??? getValues, > ??? setValues > }; > > And then I can add a #define for the array size: > > #define ArrayReference_NumCmds (sizeof(ArrayReference_Cmds) / > sizeof(CommandHandler)) > > char *ArrayReference_CmdNames[ArrayReference_NumCmds] = { > ??? "Length", > ??? "GetValues", > ??? "SetValues" > }; > > Then I can either access these arrays in parallel, meaning instead of: > > ??? cmdSetsArray[JDWP_COMMAND_SET(ArrayReference)] = &ArrayReference_Cmds; > > I would have (not I need an array for the sizes also for the second > option abov): > > ??? cmdSetsCmdsArraySize[JDWP_COMMAND_SET(ArrayReference)] = > ArrayReference_NumCmds; > ??? cmdSetsCmdsArray[JDWP_COMMAND_SET(ArrayReference)] = > &ArrayReference_Cmds; > ??? cmdSetsCmdNamesArray[JDWP_COMMAND_SET(ArrayReference)] = > &ArrayReference_CmdNames; > > Or I could change the CommandSet definition to be: > > typedef struct CommandSet { > ??? int num_cmds; > ??? const char *cmd_set_name; > ??? CommandHandler cmd_handler[]; > ??? const char *cmd_name[]; > } CommandSet; > > And then add: > > const CommandSet ArrayReference_CommandSet = { > ??? ArrayReference_NumCmds, > ??? "ArrayReference", > ??? &ArrayReference_Cmds, > ??? &ArrayReference_CmdNames > } > > Then I would just have the array of CommandSets rather than 3 arrays to > deal with. > > Lasty, I could use a macro that declares a new type for each CommandSet, > and then when the array of CommandSets is initialized, I would cast that > type to a CommandSet. I think the invocation of the macro would look > something like: > > DEFINE_COMMAND_SET (3, ArrayReference, > ??????? {length, "Length"}, > ??????? {getValues, "GetValues"}, > ??????? {setValues, "SetValues"} > ) > > However, I'm a bit unsure of this since I haven't made any attempt to > implement it yet. There might be more issues that pop up with this one, > where-as doing the parallel arrays is pretty straight forward (although > not pretty). > > thoughts? > > Chris > > > On 1/10/20 11:27 AM, Chris Plummer wrote: >> Hello, >> >> Please review the following >> >> https://bugs.openjdk.java.net/browse/JDK-8236913 >> http://cr.openjdk.java.net/~cjplummer/8236913/webrev.00/ >> >> The debug agent has logging support that will trace all jdwp commands >> coming in. Currently all it traces is the command set number and the >> command number within that command set. So you see something like: >> >> [#|10.01.2020 06:27:24.366 >> GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command >> set 1, command 9|#] >> >> I've added support for including the name of the command set and >> command, so now you see: >> >> [#|10.01.2020 06:27:24.366 >> GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command >> set VirtualMachine(1), command Resume(9)|#] >> >> So in this case command set 1 represents VirtualMachine and command 9 >> is the Resume command. >> >> I was initially going to leverage jdwp.spec which is already processed >> by build.tools.jdwpgen.Main to produce JDWP.java and JDWPCommands.h. >> However, I could see it was more of a challenge than I initially >> hoped. Also, the main advantage would have been not having to hard >> code arrays of command names, but we already have harded coded arrays >> of function pointers to handle the various jdwp commands, so I just >> replaced these with a more specialized arrays that also include the >> names of the commands. As an example, we used to have: >> >> void *ArrayReference_Cmds[] = { (void *)0x3 >> ??? ,(void *)length >> ??? ,(void *)getValues >> ??? ,(void *)setValues}; >> >> Now we have: >> >> CommandSet ArrayReference_Cmds = { >> ??? 3, "ArrayReference", >> ??? { >> ??????? {length, "Length"}, >> ??????? {getValues, "GetValues"}, >> ??????? {setValues, "SetValues"} >> ??? } >> }; >> >> So no worse w.r.t. hard coding things that could be generated off the >> spec, and it cleans up some ugly casts also. The CommandSet typedef >> can be found in debugDispatch.h. >> >> All the header files except for debugDispatch.h have the same pattern >> for changes, so they are pretty easy to review >> >> All .c files except debugDispatch.c and debugLoop.c also have the same >> pattern. Note some command handler function names are not the same as >> the command name. If you want to double check command set names and >> command names, you can find the spec here: >> >> https://docs.oracle.com/javase/9/docs/specs/jdwp/jdwp-protocol.html >> >> In ReferenceTypeImpl.c I fixed a typo in the method() prototype. It >> had an extra argument which I think was a very old copy-n-paste bug >> from the method1() prototype. This was caught because the command >> handler functions are now directly assigned to a CommandHandler type >> rather than cast. The cast was hiding this bug. >> >> I tested by doing a test run where MISC logging was enabled by >> default. All jdwp, jdb, and jdi tests were run in this way and passed. >> >> thanks, >> >> Chris >> > > From alexey.menkov at oracle.com Wed Jan 15 22:16:40 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 15 Jan 2020 14:16:40 -0800 Subject: RFR(M): 8236913: debug agent's jdwp command logging should include the command set name and command name In-Reply-To: <9cca7543-d647-5737-6de4-56e07f9831e4@oracle.com> References: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> <9cca7543-d647-5737-6de4-56e07f9831e4@oracle.com> Message-ID: Forgot to mention you need to change CommandSet declaration: typedef struct CommandSet { int num_cmds; const char *cmd_set_name; - const Command cmds[]; + const Command *cmds; } CommandSet; --alex On 01/15/2020 14:05, Alex Menkov wrote: > Hi Chris, > > I'd prefer to not separate command handlers and names. > > maybe something like > > static Command ArrayReference_Commands[] = { > ??? {length, "Length"}, > ??? {getValues, "GetValues"}, > ??? {setValues, "SetValues"} > }; > > CommandSet ArrayReference_CommandSet = { > ??? 3, "ArrayReference", &ArrayReference_Commands > }; > > --alex > > On 01/15/2020 13:09, Chris Plummer wrote: >> Hi, >> >> Unfortunately I'm going to have to redo this fix. I ran into >> compilation problems on Solaris: >> >> error: too many struct/union initializers (E_TOO_MANY_STRUCT_UNION_INIT) >> >> This turns up on the first initializer of the cmds[] array: >> >> CommandSet ArrayReference_Cmds = { >> ???? 3, "ArrayReference", >> ???? { >> ???????? {length, "Length"},?? <---------- >> ???????? {getValues, "GetValues"}, >> ???????? {setValues, "SetValues"} >> ???? } >> }; >> >> It turns out that statically initializing a variable length array that >> is a field of a struct is not valid C syntax. You can statically >> initialize a variable length array, which is what the code was >> originally doing, but not a variable length array within a struct. >> >> I can fix this issue by giving the array a fixed size. For example: >> >> typedef struct CommandSet { >> ???? int num_cmds; >> ???? const char *cmd_set_name; >> ???? const Command cmds[20]; >> } CommandSet; >> >> The catch here is that the array size needs to be at least as big as >> the largest use, and for all the other static uses extra space will be >> allocated but never used. In other words, all the arrays would be size >> 20, even those that initialize fewer than 20 elements. >> >> So the choice here pretty much keep what I have, but waste some space >> with the fixed array size, or use parallel arrays to store the >> function pointers and command names separately. We used to have: >> >> void *ArrayReference_Cmds[] = { (void *)0x3 >> ???? ,(void *)length >> ???? ,(void *)getValues >> ???? ,(void *)setValues}; >> >> I could just keep this as-is and add: >> >> char *ArrayReference_CmdNames[] = { >> ???? "Length", >> ???? "GetValues", >> ???? "SetValues" >> }; >> >> A further improvement might be to change to original array to be: >> >> const CommandHandler ArrayReference_Cmds[] = { >> ???? length, >> ???? getValues, >> ???? setValues >> }; >> >> And then I can add a #define for the array size: >> >> #define ArrayReference_NumCmds (sizeof(ArrayReference_Cmds) / >> sizeof(CommandHandler)) >> >> char *ArrayReference_CmdNames[ArrayReference_NumCmds] = { >> ???? "Length", >> ???? "GetValues", >> ???? "SetValues" >> }; >> >> Then I can either access these arrays in parallel, meaning instead of: >> >> ???? cmdSetsArray[JDWP_COMMAND_SET(ArrayReference)] = >> &ArrayReference_Cmds; >> >> I would have (not I need an array for the sizes also for the second >> option abov): >> >> ???? cmdSetsCmdsArraySize[JDWP_COMMAND_SET(ArrayReference)] = >> ArrayReference_NumCmds; >> ???? cmdSetsCmdsArray[JDWP_COMMAND_SET(ArrayReference)] = >> &ArrayReference_Cmds; >> ???? cmdSetsCmdNamesArray[JDWP_COMMAND_SET(ArrayReference)] = >> &ArrayReference_CmdNames; >> >> Or I could change the CommandSet definition to be: >> >> typedef struct CommandSet { >> ???? int num_cmds; >> ???? const char *cmd_set_name; >> ???? CommandHandler cmd_handler[]; >> ???? const char *cmd_name[]; >> } CommandSet; >> >> And then add: >> >> const CommandSet ArrayReference_CommandSet = { >> ???? ArrayReference_NumCmds, >> ???? "ArrayReference", >> ???? &ArrayReference_Cmds, >> ???? &ArrayReference_CmdNames >> } >> >> Then I would just have the array of CommandSets rather than 3 arrays >> to deal with. >> >> Lasty, I could use a macro that declares a new type for each >> CommandSet, and then when the array of CommandSets is initialized, I >> would cast that type to a CommandSet. I think the invocation of the >> macro would look something like: >> >> DEFINE_COMMAND_SET (3, ArrayReference, >> ???????? {length, "Length"}, >> ???????? {getValues, "GetValues"}, >> ???????? {setValues, "SetValues"} >> ) >> >> However, I'm a bit unsure of this since I haven't made any attempt to >> implement it yet. There might be more issues that pop up with this >> one, where-as doing the parallel arrays is pretty straight forward >> (although not pretty). >> >> thoughts? >> >> Chris >> >> >> On 1/10/20 11:27 AM, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following >>> >>> https://bugs.openjdk.java.net/browse/JDK-8236913 >>> http://cr.openjdk.java.net/~cjplummer/8236913/webrev.00/ >>> >>> The debug agent has logging support that will trace all jdwp commands >>> coming in. Currently all it traces is the command set number and the >>> command number within that command set. So you see something like: >>> >>> [#|10.01.2020 06:27:24.366 >>> GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command >>> set 1, command 9|#] >>> >>> I've added support for including the name of the command set and >>> command, so now you see: >>> >>> [#|10.01.2020 06:27:24.366 >>> GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command >>> set VirtualMachine(1), command Resume(9)|#] >>> >>> So in this case command set 1 represents VirtualMachine and command 9 >>> is the Resume command. >>> >>> I was initially going to leverage jdwp.spec which is already >>> processed by build.tools.jdwpgen.Main to produce JDWP.java and >>> JDWPCommands.h. However, I could see it was more of a challenge than >>> I initially hoped. Also, the main advantage would have been not >>> having to hard code arrays of command names, but we already have >>> harded coded arrays of function pointers to handle the various jdwp >>> commands, so I just replaced these with a more specialized arrays >>> that also include the names of the commands. As an example, we used >>> to have: >>> >>> void *ArrayReference_Cmds[] = { (void *)0x3 >>> ??? ,(void *)length >>> ??? ,(void *)getValues >>> ??? ,(void *)setValues}; >>> >>> Now we have: >>> >>> CommandSet ArrayReference_Cmds = { >>> ??? 3, "ArrayReference", >>> ??? { >>> ??????? {length, "Length"}, >>> ??????? {getValues, "GetValues"}, >>> ??????? {setValues, "SetValues"} >>> ??? } >>> }; >>> >>> So no worse w.r.t. hard coding things that could be generated off the >>> spec, and it cleans up some ugly casts also. The CommandSet typedef >>> can be found in debugDispatch.h. >>> >>> All the header files except for debugDispatch.h have the same pattern >>> for changes, so they are pretty easy to review >>> >>> All .c files except debugDispatch.c and debugLoop.c also have the >>> same pattern. Note some command handler function names are not the >>> same as the command name. If you want to double check command set >>> names and command names, you can find the spec here: >>> >>> https://docs.oracle.com/javase/9/docs/specs/jdwp/jdwp-protocol.html >>> >>> In ReferenceTypeImpl.c I fixed a typo in the method() prototype. It >>> had an extra argument which I think was a very old copy-n-paste bug >>> from the method1() prototype. This was caught because the command >>> handler functions are now directly assigned to a CommandHandler type >>> rather than cast. The cast was hiding this bug. >>> >>> I tested by doing a test run where MISC logging was enabled by >>> default. All jdwp, jdb, and jdi tests were run in this way and passed. >>> >>> thanks, >>> >>> Chris >>> >> >> From david.holmes at oracle.com Wed Jan 15 22:28:00 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Jan 2020 08:28:00 +1000 Subject: RFR: 8236873: Worker has a deadlock bug In-Reply-To: <89fbc550-e780-835a-e133-338d75af418b@oracle.com> References: <89fbc550-e780-835a-e133-338d75af418b@oracle.com> Message-ID: +1 David On 16/01/2020 4:41 am, Daniel Fuchs wrote: > Hi Daniil, > > That looks fine to me. > > best regards, > > -- daniel > > On 15/01/2020 18:15, Daniil Titov wrote: >> Please review a change [1] that fixes a deadlock issue [2] in >> sun.tools.jconsole.Worker class. >> >> There is no need in guarding "stopped" flag by a lock. The fix removes >> this excessive locking and >> instead makes the flag volatile. >> >> Mach5 tier1-tier3 tests passed. >> >> [1] Webrev : http://cr.openjdk.java.net/~dtitov/8236873/webrev.01/ >> [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8236873 >> >> Best regards, >> Daniil >> >> > From chris.plummer at oracle.com Wed Jan 15 22:31:28 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 15 Jan 2020 14:31:28 -0800 Subject: RFR(M): 8236913: debug agent's jdwp command logging should include the command set name and command name In-Reply-To: <9cca7543-d647-5737-6de4-56e07f9831e4@oracle.com> References: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> <9cca7543-d647-5737-6de4-56e07f9831e4@oracle.com> Message-ID: Didn't think of that. It should work because it's a static array, not a static struct with an embedded array. I'll give it a try. I should also be able to use sizeof() rather than hard code the size. thanks, Chris On 1/15/20 2:05 PM, Alex Menkov wrote: > Hi Chris, > > I'd prefer to not separate command handlers and names. > > maybe something like > > static Command ArrayReference_Commands[] = { > ??? {length, "Length"}, > ??? {getValues, "GetValues"}, > ??? {setValues, "SetValues"} > }; > > CommandSet ArrayReference_CommandSet = { > ??? 3, "ArrayReference", &ArrayReference_Commands > }; > > --alex > > On 01/15/2020 13:09, Chris Plummer wrote: >> Hi, >> >> Unfortunately I'm going to have to redo this fix. I ran into >> compilation problems on Solaris: >> >> error: too many struct/union initializers (E_TOO_MANY_STRUCT_UNION_INIT) >> >> This turns up on the first initializer of the cmds[] array: >> >> CommandSet ArrayReference_Cmds = { >> ???? 3, "ArrayReference", >> ???? { >> ???????? {length, "Length"},?? <---------- >> ???????? {getValues, "GetValues"}, >> ???????? {setValues, "SetValues"} >> ???? } >> }; >> >> It turns out that statically initializing a variable length array >> that is a field of a struct is not valid C syntax. You can statically >> initialize a variable length array, which is what the code was >> originally doing, but not a variable length array within a struct. >> >> I can fix this issue by giving the array a fixed size. For example: >> >> typedef struct CommandSet { >> ???? int num_cmds; >> ???? const char *cmd_set_name; >> ???? const Command cmds[20]; >> } CommandSet; >> >> The catch here is that the array size needs to be at least as big as >> the largest use, and for all the other static uses extra space will >> be allocated but never used. In other words, all the arrays would be >> size 20, even those that initialize fewer than 20 elements. >> >> So the choice here pretty much keep what I have, but waste some space >> with the fixed array size, or use parallel arrays to store the >> function pointers and command names separately. We used to have: >> >> void *ArrayReference_Cmds[] = { (void *)0x3 >> ???? ,(void *)length >> ???? ,(void *)getValues >> ???? ,(void *)setValues}; >> >> I could just keep this as-is and add: >> >> char *ArrayReference_CmdNames[] = { >> ???? "Length", >> ???? "GetValues", >> ???? "SetValues" >> }; >> >> A further improvement might be to change to original array to be: >> >> const CommandHandler ArrayReference_Cmds[] = { >> ???? length, >> ???? getValues, >> ???? setValues >> }; >> >> And then I can add a #define for the array size: >> >> #define ArrayReference_NumCmds (sizeof(ArrayReference_Cmds) / >> sizeof(CommandHandler)) >> >> char *ArrayReference_CmdNames[ArrayReference_NumCmds] = { >> ???? "Length", >> ???? "GetValues", >> ???? "SetValues" >> }; >> >> Then I can either access these arrays in parallel, meaning instead of: >> >> ???? cmdSetsArray[JDWP_COMMAND_SET(ArrayReference)] = >> &ArrayReference_Cmds; >> >> I would have (not I need an array for the sizes also for the second >> option abov): >> >> ???? cmdSetsCmdsArraySize[JDWP_COMMAND_SET(ArrayReference)] = >> ArrayReference_NumCmds; >> ???? cmdSetsCmdsArray[JDWP_COMMAND_SET(ArrayReference)] = >> &ArrayReference_Cmds; >> ???? cmdSetsCmdNamesArray[JDWP_COMMAND_SET(ArrayReference)] = >> &ArrayReference_CmdNames; >> >> Or I could change the CommandSet definition to be: >> >> typedef struct CommandSet { >> ???? int num_cmds; >> ???? const char *cmd_set_name; >> ???? CommandHandler cmd_handler[]; >> ???? const char *cmd_name[]; >> } CommandSet; >> >> And then add: >> >> const CommandSet ArrayReference_CommandSet = { >> ???? ArrayReference_NumCmds, >> ???? "ArrayReference", >> ???? &ArrayReference_Cmds, >> ???? &ArrayReference_CmdNames >> } >> >> Then I would just have the array of CommandSets rather than 3 arrays >> to deal with. >> >> Lasty, I could use a macro that declares a new type for each >> CommandSet, and then when the array of CommandSets is initialized, I >> would cast that type to a CommandSet. I think the invocation of the >> macro would look something like: >> >> DEFINE_COMMAND_SET (3, ArrayReference, >> ???????? {length, "Length"}, >> ???????? {getValues, "GetValues"}, >> ???????? {setValues, "SetValues"} >> ) >> >> However, I'm a bit unsure of this since I haven't made any attempt to >> implement it yet. There might be more issues that pop up with this >> one, where-as doing the parallel arrays is pretty straight forward >> (although not pretty). >> >> thoughts? >> >> Chris >> >> >> On 1/10/20 11:27 AM, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following >>> >>> https://bugs.openjdk.java.net/browse/JDK-8236913 >>> http://cr.openjdk.java.net/~cjplummer/8236913/webrev.00/ >>> >>> The debug agent has logging support that will trace all jdwp >>> commands coming in. Currently all it traces is the command set >>> number and the command number within that command set. So you see >>> something like: >>> >>> [#|10.01.2020 06:27:24.366 >>> GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command >>> set 1, command 9|#] >>> >>> I've added support for including the name of the command set and >>> command, so now you see: >>> >>> [#|10.01.2020 06:27:24.366 >>> GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command >>> set VirtualMachine(1), command Resume(9)|#] >>> >>> So in this case command set 1 represents VirtualMachine and command >>> 9 is the Resume command. >>> >>> I was initially going to leverage jdwp.spec which is already >>> processed by build.tools.jdwpgen.Main to produce JDWP.java and >>> JDWPCommands.h. However, I could see it was more of a challenge than >>> I initially hoped. Also, the main advantage would have been not >>> having to hard code arrays of command names, but we already have >>> harded coded arrays of function pointers to handle the various jdwp >>> commands, so I just replaced these with a more specialized arrays >>> that also include the names of the commands. As an example, we used >>> to have: >>> >>> void *ArrayReference_Cmds[] = { (void *)0x3 >>> ??? ,(void *)length >>> ??? ,(void *)getValues >>> ??? ,(void *)setValues}; >>> >>> Now we have: >>> >>> CommandSet ArrayReference_Cmds = { >>> ??? 3, "ArrayReference", >>> ??? { >>> ??????? {length, "Length"}, >>> ??????? {getValues, "GetValues"}, >>> ??????? {setValues, "SetValues"} >>> ??? } >>> }; >>> >>> So no worse w.r.t. hard coding things that could be generated off >>> the spec, and it cleans up some ugly casts also. The CommandSet >>> typedef can be found in debugDispatch.h. >>> >>> All the header files except for debugDispatch.h have the same >>> pattern for changes, so they are pretty easy to review >>> >>> All .c files except debugDispatch.c and debugLoop.c also have the >>> same pattern. Note some command handler function names are not the >>> same as the command name. If you want to double check command set >>> names and command names, you can find the spec here: >>> >>> https://docs.oracle.com/javase/9/docs/specs/jdwp/jdwp-protocol.html >>> >>> In ReferenceTypeImpl.c I fixed a typo in the method() prototype. It >>> had an extra argument which I think was a very old copy-n-paste bug >>> from the method1() prototype. This was caught because the command >>> handler functions are now directly assigned to a CommandHandler type >>> rather than cast. The cast was hiding this bug. >>> >>> I tested by doing a test run where MISC logging was enabled by >>> default. All jdwp, jdb, and jdi tests were run in this way and passed. >>> >>> thanks, >>> >>> Chris >>> >> >> From hohensee at amazon.com Thu Jan 16 01:09:14 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 16 Jan 2020 01:09:14 +0000 Subject: RFR 8235300: VM_HeapDumper hits assert with bad dump_len In-Reply-To: <75ab359d-e556-849d-1bda-eedd9e32c09d@oracle.com> References: <7271C378-98AF-406A-8628-1A6ADDCF7A39@amazon.com> <75ab359d-e556-849d-1bda-eedd9e32c09d@oracle.com> Message-ID: <125C42A4-B2F5-4CCE-8864-043725C79DBF@amazon.com> Thanks for your review and updates, David. I've updated the CSR as you requested in its comments. Paul ?On 1/14/20, 5:12 PM, "David Holmes" wrote: Hi Paul, I made some minor updates to the CSR request and added myself as a reviewer. Thanks, David On 15/01/2020 10:00 am, Hohensee, Paul wrote: > Please review this CSR for a backport of JDK-8144732 to jdk8u. > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8144732 > > JBS release note issue: https://bugs.openjdk.java.net/browse/JDK-8174881 > > 8u backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8235299 > > 8u backport CSR: https://bugs.openjdk.java.net/browse/JDK-8235300 > > The original patch went through the Oracle CCC process prior to the > creation of the public CSR process, so there?s no public CSR issue, > hence the release note JBS issue reference. > > Thanks, > > Paul > From serguei.spitsyn at oracle.com Thu Jan 16 06:45:24 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Jan 2020 22:45:24 -0800 Subject: RFR: 8236873: Worker has a deadlock bug In-Reply-To: References: <89fbc550-e780-835a-e133-338d75af418b@oracle.com> Message-ID: <09d79ffc-9937-6840-9016-2441466eb3a1@oracle.com> Hi Daniil, LGTM++ Thanks, Serguei On 1/15/20 14:28, David Holmes wrote: > +1 > > David > > On 16/01/2020 4:41 am, Daniel Fuchs wrote: >> Hi Daniil, >> >> That looks fine to me. >> >> best regards, >> >> -- daniel >> >> On 15/01/2020 18:15, Daniil Titov wrote: >>> Please review a change [1] that fixes a deadlock issue [2] in >>> sun.tools.jconsole.Worker class. >>> >>> There is no need in guarding "stopped" flag by a lock. The fix >>> removes this excessive locking and >>> instead makes the flag volatile. >>> >>> Mach5 tier1-tier3 tests passed. >>> >>> [1] Webrev : http://cr.openjdk.java.net/~dtitov/8236873/webrev.01/ >>> [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8236873 >>> >>> Best regards, >>> Daniil >>> >>> >> From daniil.x.titov at oracle.com Thu Jan 16 17:30:36 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 16 Jan 2020 09:30:36 -0800 Subject: 8236873: Worker has a deadlock bug In-Reply-To: <09d79ffc-9937-6840-9016-2441466eb3a1@oracle.com> References: <89fbc550-e780-835a-e133-338d75af418b@oracle.com> <09d79ffc-9937-6840-9016-2441466eb3a1@oracle.com> Message-ID: <112F143A-09B6-4F93-ACAE-28D0B61D3E8B@oracle.com> Thank you David, Daniel, and Serguei for reviewing this change! Best regards, Daniil ?On 1/15/20, 10:45 PM, "serguei.spitsyn at oracle.com" wrote: Hi Daniil, LGTM++ Thanks, Serguei On 1/15/20 14:28, David Holmes wrote: > +1 > > David > > On 16/01/2020 4:41 am, Daniel Fuchs wrote: >> Hi Daniil, >> >> That looks fine to me. >> >> best regards, >> >> -- daniel >> >> On 15/01/2020 18:15, Daniil Titov wrote: >>> Please review a change [1] that fixes a deadlock issue [2] in >>> sun.tools.jconsole.Worker class. >>> >>> There is no need in guarding "stopped" flag by a lock. The fix >>> removes this excessive locking and >>> instead makes the flag volatile. >>> >>> Mach5 tier1-tier3 tests passed. >>> >>> [1] Webrev : http://cr.openjdk.java.net/~dtitov/8236873/webrev.01/ >>> [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8236873 >>> >>> Best regards, >>> Daniil >>> >>> >> From chris.plummer at oracle.com Thu Jan 16 19:41:59 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 16 Jan 2020 11:41:59 -0800 Subject: RFR(M): 8236913: debug agent's jdwp command logging should include the command set name and command name In-Reply-To: References: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> <9cca7543-d647-5737-6de4-56e07f9831e4@oracle.com> Message-ID: Hi, Here's a new webrev: http://cr.openjdk.java.net/~cjplummer/8236913/webrev.01/ Since the last webrev: ?- debugDispatch.c is and the header files (other than debugDispatch.h) are unchanged other ?? than renaming from XXX_Cmds to XXX_CmdSets ?- debugDispatch.h has a minor change to CommandSet.cmds to make it a pointer type, ?? and added the DEBUG_DISPATCH_DEFINE_CMDSET macro Command sets are now defined using the following form: ??? Command ArrayReference_Commands[] = { ? ?? ?? {length, "Length"}, ? ?? ?? {getValues, "GetValues"}, ? ? ? ? {setValues, "SetValues"} ??? }; ??? DEBUG_DISPATCH_DEFINE_CMDSET(ArrayReference) There is no need to specify the size of the array anymore. DEBUG_DISPATCH_DEFINE_CMDSET in its expanded form would be: CommandSet ArrayReference_Commands_CmdSet = { ??? sizeof(ArrayReference_Commands) / sizeof(Command), ? ? "ArrayReference", ??? ArrayReference_Commands }; Since there are 4 references to ArrayReference, plus the size calculation, I thought it was worth using a macro here. I considered also passing the initialization of the Commands array as an argument, but I dislike macros that take code as an argument, and I didn't see as much value in it. I could still be persuaded though if you think it's a good idea. I had to special case FieldImpl because it is zero length. When I discovered the Solaris issues, I also found out that Windows didn't like initializing an empty array. At the time I fixed it by adding a {NULL, NULL} entry, but eventually decided to just special case it, especially since I would no longer be able to cheat and say the array was length 0 even though it had an entry. thanks, Chris On 1/15/20 2:31 PM, Chris Plummer wrote: > Didn't think of that. It should work because it's a static array, not > a static struct with an embedded array. I'll give it a try. I should > also be able to use sizeof() rather than hard code the size. > > thanks, > > Chris > > On 1/15/20 2:05 PM, Alex Menkov wrote: >> Hi Chris, >> >> I'd prefer to not separate command handlers and names. >> >> maybe something like >> >> static Command ArrayReference_Commands[] = { >> ??? {length, "Length"}, >> ??? {getValues, "GetValues"}, >> ??? {setValues, "SetValues"} >> }; >> >> CommandSet ArrayReference_CommandSet = { >> ??? 3, "ArrayReference", &ArrayReference_Commands >> }; >> >> --alex >> >> On 01/15/2020 13:09, Chris Plummer wrote: >>> Hi, >>> >>> Unfortunately I'm going to have to redo this fix. I ran into >>> compilation problems on Solaris: >>> >>> error: too many struct/union initializers >>> (E_TOO_MANY_STRUCT_UNION_INIT) >>> >>> This turns up on the first initializer of the cmds[] array: >>> >>> CommandSet ArrayReference_Cmds = { >>> ???? 3, "ArrayReference", >>> ???? { >>> ???????? {length, "Length"},?? <---------- >>> ???????? {getValues, "GetValues"}, >>> ???????? {setValues, "SetValues"} >>> ???? } >>> }; >>> >>> It turns out that statically initializing a variable length array >>> that is a field of a struct is not valid C syntax. You can >>> statically initialize a variable length array, which is what the >>> code was originally doing, but not a variable length array within a >>> struct. >>> >>> I can fix this issue by giving the array a fixed size. For example: >>> >>> typedef struct CommandSet { >>> ???? int num_cmds; >>> ???? const char *cmd_set_name; >>> ???? const Command cmds[20]; >>> } CommandSet; >>> >>> The catch here is that the array size needs to be at least as big as >>> the largest use, and for all the other static uses extra space will >>> be allocated but never used. In other words, all the arrays would be >>> size 20, even those that initialize fewer than 20 elements. >>> >>> So the choice here pretty much keep what I have, but waste some >>> space with the fixed array size, or use parallel arrays to store the >>> function pointers and command names separately. We used to have: >>> >>> void *ArrayReference_Cmds[] = { (void *)0x3 >>> ???? ,(void *)length >>> ???? ,(void *)getValues >>> ???? ,(void *)setValues}; >>> >>> I could just keep this as-is and add: >>> >>> char *ArrayReference_CmdNames[] = { >>> ???? "Length", >>> ???? "GetValues", >>> ???? "SetValues" >>> }; >>> >>> A further improvement might be to change to original array to be: >>> >>> const CommandHandler ArrayReference_Cmds[] = { >>> ???? length, >>> ???? getValues, >>> ???? setValues >>> }; >>> >>> And then I can add a #define for the array size: >>> >>> #define ArrayReference_NumCmds (sizeof(ArrayReference_Cmds) / >>> sizeof(CommandHandler)) >>> >>> char *ArrayReference_CmdNames[ArrayReference_NumCmds] = { >>> ???? "Length", >>> ???? "GetValues", >>> ???? "SetValues" >>> }; >>> >>> Then I can either access these arrays in parallel, meaning instead of: >>> >>> ???? cmdSetsArray[JDWP_COMMAND_SET(ArrayReference)] = >>> &ArrayReference_Cmds; >>> >>> I would have (not I need an array for the sizes also for the second >>> option abov): >>> >>> ???? cmdSetsCmdsArraySize[JDWP_COMMAND_SET(ArrayReference)] = >>> ArrayReference_NumCmds; >>> ???? cmdSetsCmdsArray[JDWP_COMMAND_SET(ArrayReference)] = >>> &ArrayReference_Cmds; >>> ???? cmdSetsCmdNamesArray[JDWP_COMMAND_SET(ArrayReference)] = >>> &ArrayReference_CmdNames; >>> >>> Or I could change the CommandSet definition to be: >>> >>> typedef struct CommandSet { >>> ???? int num_cmds; >>> ???? const char *cmd_set_name; >>> ???? CommandHandler cmd_handler[]; >>> ???? const char *cmd_name[]; >>> } CommandSet; >>> >>> And then add: >>> >>> const CommandSet ArrayReference_CommandSet = { >>> ???? ArrayReference_NumCmds, >>> ???? "ArrayReference", >>> ???? &ArrayReference_Cmds, >>> ???? &ArrayReference_CmdNames >>> } >>> >>> Then I would just have the array of CommandSets rather than 3 arrays >>> to deal with. >>> >>> Lasty, I could use a macro that declares a new type for each >>> CommandSet, and then when the array of CommandSets is initialized, I >>> would cast that type to a CommandSet. I think the invocation of the >>> macro would look something like: >>> >>> DEFINE_COMMAND_SET (3, ArrayReference, >>> ???????? {length, "Length"}, >>> ???????? {getValues, "GetValues"}, >>> ???????? {setValues, "SetValues"} >>> ) >>> >>> However, I'm a bit unsure of this since I haven't made any attempt >>> to implement it yet. There might be more issues that pop up with >>> this one, where-as doing the parallel arrays is pretty straight >>> forward (although not pretty). >>> >>> thoughts? >>> >>> Chris >>> >>> >>> On 1/10/20 11:27 AM, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review the following >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8236913 >>>> http://cr.openjdk.java.net/~cjplummer/8236913/webrev.00/ >>>> >>>> The debug agent has logging support that will trace all jdwp >>>> commands coming in. Currently all it traces is the command set >>>> number and the command number within that command set. So you see >>>> something like: >>>> >>>> [#|10.01.2020 06:27:24.366 >>>> GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command >>>> set 1, command 9|#] >>>> >>>> I've added support for including the name of the command set and >>>> command, so now you see: >>>> >>>> [#|10.01.2020 06:27:24.366 >>>> GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command >>>> set VirtualMachine(1), command Resume(9)|#] >>>> >>>> So in this case command set 1 represents VirtualMachine and command >>>> 9 is the Resume command. >>>> >>>> I was initially going to leverage jdwp.spec which is already >>>> processed by build.tools.jdwpgen.Main to produce JDWP.java and >>>> JDWPCommands.h. However, I could see it was more of a challenge >>>> than I initially hoped. Also, the main advantage would have been >>>> not having to hard code arrays of command names, but we already >>>> have harded coded arrays of function pointers to handle the various >>>> jdwp commands, so I just replaced these with a more specialized >>>> arrays that also include the names of the commands. As an example, >>>> we used to have: >>>> >>>> void *ArrayReference_Cmds[] = { (void *)0x3 >>>> ??? ,(void *)length >>>> ??? ,(void *)getValues >>>> ??? ,(void *)setValues}; >>>> >>>> Now we have: >>>> >>>> CommandSet ArrayReference_Cmds = { >>>> ??? 3, "ArrayReference", >>>> ??? { >>>> ??????? {length, "Length"}, >>>> ??????? {getValues, "GetValues"}, >>>> ??????? {setValues, "SetValues"} >>>> ??? } >>>> }; >>>> >>>> So no worse w.r.t. hard coding things that could be generated off >>>> the spec, and it cleans up some ugly casts also. The CommandSet >>>> typedef can be found in debugDispatch.h. >>>> >>>> All the header files except for debugDispatch.h have the same >>>> pattern for changes, so they are pretty easy to review >>>> >>>> All .c files except debugDispatch.c and debugLoop.c also have the >>>> same pattern. Note some command handler function names are not the >>>> same as the command name. If you want to double check command set >>>> names and command names, you can find the spec here: >>>> >>>> https://docs.oracle.com/javase/9/docs/specs/jdwp/jdwp-protocol.html >>>> >>>> In ReferenceTypeImpl.c I fixed a typo in the method() prototype. It >>>> had an extra argument which I think was a very old copy-n-paste bug >>>> from the method1() prototype. This was caught because the command >>>> handler functions are now directly assigned to a CommandHandler >>>> type rather than cast. The cast was hiding this bug. >>>> >>>> I tested by doing a test run where MISC logging was enabled by >>>> default. All jdwp, jdb, and jdi tests were run in this way and passed. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>> >>> > > From mandy.chung at oracle.com Fri Jan 17 01:43:22 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 16 Jan 2020 17:43:22 -0800 Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy In-Reply-To: <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com> References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com> <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com> <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com> <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com> <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com> Message-ID: Hi Bob, Severin, On 1/9/20 11:51 AM, Severin Gehwolf wrote: > Thanks for the review! Should all be fixed now. Updated webrev: > > incremental:http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/incremental/webrev/ > full:http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/webrev/ This patch may be more appropriate to be reviewed by the serviceability group (cc'ed) as this is monitoring-related. jdk.internal.platform.Metrics is an internal API that you are free to change the API as appropriate.? Given that 13 out of 38 metrics defined in Metrics are no longer supported by cgroups v2, it's cleaner to refactor Metrics interface to be implementable by cgroups v1 and v2 and then define a cgroups version-specific metrics to extend Metrics, which means that it seems reasonable to make it linux-only sub-interface.? Client can cast to cgroup v1 metrics interface if needed.? Sorry for not chiming in earlier and I am not following the cgroups v2 changes.? This should be a straight-forward change which will make the implementation cleaner.? You would no longer need the new *_UNLIMITED and *_NOT_SUPPORTED constants. A couple of quick comments when skimming on the new files: CgroupSubsystemController.java s/parm/param (including javadoc @param tag) CgroupInfo.java cgroupPath is not used?? Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Fri Jan 17 11:51:04 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 17 Jan 2020 11:51:04 +0000 Subject: jmx-dev RFR(S): 8234484: Add ability to configure third port for remote JMX In-Reply-To: References: <18fcf60c-b342-40c6-e97e-d00563566b9c@oracle.com> <135d431c-6f1a-999c-efc5-71ab106953ee@oracle.com> Message-ID: Thanks Felix! On 16/01/2020 02:01, Yangfei (Felix) wrote: > Modified accordingly in new webrev:http://cr.openjdk.java.net/~fyang/8234484/webrev.02/ > > Also renamed property to: com.sun.management.jmxremote.local.port That looks fine to me. best regards, -- daniel From sgehwolf at redhat.com Fri Jan 17 13:31:53 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 17 Jan 2020 14:31:53 +0100 Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy In-Reply-To: References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com> <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com> <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com> <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com> <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com> Message-ID: <48794a4124d7b9e27b011dd1a3f9f8a36ef8cf36.camel@redhat.com> Hi Mandy, On Thu, 2020-01-16 at 17:43 -0800, Mandy Chung wrote: > Hi Bob, Severin, > > On 1/9/20 11:51 AM, Severin Gehwolf wrote: > > Thanks for the review! Should all be fixed now. Updated webrev: > > > > incremental: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/incremental/webrev/ > > full: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/webrev/ > > This patch may be more appropriate to be reviewed by the > serviceability group (cc'ed) as this is monitoring-related. Thanks for the review, Mandy. > jdk.internal.platform.Metrics is an internal API that you are free to > change the API as appropriate. Given that 13 out of 38 metrics > defined in Metrics are no longer supported by cgroups v2, it's > cleaner to refactor Metrics interface to be implementable by cgroups > v1 and v2 and then define a cgroups version-specific metrics to > extend Metrics, which means that it seems reasonable to make it > linux-only sub-interface. Client can cast to cgroup v1 metrics > interface if needed. Sorry for not chiming in earlier and I am not > following the cgroups v2 changes. This should be a straight-forward > change which will make the implementation cleaner. You would no > longer need the new *_UNLIMITED and *_NOT_SUPPORTED constants. If I understand you correctly, then we'd have to change how -XshowSettings:system works currently with it. Not all metrics as currently printed via LauncherHelper.java are supported in both worlds (cgroup v1 & v2). It would make handling of cgroup v1 and cgroup v2 specific metrics a little more awkward. Adding instanceof checks and downcasting as you suggest the consequence for a client would be. See: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/08/webrev/src/java.base/share/classes/sun/launcher/LauncherHelper.java.sdiff.html Also, in order to not break cross platform promises we'd also have to make the version specific interfaces available in shared code (or we'd risk requiring the user to use reflection) to get the proper sub- interface logic called. I'll experiment with it, but I'm not convinced this makes the API any nicer, really. > A couple of quick comments when skimming on the new files: > CgroupSubsystemController.java > s/parm/param (including javadoc @param tag) > > CgroupInfo.java > cgroupPath is not used?? Thanks, will update that in the next webrev. Cheers, Severin From mandy.chung at oracle.com Fri Jan 17 16:53:31 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 17 Jan 2020 08:53:31 -0800 Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy In-Reply-To: <48794a4124d7b9e27b011dd1a3f9f8a36ef8cf36.camel@redhat.com> References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com> <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com> <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com> <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com> <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com> <48794a4124d7b9e27b011dd1a3f9f8a36ef8cf36.camel@redhat.com> Message-ID: <906cb751-c63e-246d-6b6e-4dd27de46d3d@oracle.com> On 1/17/20 5:31 AM, Severin Gehwolf wrote: > > If I understand you correctly, then we'd have to change how > -XshowSettings:system works currently with it. Not all metrics as > currently printed via LauncherHelper.java are supported in both worlds > (cgroup v1 & v2). It would make handling of cgroup v1 and cgroup v2 > specific metrics a little more awkward. Adding instanceof checks and > downcasting as you suggest the consequence for a client would be. > See: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/08/webrev/src/java.base/share/classes/sun/launcher/LauncherHelper.java.sdiff.html > > Also, in order to not break cross platform promises we'd also have to > make the version specific interfaces available in shared code (or we'd > risk requiring the user to use reflection) to get the proper sub- > interface logic called. -XshowSettings:system output is implementation detail [1] and also linux-only option.?? jdk.internal.platform.Metrics is an internal API and there is no promise that it supports the union of all cgroups v1 and v2 metrics.? As you see, 1/3 of the metrics in v1 are not supported in v2.?? It's reasonable for -XshowSettings:system showing the metrics valid to the container. thanks Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8204107 From alexey.menkov at oracle.com Fri Jan 17 18:37:46 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 17 Jan 2020 10:37:46 -0800 Subject: PING: RFR: JDK-8235846: Improve WindbgDebuggerLocal implementation In-Reply-To: <2a7a52f8-aaea-2124-faaf-d371d8bcbb8e@oracle.com> References: <8ca073bf-0f82-46d5-7fd1-0a5b5757bfa4@oracle.com> <6ed9a23f-3ba4-cbf2-8156-26b4e3731eeb@oracle.com> <2bac872a-e538-83e9-1448-dcd788de2cee@oracle.com> <2a7a52f8-aaea-2124-faaf-d371d8bcbb8e@oracle.com> Message-ID: <364eb89e-4811-a3b6-67c8-0c26e8776816@oracle.com> Need 2nd reviewer. --alex On 01/14/2020 13:10, serguei.spitsyn at oracle.com wrote: > Hi Alex, > > Thank you for the update! > It looks good. > > Still incorrect indent: > > 103 ~AutoJavaString() { 104 if (m_buf) { 105 > m_env->ReleaseStringUTFChars(m_str, m_buf); 106 } 107 } 108 109 operator > const char* () const { 110 return m_buf; 111 } ... 133 void > setReleaseMode(jint mode) { > 134 releaseMode = mode; > 135 } > 136 > 137 operator jbyte* () const { > 138 return bytePtr; > 139 } > > The comment shout start from a capital letter: > > 177 // verifies COM call result is S_OK, throws DebuggerException and > exits otherwise. > > > No need for another webrev. > > Thanks, > Serguei > > > > On 1/14/20 12:39 PM, Alex Menkov wrote: >> Hi Serguei, >> >> Thank you for the review. >> updated webrev: >> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.02/ >> >> On 01/13/2020 16:39, serguei.spitsyn at oracle.com wrote: >>> Hi Alex, >>> >>> It looks pretty good. >>> Just some minor comments below. >>> >>> The class AutoCOMPtr has unfixed indents. >>> I guess, the function AutoArrayPtr.asPtr() is not used anymore and >>> can be deleted. >> >> fixed. >> >>> >>> I'd suggest to remove first level '()' brackets in the comment to >>> avoid brackets nesting: 74 // manage COM 'auto' pointers (to avoid >>> multiple Release 75 // calls at every early (exception) returns). => >>> 74 // manage COM 'auto' pointers to avoid multiple Release >>> 75 // calls at every early (exception) returns. >> >> done. >> >>> I'd suggest to reformat it as it was originally formatted: >>> >>> 297 if (IsEqualIID(interfaceId, __uuidof(IUnknown)) >>> 298 || IsEqualIID(interfaceId, __uuidof(IDebugOutputCallbacks))) { => >>> 297 if (IsEqualIID(interfaceId, __uuidof(IUnknown))? || >>> 298 IsEqualIID(interfaceId, __uuidof(IDebugOutputCallbacks))) { >> >> done. >> >>> The comment about S_FALSE is not that clear as S_FALSE is not really >>> used >>> (better to use consistently just one value: S_FALSE or false): >>> >>> 418 // S_FALSE means timeout >>> 419 COM_VERIFY_OK_(ptrIDebugControl->WaitForEvent(DEBUG_WAIT_DEFAULT, >>> INFINITE), >>> 420 "Windbg Error: WaitForEvent failed!", false); >> >> S_FALSE is a possible result of ptrIDebugControl->WaitForEvent call. >> In the case we wait infinitely, so S_FALSE is not possible and we >> don't handle it separately. >> I removed the comment. >> >> >>> NULL is used in some placesand nullptr in others. >> >> There is some mess with 0/NULL/nullptr in the file >> I fixed all NULLs and some (most likely not all) 0s. >> BTW it immediately discovered misuse of NULL/0: >> >> -? if (ptrIDebugSymbols->GetModuleParameters(loaded, 0, NULL, >> params.asPtr()) != S_OK) { >> -???? THROW_NEW_DEBUGGER_EXCEPTION_("Windbg Error: GetModuleParameters >> failed!", false); >> -? } >> +? COM_VERIFY_OK_(ptrIDebugSymbols->GetModuleParameters(loaded, >> nullptr, 0, params), >> +???????????????? "Windbg Error: GetModuleParameters failed!", false); >> >> 2nd arg of GetModuleParameters is a pointer and 3rd is ulong >> >> --alex >>> >>> Thanks, >>> Serguei >>> >>> >>> On 12/19/19 15:34, Alex Menkov wrote: >>>> Hi all, >>>> >>>> Please review a fix for >>>> https://bugs.openjdk.java.net/browse/JDK-8235846 >>>> webrev: >>>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.01/ >>>> >>>> Main goal of the change is to improve error reporting (we have >>>> several bugs and need at least COM error codes for WinDbg calls). >>>> Also the fix improves/rearranges this quite old code. >>>> >>>> --alex >>> > From serguei.spitsyn at oracle.com Fri Jan 17 22:16:03 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 Jan 2020 14:16:03 -0800 Subject: RFR(M): 8236913: debug agent's jdwp command logging should include the command set name and command name In-Reply-To: References: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> <9cca7543-d647-5737-6de4-56e07f9831e4@oracle.com> Message-ID: <12f96995-5e5d-2be0-c08c-3c4f94556bfc@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jan 17 22:19:59 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 Jan 2020 14:19:59 -0800 Subject: RFR(M): 8236913: debug agent's jdwp command logging should include the command set name and command name In-Reply-To: <12f96995-5e5d-2be0-c08c-3c4f94556bfc@oracle.com> References: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> <9cca7543-d647-5737-6de4-56e07f9831e4@oracle.com> <12f96995-5e5d-2be0-c08c-3c4f94556bfc@oracle.com> Message-ID: <24b213e1-a5ed-3e29-a663-ebff128535f6@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jan 17 22:33:56 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 Jan 2020 14:33:56 -0800 Subject: RFR(M): 8236913: debug agent's jdwp command logging should include the command set name and command name In-Reply-To: References: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> <9cca7543-d647-5737-6de4-56e07f9831e4@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Jan 17 22:36:34 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 17 Jan 2020 14:36:34 -0800 Subject: PING: RFR: JDK-8235846: Improve WindbgDebuggerLocal implementation In-Reply-To: <364eb89e-4811-a3b6-67c8-0c26e8776816@oracle.com> References: <8ca073bf-0f82-46d5-7fd1-0a5b5757bfa4@oracle.com> <6ed9a23f-3ba4-cbf2-8156-26b4e3731eeb@oracle.com> <2bac872a-e538-83e9-1448-dcd788de2cee@oracle.com> <2a7a52f8-aaea-2124-faaf-d371d8bcbb8e@oracle.com> <364eb89e-4811-a3b6-67c8-0c26e8776816@oracle.com> Message-ID: Hi Alex, I assume that the following: ? 65?? operator T* () const { ? 66???? return m_ptr; ? 67?? } Is used here: ?183?????? AutoArrayPtr errmsg(new char[strlen(str) + 32]); \ ?184?????? if (errmsg == nullptr) { \ I just don't understand how this works. Somehow it seems the "T*" operator applies to the "errmsg" reference here. This is a use of C++ operators I'm not familiar with. Can you please explain. Why is the following not placed at the end if the "if" block: ?299?? AddRef(); ?300?? return S_OK; The following was removed. It's not clear to me why it was and what the impact is: ?283?? ptrIDebugOutputCallbacks->AddRef(); thanks, Chris On 1/17/20 10:37 AM, Alex Menkov wrote: > Need 2nd reviewer. > > --alex > > On 01/14/2020 13:10, serguei.spitsyn at oracle.com wrote: >> Hi Alex, >> >> Thank you for the update! >> It looks good. >> >> Still incorrect indent: >> >> 103 ~AutoJavaString() { 104 if (m_buf) { 105 >> m_env->ReleaseStringUTFChars(m_str, m_buf); 106 } 107 } 108 109 >> operator const char* () const { 110 return m_buf; 111 } ... 133 void >> setReleaseMode(jint mode) { >> 134 releaseMode = mode; >> 135 } >> 136 >> 137 operator jbyte* () const { >> 138 return bytePtr; >> 139 } >> >> The comment shout start from a capital letter: >> >> 177 // verifies COM call result is S_OK, throws DebuggerException and >> exits otherwise. >> >> >> No need for another webrev. >> >> Thanks, >> Serguei >> >> >> >> On 1/14/20 12:39 PM, Alex Menkov wrote: >>> Hi Serguei, >>> >>> Thank you for the review. >>> updated webrev: >>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.02/ >>> >>> On 01/13/2020 16:39, serguei.spitsyn at oracle.com wrote: >>>> Hi Alex, >>>> >>>> It looks pretty good. >>>> Just some minor comments below. >>>> >>>> The class AutoCOMPtr has unfixed indents. >>>> I guess, the function AutoArrayPtr.asPtr() is not used anymore and >>>> can be deleted. >>> >>> fixed. >>> >>>> >>>> I'd suggest to remove first level '()' brackets in the comment to >>>> avoid brackets nesting: 74 // manage COM 'auto' pointers (to avoid >>>> multiple Release 75 // calls at every early (exception) returns). >>>> => 74 // manage COM 'auto' pointers to avoid multiple Release >>>> 75 // calls at every early (exception) returns. >>> >>> done. >>> >>>> I'd suggest to reformat it as it was originally formatted: >>>> >>>> 297 if (IsEqualIID(interfaceId, __uuidof(IUnknown)) >>>> 298 || IsEqualIID(interfaceId, __uuidof(IDebugOutputCallbacks))) { >>>> => 297 if (IsEqualIID(interfaceId, __uuidof(IUnknown))? || >>>> 298 IsEqualIID(interfaceId, __uuidof(IDebugOutputCallbacks))) { >>> >>> done. >>> >>>> The comment about S_FALSE is not that clear as S_FALSE is not >>>> really used >>>> (better to use consistently just one value: S_FALSE or false): >>>> >>>> 418 // S_FALSE means timeout >>>> 419 >>>> COM_VERIFY_OK_(ptrIDebugControl->WaitForEvent(DEBUG_WAIT_DEFAULT, >>>> INFINITE), >>>> 420 "Windbg Error: WaitForEvent failed!", false); >>> >>> S_FALSE is a possible result of ptrIDebugControl->WaitForEvent call. >>> In the case we wait infinitely, so S_FALSE is not possible and we >>> don't handle it separately. >>> I removed the comment. >>> >>> >>>> NULL is used in some placesand nullptr in others. >>> >>> There is some mess with 0/NULL/nullptr in the file >>> I fixed all NULLs and some (most likely not all) 0s. >>> BTW it immediately discovered misuse of NULL/0: >>> >>> -? if (ptrIDebugSymbols->GetModuleParameters(loaded, 0, NULL, >>> params.asPtr()) != S_OK) { >>> -???? THROW_NEW_DEBUGGER_EXCEPTION_("Windbg Error: >>> GetModuleParameters failed!", false); >>> -? } >>> + COM_VERIFY_OK_(ptrIDebugSymbols->GetModuleParameters(loaded, >>> nullptr, 0, params), >>> +???????????????? "Windbg Error: GetModuleParameters failed!", false); >>> >>> 2nd arg of GetModuleParameters is a pointer and 3rd is ulong >>> >>> --alex >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 12/19/19 15:34, Alex Menkov wrote: >>>>> Hi all, >>>>> >>>>> Please review a fix for >>>>> https://bugs.openjdk.java.net/browse/JDK-8235846 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.01/ >>>>> >>>>> Main goal of the change is to improve error reporting (we have >>>>> several bugs and need at least COM error codes for WinDbg calls). >>>>> Also the fix improves/rearranges this quite old code. >>>>> >>>>> --alex >>>> >> From chris.plummer at oracle.com Fri Jan 17 22:58:15 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 17 Jan 2020 14:58:15 -0800 Subject: RFR(M): 8236913: debug agent's jdwp command logging should include the command set name and command name In-Reply-To: References: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> <9cca7543-d647-5737-6de4-56e07f9831e4@oracle.com> Message-ID: <92511276-29c3-a889-1459-2b3cca4ad5c0@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jan 17 22:59:39 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 Jan 2020 14:59:39 -0800 Subject: RFR(M): 8236913: debug agent's jdwp command logging should include the command set name and command name In-Reply-To: <92511276-29c3-a889-1459-2b3cca4ad5c0@oracle.com> References: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> <9cca7543-d647-5737-6de4-56e07f9831e4@oracle.com> <92511276-29c3-a889-1459-2b3cca4ad5c0@oracle.com> Message-ID: <47694091-14e7-0792-db25-0486b5823cad@oracle.com> An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Sat Jan 18 03:10:51 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 17 Jan 2020 19:10:51 -0800 Subject: RFR: 8235681: Remove unnecessary workarounds in UnixOperatingSystem.c Message-ID: Please review a change that removes unnecessary workaround in UnixOperatingSystem.c. It looks as this workaround if (pticks->usedKernel < tmp.usedKernel) { kdiff = 0; } was added to compensate a missed initialization of counters.jvmTicks that resulted in the new counters being compared with the garbage when get_cpuload_internal(...) was called for the first time. This missed initialization was fixed in [3]. Mach5 tier1-tier3 and open/test/hotspot/jtreg/containers/docker tests successfully passed. [1] Webrev : http://cr.openjdk.java.net/~dtitov/8235681/webrev.01/ [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8235681 [3] https://bugs.openjdk.java.net/browse/JDK-8226575 Thank you, Daniil From serguei.spitsyn at oracle.com Sat Jan 18 06:20:08 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 Jan 2020 22:20:08 -0800 Subject: RFR: 8227269: Slow class loading when running JVM in debug mode In-Reply-To: <805d3200-2f12-922a-b6d6-78381c9a9d2b@redhat.com> References: <8870829e-c558-c956-2184-00204632abb6@redhat.com> <743135a7-cade-34ee-6485-1c174376d7bd@oracle.com> <20e507f7-0e6e-43a8-be0b-ea7ba6a6edcb@redhat.com> <48dad0bc-fbdf-08eb-4bdf-f8220742035d@redhat.com> <805d3200-2f12-922a-b6d6-78381c9a9d2b@redhat.com> Message-ID: <14de19af-7146-969e-2a21-80ed40d175fb@oracle.com> An HTML attachment was scrubbed... URL: From suenaga at oss.nttdata.com Sun Jan 19 02:16:38 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Sun, 19 Jan 2020 11:16:38 +0900 Subject: PING: RFR: 8234624: jstack mixed mode should refer DWARF In-Reply-To: References: <3890a0f3-55f4-c9e5-76c3-d3d18db6b79a@oss.nttdata.com> <2515a14d-90f5-da47-c802-966b06f20adc@oracle.com> Message-ID: <3ae29ebb-556f-f8c7-c107-61a5d18fce07@oss.nttdata.com> PING: Could you review it? JBS: https://bugs.openjdk.java.net/browse/JDK-8234624 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8234624/webrev.03/ I updated webrev. I discussed with Serguei in off list, and I refactored webrev.02 . It has passed tests on submit repo (mach5-one-ysuenaga-JDK-8234624-4-20200118-1353-8149549). Thanks, Yasumasa On 2019/12/15 10:51, Yasumasa Suenaga wrote: > Hi Serguei, > > Thanks for your comment! > I refactored LinuxCDebugger and LinuxAMD64CFrame in new webrev. > Also I fixed to free lib->eh_frame.data in libproc_impl.c as Dmitry said. > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8234624/webrev.02/ > > This change has been passed all tests on submit repo (mach5-one-ysuenaga-JDK-8234624-3-20191214-1527-7538487). > > > Thanks, > > Yasumasa > > > On 2019/12/14 10:02, serguei.spitsyn at oracle.com wrote: >> Hi Yasumasa, >> >> This is nice move in general. >> Thank you for working on this! >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8234624/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java.frames.html >> >> 96 long libptr = dbg.findLibPtrByAddress(pc); 97 if (libptr == 0L) { // Java frame 98 Address rbp = context.getRegisterAsAddress(AMD64ThreadContext.RBP); 99 if (rbp == null) { 100 return null; 101 } 102 return new LinuxAMD64CFrame(dbg, rbp, pc, null); 103 } else { // Native frame 104 DwarfParser dwarf; 105 try { 106 dwarf = new DwarfParser(libptr); 107 } catch (DebuggerException e) { 108 Address rbp = context.getRegisterAsAddress(AMD64ThreadContext.RBP); 109 if (rbp == null) { 110 return null; 111 } 112 return new LinuxAMD64CFrame(dbg, rbp, pc, null); 113 } 114 dwarf.processDwarf(pc); 115 Address cfa = ((dwarf.getCFARegister() == AMD64ThreadContext.RBP) && 116 !dwarf.isBPOffsetAvailable()) 117 ? context.getRegisterAsAddress(AMD64ThreadContext.RBP) 118 : context.getRegisterAsAddress(dwarf.getCFARegister()) 119 .addOffsetTo(dwarf.getCFAOffset()); 120 if (cfa == null) { 121 return null; 122 } 123 return new LinuxAMD64CFrame(dbg, cfa, pc, dwarf); 124 } >> >> >> I'd suggest to simplify the logic by refactoring to something like below: >> >> ?????????? long libptr = dbg.findLibPtrByAddress(pc); >> ?????????? Address cfa = context.getRegisterAsAddress(AMD64ThreadContext.RBP); // Java frame >> ?????????? DwarfParser dwarf = null; >> >> ?????????? if (libptr != 0L) { // Native frame >> ???????????? try { >> ?????????????? dwarf = new DwarfParser(libptr); >> ?????????????? dwarf.processDwarf(pc); >> ?????????????? Address cfa = ((dwarf.getCFARegister() == AMD64ThreadContext.RBP) && >> ????????????????????????????? !dwarf.isBPOffsetAvailable()) >> ???????????????????????????????? ? context.getRegisterAsAddress(AMD64ThreadContext.RBP) >> ???????????????????????????????? : context.getRegisterAsAddress(dwarf.getCFARegister()) >> .addOffsetTo(dwarf.getCFAOffset()); >> >> ??????????? } catch (DebuggerException e) { // bail out to Java frame case >> ??????????? } >> ????????? } >> ????????? if (cfa == null) { >> ??????????? return null; >> ????????? } >> ????????? return new LinuxAMD64CFrame(dbg, cfa, pc, dwarf); >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8234624/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java.frames.html >> >> 58 long ofs = useDwarf ? dwarf.getReturnAddressOffsetFromCFA() >> >> ?? Better to rename 'ofs' => 'offs'. >> >> 77 nextCFA = nextCFA.addOffsetTo(- nextDwarf.getBasePointerOffsetFromCFA()); >> >> ?? Extra space after '-' sign. >> >> 71 private Address getNextCFA(DwarfParser nextDwarf, ThreadContext context) { >> >> ?? It feels like the logic has to be somehow refactored/simplified as >> ?? several typical fragments appears in slightly different contexts. >> ?? But it is not easy to understand what it is. >> ?? Could you, please, add some comments to key places explaining this logic. >> ?? Then I'll check if it is possible to make it a little bit simpler. >> >> 109 private CFrame javaSender(ThreadContext context) { 110 Address nextCFA; 111 Address nextPC; 112 113 nextPC = getNextPC(false); 114 if (nextPC == null) { 115 return null; 116 } 117 118 DwarfParser nextDwarf = null; 119 long libptr = dbg.findLibPtrByAddress(nextPC); 120 if (libptr != 0L) { // Native frame 121 try { 122 nextDwarf = new DwarfParser(libptr); 123 } catch (DebuggerException e) { 124 nextCFA = getNextCFA(null, context); 125 return (nextCFA == null) ? null : new LinuxAMD64CFrame(dbg, nextCFA, nextPC, null); 126 } 127 nextDwarf.processDwarf(nextPC); 128 } 129 130 nextCFA = getNextCFA(nextDwarf, context); 131 return (nextCFA == null) ? null 132 : new LinuxAMD64CFrame(dbg, nextCFA, nextPC, nextDwarf); 133 } >> >> ??The above can be simplified if a DebuggerException can not be thrown from processDwarf(nextPC): >> ????? private CFrame javaSender(ThreadContext context) { >> ??????? Address nextPC = getNextPC(false); >> ??????? if (nextPC == null) { >> ????????? return null; >> ??????? } >> ??????? long libptr = dbg.findLibPtrByAddress(nextPC); >> ??????? DwarfParser nextDwarf = null; >> >> ??????? if (libptr != 0L) { // Native frame >> ????????? try { >> ??????????? nextDwarf = new DwarfParser(libptr); >> ??????????? nextDwarf.processDwarf(nextPC); >> ????????? } catch (DebuggerException e) { // Bail out to Java frame >> ????????? } >> ??????? } >> ??????? Address nextCFA = getNextCFA(nextDwarf, context); >> ??????? return (nextCFA == null) ? null : new LinuxAMD64CFrame(dbg, nextCFA, nextPC, nextDwarf); >> ????? } >> >> 135 public CFrame sender(ThreadProxy thread) { 136 ThreadContext context = thread.getContext(); 137 138 if (dwarf == null) { // Java frame 139 return javaSender(context); 140 } 141 142 Address nextPC = getNextPC(true); 143 if (nextPC == null) { 144 return null; 145 } 146 147 Address nextCFA; 148 DwarfParser nextDwarf = dwarf; 149 if (!dwarf.isIn(nextPC)) { 150 long libptr = dbg.findLibPtrByAddress(nextPC); 151 if (libptr == 0L) { 152 // Next frame might be Java frame 153 nextCFA = getNextCFA(null, context); 154 return (nextCFA == null) ? null : new LinuxAMD64CFrame(dbg, nextCFA, nextPC, null); 155 } 156 try { 157 nextDwarf = new DwarfParser(libptr); 158 } catch (DebuggerException e) { 159 nextCFA = getNextCFA(null, context); 160 return (nextCFA == null) ? null : new LinuxAMD64CFrame(dbg, nextCFA, nextPC, null); 161 } 162 } 163 164 nextDwarf.processDwarf(nextPC); 165 nextCFA = getNextCFA(nextDwarf, context); 166 return (nextCFA == null) ? null : new LinuxAMD64CFrame(dbg, >> nextCFA, nextPC, nextDwarf); 167 } >> >> ??This one can be also simplified a little: >> >> ????? public CFrame sender(ThreadProxy thread) { >> ??????? ThreadContext context = thread.getContext(); >> >> ??????? if (dwarf == null) { // Java frame >> ????????? return javaSender(context); >> ??????? } >> ??????? Address nextPC = getNextPC(true); >> ??????? if (nextPC == null) { >> ????????? return null; >> ??????? } >> ??????? DwarfParser nextDwarf = null; >> ??????? if (!dwarf.isIn(nextPC)) { >> ????????? long libptr = dbg.findLibPtrByAddress(nextPC); >> ????????? if (libptr != 0L) { >> ??????????? try { >> ????????????? nextDwarf = new DwarfParser(libptr); >> ????????????? nextDwarf.processDwarf(nextPC); >> ??????????? } catch (DebuggerException e) { // Bail out to Java frame >> ??????????? } >> ????????? } >> ??????? } >> ??????? Address nextCFA = getNextCFA(nextDwarf, context); >> ??????? return (nextCFA == null) ? null : new LinuxAMD64CFrame(dbg, nextCFA, nextPC, nextDwarf); >> ????? } >> >> Finally, it looks like just one method could replace both >> sender(ThreadProxy thread) and javaSender(ThreadContext context): >> >> ????? private CFrame commonSender(ThreadProxy thread) { >> ??????? ThreadContext context = thread.getContext(); >> ??????? Address nextPC = getNextPC(false); >> ??????? if (nextPC == null) { >> ????????? return null; >> ??????? } >> ??????? DwarfParser nextDwarf = null; >> >> ??????? long libptr = dbg.findLibPtrByAddress(nextPC); >> ??????? if (dwarf == null || !dwarf.isIn(nextPC)) { >> ????????? long libptr = dbg.findLibPtrByAddress(nextPC); >> ????????? if (libptr != 0L) { >> ??????????? try { >> ????????????? nextDwarf = new DwarfParser(libptr); >> ????????????? nextDwarf.processDwarf(nextPC); >> ??????????? } catch (DebuggerException e) { // Bail out to Java frame >> ??????????? } >> ????????? } >> ??????? } >> ??????? Address nextCFA = getNextCFA(nextDwarf, context); >> ??????? return (nextCFA == null) ? null : new LinuxAMD64CFrame(dbg, nextCFA, nextPC, nextDwarf); >> ????? } >> >> I'm still reviewing the dwarf parser files. >> >> Thanks, >> Serguei >> >> >> On 11/28/19 4:39 AM, Yasumasa Suenaga wrote: >>> Hi, >>> >>> I refactored LinuxAMD64CFrame.java . It works fine in serviceability/sa tests and >>> all tests on submit repo (mach5-one-ysuenaga-JDK-8234624-2-20191128-0928-7059923). >>> Could you review new webrev? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8234624/webrev.01/ >>> >>> The diff from previous webrev is here: >>> http://hg.openjdk.java.net/jdk/submit/rev/4bc47efbc90b >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2019/11/25 14:08, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Please review this change: >>>> >>>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8234624 >>>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8234624/webrev.00/ >>>> >>>> >>>> According to 2.7 Stack Unwind Algorithm in System V Application Binary Interface AMD64 >>>> Architecture Processor Supplement [1], we need to use DWARF in .eh_frame or .debug_frame >>>> for stack unwinding. >>>> >>>> As JDK-8022183 said, omit-frame-pointer is enabled by default since GCC 4.6, so system >>>> library (e.g. libc) might be compiled with this feature. >>>> >>>> However `jhsdb jstack --mixed` does not do so, it uses base pointer register (RBP). >>>> So it might be lack of stack frames. >>>> >>>> I guess JDK-8219201 is caused by same issue. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf >> From felix.yang at huawei.com Tue Jan 21 07:15:28 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 21 Jan 2020 07:15:28 +0000 Subject: jmx-dev RFR(S): 8234484: Add ability to configure third port for remote JMX In-Reply-To: References: <18fcf60c-b342-40c6-e97e-d00563566b9c@oracle.com> <135d431c-6f1a-999c-efc5-71ab106953ee@oracle.com> Message-ID: Hi Daniel, Thanks for reviewing the patch. Will do the push. Felix > > On 16/01/2020 02:01, Yangfei (Felix) wrote: > > Modified accordingly in new > webrev:http://cr.openjdk.java.net/~fyang/8234484/webrev.02/ > > > > Also renamed property to: com.sun.management.jmxremote.local.port > > That looks fine to me. > > best regards, > > -- daniel From stefan.karlsson at oracle.com Tue Jan 21 14:58:53 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 21 Jan 2020 15:58:53 +0100 Subject: RFR: 8237111: LingeredApp should be started with getTestJavaOpts Message-ID: <020a9179-b7ba-45d3-5947-1b970301b602@oracle.com> Hi all, Please review this patch to change our usages of LingeredApp and getVmOptions() to instead use getTestJavaOpts(). https://cr.openjdk.java.net/~stefank/8237111/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8237111 This issue was encountered by both Coleen and I, independently. We have two ways to pass JVM flags to jtreg. They come with different names depending on the test layer (make, jtreg, test.lib etc): 1) Utils.getVmOptions(), -vmoptions, -Dtest.vm.options, VM_OPTIONS, ... Is passed to all JVMs (not only the one under test) 2) -javaoptions, -Dtest.java.options, JAVA_OPTIONS, TEST_JAVA_OPTS, ... Is passed to tested JVM The problem is that mach5 uses the latter to propagate JVM flags, so when tests explicitly uses Utils.getVmOptions() they won't run with the specified flags. The problem also arise if someone runs the following on the command line: make -C ../build/fastdebug test TEST=test/hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java JTREG="JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+UseZGC" There's no Utils.getJavaOptions() function that fetches the (2) flags, but there is a Utils.getTestJavaOpts() function that fetches flags from both (1) and (2). The proposal is to stop using (and remove) Utils.getVmOptions() and instead use Utils.getTestJavaOpts(). This patch touches more than LingeredApp, so we should probably rename it. Some details about the patch: - LingeredApp.startApp() now runs with getTestJavaOpts(). - getVmOptions() returned a List and getTestJavaOpts() returns a String[]. I've adapted the code to use String[] instead. - Changed the parameter list of LingeredApp so that we could use String..., and lower the amount of boiler plate code. - Removed Utils.getVmOptions() - Left Utils.getForwardVmOptions() for now, because replacing it requires changes that needs to be reviewed on other lists. - Added appendTestJavaOpts and prependTestJavaOpts since the order is important to tests. - Left addTestJavaOpts for now, because replacing it requires changes that needs to be reviewed on other lists. - Excluded some ZGC SA tests, because now we actually run with ZGC when we ask for it. - JMapHeapConfigTest.java is broken when (jlong)-1 is passed in a flag. This prevented ZGC from running, because we set MaxNewSize to max size_t. Apparently, someone had already noticed this problem with MaxMetaspaceSize and added this cryptic line: // ignoring MaxMetaspaceSize I did the same for MaxNewSize and created a bug report. - There are two instances of LingeredApp. I fixed both and created an enhancement to combine the two classes. - ClhsdbFlags.runAllTypesTest used to *append* getVmOptions(). This started failing when I changed to getTestJavaOpts() because in some configs we override some of the flags in the test. I fixed it by *prepending* the getTestJavaOpts(). Tested with various tiers, but not on the absolute latest patch. Will run this through more testing when the review is done. Thanks, StefanK From hohensee at amazon.com Tue Jan 21 15:34:35 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 21 Jan 2020 15:34:35 +0000 Subject: RFR 8235300: VM_HeapDumper hits assert with bad dump_len In-Reply-To: <125C42A4-B2F5-4CCE-8864-043725C79DBF@amazon.com> References: <7271C378-98AF-406A-8628-1A6ADDCF7A39@amazon.com> <75ab359d-e556-849d-1bda-eedd9e32c09d@oracle.com> <125C42A4-B2F5-4CCE-8864-043725C79DBF@amazon.com> Message-ID: Hi, David, Is it ok to put this CSR in Finalized state? Thanks, Paul ?On 1/15/20, 5:12 PM, "serviceability-dev on behalf of Hohensee, Paul" wrote: Thanks for your review and updates, David. I've updated the CSR as you requested in its comments. Paul On 1/14/20, 5:12 PM, "David Holmes" wrote: Hi Paul, I made some minor updates to the CSR request and added myself as a reviewer. Thanks, David On 15/01/2020 10:00 am, Hohensee, Paul wrote: > Please review this CSR for a backport of JDK-8144732 to jdk8u. > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8144732 > > JBS release note issue: https://bugs.openjdk.java.net/browse/JDK-8174881 > > 8u backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8235299 > > 8u backport CSR: https://bugs.openjdk.java.net/browse/JDK-8235300 > > The original patch went through the Oracle CCC process prior to the > creation of the public CSR process, so there?s no public CSR issue, > hence the release note JBS issue reference. > > Thanks, > > Paul > From Alan.Bateman at oracle.com Tue Jan 21 16:00:27 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Jan 2020 16:00:27 +0000 Subject: jmx-dev RFR(S): 8234484: Add ability to configure third port for remote JMX In-Reply-To: References: <18fcf60c-b342-40c6-e97e-d00563566b9c@oracle.com> <135d431c-6f1a-999c-efc5-71ab106953ee@oracle.com> Message-ID: <8fc616ec-4913-662c-6eba-6e6334801a46@oracle.com> On 21/01/2020 07:15, Yangfei (Felix) wrote: > Hi Daniel, > > Thanks for reviewing the patch. Will do the push. > Is this a documented and supported property? I assume so, in which case you should create a CSR. I think a Release-Note sub-task will needed too so that it gets into at least the release notes. -Alan From coleen.phillimore at oracle.com Tue Jan 21 16:33:19 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 21 Jan 2020 11:33:19 -0500 Subject: RFR: 8237111: LingeredApp should be started with getTestJavaOpts In-Reply-To: <020a9179-b7ba-45d3-5947-1b970301b602@oracle.com> References: <020a9179-b7ba-45d3-5947-1b970301b602@oracle.com> Message-ID: <7a31b62c-b7e2-8cb2-49dd-440d82b22154@oracle.com> Hi Stefan, Thank you for cleaning this up!? I was expecting VM_OPTIONS and TEST_VM_OPTS to go away also, but I guess they don't need to since they are included in getJavaOpts(). The change for LingeredApp.startApp() to take a String[] is good. It was awkward the way it was in TestInstanceKlassSize*.java. Maybe when resolving the duplication of LingeredApps, someone should move the SA tests in only one place (I'll suggest it in your RFE). Thanks, Coleen On 1/21/20 9:58 AM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to change our usages of LingeredApp and > getVmOptions() to instead use getTestJavaOpts(). > > https://cr.openjdk.java.net/~stefank/8237111/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8237111 > > This issue was encountered by both Coleen and I, independently. > > We have two ways to pass JVM flags to jtreg. They come with different > names depending on the test layer (make, jtreg, test.lib etc): > > 1) Utils.getVmOptions(), -vmoptions, -Dtest.vm.options, VM_OPTIONS, ... > > ?Is passed to all JVMs (not only the one under test) > > 2) -javaoptions, -Dtest.java.options, JAVA_OPTIONS, TEST_JAVA_OPTS, ... > > ?Is passed to tested JVM > > The problem is that mach5 uses the latter to propagate JVM flags, so > when tests explicitly uses Utils.getVmOptions() they won't run with > the specified flags. > > The problem also arise if someone runs the following on the command line: > make -C ../build/fastdebug test > TEST=test/hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java > JTREG="JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+UseZGC" > > There's no Utils.getJavaOptions() function that fetches the (2) flags, > but there is a Utils.getTestJavaOpts() function that fetches flags > from both (1) and (2). > > The proposal is to stop using (and remove) Utils.getVmOptions() and > instead use Utils.getTestJavaOpts(). This patch touches more than > LingeredApp, so we should probably rename it. > > Some details about the patch: > - LingeredApp.startApp() now runs with getTestJavaOpts(). > > - getVmOptions() returned a List and getTestJavaOpts() returns > a String[]. I've adapted the code to use String[] instead. > > - Changed the parameter list of LingeredApp so that we could use > String..., and lower the amount of boiler plate code. > > - Removed Utils.getVmOptions() > > - Left Utils.getForwardVmOptions() for now, because replacing it > requires changes that needs to be reviewed on other lists. > > - Added appendTestJavaOpts and prependTestJavaOpts since the order is > important to tests. > > - Left addTestJavaOpts for now, because replacing it requires changes > that needs to be reviewed on other lists. > > - Excluded some ZGC SA tests, because now we actually run with ZGC > when we ask for it. > > - JMapHeapConfigTest.java is broken when (jlong)-1 is passed in a > flag. This prevented ZGC from running, because we set MaxNewSize to > max size_t. Apparently, someone had already noticed this problem with > MaxMetaspaceSize and added this cryptic line: > // ignoring MaxMetaspaceSize > > I did the same for MaxNewSize and created a bug report. > > - There are two instances of LingeredApp. I fixed both and created an > enhancement to combine the two classes. > > - ClhsdbFlags.runAllTypesTest used to *append* getVmOptions(). This > started failing when I changed to getTestJavaOpts() because in some > configs we override some of the flags in the test. I fixed it by > *prepending* the getTestJavaOpts(). > > Tested with various tiers, but not on the absolute latest patch. Will > run this through more testing when the review is done. > > Thanks, > StefanK > > > > From larry.cable at oracle.com Tue Jan 21 16:36:45 2020 From: larry.cable at oracle.com (Laurence Cable) Date: Tue, 21 Jan 2020 08:36:45 -0800 Subject: jmx-dev RFR(S): 8234484: Add ability to configure third port for remote JMX In-Reply-To: <8fc616ec-4913-662c-6eba-6e6334801a46@oracle.com> References: <18fcf60c-b342-40c6-e97e-d00563566b9c@oracle.com> <135d431c-6f1a-999c-efc5-71ab106953ee@oracle.com> <8fc616ec-4913-662c-6eba-6e6334801a46@oracle.com> Message-ID: <168ab1b7-f5be-6ac6-7739-5f0b7e7cc671@oracle.com> I believe it needs to be documented. On 1/21/20 8:00 AM, Alan Bateman wrote: > On 21/01/2020 07:15, Yangfei (Felix) wrote: >> Hi Daniel, >> >> Thanks for reviewing the patch. Will do the push. >> > Is this a documented and supported property? I assume so, in which > case you should create a CSR. I think a Release-Note sub-task will > needed too so that it gets into at least the release notes. > > -Alan From chris.plummer at oracle.com Tue Jan 21 18:38:43 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 21 Jan 2020 10:38:43 -0800 Subject: RFR: 8235681: Remove unnecessary workarounds in UnixOperatingSystem.c In-Reply-To: References: Message-ID: <50ca82a7-8a5c-48c9-cb90-7c1d16f88b53@oracle.com> Hi Daniil, Do you think it's worth changing the check to an assert instead of removing it? Also, I'm not clear on the need for the *pkernelLoad initialization. It seems this is attempting to fix a different issue, but it's already initialized to 0 at the start of the function. thanks, Chris On 1/17/20 7:10 PM, Daniil Titov wrote: > Please review a change that removes unnecessary workaround in UnixOperatingSystem.c. > > It looks as this workaround > > if (pticks->usedKernel < tmp.usedKernel) { > kdiff = 0; > } > > was added to compensate a missed initialization of counters.jvmTicks that resulted in the new > counters being compared with the garbage when get_cpuload_internal(...) was called for the first time. > > This missed initialization was fixed in [3]. > > Mach5 tier1-tier3 and open/test/hotspot/jtreg/containers/docker tests successfully passed. > > [1] Webrev : http://cr.openjdk.java.net/~dtitov/8235681/webrev.01/ > [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8235681 > [3] https://bugs.openjdk.java.net/browse/JDK-8226575 > > Thank you, > Daniil > > From sgehwolf at redhat.com Tue Jan 21 19:30:08 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 21 Jan 2020 20:30:08 +0100 Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy In-Reply-To: References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com> <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com> <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com> <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com> <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com> Message-ID: <4a304e2ce72a53859b4e9cc8b21db404a260b531.camel@redhat.com> Hi Mandy, On Thu, 2020-01-16 at 17:43 -0800, Mandy Chung wrote: > Hi Bob, Severin, > > On 1/9/20 11:51 AM, Severin Gehwolf wrote: > > Thanks for the review! Should all be fixed now. Updated webrev: > > > > incremental: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/incremental/webrev/ > > full: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/07/webrev/ > > This patch may be more appropriate to be reviewed by the > serviceability group (cc'ed) as this is monitoring-related. > > jdk.internal.platform.Metrics is an internal API that you are free to > change the API as appropriate. Given that 13 out of 38 metrics > defined in Metrics are no longer supported by cgroups v2, it's > cleaner to refactor Metrics interface to be implementable by cgroups > v1 and v2 and then define a cgroups version-specific metrics to > extend Metrics, which means that it seems reasonable to make it > linux-only sub-interface. Client can cast to cgroup v1 metrics > interface if needed. Sorry for not chiming in earlier and I am not > following the cgroups v2 changes. This should be a straight-forward > change which will make the implementation cleaner. You would no > longer need the new *_UNLIMITED and *_NOT_SUPPORTED constants. Like this? Full: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/09/webrev/ incremental: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/09/incremental/webrev/ > A couple of quick comments when skimming on the new files: > CgroupSubsystemController.java > s/parm/param (including javadoc @param tag) > > CgroupInfo.java > cgroupPath is not used?? Should both be fixed, thanks! Thanks, Severin From mandy.chung at oracle.com Tue Jan 21 19:50:08 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 21 Jan 2020 11:50:08 -0800 Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy In-Reply-To: <4a304e2ce72a53859b4e9cc8b21db404a260b531.camel@redhat.com> References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com> <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com> <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com> <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com> <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com> <4a304e2ce72a53859b4e9cc8b21db404a260b531.camel@redhat.com> Message-ID: (offlist) quick question: is the spec change in Metrics still needed?? Will the common metrics be unavailable? On 1/21/20 11:30 AM, Severin Gehwolf wrote: > Full:http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/09/webrev/ > incremental:http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/09/incremental/webrev/ > >> A couple of quick comments when skimming on the new files: >> CgroupSubsystemController.java >> s/parm/param (including javadoc @param tag) >> >> CgroupInfo.java >> cgroupPath is not used?? > Should both be fixed, thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Tue Jan 21 19:52:06 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 21 Jan 2020 11:52:06 -0800 Subject: RFR: 8237111: LingeredApp should be started with getTestJavaOpts In-Reply-To: <020a9179-b7ba-45d3-5947-1b970301b602@oracle.com> References: <020a9179-b7ba-45d3-5947-1b970301b602@oracle.com> Message-ID: <241612c4-f587-e227-203e-f428b9074f6d@oracle.com> Hi Stefan, Can you explain the un-commenting of the code in JpsHelper.java? Copyrights need updating. Other than that it looks good. thanks, Chris On 1/21/20 6:58 AM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to change our usages of LingeredApp and > getVmOptions() to instead use getTestJavaOpts(). > > https://cr.openjdk.java.net/~stefank/8237111/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8237111 > > This issue was encountered by both Coleen and I, independently. > > We have two ways to pass JVM flags to jtreg. They come with different > names depending on the test layer (make, jtreg, test.lib etc): > > 1) Utils.getVmOptions(), -vmoptions, -Dtest.vm.options, VM_OPTIONS, ... > > ?Is passed to all JVMs (not only the one under test) > > 2) -javaoptions, -Dtest.java.options, JAVA_OPTIONS, TEST_JAVA_OPTS, ... > > ?Is passed to tested JVM > > The problem is that mach5 uses the latter to propagate JVM flags, so > when tests explicitly uses Utils.getVmOptions() they won't run with > the specified flags. > > The problem also arise if someone runs the following on the command line: > make -C ../build/fastdebug test > TEST=test/hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java > JTREG="JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+UseZGC" > > There's no Utils.getJavaOptions() function that fetches the (2) flags, > but there is a Utils.getTestJavaOpts() function that fetches flags > from both (1) and (2). > > The proposal is to stop using (and remove) Utils.getVmOptions() and > instead use Utils.getTestJavaOpts(). This patch touches more than > LingeredApp, so we should probably rename it. > > Some details about the patch: > - LingeredApp.startApp() now runs with getTestJavaOpts(). > > - getVmOptions() returned a List and getTestJavaOpts() returns > a String[]. I've adapted the code to use String[] instead. > > - Changed the parameter list of LingeredApp so that we could use > String..., and lower the amount of boiler plate code. > > - Removed Utils.getVmOptions() > > - Left Utils.getForwardVmOptions() for now, because replacing it > requires changes that needs to be reviewed on other lists. > > - Added appendTestJavaOpts and prependTestJavaOpts since the order is > important to tests. > > - Left addTestJavaOpts for now, because replacing it requires changes > that needs to be reviewed on other lists. > > - Excluded some ZGC SA tests, because now we actually run with ZGC > when we ask for it. > > - JMapHeapConfigTest.java is broken when (jlong)-1 is passed in a > flag. This prevented ZGC from running, because we set MaxNewSize to > max size_t. Apparently, someone had already noticed this problem with > MaxMetaspaceSize and added this cryptic line: > // ignoring MaxMetaspaceSize > > I did the same for MaxNewSize and created a bug report. > > - There are two instances of LingeredApp. I fixed both and created an > enhancement to combine the two classes. > > - ClhsdbFlags.runAllTypesTest used to *append* getVmOptions(). This > started failing when I changed to getTestJavaOpts() because in some > configs we override some of the flags in the test. I fixed it by > *prepending* the getTestJavaOpts(). > > Tested with various tiers, but not on the absolute latest patch. Will > run this through more testing when the review is done. > > Thanks, > StefanK > > > > From coleen.phillimore at oracle.com Tue Jan 21 21:01:11 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 21 Jan 2020 16:01:11 -0500 Subject: RFR: 8237111: LingeredApp should be started with getTestJavaOpts In-Reply-To: <7a31b62c-b7e2-8cb2-49dd-440d82b22154@oracle.com> References: <020a9179-b7ba-45d3-5947-1b970301b602@oracle.com> <7a31b62c-b7e2-8cb2-49dd-440d82b22154@oracle.com> Message-ID: Stefan, https://cr.openjdk.java.net/~stefank/8237111/webrev.01/test/hotspot/jtreg/serviceability/sa/TestInstanceKlassSizeForInterface.java.udiff.html Can you also change this line? - * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -Xbootclasspath/a:. TestInstanceKlassSize + * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -Xbootclasspath/a:. TestInstanceKlassSizeForInterface https://bugs.openjdk.java.net/browse/JDK-8237501 Thanks, Coleen On 1/21/20 11:33 AM, coleen.phillimore at oracle.com wrote: > > Hi Stefan, Thank you for cleaning this up!? I was expecting VM_OPTIONS > and TEST_VM_OPTS to go away also, but I guess they don't need to since > they are included in getJavaOpts(). > > The change for LingeredApp.startApp() to take a String[] is good. It > was awkward the way it was in TestInstanceKlassSize*.java. > > Maybe when resolving the duplication of LingeredApps, someone should > move the SA tests in only one place (I'll suggest it in your RFE). > > Thanks, > Coleen > > > On 1/21/20 9:58 AM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to change our usages of LingeredApp and >> getVmOptions() to instead use getTestJavaOpts(). >> >> https://cr.openjdk.java.net/~stefank/8237111/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8237111 >> >> This issue was encountered by both Coleen and I, independently. >> >> We have two ways to pass JVM flags to jtreg. They come with different >> names depending on the test layer (make, jtreg, test.lib etc): >> >> 1) Utils.getVmOptions(), -vmoptions, -Dtest.vm.options, VM_OPTIONS, ... >> >> ?Is passed to all JVMs (not only the one under test) >> >> 2) -javaoptions, -Dtest.java.options, JAVA_OPTIONS, TEST_JAVA_OPTS, ... >> >> ?Is passed to tested JVM >> >> The problem is that mach5 uses the latter to propagate JVM flags, so >> when tests explicitly uses Utils.getVmOptions() they won't run with >> the specified flags. >> >> The problem also arise if someone runs the following on the command >> line: >> make -C ../build/fastdebug test >> TEST=test/hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java >> JTREG="JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+UseZGC" >> >> There's no Utils.getJavaOptions() function that fetches the (2) >> flags, but there is a Utils.getTestJavaOpts() function that fetches >> flags from both (1) and (2). >> >> The proposal is to stop using (and remove) Utils.getVmOptions() and >> instead use Utils.getTestJavaOpts(). This patch touches more than >> LingeredApp, so we should probably rename it. >> >> Some details about the patch: >> - LingeredApp.startApp() now runs with getTestJavaOpts(). >> >> - getVmOptions() returned a List and getTestJavaOpts() >> returns a String[]. I've adapted the code to use String[] instead. >> >> - Changed the parameter list of LingeredApp so that we could use >> String..., and lower the amount of boiler plate code. >> >> - Removed Utils.getVmOptions() >> >> - Left Utils.getForwardVmOptions() for now, because replacing it >> requires changes that needs to be reviewed on other lists. >> >> - Added appendTestJavaOpts and prependTestJavaOpts since the order is >> important to tests. >> >> - Left addTestJavaOpts for now, because replacing it requires changes >> that needs to be reviewed on other lists. >> >> - Excluded some ZGC SA tests, because now we actually run with ZGC >> when we ask for it. >> >> - JMapHeapConfigTest.java is broken when (jlong)-1 is passed in a >> flag. This prevented ZGC from running, because we set MaxNewSize to >> max size_t. Apparently, someone had already noticed this problem with >> MaxMetaspaceSize and added this cryptic line: >> // ignoring MaxMetaspaceSize >> >> I did the same for MaxNewSize and created a bug report. >> >> - There are two instances of LingeredApp. I fixed both and created an >> enhancement to combine the two classes. >> >> - ClhsdbFlags.runAllTypesTest used to *append* getVmOptions(). This >> started failing when I changed to getTestJavaOpts() because in some >> configs we override some of the flags in the test. I fixed it by >> *prepending* the getTestJavaOpts(). >> >> Tested with various tiers, but not on the absolute latest patch. Will >> run this through more testing when the review is done. >> >> Thanks, >> StefanK >> >> >> >> > From david.holmes at oracle.com Tue Jan 21 23:04:08 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jan 2020 09:04:08 +1000 Subject: RFR 8235300: VM_HeapDumper hits assert with bad dump_len In-Reply-To: References: <7271C378-98AF-406A-8628-1A6ADDCF7A39@amazon.com> <75ab359d-e556-849d-1bda-eedd9e32c09d@oracle.com> <125C42A4-B2F5-4CCE-8864-043725C79DBF@amazon.com> Message-ID: Hi Paul, On 22/01/2020 1:34 am, Hohensee, Paul wrote: > Hi, David, > > Is it ok to put this CSR in Finalized state? Of course. Didn't realize you were expecting an ACK from me. Cheers, David > Thanks, > Paul > > ?On 1/15/20, 5:12 PM, "serviceability-dev on behalf of Hohensee, Paul" wrote: > > Thanks for your review and updates, David. I've updated the CSR as you requested in its comments. > > Paul > > On 1/14/20, 5:12 PM, "David Holmes" wrote: > > Hi Paul, > > I made some minor updates to the CSR request and added myself as a reviewer. > > Thanks, > David > > On 15/01/2020 10:00 am, Hohensee, Paul wrote: > > Please review this CSR for a backport of JDK-8144732 to jdk8u. > > > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8144732 > > > > JBS release note issue: https://bugs.openjdk.java.net/browse/JDK-8174881 > > > > 8u backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8235299 > > > > 8u backport CSR: https://bugs.openjdk.java.net/browse/JDK-8235300 > > > > The original patch went through the Oracle CCC process prior to the > > creation of the public CSR process, so there?s no public CSR issue, > > hence the release note JBS issue reference. > > > > Thanks, > > > > Paul > > > > > > From mandy.chung at oracle.com Wed Jan 22 00:09:06 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 21 Jan 2020 16:09:06 -0800 Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy In-Reply-To: <4a304e2ce72a53859b4e9cc8b21db404a260b531.camel@redhat.com> References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com> <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com> <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com> <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com> <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com> <4a304e2ce72a53859b4e9cc8b21db404a260b531.camel@redhat.com> Message-ID: <97e7ff2b-f2cc-a666-afb8-521c0f5c37e7@oracle.com> Hi Severin, Thanks for the update. On 1/21/20 11:30 AM, Severin Gehwolf wrote: > > Full: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/09/webrev/ > incremental: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8231111/09/incremental/webrev/ > I have answered my own question.?? Most of the metrics used to return 0 if unavailable due to IOException reading a file or malformed content and now are changed to return -2 due to error fetching the metric. The following are about limits which used to return -1 if unlimited or no limit set. ??? public long getCpuQuota(); ??? public long getCpuShares(); ??? public long getMemoryLimit(); ??? public long getMemoryAndSwapLimit(); ??? public long getMemorySoftLimit(); With this patch, only getMemoryLimit and getMemoryAndSwapLimit specify to return -1 if unlimited or no limit set.? However the implementation does return -1.? All of the above specify to return -2 if unavailable due to error fetching the metric. I found the implementation quite hard to follow.? I spent some time reviewing the code to see if the implementation matches the spec but I can't easily tell yet.? For example, CgroupSubsystemController::getLongValueMatchingLine returns -1 when IOException occurs. CgroupSubsystemController::getLongEntry returns 0L if IOException occurs. CgroupV1SubsystemController::convertStringToLong returns Long.MAX_VALUE when value overflows CgroupV2SubsystemController::convertStringToLong returns -1 when IOException occurs CgroupV1Subsystem::getCpuShares return -1 if cpu.shares == 0 or 1024 CgroupV2Subsystem::getCpuShares returns -1 if cpu.weight == 100 or 0 CgroupV2Subsystem::getFromCpuMax returns -1 if error in reading cpu.max or malformed content CgroupV2Subsystem::sumTokensIOStat returns -2 if IOException error This is called by getBlkIOServiceCount and getBlkIOServiced I think this can be improved and add the documentation to describe what the methods do. Since Metrics APIs consistently return -2 if unavailable due to error in fetching the metric, why some utility methods in *Subsystem and *SubsystemController return -1 upon error and 0 when unlimited? I suspect if the getXXXValue and other methods are clearly documented with the error cases (possibly renaming the method name if appropriate) CgroupV1Subsystem and CgroupV2SubSystem will become very explicit to understand. CgroupSubsystem.java 44 public static final double DOUBLE_RETVAL_NOT_SUPPORTED = LONG_RETVAL_NOT_SUPPORTED; 49 public static final Boolean BOOL_RETVAL_NOT_SUPPORTED = null; They are no longer needed, right? CgroupSubsystemFactory.java 89 System.err.println("Warning: Mixed cgroupv1 and cgroupv2 not supported. Metrics disabled."); I expect this be a System.Logger log 114 if (!Integer.valueOf(0).toString().equals(tokens[0])) { This can be simplified to if (!"0".equals(tokens[0])) LauncherHelper.java 407 // Extended cgroupv1 specific metrics 408 if (c instanceof MetricsCgroupV1) { 409 MetricsCgroupV1 cgroupV1 = (MetricsCgroupV1)c; 410 limit = cgroupV1.getKernelMemoryLimit(); 411 ostream.println(formatLimitString(limit, INDENT + "Kernel Memory Limit: ")); 412 limit = cgroupV1.getTcpMemoryLimit(); 413 ostream.println(formatLimitString(limit, INDENT + "TCP Memory Limit: ")); 414 Boolean value = cgroupV1.isMemoryOOMKillEnabled(); 415 ostream.println(formatBoolean(value, INDENT + "Out Of Memory Killer Enabled: ")); 416 value = cgroupV1.isCpuSetMemoryPressureEnabled(); 417 ostream.println(formatBoolean(value, INDENT + "CPUSet Memory Pressure Enabled: ")); 418 } MetricsCgroupV1 is linux-only. It will fail the compilation when building on non-linux. One option is to move this code to src/java.base/linux/share/sun/launcher/CgroupMetrics.java Are they continued to be interesting metrics to be output from -XshowSetting? I wonder if they can simply be dropped from the output. Bob will have an opinion. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From hohensee at amazon.com Wed Jan 22 00:38:42 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 22 Jan 2020 00:38:42 +0000 Subject: RFR 8235300: VM_HeapDumper hits assert with bad dump_len In-Reply-To: References: <7271C378-98AF-406A-8628-1A6ADDCF7A39@amazon.com> <75ab359d-e556-849d-1bda-eedd9e32c09d@oracle.com> <125C42A4-B2F5-4CCE-8864-043725C79DBF@amazon.com> Message-ID: <829A6533-AE4D-4882-829C-9856B12D9608@amazon.com> Thanks, David. Thought I needed a final review of the changes you asked for. :) ?On 1/21/20, 3:04 PM, "David Holmes" wrote: Hi Paul, On 22/01/2020 1:34 am, Hohensee, Paul wrote: > Hi, David, > > Is it ok to put this CSR in Finalized state? Of course. Didn't realize you were expecting an ACK from me. Cheers, David > Thanks, > Paul > > On 1/15/20, 5:12 PM, "serviceability-dev on behalf of Hohensee, Paul" wrote: > > Thanks for your review and updates, David. I've updated the CSR as you requested in its comments. > > Paul > > On 1/14/20, 5:12 PM, "David Holmes" wrote: > > Hi Paul, > > I made some minor updates to the CSR request and added myself as a reviewer. > > Thanks, > David > > On 15/01/2020 10:00 am, Hohensee, Paul wrote: > > Please review this CSR for a backport of JDK-8144732 to jdk8u. > > > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8144732 > > > > JBS release note issue: https://bugs.openjdk.java.net/browse/JDK-8174881 > > > > 8u backport JBS issue: https://bugs.openjdk.java.net/browse/JDK-8235299 > > > > 8u backport CSR: https://bugs.openjdk.java.net/browse/JDK-8235300 > > > > The original patch went through the Oracle CCC process prior to the > > creation of the public CSR process, so there?s no public CSR issue, > > hence the release note JBS issue reference. > > > > Thanks, > > > > Paul > > > > > > From david.holmes at oracle.com Wed Jan 22 04:28:25 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jan 2020 14:28:25 +1000 Subject: RFR: 8237111: LingeredApp should be started with getTestJavaOpts In-Reply-To: <020a9179-b7ba-45d3-5947-1b970301b602@oracle.com> References: <020a9179-b7ba-45d3-5947-1b970301b602@oracle.com> Message-ID: Hi Stefan, Thanks for tackling this. On 22/01/2020 12:58 am, Stefan Karlsson wrote: > Hi all, > > Please review this patch to change our usages of LingeredApp and > getVmOptions() to instead use getTestJavaOpts(). > > https://cr.openjdk.java.net/~stefank/8237111/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8237111 > > This issue was encountered by both Coleen and I, independently. > > We have two ways to pass JVM flags to jtreg. They come with different > names depending on the test layer (make, jtreg, test.lib etc): > > 1) Utils.getVmOptions(), -vmoptions, -Dtest.vm.options, VM_OPTIONS, ... > > ?Is passed to all JVMs (not only the one under test) > > 2) -javaoptions, -Dtest.java.options, JAVA_OPTIONS, TEST_JAVA_OPTS, ... > > ?Is passed to tested JVM > > The problem is that mach5 uses the latter to propagate JVM flags, so > when tests explicitly uses Utils.getVmOptions() they won't run with the > specified flags. > > The problem also arise if someone runs the following on the command line: > make -C ../build/fastdebug test > TEST=test/hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java > JTREG="JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+UseZGC" > > There's no Utils.getJavaOptions() function that fetches the (2) flags, > but there is a Utils.getTestJavaOpts() function that fetches flags from > both (1) and (2). There's some odd history here and the addition of getTestJavaOpts seemed to fly under the radar. It was reviewed by "sla" but I can only find the RFR request on serviceability-dev in Nov 2013, with no actual review. So the tests using getVmOptions have been broken for a very long time. :( > The proposal is to stop using (and remove) Utils.getVmOptions() and > instead use Utils.getTestJavaOpts(). This patch touches more than > LingeredApp, so we should probably rename it. Agreed - please change synopsis to be more encompassing. > Some details about the patch: > - LingeredApp.startApp() now runs with getTestJavaOpts(). Good. > - getVmOptions() returned a List and getTestJavaOpts() returns a > String[]. I've adapted the code to use String[] instead. Works for me, but many Java programmers tend to be fond of using Collections over arrays. This code originated in the JDK version of the test library. :) > - Changed the parameter list of LingeredApp so that we could use > String..., and lower the amount of boiler plate code. > > - Removed Utils.getVmOptions() Okay. The raw property values are still available if anyone actually wanted to use them for some reason. > - Left Utils.getForwardVmOptions() for now, because replacing it > requires changes that needs to be reviewed on other lists. Agreed - is there an open issue for this? (I also don't like the name of this method as it doesn't get the "forward VM options" is creates them.) > - Added appendTestJavaOpts and prependTestJavaOpts since the order is > important to tests. Hmmmm. I can't see any need for appendTestJavaOpts - none of the tests using it now actually need it versus prependTestJavaOpts. To use appendTestJavaOpts you have to know for certain that nothing in an incoming flag will interfere with the flags you are deliberately setting. Given "last flag wins" then you would "always" want the explicit per-test flags to come after the incoming flags. > - Left addTestJavaOpts for now, because replacing it requires changes > that needs to be reviewed on other lists. Okay. > - Excluded some ZGC SA tests, because now we actually run with ZGC when > we ask for it. Okay > - JMapHeapConfigTest.java is broken when (jlong)-1 is passed in a flag. > This prevented ZGC from running, because we set MaxNewSize to max > size_t. Apparently, someone had already noticed this problem with > MaxMetaspaceSize and added this cryptic line: > // ignoring MaxMetaspaceSize > > I did the same for MaxNewSize and created a bug report. Okay > - There are two instances of LingeredApp. I fixed both and created an > enhancement to combine the two classes. Okay > - ClhsdbFlags.runAllTypesTest used to *append* getVmOptions(). This > started failing when I changed to getTestJavaOpts() because in some > configs we override some of the flags in the test. I fixed it by > *prepending* the getTestJavaOpts(). Okay. This reinforces my point above :) > Tested with various tiers, but not on the absolute latest patch. Will > run this through more testing when the review is done. Other than the query on appendTestJavaOpts everything looks good. Thanks, David ----- > > Thanks, > StefanK > > > > From felix.yang at huawei.com Wed Jan 22 08:12:37 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 22 Jan 2020 08:12:37 +0000 Subject: jmx-dev RFR(S): 8234484: Add ability to configure third port for remote JMX In-Reply-To: <8fc616ec-4913-662c-6eba-6e6334801a46@oracle.com> References: <18fcf60c-b342-40c6-e97e-d00563566b9c@oracle.com> <135d431c-6f1a-999c-efc5-71ab106953ee@oracle.com> <8fc616ec-4913-662c-6eba-6e6334801a46@oracle.com> Message-ID: > On 21/01/2020 07:15, Yangfei (Felix) wrote: > > Hi Daniel, > > > > Thanks for reviewing the patch. Will do the push. > > > Is this a documented and supported property? I assume so, in which case you > should create a CSR. I think a Release-Note sub-task will needed too so that it > gets into at least the release notes. Hi, Thanks for reminding this. I have created a retroactive CSR for that: https://bugs.openjdk.java.net/browse/JDK-8237631 Larry Cable has added release-note label to indicate need for this addition to be mentioned in the release notes for 15. Please let me know if there are other things that I can help. Best regards, Felix From stefan.karlsson at oracle.com Wed Jan 22 08:41:47 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 22 Jan 2020 09:41:47 +0100 Subject: RFR: 8237111: LingeredApp should be started with getTestJavaOpts In-Reply-To: <241612c4-f587-e227-203e-f428b9074f6d@oracle.com> References: <020a9179-b7ba-45d3-5947-1b970301b602@oracle.com> <241612c4-f587-e227-203e-f428b9074f6d@oracle.com> Message-ID: <2a4e0a7e-d39c-5e77-e221-47c05705811e@oracle.com> Hi Chris, On 2020-01-21 20:52, Chris Plummer wrote: > Hi Stefan, > > Can you explain the un-commenting of the code in JpsHelper.java? The comment was not removed, but moved over to testVmArgs. The reason for the change is that I need getVmArgs() to return a String[] instead of List. So, I initialized testVmArgs with an array of the final sized, and then lazily initialize the runtime data. > > Copyrights need updating. > > Other than that it looks good. Thanks for reviewing, StefanK > > thanks, > > Chris > > On 1/21/20 6:58 AM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to change our usages of LingeredApp and >> getVmOptions() to instead use getTestJavaOpts(). >> >> https://cr.openjdk.java.net/~stefank/8237111/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8237111 >> >> This issue was encountered by both Coleen and I, independently. >> >> We have two ways to pass JVM flags to jtreg. They come with different >> names depending on the test layer (make, jtreg, test.lib etc): >> >> 1) Utils.getVmOptions(), -vmoptions, -Dtest.vm.options, VM_OPTIONS, ... >> >> ?Is passed to all JVMs (not only the one under test) >> >> 2) -javaoptions, -Dtest.java.options, JAVA_OPTIONS, TEST_JAVA_OPTS, ... >> >> ?Is passed to tested JVM >> >> The problem is that mach5 uses the latter to propagate JVM flags, so >> when tests explicitly uses Utils.getVmOptions() they won't run with >> the specified flags. >> >> The problem also arise if someone runs the following on the command line: >> make -C ../build/fastdebug test >> TEST=test/hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java >> JTREG="JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+UseZGC" >> >> There's no Utils.getJavaOptions() function that fetches the (2) flags, >> but there is a Utils.getTestJavaOpts() function that fetches flags >> from both (1) and (2). >> >> The proposal is to stop using (and remove) Utils.getVmOptions() and >> instead use Utils.getTestJavaOpts(). This patch touches more than >> LingeredApp, so we should probably rename it. >> >> Some details about the patch: >> - LingeredApp.startApp() now runs with getTestJavaOpts(). >> >> - getVmOptions() returned a List and getTestJavaOpts() returns >> a String[]. I've adapted the code to use String[] instead. >> >> - Changed the parameter list of LingeredApp so that we could use >> String..., and lower the amount of boiler plate code. >> >> - Removed Utils.getVmOptions() >> >> - Left Utils.getForwardVmOptions() for now, because replacing it >> requires changes that needs to be reviewed on other lists. >> >> - Added appendTestJavaOpts and prependTestJavaOpts since the order is >> important to tests. >> >> - Left addTestJavaOpts for now, because replacing it requires changes >> that needs to be reviewed on other lists. >> >> - Excluded some ZGC SA tests, because now we actually run with ZGC >> when we ask for it. >> >> - JMapHeapConfigTest.java is broken when (jlong)-1 is passed in a >> flag. This prevented ZGC from running, because we set MaxNewSize to >> max size_t. Apparently, someone had already noticed this problem with >> MaxMetaspaceSize and added this cryptic line: >> // ignoring MaxMetaspaceSize >> >> I did the same for MaxNewSize and created a bug report. >> >> - There are two instances of LingeredApp. I fixed both and created an >> enhancement to combine the two classes. >> >> - ClhsdbFlags.runAllTypesTest used to *append* getVmOptions(). This >> started failing when I changed to getTestJavaOpts() because in some >> configs we override some of the flags in the test. I fixed it by >> *prepending* the getTestJavaOpts(). >> >> Tested with various tiers, but not on the absolute latest patch. Will >> run this through more testing when the review is done. >> >> Thanks, >> StefanK >> >> >> >> > > From stefan.karlsson at oracle.com Wed Jan 22 08:58:02 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 22 Jan 2020 09:58:02 +0100 Subject: RFR: 8237111: LingeredApp should be started with getTestJavaOpts In-Reply-To: References: <020a9179-b7ba-45d3-5947-1b970301b602@oracle.com> Message-ID: <0039e43a-7763-eff4-cb94-c5600a688e89@oracle.com> Hi David, On 2020-01-22 05:28, David Holmes wrote: > Hi Stefan, > > Thanks for tackling this. > > On 22/01/2020 12:58 am, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to change our usages of LingeredApp and >> getVmOptions() to instead use getTestJavaOpts(). >> >> https://cr.openjdk.java.net/~stefank/8237111/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8237111 >> >> This issue was encountered by both Coleen and I, independently. >> >> We have two ways to pass JVM flags to jtreg. They come with different >> names depending on the test layer (make, jtreg, test.lib etc): >> >> 1) Utils.getVmOptions(), -vmoptions, -Dtest.vm.options, VM_OPTIONS, ... >> >> ??Is passed to all JVMs (not only the one under test) >> >> 2) -javaoptions, -Dtest.java.options, JAVA_OPTIONS, TEST_JAVA_OPTS, ... >> >> ??Is passed to tested JVM >> >> The problem is that mach5 uses the latter to propagate JVM flags, so >> when tests explicitly uses Utils.getVmOptions() they won't run with >> the specified flags. >> >> The problem also arise if someone runs the following on the command line: >> make -C ../build/fastdebug test >> TEST=test/hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java >> JTREG="JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+UseZGC" >> >> There's no Utils.getJavaOptions() function that fetches the (2) flags, >> but there is a Utils.getTestJavaOpts() function that fetches flags >> from both (1) and (2). > > There's some odd history here and the addition of getTestJavaOpts seemed > to fly under the radar. It was reviewed by "sla" but I can only find the > RFR request on serviceability-dev in Nov 2013, with no actual review. So > the tests using getVmOptions have been broken for a very long time. :( > >> The proposal is to stop using (and remove) Utils.getVmOptions() and >> instead use Utils.getTestJavaOpts(). This patch touches more than >> LingeredApp, so we should probably rename it. > > Agreed - please change synopsis to be more encompassing. > >> Some details about the patch: >> - LingeredApp.startApp() now runs with getTestJavaOpts(). > > Good. > >> - getVmOptions() returned a List and getTestJavaOpts() returns >> a String[]. I've adapted the code to use String[] instead. > > Works for me, but many Java programmers tend to be fond of using > Collections over arrays. This code originated in the JDK version of the > test library. :) I actually started changing the code to only use List, but that change was much larger and reaching into non-hotspot/svc domains. The tests that today is using getTestJavaOpts() are already adapted to work with String[]. I don't mind if this were changed to List. > >> - Changed the parameter list of LingeredApp so that we could use >> String..., and lower the amount of boiler plate code. >> >> - Removed Utils.getVmOptions() > > Okay. The raw property values are still available if anyone actually > wanted to use them for some reason. > >> - Left Utils.getForwardVmOptions() for now, because replacing it >> requires changes that needs to be reviewed on other lists. > > Agreed - is there an open issue for this? (I also don't like the name of > this method as it doesn't get the "forward VM options" is creates them.) I created a placeholder RFR: JDK-8237634. I think they meant forward from launcher to JVM. If we figure out a better name, we change change it with JDK-8237634. > >> - Added appendTestJavaOpts and prependTestJavaOpts since the order is >> important to tests. > > Hmmmm. I can't see any need for appendTestJavaOpts - none of the tests > using it now actually need it versus prependTestJavaOpts. To use > appendTestJavaOpts you have to know for certain that nothing in an > incoming flag will interfere with the flags you are deliberately > setting. Given "last flag wins" then you would "always" want the > explicit per-test flags to come after the incoming flags. That could be the case, but I don't want to change the current order of flags and risk braking something. Seems like an easy fix to change this as a separate RFE. > >> - Left addTestJavaOpts for now, because replacing it requires changes >> that needs to be reviewed on other lists. > > Okay. > >> - Excluded some ZGC SA tests, because now we actually run with ZGC >> when we ask for it. > > Okay > >> - JMapHeapConfigTest.java is broken when (jlong)-1 is passed in a >> flag. This prevented ZGC from running, because we set MaxNewSize to >> max size_t. Apparently, someone had already noticed this problem with >> MaxMetaspaceSize and added this cryptic line: >> // ignoring MaxMetaspaceSize >> >> I did the same for MaxNewSize and created a bug report. > > Okay > >> - There are two instances of LingeredApp. I fixed both and created an >> enhancement to combine the two classes. > > Okay > >> - ClhsdbFlags.runAllTypesTest used to *append* getVmOptions(). This >> started failing when I changed to getTestJavaOpts() because in some >> configs we override some of the flags in the test. I fixed it by >> *prepending* the getTestJavaOpts(). > > Okay. This reinforces my point above :) > >> Tested with various tiers, but not on the absolute latest patch. Will >> run this through more testing when the review is done. > > Other than the query on appendTestJavaOpts everything looks good. Thanks David. Would you accept it if I created a follow-up RFR to investigate if we could change order of the combined flags? StefanK > > Thanks, > David > ----- > >> >> Thanks, >> StefanK >> >> >> >> From david.holmes at oracle.com Wed Jan 22 09:50:49 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Jan 2020 19:50:49 +1000 Subject: RFR: 8237111: LingeredApp should be started with getTestJavaOpts In-Reply-To: <0039e43a-7763-eff4-cb94-c5600a688e89@oracle.com> References: <020a9179-b7ba-45d3-5947-1b970301b602@oracle.com> <0039e43a-7763-eff4-cb94-c5600a688e89@oracle.com> Message-ID: Hi Stefan, > Thanks David. Would you accept it if I created a follow-up RFR to investigate if we could change order of the combined flags? Sure, no problem. Thanks, David On 22/01/2020 6:58 pm, Stefan Karlsson wrote: > Hi David, > > On 2020-01-22 05:28, David Holmes wrote: >> Hi Stefan, >> >> Thanks for tackling this. >> >> On 22/01/2020 12:58 am, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this patch to change our usages of LingeredApp and >>> getVmOptions() to instead use getTestJavaOpts(). >>> >>> https://cr.openjdk.java.net/~stefank/8237111/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8237111 >>> >>> This issue was encountered by both Coleen and I, independently. >>> >>> We have two ways to pass JVM flags to jtreg. They come with different >>> names depending on the test layer (make, jtreg, test.lib etc): >>> >>> 1) Utils.getVmOptions(), -vmoptions, -Dtest.vm.options, VM_OPTIONS, ... >>> >>> ??Is passed to all JVMs (not only the one under test) >>> >>> 2) -javaoptions, -Dtest.java.options, JAVA_OPTIONS, TEST_JAVA_OPTS, ... >>> >>> ??Is passed to tested JVM >>> >>> The problem is that mach5 uses the latter to propagate JVM flags, so >>> when tests explicitly uses Utils.getVmOptions() they won't run with >>> the specified flags. >>> >>> The problem also arise if someone runs the following on the command >>> line: >>> make -C ../build/fastdebug test >>> TEST=test/hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java >>> JTREG="JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+UseZGC" >>> >>> There's no Utils.getJavaOptions() function that fetches the (2) >>> flags, but there is a Utils.getTestJavaOpts() function that fetches >>> flags from both (1) and (2). >> >> There's some odd history here and the addition of getTestJavaOpts >> seemed to fly under the radar. It was reviewed by "sla" but I can only >> find the RFR request on serviceability-dev in Nov 2013, with no actual >> review. So the tests using getVmOptions have been broken for a very >> long time. :( >> >>> The proposal is to stop using (and remove) Utils.getVmOptions() and >>> instead use Utils.getTestJavaOpts(). This patch touches more than >>> LingeredApp, so we should probably rename it. >> >> Agreed - please change synopsis to be more encompassing. >> >>> Some details about the patch: >>> - LingeredApp.startApp() now runs with getTestJavaOpts(). >> >> Good. >> >>> - getVmOptions() returned a List and getTestJavaOpts() >>> returns a String[]. I've adapted the code to use String[] instead. >> >> Works for me, but many Java programmers tend to be fond of using >> Collections over arrays. This code originated in the JDK version of >> the test library. :) > > I actually started changing the code to only use List, but that > change was much larger and reaching into non-hotspot/svc domains. The > tests that today is using getTestJavaOpts() are already adapted to work > with String[]. > > I don't mind if this were changed to List. > >> >>> - Changed the parameter list of LingeredApp so that we could use >>> String..., and lower the amount of boiler plate code. >>> >>> - Removed Utils.getVmOptions() >> >> Okay. The raw property values are still available if anyone actually >> wanted to use them for some reason. >> >>> - Left Utils.getForwardVmOptions() for now, because replacing it >>> requires changes that needs to be reviewed on other lists. >> >> Agreed - is there an open issue for this? (I also don't like the name >> of this method as it doesn't get the "forward VM options" is creates >> them.) > > I created a placeholder RFR: JDK-8237634. > > I think they meant forward from launcher to JVM. If we figure out a > better name, we change change it with JDK-8237634. > >> >>> - Added appendTestJavaOpts and prependTestJavaOpts since the order is >>> important to tests. >> >> Hmmmm. I can't see any need for appendTestJavaOpts - none of the tests >> using it now actually need it versus prependTestJavaOpts. To use >> appendTestJavaOpts you have to know for certain that nothing in an >> incoming flag will interfere with the flags you are deliberately >> setting. Given "last flag wins" then you would "always" want the >> explicit per-test flags to come after the incoming flags. > > That could be the case, but I don't want to change the current order of > flags and risk braking something. Seems like an easy fix to change this > as a separate RFE. > >> >>> - Left addTestJavaOpts for now, because replacing it requires changes >>> that needs to be reviewed on other lists. >> >> Okay. >> >>> - Excluded some ZGC SA tests, because now we actually run with ZGC >>> when we ask for it. >> >> Okay >> >>> - JMapHeapConfigTest.java is broken when (jlong)-1 is passed in a >>> flag. This prevented ZGC from running, because we set MaxNewSize to >>> max size_t. Apparently, someone had already noticed this problem with >>> MaxMetaspaceSize and added this cryptic line: >>> // ignoring MaxMetaspaceSize >>> >>> I did the same for MaxNewSize and created a bug report. >> >> Okay >> >>> - There are two instances of LingeredApp. I fixed both and created an >>> enhancement to combine the two classes. >> >> Okay >> >>> - ClhsdbFlags.runAllTypesTest used to *append* getVmOptions(). This >>> started failing when I changed to getTestJavaOpts() because in some >>> configs we override some of the flags in the test. I fixed it by >>> *prepending* the getTestJavaOpts(). >> >> Okay. This reinforces my point above :) >> >>> Tested with various tiers, but not on the absolute latest patch. Will >>> run this through more testing when the review is done. >> >> Other than the query on appendTestJavaOpts everything looks good. > > Thanks David. Would you accept it if I created a follow-up RFR to > investigate if we could change order of the combined flags? > > StefanK > >> >> Thanks, >> David >> ----- >> >>> >>> Thanks, >>> StefanK >>> >>> >>> >>> From sgehwolf at redhat.com Wed Jan 22 09:53:46 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 22 Jan 2020 10:53:46 +0100 Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy In-Reply-To: <97e7ff2b-f2cc-a666-afb8-521c0f5c37e7@oracle.com> References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com> <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com> <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com> <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com> <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com> <4a304e2ce72a53859b4e9cc8b21db404a260b531.camel@redhat.com> <97e7ff2b-f2cc-a666-afb8-521c0f5c37e7@oracle.com> Message-ID: Hi Mandy, Thanks again for the review! I'll be sure to fix things. Some of the issues you've pointed out probably pre-existed in old code. Some became more complicated since unlimited in cgroupv1 is a large long value in files. Anyway, I'll update it. On Tue, 2020-01-21 at 16:09 -0800, Mandy Chung wrote: > MetricsCgroupV1 is linux-only. It will fail the compilation when > building on non-linux. I don't think so. MetricsCgroupV1 is a new interface in shared code just like Metrics itself: src/java.base/share/classes/jdk/internal/platform/MetricsCgroupV1.java I've put it there for the exact reason to NOT break compilation on non- Linux. We could call it ExtendedMetrics or something, though. Pondered that for a bit, but it wasn't important enough so I've kept it. > One option is to move this code to > src/java.base/linux/share/sun/launcher/CgroupMetrics.java Not sure if that would help. MetricsCgropuV1 is being used in LauncherHelper.java which itself is available on all platforms, no? > Are they continued to be interesting metrics to be output from > -XshowSetting? I wonder if they can simply be dropped from the output. > Bob will have an opinion. I think they are. At least it prints the same metrics as were printed before this patch on cgroupv1. What's the rationale of not printing them any longer? My premise was, they were useful before and they continue to be useful. For cgroupv2 they're not configurable so they're not printed (and not useful as they'd show up as N/A anyway). Thanks, Severin From stefan.karlsson at oracle.com Wed Jan 22 10:20:19 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 22 Jan 2020 11:20:19 +0100 Subject: RFR: 8237111: LingeredApp should be started with getTestJavaOpts In-Reply-To: References: <020a9179-b7ba-45d3-5947-1b970301b602@oracle.com> <0039e43a-7763-eff4-cb94-c5600a688e89@oracle.com> Message-ID: <26a564d9-6d93-c420-3c84-abbf07f089ec@oracle.com> Thanks. Created JDK-8237639. StefanK On 2020-01-22 10:50, David Holmes wrote: > Hi Stefan, > >> Thanks David. Would you accept it if I created a follow-up RFR to >> investigate if we could change order of the combined flags? > > Sure, no problem. > > Thanks, > David > > On 22/01/2020 6:58 pm, Stefan Karlsson wrote: >> Hi David, >> >> On 2020-01-22 05:28, David Holmes wrote: >>> Hi Stefan, >>> >>> Thanks for tackling this. >>> >>> On 22/01/2020 12:58 am, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Please review this patch to change our usages of LingeredApp and >>>> getVmOptions() to instead use getTestJavaOpts(). >>>> >>>> https://cr.openjdk.java.net/~stefank/8237111/webrev.01/ >>>> https://bugs.openjdk.java.net/browse/JDK-8237111 >>>> >>>> This issue was encountered by both Coleen and I, independently. >>>> >>>> We have two ways to pass JVM flags to jtreg. They come with >>>> different names depending on the test layer (make, jtreg, test.lib >>>> etc): >>>> >>>> 1) Utils.getVmOptions(), -vmoptions, -Dtest.vm.options, VM_OPTIONS, ... >>>> >>>> ??Is passed to all JVMs (not only the one under test) >>>> >>>> 2) -javaoptions, -Dtest.java.options, JAVA_OPTIONS, TEST_JAVA_OPTS, ... >>>> >>>> ??Is passed to tested JVM >>>> >>>> The problem is that mach5 uses the latter to propagate JVM flags, so >>>> when tests explicitly uses Utils.getVmOptions() they won't run with >>>> the specified flags. >>>> >>>> The problem also arise if someone runs the following on the command >>>> line: >>>> make -C ../build/fastdebug test >>>> TEST=test/hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java >>>> JTREG="JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+UseZGC" >>>> >>>> There's no Utils.getJavaOptions() function that fetches the (2) >>>> flags, but there is a Utils.getTestJavaOpts() function that fetches >>>> flags from both (1) and (2). >>> >>> There's some odd history here and the addition of getTestJavaOpts >>> seemed to fly under the radar. It was reviewed by "sla" but I can >>> only find the RFR request on serviceability-dev in Nov 2013, with no >>> actual review. So the tests using getVmOptions have been broken for a >>> very long time. :( >>> >>>> The proposal is to stop using (and remove) Utils.getVmOptions() and >>>> instead use Utils.getTestJavaOpts(). This patch touches more than >>>> LingeredApp, so we should probably rename it. >>> >>> Agreed - please change synopsis to be more encompassing. >>> >>>> Some details about the patch: >>>> - LingeredApp.startApp() now runs with getTestJavaOpts(). >>> >>> Good. >>> >>>> - getVmOptions() returned a List and getTestJavaOpts() >>>> returns a String[]. I've adapted the code to use String[] instead. >>> >>> Works for me, but many Java programmers tend to be fond of using >>> Collections over arrays. This code originated in the JDK version of >>> the test library. :) >> >> I actually started changing the code to only use List, but >> that change was much larger and reaching into non-hotspot/svc domains. >> The tests that today is using getTestJavaOpts() are already adapted to >> work with String[]. >> >> I don't mind if this were changed to List. >> >>> >>>> - Changed the parameter list of LingeredApp so that we could use >>>> String..., and lower the amount of boiler plate code. >>>> >>>> - Removed Utils.getVmOptions() >>> >>> Okay. The raw property values are still available if anyone actually >>> wanted to use them for some reason. >>> >>>> - Left Utils.getForwardVmOptions() for now, because replacing it >>>> requires changes that needs to be reviewed on other lists. >>> >>> Agreed - is there an open issue for this? (I also don't like the name >>> of this method as it doesn't get the "forward VM options" is creates >>> them.) >> >> I created a placeholder RFR: JDK-8237634. >> >> I think they meant forward from launcher to JVM. If we figure out a >> better name, we change change it with JDK-8237634. >> >>> >>>> - Added appendTestJavaOpts and prependTestJavaOpts since the order >>>> is important to tests. >>> >>> Hmmmm. I can't see any need for appendTestJavaOpts - none of the >>> tests using it now actually need it versus prependTestJavaOpts. To >>> use appendTestJavaOpts you have to know for certain that nothing in >>> an incoming flag will interfere with the flags you are deliberately >>> setting. Given "last flag wins" then you would "always" want the >>> explicit per-test flags to come after the incoming flags. >> >> That could be the case, but I don't want to change the current order >> of flags and risk braking something. Seems like an easy fix to change >> this as a separate RFE. >> >>> >>>> - Left addTestJavaOpts for now, because replacing it requires >>>> changes that needs to be reviewed on other lists. >>> >>> Okay. >>> >>>> - Excluded some ZGC SA tests, because now we actually run with ZGC >>>> when we ask for it. >>> >>> Okay >>> >>>> - JMapHeapConfigTest.java is broken when (jlong)-1 is passed in a >>>> flag. This prevented ZGC from running, because we set MaxNewSize to >>>> max size_t. Apparently, someone had already noticed this problem >>>> with MaxMetaspaceSize and added this cryptic line: >>>> // ignoring MaxMetaspaceSize >>>> >>>> I did the same for MaxNewSize and created a bug report. >>> >>> Okay >>> >>>> - There are two instances of LingeredApp. I fixed both and created >>>> an enhancement to combine the two classes. >>> >>> Okay >>> >>>> - ClhsdbFlags.runAllTypesTest used to *append* getVmOptions(). This >>>> started failing when I changed to getTestJavaOpts() because in some >>>> configs we override some of the flags in the test. I fixed it by >>>> *prepending* the getTestJavaOpts(). >>> >>> Okay. This reinforces my point above :) >>> >>>> Tested with various tiers, but not on the absolute latest patch. >>>> Will run this through more testing when the review is done. >>> >>> Other than the query on appendTestJavaOpts everything looks good. >> >> Thanks David. Would you accept it if I created a follow-up RFR to >> investigate if we could change order of the combined flags? >> >> StefanK >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> >>>> Thanks, >>>> StefanK >>>> >>>> >>>> >>>> From rkennke at redhat.com Wed Jan 22 16:05:17 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 22 Jan 2020 17:05:17 +0100 Subject: RFR: 8227269: Slow class loading when running JVM in debug mode In-Reply-To: <14de19af-7146-969e-2a21-80ed40d175fb@oracle.com> References: <8870829e-c558-c956-2184-00204632abb6@redhat.com> <743135a7-cade-34ee-6485-1c174376d7bd@oracle.com> <20e507f7-0e6e-43a8-be0b-ea7ba6a6edcb@redhat.com> <48dad0bc-fbdf-08eb-4bdf-f8220742035d@redhat.com> <805d3200-2f12-922a-b6d6-78381c9a9d2b@redhat.com> <14de19af-7146-969e-2a21-80ed40d175fb@oracle.com> Message-ID: <13f27bc5-8f69-7b11-830c-fb08eaa80528@redhat.com> Hi Serguei, Thanks for reviewing! I updated the patch to reflect your suggestions, very good! It also includes a fix to allow re-connecting an agent after disconnect, namely move setup of the trackingEnv and deletedSignatureBag to _activate() to ensure have those structures after re-connect. http://cr.openjdk.java.net/~rkennke/JDK-8227269/webrev.05/ Let me know what you think! Roman > Hi Roman, > > Thank you for taking care about this scalability issue! > > I have a couple of quick comments. > > http://cr.openjdk.java.net/~rkennke/JDK-8227269/webrev.04/src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c.frames.html > > 72 /* > 73 * Lock to protect deletedSignatureBag > 74 */ > 75 static jrawMonitorID deletedSignatureLock; 76 77 /* > 78 * A bag containing all the deleted classes' signatures. Must be > accessed under > 79 * deletedTagLock, > 80 */ > 81 struct bag* deletedSignatureBag; > > ? The comments contradict to each other. > ? I guess, the lock name at line 79 has to be deletedSignatureLock > instead of deletedTagLock. > ? Also, comma at the end must be replaced with dot. > > > 101 // Tag not found? Ignore. > 102 if (klass == NULL) { > 103 debugMonitorExit(deletedSignatureLock); > 104 return; > 105 } > 106 > 107 // Scan linked-list. > 108 jlong found_tag = klass->klass_tag; > 109 while (klass != NULL && found_tag != tag) { > 110 klass_ptr = &klass->next; > 111 klass = *klass_ptr; > 112 found_tag = klass->klass_tag; > 113 } > 114 > 115 // Tag not found? Ignore. > 116 if (found_tag != tag) { > 117 debugMonitorExit(deletedSignatureLock); > 118 return; > 119 } > > > ?The code above can be simplified, so that the lines 101-105 are not > needed anymore. > ?It can be something like this: > > // Scan linked-list. > while (klass != NULL && klass->klass_tag != tag) { > klass_ptr = &klass->next; > klass = *klass_ptr; > } > if (klass == NULL || klass->klass_tag != tag) { // klass not found - ignore. > debugMonitorExit(deletedSignatureLock); > return; > } > > It will take more time when I get a chance to look at the rest. > > > Thanks, > Serguei > > > > > On 12/21/19 13:24, Roman Kennke wrote: >> Here comes an update that resolves some races that happen when >> disconnecting an agent. In particular, we need to take the lock on >> basically every operation, and also need to check whether or not >> class-tracking is active and return an appropriate result (e.g. an empty >> list) when we're not. >> >> Updated webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8227269/webrev.04/ >> >> Thanks, >> Roman >> >> >>> So, here comes the O(1) implementation: >>> >>> - Whenever a class is 'prepared', it is registered with a tag, and we >>> set-up a listener to get notified when it is unloaded. >>> - Prepared classes are kept in a datastructure that is a table, which >>> each entry being the head of a linked-list of KlassNode*. The table is >>> indexed by tag % slot-count, and then simply prepend the new KlassNode*. >>> This is O(1) operation. >>> - When we get notified of unloading a class, we look up the signature of >>> the reported tag in that table, and remember it in a bag. The KlassNode* >>> is then unlinked from the table and deallocated. This is ~O(1) operation >>> too, depending on the depth of the table. In my testcase which hammered >>> the code with class-loads and unloads, I usually see depths of like 2-3, >>> but not usually more. It should be ok. >>> - when processUnloads() gets called, we simply hand out that bag, and >>> allocate a new one. >>> - I also added cleanup-code in classTrack_reset() to avoid leaking the >>> signatures and KlassNode* etc when debug agent gets detached and/or >>> re-attached (was missing before). >>> - I also added locks around data-structure-manipulation (was missing >>> before). >>> - Also, I only activate this whole process when an actual listener gets >>> registered on EI_GC_FINISH. This seems to happen right when attaching a >>> jdb, not sure why jdb does that though. This may be something to improve >>> in the future? >>> >>> In my tests, the performance of class-tracking itself looks really good. >>> The bottleneck now is clearly actual synthesizing the class-unload >>> events. I don't see how this can be helped when the debug agent asks for it? >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~rkennke/JDK-8227269/webrev.03/ >>> >>> Please let me know what you think of it. >>> >>> Thanks, >>> Roman >>> >>> >>>> Alright, the perfectionist in me got me. I am implementing the even more >>>> efficient ~O(1) class tracking. Please hold off reviewing for now. >>>> >>>> Thanks,Roman >>>> >>>> Hi Chris, >>>>>> I'll have a look at this, although it might not be for a few days. In >>>>>> the meantime, maybe you can describe your new implementation in >>>>>> classTrack.c so it's easier to look through the changes. >>>>> Sure. >>>>> >>>>> The purpose of this class-tracking is to be able to determine the >>>>> signatures of unloaded classes when GC/class-unloading happened, so that >>>>> we can generate the appropriate JDWP event. >>>>> >>>>> The current implementation does so by maintaining a table of currently >>>>> prepared classes by building that table when classTrack is initialized, >>>>> and then add new classes whenever a class gets loaded. When unloading >>>>> occurs, that cache is rebuilt into a new table, and compared with the >>>>> old table, and whatever is in the old, but not in the new table gets >>>>> returned. The problem is that when GCs happen frequently and/or many >>>>> classes get loaded+unloaded, this amounts to O(classCount*gcCount) >>>>> complexity. >>>>> >>>>> The new implementation keeps a linked-list of prepared classes, and also >>>>> tracks unloads via the listener cbTrackingObjectFree(). Whenever an >>>>> unload/GC occurs, the list of prepared classes is scanned, and classes >>>>> that are also in the deletedTagBag are unlinked (thus maintaining the >>>>> prepared-classes-list) and its signature put in the list that gets returned. >>>>> >>>>> The implementation is not perfect. In order to determine whether or not >>>>> a class is unloaded, it needs to scan the deletedTagBag. That process is >>>>> therefore still O(unloadedClassCount). The assumption here is that >>>>> unloadedClassCount << classCount. In my experiments this seems to be >>>>> true, and also reasonable to expect. >>>>> >>>>> (I have some ideas how to improve the implementation to ~O(1) but it >>>>> would be considerably more complex: have to maintain a (hash)table that >>>>> maps tags -> KlassNode*, unlink them directly upon unload, and build the >>>>> unloaded-signatures list there, but I don't currently see that it's >>>>> worth the effort). >>>>> >>>>> In addition to all that, this process is only activated when there's an >>>>> actual listener registered for EI_GC_FINISH. >>>>> >>>>> Thanks, >>>>> Roman >>>>> >>>>> >>>>>> Chris >>>>>> >>>>>> On 12/18/19 5:05 AM, Roman Kennke wrote: >>>>>>> Hello all, >>>>>>> >>>>>>> Issue: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8227269 >>>>>>> >>>>>>> I am proposing what amounts to a rewrite of classTrack.c. It avoids >>>>>>> throwing away the class cache on GC, and instead keeps track of >>>>>>> loaded/unloaded classes one-by-one. >>>>>>> >>>>>>> In addition to that, it avoids this whole dance until an agent >>>>>>> registers interest in EI_GC_FINISH. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8227269/webrev.01/ >>>>>>> >>>>>>> Testing: manual testing of provided test scenarios and timing. >>>>>>> >>>>>>> Eg with the testcase provided here: >>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1751985 >>>>>>> >>>>>>> I am getting those numbers: >>>>>>> unpatched: no debug: 84s with debug: 225s >>>>>>> patched:?? no debug: 85s with debug: 95s >>>>>>> >>>>>>> I also tested successfully through jdk/submit repo >>>>>>> >>>>>>> Can I please get a review? >>>>>>> >>>>>>> Thanks, >>>>>>> Roman >>>>>>> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From mandy.chung at oracle.com Wed Jan 22 16:06:16 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 22 Jan 2020 08:06:16 -0800 Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy In-Reply-To: References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com> <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com> <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com> <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com> <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com> <4a304e2ce72a53859b4e9cc8b21db404a260b531.camel@redhat.com> <97e7ff2b-f2cc-a666-afb8-521c0f5c37e7@oracle.com> Message-ID: On 1/22/20 1:53 AM, Severin Gehwolf wrote: > Hi Mandy, > > Thanks again for the review! I'll be sure to fix things. Some of the > issues you've pointed out probably pre-existed in old code. Some became > more complicated since unlimited in cgroupv1 is a large long value in > files. Anyway, I'll update it. Thank you. > On Tue, 2020-01-21 at 16:09 -0800, Mandy Chung wrote: >> MetricsCgroupV1 is linux-only. It will fail the compilation when >> building on non-linux. > I don't think so. MetricsCgroupV1 is a new interface in shared code > just like Metrics itself: > src/java.base/share/classes/jdk/internal/platform/MetricsCgroupV1.java Ah, I mis-read that was placed under src/java.base/linux/classes. OK. > I've put it there for the exact reason to NOT break compilation on non- > Linux. We could call it ExtendedMetrics or something, though. Pondered > that for a bit, but it wasn't important enough so I've kept it. >> One option is to move this code to >> src/java.base/linux/share/sun/launcher/CgroupMetrics.java > Not sure if that would help. MetricsCgropuV1 is being used in > LauncherHelper.java which itself is available on all platforms, no? -XshowSettings:system is a linux-only option. >> Are they continued to be interesting metrics to be output from >> -XshowSetting? I wonder if they can simply be dropped from the output. >> Bob will have an opinion. > I think they are. At least it prints the same metrics as were printed > before this patch on cgroupv1. What's the rationale of not printing > them any longer? My premise was, they were useful before and they > continue to be useful. For cgroupv2 they're not configurable so they're > not printed (and not useful as they'd show up as N/A anyway). Bob can advice on the usefulness of these metrics.??? I have no objection to print them on cgroup v1.? On v2,? they are not shown (not even N/A, right?) Mandy From bob.vandette at oracle.com Wed Jan 22 16:19:07 2020 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 22 Jan 2020 11:19:07 -0500 Subject: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy In-Reply-To: References: <75fc377f8d5ca76b7dac02f55db640cbdd305633.camel@redhat.com> <4bf65380bc26cd3bf684d7994b33e66bcb87927b.camel@redhat.com> <6CACCC0D-7F5A-42A3-83F1-746497940CCA@oracle.com> <29544339574e34c4c25cbec0314c26f35e8d1a99.camel@redhat.com> <4CE7C7F6-ABFA-4263-98B2-32BBD5013A3C@oracle.com> <10b5e83bfb7e618e5f5906c8e707057ff8680785.camel@redhat.com> <4a304e2ce72a53859b4e9cc8b21db404a260b531.camel@redhat.com> <97e7ff2b-f2cc-a666-afb8-521c0f5c37e7@oracle.com> Message-ID: <80051010-726E-4349-9C65-4804A27E6F5E@oracle.com> > On Jan 22, 2020, at 11:06 AM, Mandy Chung wrote: > > > > On 1/22/20 1:53 AM, Severin Gehwolf wrote: >> Hi Mandy, >> >> Thanks again for the review! I'll be sure to fix things. Some of the >> issues you've pointed out probably pre-existed in old code. Some became >> more complicated since unlimited in cgroupv1 is a large long value in >> files. Anyway, I'll update it. > > Thank you. >> On Tue, 2020-01-21 at 16:09 -0800, Mandy Chung wrote: >>> MetricsCgroupV1 is linux-only. It will fail the compilation when >>> building on non-linux. >> I don't think so. MetricsCgroupV1 is a new interface in shared code >> just like Metrics itself: >> src/java.base/share/classes/jdk/internal/platform/MetricsCgroupV1.java > > Ah, I mis-read that was placed under src/java.base/linux/classes. OK. >> I've put it there for the exact reason to NOT break compilation on non- >> Linux. We could call it ExtendedMetrics or something, though. Pondered >> that for a bit, but it wasn't important enough so I've kept it. >>> One option is to move this code to >>> src/java.base/linux/share/sun/launcher/CgroupMetrics.java >> Not sure if that would help. MetricsCgropuV1 is being used in >> LauncherHelper.java which itself is available on all platforms, no? > > -XshowSettings:system is a linux-only option. >>> Are they continued to be interesting metrics to be output from >>> -XshowSetting? I wonder if they can simply be dropped from the output. >>> Bob will have an opinion. >> I think they are. At least it prints the same metrics as were printed >> before this patch on cgroupv1. What's the rationale of not printing >> them any longer? My premise was, they were useful before and they >> continue to be useful. For cgroupv2 they're not configurable so they're >> not printed (and not useful as they'd show up as N/A anyway). > > Bob can advice on the usefulness of these metrics. I have no objection to print them on cgroup v1. On v2, they are not shown (not even N/A, right?) These metrics are not that useful in the -XshowSettings context. I?d just drop them from the output. Bob. > > Mandy From alexey.menkov at oracle.com Wed Jan 22 19:11:08 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 22 Jan 2020 11:11:08 -0800 Subject: RFR(M): 8236913: debug agent's jdwp command logging should include the command set name and command name In-Reply-To: References: <7fc3d946-14c7-d796-c1f6-610cfce177a7@oracle.com> <9cca7543-d647-5737-6de4-56e07f9831e4@oracle.com> Message-ID: <6f0c2237-8f53-c44e-9ff0-541261c9d7bf@oracle.com> LGTM --alex On 01/16/2020 11:41, Chris Plummer wrote: > Hi, > > Here's a new webrev: > > http://cr.openjdk.java.net/~cjplummer/8236913/webrev.01/ > > Since the last webrev: > ?- debugDispatch.c is and the header files (other than debugDispatch.h) > are unchanged other > ?? than renaming from XXX_Cmds to XXX_CmdSets > ?- debugDispatch.h has a minor change to CommandSet.cmds to make it a > pointer type, > ?? and added the DEBUG_DISPATCH_DEFINE_CMDSET macro > > Command sets are now defined using the following form: > > ??? Command ArrayReference_Commands[] = { > ? ?? ?? {length, "Length"}, > ? ?? ?? {getValues, "GetValues"}, > ? ? ? ? {setValues, "SetValues"} > ??? }; > > ??? DEBUG_DISPATCH_DEFINE_CMDSET(ArrayReference) > > There is no need to specify the size of the array anymore. > DEBUG_DISPATCH_DEFINE_CMDSET in its expanded form would be: > > CommandSet ArrayReference_Commands_CmdSet = { > ??? sizeof(ArrayReference_Commands) / sizeof(Command), > ? ? "ArrayReference", > ??? ArrayReference_Commands > }; > > Since there are 4 references to ArrayReference, plus the size > calculation, I thought it was worth using a macro here. I considered > also passing the initialization of the Commands array as an argument, > but I dislike macros that take code as an argument, and I didn't see as > much value in it. I could still be persuaded though if you think it's a > good idea. > > I had to special case FieldImpl because it is zero length. When I > discovered the Solaris issues, I also found out that Windows didn't like > initializing an empty array. At the time I fixed it by adding a {NULL, > NULL} entry, but eventually decided to just special case it, especially > since I would no longer be able to cheat and say the array was length 0 > even though it had an entry. > > thanks, > > Chris > > On 1/15/20 2:31 PM, Chris Plummer wrote: >> Didn't think of that. It should work because it's a static array, not >> a static struct with an embedded array. I'll give it a try. I should >> also be able to use sizeof() rather than hard code the size. >> >> thanks, >> >> Chris >> >> On 1/15/20 2:05 PM, Alex Menkov wrote: >>> Hi Chris, >>> >>> I'd prefer to not separate command handlers and names. >>> >>> maybe something like >>> >>> static Command ArrayReference_Commands[] = { >>> ??? {length, "Length"}, >>> ??? {getValues, "GetValues"}, >>> ??? {setValues, "SetValues"} >>> }; >>> >>> CommandSet ArrayReference_CommandSet = { >>> ??? 3, "ArrayReference", &ArrayReference_Commands >>> }; >>> >>> --alex >>> >>> On 01/15/2020 13:09, Chris Plummer wrote: >>>> Hi, >>>> >>>> Unfortunately I'm going to have to redo this fix. I ran into >>>> compilation problems on Solaris: >>>> >>>> error: too many struct/union initializers >>>> (E_TOO_MANY_STRUCT_UNION_INIT) >>>> >>>> This turns up on the first initializer of the cmds[] array: >>>> >>>> CommandSet ArrayReference_Cmds = { >>>> ???? 3, "ArrayReference", >>>> ???? { >>>> ???????? {length, "Length"},?? <---------- >>>> ???????? {getValues, "GetValues"}, >>>> ???????? {setValues, "SetValues"} >>>> ???? } >>>> }; >>>> >>>> It turns out that statically initializing a variable length array >>>> that is a field of a struct is not valid C syntax. You can >>>> statically initialize a variable length array, which is what the >>>> code was originally doing, but not a variable length array within a >>>> struct. >>>> >>>> I can fix this issue by giving the array a fixed size. For example: >>>> >>>> typedef struct CommandSet { >>>> ???? int num_cmds; >>>> ???? const char *cmd_set_name; >>>> ???? const Command cmds[20]; >>>> } CommandSet; >>>> >>>> The catch here is that the array size needs to be at least as big as >>>> the largest use, and for all the other static uses extra space will >>>> be allocated but never used. In other words, all the arrays would be >>>> size 20, even those that initialize fewer than 20 elements. >>>> >>>> So the choice here pretty much keep what I have, but waste some >>>> space with the fixed array size, or use parallel arrays to store the >>>> function pointers and command names separately. We used to have: >>>> >>>> void *ArrayReference_Cmds[] = { (void *)0x3 >>>> ???? ,(void *)length >>>> ???? ,(void *)getValues >>>> ???? ,(void *)setValues}; >>>> >>>> I could just keep this as-is and add: >>>> >>>> char *ArrayReference_CmdNames[] = { >>>> ???? "Length", >>>> ???? "GetValues", >>>> ???? "SetValues" >>>> }; >>>> >>>> A further improvement might be to change to original array to be: >>>> >>>> const CommandHandler ArrayReference_Cmds[] = { >>>> ???? length, >>>> ???? getValues, >>>> ???? setValues >>>> }; >>>> >>>> And then I can add a #define for the array size: >>>> >>>> #define ArrayReference_NumCmds (sizeof(ArrayReference_Cmds) / >>>> sizeof(CommandHandler)) >>>> >>>> char *ArrayReference_CmdNames[ArrayReference_NumCmds] = { >>>> ???? "Length", >>>> ???? "GetValues", >>>> ???? "SetValues" >>>> }; >>>> >>>> Then I can either access these arrays in parallel, meaning instead of: >>>> >>>> ???? cmdSetsArray[JDWP_COMMAND_SET(ArrayReference)] = >>>> &ArrayReference_Cmds; >>>> >>>> I would have (not I need an array for the sizes also for the second >>>> option abov): >>>> >>>> ???? cmdSetsCmdsArraySize[JDWP_COMMAND_SET(ArrayReference)] = >>>> ArrayReference_NumCmds; >>>> ???? cmdSetsCmdsArray[JDWP_COMMAND_SET(ArrayReference)] = >>>> &ArrayReference_Cmds; >>>> ???? cmdSetsCmdNamesArray[JDWP_COMMAND_SET(ArrayReference)] = >>>> &ArrayReference_CmdNames; >>>> >>>> Or I could change the CommandSet definition to be: >>>> >>>> typedef struct CommandSet { >>>> ???? int num_cmds; >>>> ???? const char *cmd_set_name; >>>> ???? CommandHandler cmd_handler[]; >>>> ???? const char *cmd_name[]; >>>> } CommandSet; >>>> >>>> And then add: >>>> >>>> const CommandSet ArrayReference_CommandSet = { >>>> ???? ArrayReference_NumCmds, >>>> ???? "ArrayReference", >>>> ???? &ArrayReference_Cmds, >>>> ???? &ArrayReference_CmdNames >>>> } >>>> >>>> Then I would just have the array of CommandSets rather than 3 arrays >>>> to deal with. >>>> >>>> Lasty, I could use a macro that declares a new type for each >>>> CommandSet, and then when the array of CommandSets is initialized, I >>>> would cast that type to a CommandSet. I think the invocation of the >>>> macro would look something like: >>>> >>>> DEFINE_COMMAND_SET (3, ArrayReference, >>>> ???????? {length, "Length"}, >>>> ???????? {getValues, "GetValues"}, >>>> ???????? {setValues, "SetValues"} >>>> ) >>>> >>>> However, I'm a bit unsure of this since I haven't made any attempt >>>> to implement it yet. There might be more issues that pop up with >>>> this one, where-as doing the parallel arrays is pretty straight >>>> forward (although not pretty). >>>> >>>> thoughts? >>>> >>>> Chris >>>> >>>> >>>> On 1/10/20 11:27 AM, Chris Plummer wrote: >>>>> Hello, >>>>> >>>>> Please review the following >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8236913 >>>>> http://cr.openjdk.java.net/~cjplummer/8236913/webrev.00/ >>>>> >>>>> The debug agent has logging support that will trace all jdwp >>>>> commands coming in. Currently all it traces is the command set >>>>> number and the command number within that command set. So you see >>>>> something like: >>>>> >>>>> [#|10.01.2020 06:27:24.366 >>>>> GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command >>>>> set 1, command 9|#] >>>>> >>>>> I've added support for including the name of the command set and >>>>> command, so now you see: >>>>> >>>>> [#|10.01.2020 06:27:24.366 >>>>> GMT|FINEST|J2SE1.5|jdwp|LOC=MISC:"debugLoop.c":240;;PID=12719;THR=t at 915490560|:Command >>>>> set VirtualMachine(1), command Resume(9)|#] >>>>> >>>>> So in this case command set 1 represents VirtualMachine and command >>>>> 9 is the Resume command. >>>>> >>>>> I was initially going to leverage jdwp.spec which is already >>>>> processed by build.tools.jdwpgen.Main to produce JDWP.java and >>>>> JDWPCommands.h. However, I could see it was more of a challenge >>>>> than I initially hoped. Also, the main advantage would have been >>>>> not having to hard code arrays of command names, but we already >>>>> have harded coded arrays of function pointers to handle the various >>>>> jdwp commands, so I just replaced these with a more specialized >>>>> arrays that also include the names of the commands. As an example, >>>>> we used to have: >>>>> >>>>> void *ArrayReference_Cmds[] = { (void *)0x3 >>>>> ??? ,(void *)length >>>>> ??? ,(void *)getValues >>>>> ??? ,(void *)setValues}; >>>>> >>>>> Now we have: >>>>> >>>>> CommandSet ArrayReference_Cmds = { >>>>> ??? 3, "ArrayReference", >>>>> ??? { >>>>> ??????? {length, "Length"}, >>>>> ??????? {getValues, "GetValues"}, >>>>> ??????? {setValues, "SetValues"} >>>>> ??? } >>>>> }; >>>>> >>>>> So no worse w.r.t. hard coding things that could be generated off >>>>> the spec, and it cleans up some ugly casts also. The CommandSet >>>>> typedef can be found in debugDispatch.h. >>>>> >>>>> All the header files except for debugDispatch.h have the same >>>>> pattern for changes, so they are pretty easy to review >>>>> >>>>> All .c files except debugDispatch.c and debugLoop.c also have the >>>>> same pattern. Note some command handler function names are not the >>>>> same as the command name. If you want to double check command set >>>>> names and command names, you can find the spec here: >>>>> >>>>> https://docs.oracle.com/javase/9/docs/specs/jdwp/jdwp-protocol.html >>>>> >>>>> In ReferenceTypeImpl.c I fixed a typo in the method() prototype. It >>>>> had an extra argument which I think was a very old copy-n-paste bug >>>>> from the method1() prototype. This was caught because the command >>>>> handler functions are now directly assigned to a CommandHandler >>>>> type rather than cast. The cast was hiding this bug. >>>>> >>>>> I tested by doing a test run where MISC logging was enabled by >>>>> default. All jdwp, jdb, and jdi tests were run in this way and passed. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>> >>>> >> >> > > From alexey.menkov at oracle.com Wed Jan 22 20:23:47 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 22 Jan 2020 12:23:47 -0800 Subject: PING: RFR: JDK-8235846: Improve WindbgDebuggerLocal implementation In-Reply-To: References: <8ca073bf-0f82-46d5-7fd1-0a5b5757bfa4@oracle.com> <6ed9a23f-3ba4-cbf2-8156-26b4e3731eeb@oracle.com> <2bac872a-e538-83e9-1448-dcd788de2cee@oracle.com> <2a7a52f8-aaea-2124-faaf-d371d8bcbb8e@oracle.com> <364eb89e-4811-a3b6-67c8-0c26e8776816@oracle.com> Message-ID: Hi Chris, On 01/17/2020 14:36, Chris Plummer wrote: > Hi Alex, > > I assume that the following: > > ? 65?? operator T* () const { > ? 66???? return m_ptr; > ? 67?? } > > Is used here: > > ?183?????? AutoArrayPtr errmsg(new char[strlen(str) + 32]); \ > ?184?????? if (errmsg == nullptr) { \ > > I just don't understand how this works. Somehow it seems the "T*" > operator applies to the "errmsg" reference here. This is a use of C++ > operators I'm not familiar with. Can you please explain. Yes, you are right. errmsg is an object and nullptr is a pointer, so compiler tries to find a way to cast types. This cast operator is the only way to cast errmsg to pointer (char *), so compiler uses it. You can read more about cast operators: https://en.cppreference.com/w/cpp/language/cast_operator They are quite convenient. > Why is the following not placed at the end if the "if" block: > > ?299?? AddRef(); > ?300?? return S_OK; > > The following was removed. It's not clear to me why it was and what the > impact is: > > ?283?? ptrIDebugOutputCallbacks->AddRef(); I updated COM object implementation (SAOutputCallbacks) to follow "standard way". - standard implementation for QueryInterface looks like *ppInterface = nullptr; if (IsEqualIID(interfaceId, __uuidof(IUnknown)) || IsEqualIID(interfaceId, __uuidof(MyInterface1))) { *ppInterface = static_cast(this); } else if (IsEqualIID(interfaceId, __uuidof(MyInterface2))) { *ppInterface = static_cast(this); } else if (IsEqualIID(interfaceId, __uuidof(MyInterface3))) { *ppInterface = static_cast(this); ... } else { return E_NOINTERFACE; } AddRef(); return S_OK; } - standard handling of ref. counter sets it to 1 during object creation (so callers don't have to call AddRef after each creation) So I did: - SAOutputCallbacks() : m_refCount(0), m_msgBuffer(0) { + SAOutputCallbacks() : m_refCount(1), m_msgBuffer(nullptr) { and removed unnecessary AddRef: SAOutputCallbacks* ptrIDebugOutputCallbacks = new SAOutputCallbacks(); - ptrIDebugOutputCallbacks->AddRef(); --alex > > thanks, > > Chris > > On 1/17/20 10:37 AM, Alex Menkov wrote: >> Need 2nd reviewer. >> >> --alex >> >> On 01/14/2020 13:10, serguei.spitsyn at oracle.com wrote: >>> Hi Alex, >>> >>> Thank you for the update! >>> It looks good. >>> >>> Still incorrect indent: >>> >>> 103 ~AutoJavaString() { 104 if (m_buf) { 105 >>> m_env->ReleaseStringUTFChars(m_str, m_buf); 106 } 107 } 108 109 >>> operator const char* () const { 110 return m_buf; 111 } ... 133 void >>> setReleaseMode(jint mode) { >>> 134 releaseMode = mode; >>> 135 } >>> 136 >>> 137 operator jbyte* () const { >>> 138 return bytePtr; >>> 139 } >>> >>> The comment shout start from a capital letter: >>> >>> 177 // verifies COM call result is S_OK, throws DebuggerException and >>> exits otherwise. >>> >>> >>> No need for another webrev. >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 1/14/20 12:39 PM, Alex Menkov wrote: >>>> Hi Serguei, >>>> >>>> Thank you for the review. >>>> updated webrev: >>>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.02/ >>>> >>>> On 01/13/2020 16:39, serguei.spitsyn at oracle.com wrote: >>>>> Hi Alex, >>>>> >>>>> It looks pretty good. >>>>> Just some minor comments below. >>>>> >>>>> The class AutoCOMPtr has unfixed indents. >>>>> I guess, the function AutoArrayPtr.asPtr() is not used anymore and >>>>> can be deleted. >>>> >>>> fixed. >>>> >>>>> >>>>> I'd suggest to remove first level '()' brackets in the comment to >>>>> avoid brackets nesting: 74 // manage COM 'auto' pointers (to avoid >>>>> multiple Release 75 // calls at every early (exception) returns). >>>>> => 74 // manage COM 'auto' pointers to avoid multiple Release >>>>> 75 // calls at every early (exception) returns. >>>> >>>> done. >>>> >>>>> I'd suggest to reformat it as it was originally formatted: >>>>> >>>>> 297 if (IsEqualIID(interfaceId, __uuidof(IUnknown)) >>>>> 298 || IsEqualIID(interfaceId, __uuidof(IDebugOutputCallbacks))) { >>>>> => 297 if (IsEqualIID(interfaceId, __uuidof(IUnknown))? || >>>>> 298 IsEqualIID(interfaceId, __uuidof(IDebugOutputCallbacks))) { >>>> >>>> done. >>>> >>>>> The comment about S_FALSE is not that clear as S_FALSE is not >>>>> really used >>>>> (better to use consistently just one value: S_FALSE or false): >>>>> >>>>> 418 // S_FALSE means timeout >>>>> 419 >>>>> COM_VERIFY_OK_(ptrIDebugControl->WaitForEvent(DEBUG_WAIT_DEFAULT, >>>>> INFINITE), >>>>> 420 "Windbg Error: WaitForEvent failed!", false); >>>> >>>> S_FALSE is a possible result of ptrIDebugControl->WaitForEvent call. >>>> In the case we wait infinitely, so S_FALSE is not possible and we >>>> don't handle it separately. >>>> I removed the comment. >>>> >>>> >>>>> NULL is used in some placesand nullptr in others. >>>> >>>> There is some mess with 0/NULL/nullptr in the file >>>> I fixed all NULLs and some (most likely not all) 0s. >>>> BTW it immediately discovered misuse of NULL/0: >>>> >>>> -? if (ptrIDebugSymbols->GetModuleParameters(loaded, 0, NULL, >>>> params.asPtr()) != S_OK) { >>>> -???? THROW_NEW_DEBUGGER_EXCEPTION_("Windbg Error: >>>> GetModuleParameters failed!", false); >>>> -? } >>>> + COM_VERIFY_OK_(ptrIDebugSymbols->GetModuleParameters(loaded, >>>> nullptr, 0, params), >>>> +???????????????? "Windbg Error: GetModuleParameters failed!", false); >>>> >>>> 2nd arg of GetModuleParameters is a pointer and 3rd is ulong >>>> >>>> --alex >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 12/19/19 15:34, Alex Menkov wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review a fix for >>>>>> https://bugs.openjdk.java.net/browse/JDK-8235846 >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.01/ >>>>>> >>>>>> Main goal of the change is to improve error reporting (we have >>>>>> several bugs and need at least COM error codes for WinDbg calls). >>>>>> Also the fix improves/rearranges this quite old code. >>>>>> >>>>>> --alex >>>>> >>> > > From daniil.x.titov at oracle.com Wed Jan 22 23:30:12 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 22 Jan 2020 15:30:12 -0800 Subject: RFR: 8235681: Remove unnecessary workarounds in UnixOperatingSystem.c In-Reply-To: <50ca82a7-8a5c-48c9-cb90-7c1d16f88b53@oracle.com> References: <50ca82a7-8a5c-48c9-cb90-7c1d16f88b53@oracle.com> Message-ID: Hi Chris, Please review a new version of the fix [1] that converts the check to the assert. > Also, I'm not clear on the need for the *pkernelLoad initialization. It > seems this is attempting to fix a different issue, but it's already > initialized to 0 at the start of the function. You are right, *pkernelLoad is already initialized on line 251. The new version of the webrev does not include this change. [1] Webrev: http://cr.openjdk.java.net/~dtitov/8235681/webrev.02/ [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8235681 Thank you, Daniil ?On 1/21/20, 10:38 AM, "Chris Plummer" wrote: Hi Daniil, Do you think it's worth changing the check to an assert instead of removing it? Also, I'm not clear on the need for the *pkernelLoad initialization. It seems this is attempting to fix a different issue, but it's already initialized to 0 at the start of the function. thanks, Chris On 1/17/20 7:10 PM, Daniil Titov wrote: > Please review a change that removes unnecessary workaround in UnixOperatingSystem.c. > > It looks as this workaround > > if (pticks->usedKernel < tmp.usedKernel) { > kdiff = 0; > } > > was added to compensate a missed initialization of counters.jvmTicks that resulted in the new > counters being compared with the garbage when get_cpuload_internal(...) was called for the first time. > > This missed initialization was fixed in [3]. > > Mach5 tier1-tier3 and open/test/hotspot/jtreg/containers/docker tests successfully passed. > > [1] Webrev : http://cr.openjdk.java.net/~dtitov/8235681/webrev.01/ > [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8235681 > [3] https://bugs.openjdk.java.net/browse/JDK-8226575 > > Thank you, > Daniil > > From chris.plummer at oracle.com Thu Jan 23 03:02:59 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 22 Jan 2020 19:02:59 -0800 Subject: RFR: 8235681: Remove unnecessary workarounds in UnixOperatingSystem.c In-Reply-To: References: <50ca82a7-8a5c-48c9-cb90-7c1d16f88b53@oracle.com> Message-ID: <1ce5fdb5-a1da-0ce2-b6dc-50fb1953c592@oracle.com> Looks good. Chris On 1/22/20 3:30 PM, Daniil Titov wrote: > Hi Chris, > > Please review a new version of the fix [1] that converts the check to the assert. > >> Also, I'm not clear on the need for the *pkernelLoad initialization. It >> seems this is attempting to fix a different issue, but it's already >> initialized to 0 at the start of the function. > You are right, *pkernelLoad is already initialized on line 251. The new version of > the webrev does not include this change. > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8235681/webrev.02/ > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8235681 > > Thank you, > Daniil > > ?On 1/21/20, 10:38 AM, "Chris Plummer" wrote: > > Hi Daniil, > > Do you think it's worth changing the check to an assert instead of > removing it? > > Also, I'm not clear on the need for the *pkernelLoad initialization. It > seems this is attempting to fix a different issue, but it's already > initialized to 0 at the start of the function. > > thanks, > > Chris > > On 1/17/20 7:10 PM, Daniil Titov wrote: > > Please review a change that removes unnecessary workaround in UnixOperatingSystem.c. > > > > It looks as this workaround > > > > if (pticks->usedKernel < tmp.usedKernel) { > > kdiff = 0; > > } > > > > was added to compensate a missed initialization of counters.jvmTicks that resulted in the new > > counters being compared with the garbage when get_cpuload_internal(...) was called for the first time. > > > > This missed initialization was fixed in [3]. > > > > Mach5 tier1-tier3 and open/test/hotspot/jtreg/containers/docker tests successfully passed. > > > > [1] Webrev : http://cr.openjdk.java.net/~dtitov/8235681/webrev.01/ > > [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8235681 > > [3] https://bugs.openjdk.java.net/browse/JDK-8226575 > > > > Thank you, > > Daniil > > > > > > > > From chris.plummer at oracle.com Thu Jan 23 03:21:30 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 22 Jan 2020 19:21:30 -0800 Subject: PING: RFR: JDK-8235846: Improve WindbgDebuggerLocal implementation In-Reply-To: References: <8ca073bf-0f82-46d5-7fd1-0a5b5757bfa4@oracle.com> <6ed9a23f-3ba4-cbf2-8156-26b4e3731eeb@oracle.com> <2bac872a-e538-83e9-1448-dcd788de2cee@oracle.com> <2a7a52f8-aaea-2124-faaf-d371d8bcbb8e@oracle.com> <364eb89e-4811-a3b6-67c8-0c26e8776816@oracle.com> Message-ID: <27dbbdf8-c312-fc17-fe11-7da9f743f8c0@oracle.com> On 1/22/20 12:23 PM, Alex Menkov wrote: > Hi Chris, > > On 01/17/2020 14:36, Chris Plummer wrote: >> Hi Alex, >> >> I assume that the following: >> >> ?? 65?? operator T* () const { >> ?? 66???? return m_ptr; >> ?? 67?? } >> >> Is used here: >> >> ??183?????? AutoArrayPtr errmsg(new char[strlen(str) + 32]); \ >> ??184?????? if (errmsg == nullptr) { \ >> >> I just don't understand how this works. Somehow it seems the "T*" >> operator applies to the "errmsg" reference here. This is a use of C++ >> operators I'm not familiar with. Can you please explain. > > Yes, you are right. > errmsg is an object and nullptr is a pointer, so compiler tries to > find a way to cast types. > This cast operator is the only way to cast errmsg to pointer (char *), > so compiler uses it. > You can read more about cast operators: > https://en.cppreference.com/w/cpp/language/cast_operator > They are quite convenient. Ok. This is probably acceptable C++, but TBH not something I really care for. It's confusing to someone who is not fluent in this use of cast operators. It reads funny to me because you have a local variable that is an instance of an object (not a pointer to an object), yet are comparing it to null. > >> Why is the following not placed at the end if the "if" block: >> >> ??299?? AddRef(); >> ??300?? return S_OK; >> >> The following was removed. It's not clear to me why it was and what >> the impact is: >> >> ??283?? ptrIDebugOutputCallbacks->AddRef(); > > I updated COM object implementation (SAOutputCallbacks) to follow > "standard way". > - standard implementation for QueryInterface looks like > > ? *ppInterface = nullptr; > ? if (IsEqualIID(interfaceId, __uuidof(IUnknown)) || > ??????? IsEqualIID(interfaceId, __uuidof(MyInterface1))) { > ??? *ppInterface = static_cast(this); > ? } else if (IsEqualIID(interfaceId, __uuidof(MyInterface2))) { > ??? *ppInterface = static_cast(this); > ? } else if (IsEqualIID(interfaceId, __uuidof(MyInterface3))) { > ??? *ppInterface = static_cast(this); > ... > ? } else { > ??? return E_NOINTERFACE; > ? } > ? AddRef(); > ? return S_OK; > } > I'm not sure what standard you are referring to. The only other uses of E_NOINTERFACE I see are 5 uses in awt that all put the AddRef() in the if/else blocks, not outside. Can you please explain what this standard is? thanks Chris > - standard handling of ref. counter sets it to 1 during object > creation (so callers don't have to call AddRef after each creation) > So I did: > -? SAOutputCallbacks() : m_refCount(0), m_msgBuffer(0) { > +? SAOutputCallbacks() : m_refCount(1), m_msgBuffer(nullptr) { > > and removed unnecessary AddRef: > ?? SAOutputCallbacks* ptrIDebugOutputCallbacks = new SAOutputCallbacks(); > -? ptrIDebugOutputCallbacks->AddRef(); > > > --alex > >> >> thanks, >> >> Chris >> >> On 1/17/20 10:37 AM, Alex Menkov wrote: >>> Need 2nd reviewer. >>> >>> --alex >>> >>> On 01/14/2020 13:10, serguei.spitsyn at oracle.com wrote: >>>> Hi Alex, >>>> >>>> Thank you for the update! >>>> It looks good. >>>> >>>> Still incorrect indent: >>>> >>>> 103 ~AutoJavaString() { 104 if (m_buf) { 105 >>>> m_env->ReleaseStringUTFChars(m_str, m_buf); 106 } 107 } 108 109 >>>> operator const char* () const { 110 return m_buf; 111 } ... 133 >>>> void setReleaseMode(jint mode) { >>>> 134 releaseMode = mode; >>>> 135 } >>>> 136 >>>> 137 operator jbyte* () const { >>>> 138 return bytePtr; >>>> 139 } >>>> >>>> The comment shout start from a capital letter: >>>> >>>> 177 // verifies COM call result is S_OK, throws DebuggerException >>>> and exits otherwise. >>>> >>>> >>>> No need for another webrev. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 1/14/20 12:39 PM, Alex Menkov wrote: >>>>> Hi Serguei, >>>>> >>>>> Thank you for the review. >>>>> updated webrev: >>>>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.02/ >>>>> >>>>> On 01/13/2020 16:39, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Alex, >>>>>> >>>>>> It looks pretty good. >>>>>> Just some minor comments below. >>>>>> >>>>>> The class AutoCOMPtr has unfixed indents. >>>>>> I guess, the function AutoArrayPtr.asPtr() is not used anymore >>>>>> and can be deleted. >>>>> >>>>> fixed. >>>>> >>>>>> >>>>>> I'd suggest to remove first level '()' brackets in the comment to >>>>>> avoid brackets nesting: 74 // manage COM 'auto' pointers (to >>>>>> avoid multiple Release 75 // calls at every early (exception) >>>>>> returns). => 74 // manage COM 'auto' pointers to avoid multiple >>>>>> Release >>>>>> 75 // calls at every early (exception) returns. >>>>> >>>>> done. >>>>> >>>>>> I'd suggest to reformat it as it was originally formatted: >>>>>> >>>>>> 297 if (IsEqualIID(interfaceId, __uuidof(IUnknown)) >>>>>> 298 || IsEqualIID(interfaceId, __uuidof(IDebugOutputCallbacks))) >>>>>> { => 297 if (IsEqualIID(interfaceId, __uuidof(IUnknown))? || >>>>>> 298 IsEqualIID(interfaceId, __uuidof(IDebugOutputCallbacks))) { >>>>> >>>>> done. >>>>> >>>>>> The comment about S_FALSE is not that clear as S_FALSE is not >>>>>> really used >>>>>> (better to use consistently just one value: S_FALSE or false): >>>>>> >>>>>> 418 // S_FALSE means timeout >>>>>> 419 >>>>>> COM_VERIFY_OK_(ptrIDebugControl->WaitForEvent(DEBUG_WAIT_DEFAULT, >>>>>> INFINITE), >>>>>> 420 "Windbg Error: WaitForEvent failed!", false); >>>>> >>>>> S_FALSE is a possible result of ptrIDebugControl->WaitForEvent call. >>>>> In the case we wait infinitely, so S_FALSE is not possible and we >>>>> don't handle it separately. >>>>> I removed the comment. >>>>> >>>>> >>>>>> NULL is used in some placesand nullptr in others. >>>>> >>>>> There is some mess with 0/NULL/nullptr in the file >>>>> I fixed all NULLs and some (most likely not all) 0s. >>>>> BTW it immediately discovered misuse of NULL/0: >>>>> >>>>> -? if (ptrIDebugSymbols->GetModuleParameters(loaded, 0, NULL, >>>>> params.asPtr()) != S_OK) { >>>>> -???? THROW_NEW_DEBUGGER_EXCEPTION_("Windbg Error: >>>>> GetModuleParameters failed!", false); >>>>> -? } >>>>> + COM_VERIFY_OK_(ptrIDebugSymbols->GetModuleParameters(loaded, >>>>> nullptr, 0, params), >>>>> +???????????????? "Windbg Error: GetModuleParameters failed!", >>>>> false); >>>>> >>>>> 2nd arg of GetModuleParameters is a pointer and 3rd is ulong >>>>> >>>>> --alex >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 12/19/19 15:34, Alex Menkov wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review a fix for >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8235846 >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.01/ >>>>>>> >>>>>>> Main goal of the change is to improve error reporting (we have >>>>>>> several bugs and need at least COM error codes for WinDbg calls). >>>>>>> Also the fix improves/rearranges this quite old code. >>>>>>> >>>>>>> --alex >>>>>> >>>> >> >> From thomas.stuefe at gmail.com Thu Jan 23 08:36:48 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 23 Jan 2020 09:36:48 +0100 Subject: RFR (M) 8234510: Remove file seeking requirement for writing a heap dump In-Reply-To: References: Message-ID: Hi Ralf, belated, but looks good to me. Thanks, Thomas On Mon, Dec 16, 2019 at 1:28 PM Schmelter, Ralf wrote: > I forgot to post the updated webrev: > http://cr.openjdk.java.net/~rschmelter/webrevs/8234510/webrev.2/ > > In addition to the changes requested by Thomas, I also renamed the entries > in the heap dump segment from entries to sub-records, since that is what > they are called in the comment describing the format. > > Best regards, > Ralf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Thu Jan 23 19:21:13 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 23 Jan 2020 11:21:13 -0800 Subject: PING: RFR: JDK-8235846: Improve WindbgDebuggerLocal implementation In-Reply-To: <27dbbdf8-c312-fc17-fe11-7da9f743f8c0@oracle.com> References: <8ca073bf-0f82-46d5-7fd1-0a5b5757bfa4@oracle.com> <6ed9a23f-3ba4-cbf2-8156-26b4e3731eeb@oracle.com> <2bac872a-e538-83e9-1448-dcd788de2cee@oracle.com> <2a7a52f8-aaea-2124-faaf-d371d8bcbb8e@oracle.com> <364eb89e-4811-a3b6-67c8-0c26e8776816@oracle.com> <27dbbdf8-c312-fc17-fe11-7da9f743f8c0@oracle.com> Message-ID: Hi Chris, On 01/22/2020 19:21, Chris Plummer wrote: > On 1/22/20 12:23 PM, Alex Menkov wrote: >> Hi Chris, >> >> On 01/17/2020 14:36, Chris Plummer wrote: >>> Hi Alex, >>> >>> I assume that the following: >>> >>> ?? 65?? operator T* () const { >>> ?? 66???? return m_ptr; >>> ?? 67?? } >>> >>> Is used here: >>> >>> ??183?????? AutoArrayPtr errmsg(new char[strlen(str) + 32]); \ >>> ??184?????? if (errmsg == nullptr) { \ >>> >>> I just don't understand how this works. Somehow it seems the "T*" >>> operator applies to the "errmsg" reference here. This is a use of C++ >>> operators I'm not familiar with. Can you please explain. >> >> Yes, you are right. >> errmsg is an object and nullptr is a pointer, so compiler tries to >> find a way to cast types. >> This cast operator is the only way to cast errmsg to pointer (char *), >> so compiler uses it. >> You can read more about cast operators: >> https://en.cppreference.com/w/cpp/language/cast_operator >> They are quite convenient. > Ok. This is probably acceptable C++, but TBH not something I really care > for. It's confusing to someone who is not fluent in this use of cast > operators. It reads funny to me because you have a local variable that > is an instance of an object (not a pointer to an object), yet are > comparing it to null. Maybe it would be more clear to introduce bool cast operator (so to check errmsg is invalid "if (!errmsg)" can be used), but it requires more work to resolve "safe bool" issue: https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Safe_bool >> >>> Why is the following not placed at the end if the "if" block: >>> >>> ??299?? AddRef(); >>> ??300?? return S_OK; >>> >>> The following was removed. It's not clear to me why it was and what >>> the impact is: >>> >>> ??283?? ptrIDebugOutputCallbacks->AddRef(); >> >> I updated COM object implementation (SAOutputCallbacks) to follow >> "standard way". >> - standard implementation for QueryInterface looks like >> >> ? *ppInterface = nullptr; >> ? if (IsEqualIID(interfaceId, __uuidof(IUnknown)) || >> ??????? IsEqualIID(interfaceId, __uuidof(MyInterface1))) { >> ??? *ppInterface = static_cast(this); >> ? } else if (IsEqualIID(interfaceId, __uuidof(MyInterface2))) { >> ??? *ppInterface = static_cast(this); >> ? } else if (IsEqualIID(interfaceId, __uuidof(MyInterface3))) { >> ??? *ppInterface = static_cast(this); >> ... >> ? } else { >> ??? return E_NOINTERFACE; >> ? } >> ? AddRef(); >> ? return S_OK; >> } >> > I'm not sure what standard you are referring to. The only other uses of > E_NOINTERFACE I see are 5 uses in awt that all put the AddRef() in the > if/else blocks, not outside. Can you please explain what this standard is? Well, openjdk implements only 3 COM interfaces. This "standard way" is from other projects I worked on (including jdk installer which implements a lot of COM objects). I don't care much about this change and can revert it. As for ref.counter - I never see ref.counter is initialized by 0 (AWT code initialize ref.counter by 1 in ctor too). --alex > > thanks > > Chris >> - standard handling of ref. counter sets it to 1 during object >> creation (so callers don't have to call AddRef after each creation) >> So I did: >> -? SAOutputCallbacks() : m_refCount(0), m_msgBuffer(0) { >> +? SAOutputCallbacks() : m_refCount(1), m_msgBuffer(nullptr) { >> >> and removed unnecessary AddRef: >> ?? SAOutputCallbacks* ptrIDebugOutputCallbacks = new SAOutputCallbacks(); >> -? ptrIDebugOutputCallbacks->AddRef(); >> >> >> --alex >> >>> >>> thanks, >>> >>> Chris >>> >>> On 1/17/20 10:37 AM, Alex Menkov wrote: >>>> Need 2nd reviewer. >>>> >>>> --alex >>>> >>>> On 01/14/2020 13:10, serguei.spitsyn at oracle.com wrote: >>>>> Hi Alex, >>>>> >>>>> Thank you for the update! >>>>> It looks good. >>>>> >>>>> Still incorrect indent: >>>>> >>>>> 103 ~AutoJavaString() { 104 if (m_buf) { 105 >>>>> m_env->ReleaseStringUTFChars(m_str, m_buf); 106 } 107 } 108 109 >>>>> operator const char* () const { 110 return m_buf; 111 } ... 133 >>>>> void setReleaseMode(jint mode) { >>>>> 134 releaseMode = mode; >>>>> 135 } >>>>> 136 >>>>> 137 operator jbyte* () const { >>>>> 138 return bytePtr; >>>>> 139 } >>>>> >>>>> The comment shout start from a capital letter: >>>>> >>>>> 177 // verifies COM call result is S_OK, throws DebuggerException >>>>> and exits otherwise. >>>>> >>>>> >>>>> No need for another webrev. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> On 1/14/20 12:39 PM, Alex Menkov wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> Thank you for the review. >>>>>> updated webrev: >>>>>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.02/ >>>>>> >>>>>> On 01/13/2020 16:39, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Alex, >>>>>>> >>>>>>> It looks pretty good. >>>>>>> Just some minor comments below. >>>>>>> >>>>>>> The class AutoCOMPtr has unfixed indents. >>>>>>> I guess, the function AutoArrayPtr.asPtr() is not used anymore >>>>>>> and can be deleted. >>>>>> >>>>>> fixed. >>>>>> >>>>>>> >>>>>>> I'd suggest to remove first level '()' brackets in the comment to >>>>>>> avoid brackets nesting: 74 // manage COM 'auto' pointers (to >>>>>>> avoid multiple Release 75 // calls at every early (exception) >>>>>>> returns). => 74 // manage COM 'auto' pointers to avoid multiple >>>>>>> Release >>>>>>> 75 // calls at every early (exception) returns. >>>>>> >>>>>> done. >>>>>> >>>>>>> I'd suggest to reformat it as it was originally formatted: >>>>>>> >>>>>>> 297 if (IsEqualIID(interfaceId, __uuidof(IUnknown)) >>>>>>> 298 || IsEqualIID(interfaceId, __uuidof(IDebugOutputCallbacks))) >>>>>>> { => 297 if (IsEqualIID(interfaceId, __uuidof(IUnknown))? || >>>>>>> 298 IsEqualIID(interfaceId, __uuidof(IDebugOutputCallbacks))) { >>>>>> >>>>>> done. >>>>>> >>>>>>> The comment about S_FALSE is not that clear as S_FALSE is not >>>>>>> really used >>>>>>> (better to use consistently just one value: S_FALSE or false): >>>>>>> >>>>>>> 418 // S_FALSE means timeout >>>>>>> 419 >>>>>>> COM_VERIFY_OK_(ptrIDebugControl->WaitForEvent(DEBUG_WAIT_DEFAULT, >>>>>>> INFINITE), >>>>>>> 420 "Windbg Error: WaitForEvent failed!", false); >>>>>> >>>>>> S_FALSE is a possible result of ptrIDebugControl->WaitForEvent call. >>>>>> In the case we wait infinitely, so S_FALSE is not possible and we >>>>>> don't handle it separately. >>>>>> I removed the comment. >>>>>> >>>>>> >>>>>>> NULL is used in some placesand nullptr in others. >>>>>> >>>>>> There is some mess with 0/NULL/nullptr in the file >>>>>> I fixed all NULLs and some (most likely not all) 0s. >>>>>> BTW it immediately discovered misuse of NULL/0: >>>>>> >>>>>> -? if (ptrIDebugSymbols->GetModuleParameters(loaded, 0, NULL, >>>>>> params.asPtr()) != S_OK) { >>>>>> -???? THROW_NEW_DEBUGGER_EXCEPTION_("Windbg Error: >>>>>> GetModuleParameters failed!", false); >>>>>> -? } >>>>>> + COM_VERIFY_OK_(ptrIDebugSymbols->GetModuleParameters(loaded, >>>>>> nullptr, 0, params), >>>>>> +???????????????? "Windbg Error: GetModuleParameters failed!", >>>>>> false); >>>>>> >>>>>> 2nd arg of GetModuleParameters is a pointer and 3rd is ulong >>>>>> >>>>>> --alex >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 12/19/19 15:34, Alex Menkov wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review a fix for >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8235846 >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.01/ >>>>>>>> >>>>>>>> Main goal of the change is to improve error reporting (we have >>>>>>>> several bugs and need at least COM error codes for WinDbg calls). >>>>>>>> Also the fix improves/rearranges this quite old code. >>>>>>>> >>>>>>>> --alex >>>>>>> >>>>> >>> >>> > > From chris.plummer at oracle.com Thu Jan 23 20:35:13 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 23 Jan 2020 12:35:13 -0800 Subject: PING: RFR: JDK-8235846: Improve WindbgDebuggerLocal implementation In-Reply-To: References: <8ca073bf-0f82-46d5-7fd1-0a5b5757bfa4@oracle.com> <6ed9a23f-3ba4-cbf2-8156-26b4e3731eeb@oracle.com> <2bac872a-e538-83e9-1448-dcd788de2cee@oracle.com> <2a7a52f8-aaea-2124-faaf-d371d8bcbb8e@oracle.com> <364eb89e-4811-a3b6-67c8-0c26e8776816@oracle.com> <27dbbdf8-c312-fc17-fe11-7da9f743f8c0@oracle.com> Message-ID: <8c21cc38-4d06-964e-0960-7146b8b05d93@oracle.com> On 1/23/20 11:21 AM, Alex Menkov wrote: > Hi Chris, > > On 01/22/2020 19:21, Chris Plummer wrote: >> On 1/22/20 12:23 PM, Alex Menkov wrote: >>> Hi Chris, >>> >>> On 01/17/2020 14:36, Chris Plummer wrote: >>>> Hi Alex, >>>> >>>> I assume that the following: >>>> >>>> ?? 65?? operator T* () const { >>>> ?? 66???? return m_ptr; >>>> ?? 67?? } >>>> >>>> Is used here: >>>> >>>> ??183?????? AutoArrayPtr errmsg(new char[strlen(str) + 32]); \ >>>> ??184?????? if (errmsg == nullptr) { \ >>>> >>>> I just don't understand how this works. Somehow it seems the "T*" >>>> operator applies to the "errmsg" reference here. This is a use of >>>> C++ operators I'm not familiar with. Can you please explain. >>> >>> Yes, you are right. >>> errmsg is an object and nullptr is a pointer, so compiler tries to >>> find a way to cast types. >>> This cast operator is the only way to cast errmsg to pointer (char >>> *), so compiler uses it. >>> You can read more about cast operators: >>> https://en.cppreference.com/w/cpp/language/cast_operator >>> They are quite convenient. >> Ok. This is probably acceptable C++, but TBH not something I really >> care for. It's confusing to someone who is not fluent in this use of >> cast operators. It reads funny to me because you have a local >> variable that is an instance of an object (not a pointer to an >> object), yet are comparing it to null. > > Maybe it would be more clear to introduce bool cast operator (so to > check errmsg is invalid "if (!errmsg)" can be used), but it requires > more work to resolve "safe bool" issue: > https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Safe_bool It's fine the way you have it. > >>> >>>> Why is the following not placed at the end if the "if" block: >>>> >>>> ??299?? AddRef(); >>>> ??300?? return S_OK; >>>> >>>> The following was removed. It's not clear to me why it was and what >>>> the impact is: >>>> >>>> ??283?? ptrIDebugOutputCallbacks->AddRef(); >>> >>> I updated COM object implementation (SAOutputCallbacks) to follow >>> "standard way". >>> - standard implementation for QueryInterface looks like >>> >>> ? *ppInterface = nullptr; >>> ? if (IsEqualIID(interfaceId, __uuidof(IUnknown)) || >>> ??????? IsEqualIID(interfaceId, __uuidof(MyInterface1))) { >>> ??? *ppInterface = static_cast(this); >>> ? } else if (IsEqualIID(interfaceId, __uuidof(MyInterface2))) { >>> ??? *ppInterface = static_cast(this); >>> ? } else if (IsEqualIID(interfaceId, __uuidof(MyInterface3))) { >>> ??? *ppInterface = static_cast(this); >>> ... >>> ? } else { >>> ??? return E_NOINTERFACE; >>> ? } >>> ? AddRef(); >>> ? return S_OK; >>> } >>> >> I'm not sure what standard you are referring to. The only other uses >> of E_NOINTERFACE I see are 5 uses in awt that all put the AddRef() in >> the if/else blocks, not outside. Can you please explain what this >> standard is? > > Well, openjdk implements only 3 COM interfaces. > This "standard way" is from other projects I worked on (including jdk > installer which implements a lot of COM objects). > I don't care much about this change and can revert it. OK. thanks, Chris > > As for ref.counter - I never see ref.counter is initialized by 0 (AWT > code initialize ref.counter by 1 in ctor too). > > --alex > >> >> thanks >> >> Chris >>> - standard handling of ref. counter sets it to 1 during object >>> creation (so callers don't have to call AddRef after each creation) >>> So I did: >>> -? SAOutputCallbacks() : m_refCount(0), m_msgBuffer(0) { >>> +? SAOutputCallbacks() : m_refCount(1), m_msgBuffer(nullptr) { >>> >>> and removed unnecessary AddRef: >>> ?? SAOutputCallbacks* ptrIDebugOutputCallbacks = new >>> SAOutputCallbacks(); >>> -? ptrIDebugOutputCallbacks->AddRef(); >>> >>> >>> --alex >>> >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 1/17/20 10:37 AM, Alex Menkov wrote: >>>>> Need 2nd reviewer. >>>>> >>>>> --alex >>>>> >>>>> On 01/14/2020 13:10, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Alex, >>>>>> >>>>>> Thank you for the update! >>>>>> It looks good. >>>>>> >>>>>> Still incorrect indent: >>>>>> >>>>>> 103 ~AutoJavaString() { 104 if (m_buf) { 105 >>>>>> m_env->ReleaseStringUTFChars(m_str, m_buf); 106 } 107 } 108 109 >>>>>> operator const char* () const { 110 return m_buf; 111 } ... 133 >>>>>> void setReleaseMode(jint mode) { >>>>>> 134 releaseMode = mode; >>>>>> 135 } >>>>>> 136 >>>>>> 137 operator jbyte* () const { >>>>>> 138 return bytePtr; >>>>>> 139 } >>>>>> >>>>>> The comment shout start from a capital letter: >>>>>> >>>>>> 177 // verifies COM call result is S_OK, throws DebuggerException >>>>>> and exits otherwise. >>>>>> >>>>>> >>>>>> No need for another webrev. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> On 1/14/20 12:39 PM, Alex Menkov wrote: >>>>>>> Hi Serguei, >>>>>>> >>>>>>> Thank you for the review. >>>>>>> updated webrev: >>>>>>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.02/ >>>>>>> >>>>>>> On 01/13/2020 16:39, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Alex, >>>>>>>> >>>>>>>> It looks pretty good. >>>>>>>> Just some minor comments below. >>>>>>>> >>>>>>>> The class AutoCOMPtr has unfixed indents. >>>>>>>> I guess, the function AutoArrayPtr.asPtr() is not used anymore >>>>>>>> and can be deleted. >>>>>>> >>>>>>> fixed. >>>>>>> >>>>>>>> >>>>>>>> I'd suggest to remove first level '()' brackets in the comment >>>>>>>> to avoid brackets nesting: 74 // manage COM 'auto' pointers (to >>>>>>>> avoid multiple Release 75 // calls at every early (exception) >>>>>>>> returns). => 74 // manage COM 'auto' pointers to avoid multiple >>>>>>>> Release >>>>>>>> 75 // calls at every early (exception) returns. >>>>>>> >>>>>>> done. >>>>>>> >>>>>>>> I'd suggest to reformat it as it was originally formatted: >>>>>>>> >>>>>>>> 297 if (IsEqualIID(interfaceId, __uuidof(IUnknown)) >>>>>>>> 298 || IsEqualIID(interfaceId, >>>>>>>> __uuidof(IDebugOutputCallbacks))) { => 297 if >>>>>>>> (IsEqualIID(interfaceId, __uuidof(IUnknown))? || >>>>>>>> 298 IsEqualIID(interfaceId, __uuidof(IDebugOutputCallbacks))) { >>>>>>> >>>>>>> done. >>>>>>> >>>>>>>> The comment about S_FALSE is not that clear as S_FALSE is not >>>>>>>> really used >>>>>>>> (better to use consistently just one value: S_FALSE or false): >>>>>>>> >>>>>>>> 418 // S_FALSE means timeout >>>>>>>> 419 >>>>>>>> COM_VERIFY_OK_(ptrIDebugControl->WaitForEvent(DEBUG_WAIT_DEFAULT, >>>>>>>> INFINITE), >>>>>>>> 420 "Windbg Error: WaitForEvent failed!", false); >>>>>>> >>>>>>> S_FALSE is a possible result of ptrIDebugControl->WaitForEvent >>>>>>> call. >>>>>>> In the case we wait infinitely, so S_FALSE is not possible and >>>>>>> we don't handle it separately. >>>>>>> I removed the comment. >>>>>>> >>>>>>> >>>>>>>> NULL is used in some placesand nullptr in others. >>>>>>> >>>>>>> There is some mess with 0/NULL/nullptr in the file >>>>>>> I fixed all NULLs and some (most likely not all) 0s. >>>>>>> BTW it immediately discovered misuse of NULL/0: >>>>>>> >>>>>>> -? if (ptrIDebugSymbols->GetModuleParameters(loaded, 0, NULL, >>>>>>> params.asPtr()) != S_OK) { >>>>>>> -???? THROW_NEW_DEBUGGER_EXCEPTION_("Windbg Error: >>>>>>> GetModuleParameters failed!", false); >>>>>>> -? } >>>>>>> + COM_VERIFY_OK_(ptrIDebugSymbols->GetModuleParameters(loaded, >>>>>>> nullptr, 0, params), >>>>>>> +???????????????? "Windbg Error: GetModuleParameters failed!", >>>>>>> false); >>>>>>> >>>>>>> 2nd arg of GetModuleParameters is a pointer and 3rd is ulong >>>>>>> >>>>>>> --alex >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 12/19/19 15:34, Alex Menkov wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review a fix for >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8235846 >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.01/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Main goal of the change is to improve error reporting (we have >>>>>>>>> several bugs and need at least COM error codes for WinDbg calls). >>>>>>>>> Also the fix improves/rearranges this quite old code. >>>>>>>>> >>>>>>>>> --alex >>>>>>>> >>>>>> >>>> >>>> >> >> From alexey.menkov at oracle.com Thu Jan 23 21:16:47 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 23 Jan 2020 13:16:47 -0800 Subject: PING: RFR: JDK-8235846: Improve WindbgDebuggerLocal implementation In-Reply-To: <8c21cc38-4d06-964e-0960-7146b8b05d93@oracle.com> References: <8ca073bf-0f82-46d5-7fd1-0a5b5757bfa4@oracle.com> <6ed9a23f-3ba4-cbf2-8156-26b4e3731eeb@oracle.com> <2bac872a-e538-83e9-1448-dcd788de2cee@oracle.com> <2a7a52f8-aaea-2124-faaf-d371d8bcbb8e@oracle.com> <364eb89e-4811-a3b6-67c8-0c26e8776816@oracle.com> <27dbbdf8-c312-fc17-fe11-7da9f743f8c0@oracle.com> <8c21cc38-4d06-964e-0960-7146b8b05d93@oracle.com> Message-ID: <602c875f-cf49-4f4b-49ab-2e5a8f0f2345@oracle.com> On 01/23/2020 12:35, Chris Plummer wrote: > On 1/23/20 11:21 AM, Alex Menkov wrote: ...skipped... >>>> >>>>> Why is the following not placed at the end if the "if" block: >>>>> >>>>> ??299?? AddRef(); >>>>> ??300?? return S_OK; >>>>> >>>>> The following was removed. It's not clear to me why it was and what >>>>> the impact is: >>>>> >>>>> ??283?? ptrIDebugOutputCallbacks->AddRef(); >>>> >>>> I updated COM object implementation (SAOutputCallbacks) to follow >>>> "standard way". >>>> - standard implementation for QueryInterface looks like >>>> >>>> ? *ppInterface = nullptr; >>>> ? if (IsEqualIID(interfaceId, __uuidof(IUnknown)) || >>>> ??????? IsEqualIID(interfaceId, __uuidof(MyInterface1))) { >>>> ??? *ppInterface = static_cast(this); >>>> ? } else if (IsEqualIID(interfaceId, __uuidof(MyInterface2))) { >>>> ??? *ppInterface = static_cast(this); >>>> ? } else if (IsEqualIID(interfaceId, __uuidof(MyInterface3))) { >>>> ??? *ppInterface = static_cast(this); >>>> ... >>>> ? } else { >>>> ??? return E_NOINTERFACE; >>>> ? } >>>> ? AddRef(); >>>> ? return S_OK; >>>> } >>>> >>> I'm not sure what standard you are referring to. The only other uses >>> of E_NOINTERFACE I see are 5 uses in awt that all put the AddRef() in >>> the if/else blocks, not outside. Can you please explain what this >>> standard is? >> >> Well, openjdk implements only 3 COM interfaces. >> This "standard way" is from other projects I worked on (including jdk >> installer which implements a lot of COM objects). >> I don't care much about this change and can revert it. > OK. What does the "OK" mean? :) Do you prefer revert the change? --alex > > thanks, > > Chris >> >> As for ref.counter - I never see ref.counter is initialized by 0 (AWT >> code initialize ref.counter by 1 in ctor too). >> >> --alex >> >>> >>> thanks >>> >>> Chris >>>> - standard handling of ref. counter sets it to 1 during object >>>> creation (so callers don't have to call AddRef after each creation) >>>> So I did: >>>> -? SAOutputCallbacks() : m_refCount(0), m_msgBuffer(0) { >>>> +? SAOutputCallbacks() : m_refCount(1), m_msgBuffer(nullptr) { >>>> >>>> and removed unnecessary AddRef: >>>> ?? SAOutputCallbacks* ptrIDebugOutputCallbacks = new >>>> SAOutputCallbacks(); >>>> -? ptrIDebugOutputCallbacks->AddRef(); >>>> >>>> >>>> --alex >>>> >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 1/17/20 10:37 AM, Alex Menkov wrote: >>>>>> Need 2nd reviewer. >>>>>> >>>>>> --alex >>>>>> >>>>>> On 01/14/2020 13:10, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Alex, >>>>>>> >>>>>>> Thank you for the update! >>>>>>> It looks good. >>>>>>> >>>>>>> Still incorrect indent: >>>>>>> >>>>>>> 103 ~AutoJavaString() { 104 if (m_buf) { 105 >>>>>>> m_env->ReleaseStringUTFChars(m_str, m_buf); 106 } 107 } 108 109 >>>>>>> operator const char* () const { 110 return m_buf; 111 } ... 133 >>>>>>> void setReleaseMode(jint mode) { >>>>>>> 134 releaseMode = mode; >>>>>>> 135 } >>>>>>> 136 >>>>>>> 137 operator jbyte* () const { >>>>>>> 138 return bytePtr; >>>>>>> 139 } >>>>>>> >>>>>>> The comment shout start from a capital letter: >>>>>>> >>>>>>> 177 // verifies COM call result is S_OK, throws DebuggerException >>>>>>> and exits otherwise. >>>>>>> >>>>>>> >>>>>>> No need for another webrev. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 1/14/20 12:39 PM, Alex Menkov wrote: >>>>>>>> Hi Serguei, >>>>>>>> >>>>>>>> Thank you for the review. >>>>>>>> updated webrev: >>>>>>>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.02/ >>>>>>>> >>>>>>>> On 01/13/2020 16:39, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi Alex, >>>>>>>>> >>>>>>>>> It looks pretty good. >>>>>>>>> Just some minor comments below. >>>>>>>>> >>>>>>>>> The class AutoCOMPtr has unfixed indents. >>>>>>>>> I guess, the function AutoArrayPtr.asPtr() is not used anymore >>>>>>>>> and can be deleted. >>>>>>>> >>>>>>>> fixed. >>>>>>>> >>>>>>>>> >>>>>>>>> I'd suggest to remove first level '()' brackets in the comment >>>>>>>>> to avoid brackets nesting: 74 // manage COM 'auto' pointers (to >>>>>>>>> avoid multiple Release 75 // calls at every early (exception) >>>>>>>>> returns). => 74 // manage COM 'auto' pointers to avoid multiple >>>>>>>>> Release >>>>>>>>> 75 // calls at every early (exception) returns. >>>>>>>> >>>>>>>> done. >>>>>>>> >>>>>>>>> I'd suggest to reformat it as it was originally formatted: >>>>>>>>> >>>>>>>>> 297 if (IsEqualIID(interfaceId, __uuidof(IUnknown)) >>>>>>>>> 298 || IsEqualIID(interfaceId, >>>>>>>>> __uuidof(IDebugOutputCallbacks))) { => 297 if >>>>>>>>> (IsEqualIID(interfaceId, __uuidof(IUnknown))? || >>>>>>>>> 298 IsEqualIID(interfaceId, __uuidof(IDebugOutputCallbacks))) { >>>>>>>> >>>>>>>> done. >>>>>>>> >>>>>>>>> The comment about S_FALSE is not that clear as S_FALSE is not >>>>>>>>> really used >>>>>>>>> (better to use consistently just one value: S_FALSE or false): >>>>>>>>> >>>>>>>>> 418 // S_FALSE means timeout >>>>>>>>> 419 >>>>>>>>> COM_VERIFY_OK_(ptrIDebugControl->WaitForEvent(DEBUG_WAIT_DEFAULT, >>>>>>>>> INFINITE), >>>>>>>>> 420 "Windbg Error: WaitForEvent failed!", false); >>>>>>>> >>>>>>>> S_FALSE is a possible result of ptrIDebugControl->WaitForEvent >>>>>>>> call. >>>>>>>> In the case we wait infinitely, so S_FALSE is not possible and >>>>>>>> we don't handle it separately. >>>>>>>> I removed the comment. >>>>>>>> >>>>>>>> >>>>>>>>> NULL is used in some placesand nullptr in others. >>>>>>>> >>>>>>>> There is some mess with 0/NULL/nullptr in the file >>>>>>>> I fixed all NULLs and some (most likely not all) 0s. >>>>>>>> BTW it immediately discovered misuse of NULL/0: >>>>>>>> >>>>>>>> -? if (ptrIDebugSymbols->GetModuleParameters(loaded, 0, NULL, >>>>>>>> params.asPtr()) != S_OK) { >>>>>>>> -???? THROW_NEW_DEBUGGER_EXCEPTION_("Windbg Error: >>>>>>>> GetModuleParameters failed!", false); >>>>>>>> -? } >>>>>>>> + COM_VERIFY_OK_(ptrIDebugSymbols->GetModuleParameters(loaded, >>>>>>>> nullptr, 0, params), >>>>>>>> +???????????????? "Windbg Error: GetModuleParameters failed!", >>>>>>>> false); >>>>>>>> >>>>>>>> 2nd arg of GetModuleParameters is a pointer and 3rd is ulong >>>>>>>> >>>>>>>> --alex >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12/19/19 15:34, Alex Menkov wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Please review a fix for >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8235846 >>>>>>>>>> webrev: >>>>>>>>>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.01/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Main goal of the change is to improve error reporting (we have >>>>>>>>>> several bugs and need at least COM error codes for WinDbg calls). >>>>>>>>>> Also the fix improves/rearranges this quite old code. >>>>>>>>>> >>>>>>>>>> --alex >>>>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From chris.plummer at oracle.com Thu Jan 23 21:56:35 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 23 Jan 2020 13:56:35 -0800 Subject: PING: RFR: JDK-8235846: Improve WindbgDebuggerLocal implementation In-Reply-To: <602c875f-cf49-4f4b-49ab-2e5a8f0f2345@oracle.com> References: <8ca073bf-0f82-46d5-7fd1-0a5b5757bfa4@oracle.com> <6ed9a23f-3ba4-cbf2-8156-26b4e3731eeb@oracle.com> <2bac872a-e538-83e9-1448-dcd788de2cee@oracle.com> <2a7a52f8-aaea-2124-faaf-d371d8bcbb8e@oracle.com> <364eb89e-4811-a3b6-67c8-0c26e8776816@oracle.com> <27dbbdf8-c312-fc17-fe11-7da9f743f8c0@oracle.com> <8c21cc38-4d06-964e-0960-7146b8b05d93@oracle.com> <602c875f-cf49-4f4b-49ab-2e5a8f0f2345@oracle.com> Message-ID: <173ab2c3-e1c0-dabd-135f-f750241bf7c7@oracle.com> On 1/23/20 1:16 PM, Alex Menkov wrote: > > > On 01/23/2020 12:35, Chris Plummer wrote: >> On 1/23/20 11:21 AM, Alex Menkov wrote: > > ...skipped... > >>>>> >>>>>> Why is the following not placed at the end if the "if" block: >>>>>> >>>>>> ??299?? AddRef(); >>>>>> ??300?? return S_OK; >>>>>> >>>>>> The following was removed. It's not clear to me why it was and >>>>>> what the impact is: >>>>>> >>>>>> ??283?? ptrIDebugOutputCallbacks->AddRef(); >>>>> >>>>> I updated COM object implementation (SAOutputCallbacks) to follow >>>>> "standard way". >>>>> - standard implementation for QueryInterface looks like >>>>> >>>>> ? *ppInterface = nullptr; >>>>> ? if (IsEqualIID(interfaceId, __uuidof(IUnknown)) || >>>>> ??????? IsEqualIID(interfaceId, __uuidof(MyInterface1))) { >>>>> ??? *ppInterface = static_cast(this); >>>>> ? } else if (IsEqualIID(interfaceId, __uuidof(MyInterface2))) { >>>>> ??? *ppInterface = static_cast(this); >>>>> ? } else if (IsEqualIID(interfaceId, __uuidof(MyInterface3))) { >>>>> ??? *ppInterface = static_cast(this); >>>>> ... >>>>> ? } else { >>>>> ??? return E_NOINTERFACE; >>>>> ? } >>>>> ? AddRef(); >>>>> ? return S_OK; >>>>> } >>>>> >>>> I'm not sure what standard you are referring to. The only other >>>> uses of E_NOINTERFACE I see are 5 uses in awt that all put the >>>> AddRef() in the if/else blocks, not outside. Can you please explain >>>> what this standard is? >>> >>> Well, openjdk implements only 3 COM interfaces. >>> This "standard way" is from other projects I worked on (including >>> jdk installer which implements a lot of COM objects). >>> I don't care much about this change and can revert it. >> OK. > > What does the "OK" mean? :) > Do you prefer revert the change? Either is fine. Chris > > --alex > >> >> thanks, >> >> Chris >>> >>> As for ref.counter - I never see ref.counter is initialized by 0 >>> (AWT code initialize ref.counter by 1 in ctor too). >>> >>> --alex >>> >>>> >>>> thanks >>>> >>>> Chris >>>>> - standard handling of ref. counter sets it to 1 during object >>>>> creation (so callers don't have to call AddRef after each creation) >>>>> So I did: >>>>> -? SAOutputCallbacks() : m_refCount(0), m_msgBuffer(0) { >>>>> +? SAOutputCallbacks() : m_refCount(1), m_msgBuffer(nullptr) { >>>>> >>>>> and removed unnecessary AddRef: >>>>> ?? SAOutputCallbacks* ptrIDebugOutputCallbacks = new >>>>> SAOutputCallbacks(); >>>>> -? ptrIDebugOutputCallbacks->AddRef(); >>>>> >>>>> >>>>> --alex >>>>> >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> On 1/17/20 10:37 AM, Alex Menkov wrote: >>>>>>> Need 2nd reviewer. >>>>>>> >>>>>>> --alex >>>>>>> >>>>>>> On 01/14/2020 13:10, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Alex, >>>>>>>> >>>>>>>> Thank you for the update! >>>>>>>> It looks good. >>>>>>>> >>>>>>>> Still incorrect indent: >>>>>>>> >>>>>>>> 103 ~AutoJavaString() { 104 if (m_buf) { 105 >>>>>>>> m_env->ReleaseStringUTFChars(m_str, m_buf); 106 } 107 } 108 109 >>>>>>>> operator const char* () const { 110 return m_buf; 111 } ... 133 >>>>>>>> void setReleaseMode(jint mode) { >>>>>>>> 134 releaseMode = mode; >>>>>>>> 135 } >>>>>>>> 136 >>>>>>>> 137 operator jbyte* () const { >>>>>>>> 138 return bytePtr; >>>>>>>> 139 } >>>>>>>> >>>>>>>> The comment shout start from a capital letter: >>>>>>>> >>>>>>>> 177 // verifies COM call result is S_OK, throws >>>>>>>> DebuggerException and exits otherwise. >>>>>>>> >>>>>>>> >>>>>>>> No need for another webrev. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 1/14/20 12:39 PM, Alex Menkov wrote: >>>>>>>>> Hi Serguei, >>>>>>>>> >>>>>>>>> Thank you for the review. >>>>>>>>> updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.02/ >>>>>>>>> >>>>>>>>> >>>>>>>>> On 01/13/2020 16:39, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi Alex, >>>>>>>>>> >>>>>>>>>> It looks pretty good. >>>>>>>>>> Just some minor comments below. >>>>>>>>>> >>>>>>>>>> The class AutoCOMPtr has unfixed indents. >>>>>>>>>> I guess, the function AutoArrayPtr.asPtr() is not used >>>>>>>>>> anymore and can be deleted. >>>>>>>>> >>>>>>>>> fixed. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'd suggest to remove first level '()' brackets in the >>>>>>>>>> comment to avoid brackets nesting: 74 // manage COM 'auto' >>>>>>>>>> pointers (to avoid multiple Release 75 // calls at every >>>>>>>>>> early (exception) returns). => 74 // manage COM 'auto' >>>>>>>>>> pointers to avoid multiple Release >>>>>>>>>> 75 // calls at every early (exception) returns. >>>>>>>>> >>>>>>>>> done. >>>>>>>>> >>>>>>>>>> I'd suggest to reformat it as it was originally formatted: >>>>>>>>>> >>>>>>>>>> 297 if (IsEqualIID(interfaceId, __uuidof(IUnknown)) >>>>>>>>>> 298 || IsEqualIID(interfaceId, >>>>>>>>>> __uuidof(IDebugOutputCallbacks))) { => 297 if >>>>>>>>>> (IsEqualIID(interfaceId, __uuidof(IUnknown))? || >>>>>>>>>> 298 IsEqualIID(interfaceId, __uuidof(IDebugOutputCallbacks))) { >>>>>>>>> >>>>>>>>> done. >>>>>>>>> >>>>>>>>>> The comment about S_FALSE is not that clear as S_FALSE is not >>>>>>>>>> really used >>>>>>>>>> (better to use consistently just one value: S_FALSE or false): >>>>>>>>>> >>>>>>>>>> 418 // S_FALSE means timeout >>>>>>>>>> 419 >>>>>>>>>> COM_VERIFY_OK_(ptrIDebugControl->WaitForEvent(DEBUG_WAIT_DEFAULT, >>>>>>>>>> INFINITE), >>>>>>>>>> 420 "Windbg Error: WaitForEvent failed!", false); >>>>>>>>> >>>>>>>>> S_FALSE is a possible result of ptrIDebugControl->WaitForEvent >>>>>>>>> call. >>>>>>>>> In the case we wait infinitely, so S_FALSE is not possible and >>>>>>>>> we don't handle it separately. >>>>>>>>> I removed the comment. >>>>>>>>> >>>>>>>>> >>>>>>>>>> NULL is used in some placesand nullptr in others. >>>>>>>>> >>>>>>>>> There is some mess with 0/NULL/nullptr in the file >>>>>>>>> I fixed all NULLs and some (most likely not all) 0s. >>>>>>>>> BTW it immediately discovered misuse of NULL/0: >>>>>>>>> >>>>>>>>> -? if (ptrIDebugSymbols->GetModuleParameters(loaded, 0, NULL, >>>>>>>>> params.asPtr()) != S_OK) { >>>>>>>>> -???? THROW_NEW_DEBUGGER_EXCEPTION_("Windbg Error: >>>>>>>>> GetModuleParameters failed!", false); >>>>>>>>> -? } >>>>>>>>> + COM_VERIFY_OK_(ptrIDebugSymbols->GetModuleParameters(loaded, >>>>>>>>> nullptr, 0, params), >>>>>>>>> +???????????????? "Windbg Error: GetModuleParameters failed!", >>>>>>>>> false); >>>>>>>>> >>>>>>>>> 2nd arg of GetModuleParameters is a pointer and 3rd is ulong >>>>>>>>> >>>>>>>>> --alex >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 12/19/19 15:34, Alex Menkov wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Please review a fix for >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8235846 >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Main goal of the change is to improve error reporting (we >>>>>>>>>>> have several bugs and need at least COM error codes for >>>>>>>>>>> WinDbg calls). >>>>>>>>>>> Also the fix improves/rearranges this quite old code. >>>>>>>>>>> >>>>>>>>>>> --alex >>>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> From alexey.menkov at oracle.com Thu Jan 23 23:12:16 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 23 Jan 2020 15:12:16 -0800 Subject: PING: RFR: JDK-8235846: Improve WindbgDebuggerLocal implementation In-Reply-To: <173ab2c3-e1c0-dabd-135f-f750241bf7c7@oracle.com> References: <8ca073bf-0f82-46d5-7fd1-0a5b5757bfa4@oracle.com> <6ed9a23f-3ba4-cbf2-8156-26b4e3731eeb@oracle.com> <2bac872a-e538-83e9-1448-dcd788de2cee@oracle.com> <2a7a52f8-aaea-2124-faaf-d371d8bcbb8e@oracle.com> <364eb89e-4811-a3b6-67c8-0c26e8776816@oracle.com> <27dbbdf8-c312-fc17-fe11-7da9f743f8c0@oracle.com> <8c21cc38-4d06-964e-0960-7146b8b05d93@oracle.com> <602c875f-cf49-4f4b-49ab-2e5a8f0f2345@oracle.com> <173ab2c3-e1c0-dabd-135f-f750241bf7c7@oracle.com> Message-ID: On 01/23/2020 13:56, Chris Plummer wrote: > On 1/23/20 1:16 PM, Alex Menkov wrote: >> >> >> On 01/23/2020 12:35, Chris Plummer wrote: >>> On 1/23/20 11:21 AM, Alex Menkov wrote: >> >> ...skipped... >> >>>> I don't care much about this change and can revert it. >>> OK. >> >> What does the "OK" mean? :) >> Do you prefer revert the change? > Either is fine. Then I'll keep the change. May I count you as reviewer? --alex > > Chris >> >> --alex >> >>> >>> thanks, >>> >>> Chris >>>> >>>> As for ref.counter - I never see ref.counter is initialized by 0 >>>> (AWT code initialize ref.counter by 1 in ctor too). >>>> >>>> --alex >>>> >>>>> >>>>> thanks >>>>> >>>>> Chris >>>>>> - standard handling of ref. counter sets it to 1 during object >>>>>> creation (so callers don't have to call AddRef after each creation) >>>>>> So I did: >>>>>> -? SAOutputCallbacks() : m_refCount(0), m_msgBuffer(0) { >>>>>> +? SAOutputCallbacks() : m_refCount(1), m_msgBuffer(nullptr) { >>>>>> >>>>>> and removed unnecessary AddRef: >>>>>> ?? SAOutputCallbacks* ptrIDebugOutputCallbacks = new >>>>>> SAOutputCallbacks(); >>>>>> -? ptrIDebugOutputCallbacks->AddRef(); >>>>>> >>>>>> >>>>>> --alex >>>>>> >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 1/17/20 10:37 AM, Alex Menkov wrote: >>>>>>>> Need 2nd reviewer. >>>>>>>> >>>>>>>> --alex >>>>>>>> >>>>>>>> On 01/14/2020 13:10, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi Alex, >>>>>>>>> >>>>>>>>> Thank you for the update! >>>>>>>>> It looks good. >>>>>>>>> >>>>>>>>> Still incorrect indent: >>>>>>>>> >>>>>>>>> 103 ~AutoJavaString() { 104 if (m_buf) { 105 >>>>>>>>> m_env->ReleaseStringUTFChars(m_str, m_buf); 106 } 107 } 108 109 >>>>>>>>> operator const char* () const { 110 return m_buf; 111 } ... 133 >>>>>>>>> void setReleaseMode(jint mode) { >>>>>>>>> 134 releaseMode = mode; >>>>>>>>> 135 } >>>>>>>>> 136 >>>>>>>>> 137 operator jbyte* () const { >>>>>>>>> 138 return bytePtr; >>>>>>>>> 139 } >>>>>>>>> >>>>>>>>> The comment shout start from a capital letter: >>>>>>>>> >>>>>>>>> 177 // verifies COM call result is S_OK, throws >>>>>>>>> DebuggerException and exits otherwise. >>>>>>>>> >>>>>>>>> >>>>>>>>> No need for another webrev. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 1/14/20 12:39 PM, Alex Menkov wrote: >>>>>>>>>> Hi Serguei, >>>>>>>>>> >>>>>>>>>> Thank you for the review. >>>>>>>>>> updated webrev: >>>>>>>>>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.02/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 01/13/2020 16:39, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Hi Alex, >>>>>>>>>>> >>>>>>>>>>> It looks pretty good. >>>>>>>>>>> Just some minor comments below. >>>>>>>>>>> >>>>>>>>>>> The class AutoCOMPtr has unfixed indents. >>>>>>>>>>> I guess, the function AutoArrayPtr.asPtr() is not used >>>>>>>>>>> anymore and can be deleted. >>>>>>>>>> >>>>>>>>>> fixed. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'd suggest to remove first level '()' brackets in the >>>>>>>>>>> comment to avoid brackets nesting: 74 // manage COM 'auto' >>>>>>>>>>> pointers (to avoid multiple Release 75 // calls at every >>>>>>>>>>> early (exception) returns). => 74 // manage COM 'auto' >>>>>>>>>>> pointers to avoid multiple Release >>>>>>>>>>> 75 // calls at every early (exception) returns. >>>>>>>>>> >>>>>>>>>> done. >>>>>>>>>> >>>>>>>>>>> I'd suggest to reformat it as it was originally formatted: >>>>>>>>>>> >>>>>>>>>>> 297 if (IsEqualIID(interfaceId, __uuidof(IUnknown)) >>>>>>>>>>> 298 || IsEqualIID(interfaceId, >>>>>>>>>>> __uuidof(IDebugOutputCallbacks))) { => 297 if >>>>>>>>>>> (IsEqualIID(interfaceId, __uuidof(IUnknown))? || >>>>>>>>>>> 298 IsEqualIID(interfaceId, __uuidof(IDebugOutputCallbacks))) { >>>>>>>>>> >>>>>>>>>> done. >>>>>>>>>> >>>>>>>>>>> The comment about S_FALSE is not that clear as S_FALSE is not >>>>>>>>>>> really used >>>>>>>>>>> (better to use consistently just one value: S_FALSE or false): >>>>>>>>>>> >>>>>>>>>>> 418 // S_FALSE means timeout >>>>>>>>>>> 419 >>>>>>>>>>> COM_VERIFY_OK_(ptrIDebugControl->WaitForEvent(DEBUG_WAIT_DEFAULT, >>>>>>>>>>> INFINITE), >>>>>>>>>>> 420 "Windbg Error: WaitForEvent failed!", false); >>>>>>>>>> >>>>>>>>>> S_FALSE is a possible result of ptrIDebugControl->WaitForEvent >>>>>>>>>> call. >>>>>>>>>> In the case we wait infinitely, so S_FALSE is not possible and >>>>>>>>>> we don't handle it separately. >>>>>>>>>> I removed the comment. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> NULL is used in some placesand nullptr in others. >>>>>>>>>> >>>>>>>>>> There is some mess with 0/NULL/nullptr in the file >>>>>>>>>> I fixed all NULLs and some (most likely not all) 0s. >>>>>>>>>> BTW it immediately discovered misuse of NULL/0: >>>>>>>>>> >>>>>>>>>> -? if (ptrIDebugSymbols->GetModuleParameters(loaded, 0, NULL, >>>>>>>>>> params.asPtr()) != S_OK) { >>>>>>>>>> -???? THROW_NEW_DEBUGGER_EXCEPTION_("Windbg Error: >>>>>>>>>> GetModuleParameters failed!", false); >>>>>>>>>> -? } >>>>>>>>>> + COM_VERIFY_OK_(ptrIDebugSymbols->GetModuleParameters(loaded, >>>>>>>>>> nullptr, 0, params), >>>>>>>>>> +???????????????? "Windbg Error: GetModuleParameters failed!", >>>>>>>>>> false); >>>>>>>>>> >>>>>>>>>> 2nd arg of GetModuleParameters is a pointer and 3rd is ulong >>>>>>>>>> >>>>>>>>>> --alex >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 12/19/19 15:34, Alex Menkov wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> Please review a fix for >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8235846 >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Main goal of the change is to improve error reporting (we >>>>>>>>>>>> have several bugs and need at least COM error codes for >>>>>>>>>>>> WinDbg calls). >>>>>>>>>>>> Also the fix improves/rearranges this quite old code. >>>>>>>>>>>> >>>>>>>>>>>> --alex >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From chris.plummer at oracle.com Thu Jan 23 23:15:57 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 23 Jan 2020 15:15:57 -0800 Subject: PING: RFR: JDK-8235846: Improve WindbgDebuggerLocal implementation In-Reply-To: References: <8ca073bf-0f82-46d5-7fd1-0a5b5757bfa4@oracle.com> <6ed9a23f-3ba4-cbf2-8156-26b4e3731eeb@oracle.com> <2bac872a-e538-83e9-1448-dcd788de2cee@oracle.com> <2a7a52f8-aaea-2124-faaf-d371d8bcbb8e@oracle.com> <364eb89e-4811-a3b6-67c8-0c26e8776816@oracle.com> <27dbbdf8-c312-fc17-fe11-7da9f743f8c0@oracle.com> <8c21cc38-4d06-964e-0960-7146b8b05d93@oracle.com> <602c875f-cf49-4f4b-49ab-2e5a8f0f2345@oracle.com> <173ab2c3-e1c0-dabd-135f-f750241bf7c7@oracle.com> Message-ID: <73303452-4907-557a-b4f9-d3d07df7d43c@oracle.com> On 1/23/20 3:12 PM, Alex Menkov wrote: > > On 01/23/2020 13:56, Chris Plummer wrote: >> On 1/23/20 1:16 PM, Alex Menkov wrote: >>> >>> >>> On 01/23/2020 12:35, Chris Plummer wrote: >>>> On 1/23/20 11:21 AM, Alex Menkov wrote: >>> >>> ...skipped... >>> >>>>> I don't care much about this change and can revert it. >>>> OK. >>> >>> What does the "OK" mean? :) >>> Do you prefer revert the change? >> Either is fine. > > Then I'll keep the change. > May I count you as reviewer? > Yes. Chris > --alex > >> >> Chris >>> >>> --alex >>> >>>> >>>> thanks, >>>> >>>> Chris >>>>> >>>>> As for ref.counter - I never see ref.counter is initialized by 0 >>>>> (AWT code initialize ref.counter by 1 in ctor too). >>>>> >>>>> --alex >>>>> >>>>>> >>>>>> thanks >>>>>> >>>>>> Chris >>>>>>> - standard handling of ref. counter sets it to 1 during object >>>>>>> creation (so callers don't have to call AddRef after each creation) >>>>>>> So I did: >>>>>>> -? SAOutputCallbacks() : m_refCount(0), m_msgBuffer(0) { >>>>>>> +? SAOutputCallbacks() : m_refCount(1), m_msgBuffer(nullptr) { >>>>>>> >>>>>>> and removed unnecessary AddRef: >>>>>>> ?? SAOutputCallbacks* ptrIDebugOutputCallbacks = new >>>>>>> SAOutputCallbacks(); >>>>>>> -? ptrIDebugOutputCallbacks->AddRef(); >>>>>>> >>>>>>> >>>>>>> --alex >>>>>>> >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 1/17/20 10:37 AM, Alex Menkov wrote: >>>>>>>>> Need 2nd reviewer. >>>>>>>>> >>>>>>>>> --alex >>>>>>>>> >>>>>>>>> On 01/14/2020 13:10, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi Alex, >>>>>>>>>> >>>>>>>>>> Thank you for the update! >>>>>>>>>> It looks good. >>>>>>>>>> >>>>>>>>>> Still incorrect indent: >>>>>>>>>> >>>>>>>>>> 103 ~AutoJavaString() { 104 if (m_buf) { 105 >>>>>>>>>> m_env->ReleaseStringUTFChars(m_str, m_buf); 106 } 107 } 108 >>>>>>>>>> 109 operator const char* () const { 110 return m_buf; 111 } >>>>>>>>>> ... 133 void setReleaseMode(jint mode) { >>>>>>>>>> 134 releaseMode = mode; >>>>>>>>>> 135 } >>>>>>>>>> 136 >>>>>>>>>> 137 operator jbyte* () const { >>>>>>>>>> 138 return bytePtr; >>>>>>>>>> 139 } >>>>>>>>>> >>>>>>>>>> The comment shout start from a capital letter: >>>>>>>>>> >>>>>>>>>> 177 // verifies COM call result is S_OK, throws >>>>>>>>>> DebuggerException and exits otherwise. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> No need for another webrev. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 1/14/20 12:39 PM, Alex Menkov wrote: >>>>>>>>>>> Hi Serguei, >>>>>>>>>>> >>>>>>>>>>> Thank you for the review. >>>>>>>>>>> updated webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.02/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 01/13/2020 16:39, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> Hi Alex, >>>>>>>>>>>> >>>>>>>>>>>> It looks pretty good. >>>>>>>>>>>> Just some minor comments below. >>>>>>>>>>>> >>>>>>>>>>>> The class AutoCOMPtr has unfixed indents. >>>>>>>>>>>> I guess, the function AutoArrayPtr.asPtr() is not used >>>>>>>>>>>> anymore and can be deleted. >>>>>>>>>>> >>>>>>>>>>> fixed. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'd suggest to remove first level '()' brackets in the >>>>>>>>>>>> comment to avoid brackets nesting: 74 // manage COM 'auto' >>>>>>>>>>>> pointers (to avoid multiple Release 75 // calls at every >>>>>>>>>>>> early (exception) returns). => 74 // manage COM 'auto' >>>>>>>>>>>> pointers to avoid multiple Release >>>>>>>>>>>> 75 // calls at every early (exception) returns. >>>>>>>>>>> >>>>>>>>>>> done. >>>>>>>>>>> >>>>>>>>>>>> I'd suggest to reformat it as it was originally formatted: >>>>>>>>>>>> >>>>>>>>>>>> 297 if (IsEqualIID(interfaceId, __uuidof(IUnknown)) >>>>>>>>>>>> 298 || IsEqualIID(interfaceId, >>>>>>>>>>>> __uuidof(IDebugOutputCallbacks))) { => 297 if >>>>>>>>>>>> (IsEqualIID(interfaceId, __uuidof(IUnknown))? || >>>>>>>>>>>> 298 IsEqualIID(interfaceId, >>>>>>>>>>>> __uuidof(IDebugOutputCallbacks))) { >>>>>>>>>>> >>>>>>>>>>> done. >>>>>>>>>>> >>>>>>>>>>>> The comment about S_FALSE is not that clear as S_FALSE is >>>>>>>>>>>> not really used >>>>>>>>>>>> (better to use consistently just one value: S_FALSE or false): >>>>>>>>>>>> >>>>>>>>>>>> 418 // S_FALSE means timeout >>>>>>>>>>>> 419 >>>>>>>>>>>> COM_VERIFY_OK_(ptrIDebugControl->WaitForEvent(DEBUG_WAIT_DEFAULT, >>>>>>>>>>>> INFINITE), >>>>>>>>>>>> 420 "Windbg Error: WaitForEvent failed!", false); >>>>>>>>>>> >>>>>>>>>>> S_FALSE is a possible result of >>>>>>>>>>> ptrIDebugControl->WaitForEvent call. >>>>>>>>>>> In the case we wait infinitely, so S_FALSE is not possible >>>>>>>>>>> and we don't handle it separately. >>>>>>>>>>> I removed the comment. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> NULL is used in some placesand nullptr in others. >>>>>>>>>>> >>>>>>>>>>> There is some mess with 0/NULL/nullptr in the file >>>>>>>>>>> I fixed all NULLs and some (most likely not all) 0s. >>>>>>>>>>> BTW it immediately discovered misuse of NULL/0: >>>>>>>>>>> >>>>>>>>>>> -? if (ptrIDebugSymbols->GetModuleParameters(loaded, 0, >>>>>>>>>>> NULL, params.asPtr()) != S_OK) { >>>>>>>>>>> -???? THROW_NEW_DEBUGGER_EXCEPTION_("Windbg Error: >>>>>>>>>>> GetModuleParameters failed!", false); >>>>>>>>>>> -? } >>>>>>>>>>> + >>>>>>>>>>> COM_VERIFY_OK_(ptrIDebugSymbols->GetModuleParameters(loaded, >>>>>>>>>>> nullptr, 0, params), >>>>>>>>>>> +???????????????? "Windbg Error: GetModuleParameters >>>>>>>>>>> failed!", false); >>>>>>>>>>> >>>>>>>>>>> 2nd arg of GetModuleParameters is a pointer and 3rd is ulong >>>>>>>>>>> >>>>>>>>>>> --alex >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 12/19/19 15:34, Alex Menkov wrote: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review a fix for >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8235846 >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Main goal of the change is to improve error reporting (we >>>>>>>>>>>>> have several bugs and need at least COM error codes for >>>>>>>>>>>>> WinDbg calls). >>>>>>>>>>>>> Also the fix improves/rearranges this quite old code. >>>>>>>>>>>>> >>>>>>>>>>>>> --alex >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> From coleen.phillimore at oracle.com Fri Jan 24 14:01:03 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 24 Jan 2020 09:01:03 -0500 Subject: RFR (T) 8237501: TestInstanceKlassSizeForInstance runs TestInstanceKlassSize instead Message-ID: <389ffc91-b844-7e31-32e3-b07ce32b0093@oracle.com> Fix cut/paste error and reran the test, which passes. open webrev at http://cr.openjdk.java.net/~coleenp/2020/8237501.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8237501 Thanks, Coleen From daniel.daugherty at oracle.com Fri Jan 24 14:59:17 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 24 Jan 2020 09:59:17 -0500 Subject: RFR (T) 8237501: TestInstanceKlassSizeForInstance runs TestInstanceKlassSize instead In-Reply-To: <389ffc91-b844-7e31-32e3-b07ce32b0093@oracle.com> References: <389ffc91-b844-7e31-32e3-b07ce32b0093@oracle.com> Message-ID: <3d302aef-0e4d-e5e5-2b62-b02a17b9bf88@oracle.com> Thumbs up and I agree that this is a trivial fix. Dan On 1/24/20 9:01 AM, coleen.phillimore at oracle.com wrote: > Fix cut/paste error and reran the test, which passes. > > open webrev at http://cr.openjdk.java.net/~coleenp/2020/8237501.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8237501 > > Thanks, > Coleen From coleen.phillimore at oracle.com Fri Jan 24 15:11:07 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 24 Jan 2020 10:11:07 -0500 Subject: RFR (T) 8237501: TestInstanceKlassSizeForInstance runs TestInstanceKlassSize instead In-Reply-To: <3d302aef-0e4d-e5e5-2b62-b02a17b9bf88@oracle.com> References: <389ffc91-b844-7e31-32e3-b07ce32b0093@oracle.com> <3d302aef-0e4d-e5e5-2b62-b02a17b9bf88@oracle.com> Message-ID: Thanks, Dan! Coleen On 1/24/20 9:59 AM, Daniel D. Daugherty wrote: > Thumbs up and I agree that this is a trivial fix. > > Dan > > > On 1/24/20 9:01 AM, coleen.phillimore at oracle.com wrote: >> Fix cut/paste error and reran the test, which passes. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2020/8237501.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8237501 >> >> Thanks, >> Coleen > From alexey.menkov at oracle.com Fri Jan 24 18:38:04 2020 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 24 Jan 2020 10:38:04 -0800 Subject: RFR: 8235681: Remove unnecessary workarounds in UnixOperatingSystem.c In-Reply-To: <1ce5fdb5-a1da-0ce2-b6dc-50fb1953c592@oracle.com> References: <50ca82a7-8a5c-48c9-cb90-7c1d16f88b53@oracle.com> <1ce5fdb5-a1da-0ce2-b6dc-50fb1953c592@oracle.com> Message-ID: <7e17fc44-54ad-b5a8-494e-25419620c5ca@oracle.com> +1 --alex On 01/22/2020 19:02, Chris Plummer wrote: > Looks good. > > Chris > > On 1/22/20 3:30 PM, Daniil Titov wrote: >> Hi Chris, >> >> Please review a new version of the fix [1] that converts the check to >> the assert. >> >>> ??? Also, I'm not clear on the need for the *pkernelLoad >>> initialization. It >>> ??? seems this is attempting to fix a different issue, but it's already >>> ??? initialized to 0 at the start of the function. >> You are right, *pkernelLoad is already initialized on line 251. The >> new version of >> the webrev does not include this change. >> >> [1] Webrev:? http://cr.openjdk.java.net/~dtitov/8235681/webrev.02/ >> [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8235681 >> >> Thank you, >> Daniil >> >> ?On 1/21/20, 10:38 AM, "Chris Plummer" wrote: >> >> ???? Hi Daniil, >> ???? Do you think it's worth changing the check to an assert instead of >> ???? removing it? >> ???? Also, I'm not clear on the need for the *pkernelLoad >> initialization. It >> ???? seems this is attempting to fix a different issue, but it's already >> ???? initialized to 0 at the start of the function. >> ???? thanks, >> ???? Chris >> ???? On 1/17/20 7:10 PM, Daniil Titov wrote: >> ???? > Please review a change that removes unnecessary workaround in >> UnixOperatingSystem.c. >> ???? > >> ???? > It looks as this workaround >> ???? > >> ???? > if (pticks->usedKernel < tmp.usedKernel) { >> ???? >????????? kdiff = 0; >> ???? >?? } >> ???? > >> ???? > was added to compensate a missed initialization of >> counters.jvmTicks that resulted in the new >> ???? > counters being compared with the garbage when >> get_cpuload_internal(...) was called for the first time. >> ???? > >> ???? > This missed initialization was fixed in [3]. >> ???? > >> ???? > Mach5 tier1-tier3 and open/test/hotspot/jtreg/containers/docker >> tests successfully passed. >> ???? > >> ???? > [1] Webrev : http://cr.openjdk.java.net/~dtitov/8235681/webrev.01/ >> ???? > [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8235681 >> ???? > [3] https://bugs.openjdk.java.net/browse/JDK-8226575 >> ???? > >> ???? > Thank you, >> ???? > Daniil >> ???? > >> ???? > >> >> > > From daniil.x.titov at oracle.com Fri Jan 24 18:39:15 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 24 Jan 2020 10:39:15 -0800 Subject: RFR: 8235681: Remove unnecessary workarounds in UnixOperatingSystem.c In-Reply-To: <7e17fc44-54ad-b5a8-494e-25419620c5ca@oracle.com> References: <50ca82a7-8a5c-48c9-cb90-7c1d16f88b53@oracle.com> <1ce5fdb5-a1da-0ce2-b6dc-50fb1953c592@oracle.com> <7e17fc44-54ad-b5a8-494e-25419620c5ca@oracle.com> Message-ID: Thank you Alex and Chris for reviewing this change! Best regards, Daniil ?On 1/24/20, 10:38 AM, "Alex Menkov" wrote: +1 --alex On 01/22/2020 19:02, Chris Plummer wrote: > Looks good. > > Chris > > On 1/22/20 3:30 PM, Daniil Titov wrote: >> Hi Chris, >> >> Please review a new version of the fix [1] that converts the check to >> the assert. >> >>> Also, I'm not clear on the need for the *pkernelLoad >>> initialization. It >>> seems this is attempting to fix a different issue, but it's already >>> initialized to 0 at the start of the function. >> You are right, *pkernelLoad is already initialized on line 251. The >> new version of >> the webrev does not include this change. >> >> [1] Webrev: http://cr.openjdk.java.net/~dtitov/8235681/webrev.02/ >> [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8235681 >> >> Thank you, >> Daniil >> >> ?On 1/21/20, 10:38 AM, "Chris Plummer" wrote: >> >> Hi Daniil, >> Do you think it's worth changing the check to an assert instead of >> removing it? >> Also, I'm not clear on the need for the *pkernelLoad >> initialization. It >> seems this is attempting to fix a different issue, but it's already >> initialized to 0 at the start of the function. >> thanks, >> Chris >> On 1/17/20 7:10 PM, Daniil Titov wrote: >> > Please review a change that removes unnecessary workaround in >> UnixOperatingSystem.c. >> > >> > It looks as this workaround >> > >> > if (pticks->usedKernel < tmp.usedKernel) { >> > kdiff = 0; >> > } >> > >> > was added to compensate a missed initialization of >> counters.jvmTicks that resulted in the new >> > counters being compared with the garbage when >> get_cpuload_internal(...) was called for the first time. >> > >> > This missed initialization was fixed in [3]. >> > >> > Mach5 tier1-tier3 and open/test/hotspot/jtreg/containers/docker >> tests successfully passed. >> > >> > [1] Webrev : http://cr.openjdk.java.net/~dtitov/8235681/webrev.01/ >> > [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8235681 >> > [3] https://bugs.openjdk.java.net/browse/JDK-8226575 >> > >> > Thank you, >> > Daniil >> > >> > >> >> > > From richard.reingruber at sap.com Tue Jan 28 15:31:31 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Tue, 28 Jan 2020 15:31:31 +0000 Subject: VM_EnterInterpOnlyMode: why make compiled methods on stack not_entrant? Message-ID: Hi, I noticed that VM_EnterInterpOnlyMode makes all compiled methods on stack not_entrant. To me this seems unnecessary. I think it would be sufficient to patch the return pc of compiled frames and let them return to their deopt handler. Or what would be the reason to make the compiled methods not_entrant? VM_EnterInterpOnlyMode::doit(): all compiled methods on stack that are not native methods get marked. Deoptimization::deoptimize_all_marked(): all marked methods are made not_entrant. Maybe this is for historical reasons? If I remember correctly, many years ago, deoptimizing a compiled frame used to require making the corresponding nmethod not_entrant. And making a nmethod not_entrant meant overriding its code with a slide of nops that led to the deopt handler. I'd like to change this and just apply Deoptimization::deoptimize() on every compiled frame on stack. I've done this locally and tested the change without issues. Thanks, Richard. From vladimir.x.ivanov at oracle.com Thu Jan 30 16:55:25 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 30 Jan 2020 19:55:25 +0300 Subject: VM_EnterInterpOnlyMode: why make compiled methods on stack not_entrant? In-Reply-To: References: Message-ID: <7dd97d12-dc9f-99cc-384a-4d1ccfe516dd@oracle.com> Hi Richard, > I noticed that VM_EnterInterpOnlyMode makes all compiled methods on stack not_entrant. To me this > seems unnecessary. I think it would be sufficient to patch the return pc of compiled frames and > let them return to their deopt handler. Or what would be the reason to make the compiled methods > not_entrant? > > VM_EnterInterpOnlyMode::doit(): all compiled methods on stack that are not native methods get > marked. > > Deoptimization::deoptimize_all_marked(): all marked methods are made not_entrant. > > Maybe this is for historical reasons? If I remember correctly, many years ago, deoptimizing a > compiled frame used to require making the corresponding nmethod not_entrant. And making a nmethod > not_entrant meant overriding its code with a slide of nops that led to the deopt handler. > > I'd like to change this and just apply Deoptimization::deoptimize() on every compiled frame on > stack. I've done this locally and tested the change without issues. I'm not a JVMTI expert, but considering VM_EnterInterpOnlyMode is performed on per-thread basis [1], it looks like per-frame deoptimization (instead of per-nmethod) should be enough to do the job. So, from JIT-compiler perspective, your suggestion to use Deoptimization::deoptimize() instead of CompiledMethod::mark_for_deoptimization()/Deoptimization::deoptimize_all_marked() sounds good. PS: also, it looks like handshakes become a perfect fit for VM_EnterInterpOnlyMode: once you don't need to deoptimize on per-nmethod basis, there's no need to trigger global safepoint. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/share/prims/jvmtiEventController.cpp#l227 // If running in fullspeed mode, single stepping is implemented // as follows: first, the interpreter does not dispatch to // compiled code for threads that have single stepping enabled; // second, we deoptimize all methods on the thread's stack when // interpreted-only mode is enabled the first time for a given // thread (nothing to do if no Java frames yet). From chris.plummer at oracle.com Fri Jan 31 06:10:19 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 30 Jan 2020 22:10:19 -0800 Subject: [14] RFR: 8238196: tests that use SA Attach should not be allowed to run against signed binaries on Mac OS X 10.14.5 and later Message-ID: Hello, Please review the following fix for some SA tests that are failing on Mac OS X 10.14.5 and later: https://bugs.openjdk.java.net/browse/JDK-8238196 http://cr.openjdk.java.net/~cjplummer/8236913/webrev.00 The issue is that SA can't attach to a signed binary starting with 10.14.5. There is no workaround for this, so these tests are being disabled when it is detected that the binary is signed and we are running on 10.14 or later (I chose all 10.14 releases to simplify the check). Some background may help explain the fix. In order for SA to attach to a live process (not a core file) on OSX, either the attaching process (ie. the test) has to be run as root, or sudo needs to be supported. However, the only tests that make the sudo check are the 20 or so that use ClhsdbLauncher. The rest all rely on "@requires vm.hasSAandCanAttach" to filter out tests that use SA attach. vm.hasSAandCanAttach only checks if the test is being run as root. Thus all our non-ClhsdbLauncher tests that SA attach to a live process are currently not run unless they are run as root. 8238268 [1] has been filed to address this, making it so all the tests will attempt to use sudo if not run as root. Because of the difference in how ClhsdbLauncher tests and "@requires? vm.hasSAandCanAttach" tests check to see if they are runnable, this fix needs to address both types of checks. The common code for both these cases is Platform.shouldSAAttach(), which on OSX basically equates to check to see if we are running as root. I changed it to also return false if running on signed binary with 10.14 or later. However, this confused the ClhsdbLauncher use of Platform.shouldSAAttach() somewhat, since it assumed a false result only happens because you are not running as root (in which case it would then check if sudo will work). So ClhsdbLauncher now has double check that the false result was not because of running a signed binary. If it is signed, it won't do the sudo check. This will get cleaned up with 8238268 [1], which will move the sudo check into Platform.shouldSAAttach(). thanks, Chris [1] https://bugs.openjdk.java.net/browse/JDK-8238268 From igor.ignatyev at oracle.com Fri Jan 31 06:13:09 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 30 Jan 2020 22:13:09 -0800 Subject: [14] RFR: 8238196: tests that use SA Attach should not be allowed to run against signed binaries on Mac OS X 10.14.5 and later In-Reply-To: References: Message-ID: <39200476-D017-4BFD-ABF2-8ABC59ADA8C0@oracle.com> Hi Chris, http://cr.openjdk.java.net/~cjplummer/8236913/webrev.00 seems to be a webrev from another issue, should it have been http://cr.openjdk.java.net/~cjplummer/8238196/webrev.00/ ? -- Igor > On Jan 30, 2020, at 10:10 PM, Chris Plummer wrote: > > Hello, > > Please review the following fix for some SA tests that are failing on Mac OS X 10.14.5 and later: > > https://bugs.openjdk.java.net/browse/JDK-8238196 > http://cr.openjdk.java.net/~cjplummer/8236913/webrev.00 > > The issue is that SA can't attach to a signed binary starting with 10.14.5. There is no workaround for this, so these tests are being disabled when it is detected that the binary is signed and we are running on 10.14 or later (I chose all 10.14 releases to simplify the check). > > Some background may help explain the fix. In order for SA to attach to a live process (not a core file) on OSX, either the attaching process (ie. the test) has to be run as root, or sudo needs to be supported. However, the only tests that make the sudo check are the 20 or so that use ClhsdbLauncher. The rest all rely on "@requires vm.hasSAandCanAttach" to filter out tests that use SA attach. vm.hasSAandCanAttach only checks if the test is being run as root. Thus all our non-ClhsdbLauncher tests that SA attach to a live process are currently not run unless they are run as root. 8238268 [1] has been filed to address this, making it so all the tests will attempt to use sudo if not run as root. > > Because of the difference in how ClhsdbLauncher tests and "@requires vm.hasSAandCanAttach" tests check to see if they are runnable, this fix needs to address both types of checks. The common code for both these cases is Platform.shouldSAAttach(), which on OSX basically equates to check to see if we are running as root. I changed it to also return false if running on signed binary with 10.14 or later. However, this confused the ClhsdbLauncher use of Platform.shouldSAAttach() somewhat, since it assumed a false result only happens because you are not running as root (in which case it would then check if sudo will work). So ClhsdbLauncher now has double check that the false result was not because of running a signed binary. If it is signed, it won't do the sudo check. This will get cleaned up with 8238268 [1], which will move the sudo check into Platform.shouldSAAttach(). > > thanks, > > Chris > > [1] https://bugs.openjdk.java.net/browse/JDK-8238268 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Jan 31 06:20:11 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 30 Jan 2020 22:20:11 -0800 Subject: [14] RFR: 8238196: tests that use SA Attach should not be allowed to run against signed binaries on Mac OS X 10.14.5 and later In-Reply-To: <39200476-D017-4BFD-ABF2-8ABC59ADA8C0@oracle.com> References: <39200476-D017-4BFD-ABF2-8ABC59ADA8C0@oracle.com> Message-ID: <3edb4c50-588d-d111-2a39-c9859ec64931@oracle.com> An HTML attachment was scrubbed... URL: From richard.reingruber at sap.com Fri Jan 31 17:24:50 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Fri, 31 Jan 2020 17:24:50 +0000 Subject: VM_EnterInterpOnlyMode: why make compiled methods on stack not_entrant? In-Reply-To: <7dd97d12-dc9f-99cc-384a-4d1ccfe516dd@oracle.com> References: <7dd97d12-dc9f-99cc-384a-4d1ccfe516dd@oracle.com> Message-ID: Hi Vladimir, thanks for looking at this and providing feedback. I though as well about using a handshake there. I'll try it. Thanks, Richard. -----Original Message----- From: Vladimir Ivanov Sent: Donnerstag, 30. Januar 2020 17:55 To: Reingruber, Richard ; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Subject: Re: VM_EnterInterpOnlyMode: why make compiled methods on stack not_entrant? Hi Richard, > I noticed that VM_EnterInterpOnlyMode makes all compiled methods on stack not_entrant. To me this > seems unnecessary. I think it would be sufficient to patch the return pc of compiled frames and > let them return to their deopt handler. Or what would be the reason to make the compiled methods > not_entrant? > > VM_EnterInterpOnlyMode::doit(): all compiled methods on stack that are not native methods get > marked. > > Deoptimization::deoptimize_all_marked(): all marked methods are made not_entrant. > > Maybe this is for historical reasons? If I remember correctly, many years ago, deoptimizing a > compiled frame used to require making the corresponding nmethod not_entrant. And making a nmethod > not_entrant meant overriding its code with a slide of nops that led to the deopt handler. > > I'd like to change this and just apply Deoptimization::deoptimize() on every compiled frame on > stack. I've done this locally and tested the change without issues. I'm not a JVMTI expert, but considering VM_EnterInterpOnlyMode is performed on per-thread basis [1], it looks like per-frame deoptimization (instead of per-nmethod) should be enough to do the job. So, from JIT-compiler perspective, your suggestion to use Deoptimization::deoptimize() instead of CompiledMethod::mark_for_deoptimization()/Deoptimization::deoptimize_all_marked() sounds good. PS: also, it looks like handshakes become a perfect fit for VM_EnterInterpOnlyMode: once you don't need to deoptimize on per-nmethod basis, there's no need to trigger global safepoint. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/share/prims/jvmtiEventController.cpp#l227 // If running in fullspeed mode, single stepping is implemented // as follows: first, the interpreter does not dispatch to // compiled code for threads that have single stepping enabled; // second, we deoptimize all methods on the thread's stack when // interpreted-only mode is enabled the first time for a given // thread (nothing to do if no Java frames yet). From daniil.x.titov at oracle.com Fri Jan 31 21:08:51 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 31 Jan 2020 13:08:51 -0800 Subject: RFR: 8196729: Add jstatd option to specify RMI connector port Message-ID: Please review change [1] that adds a new command line option to jstatd tool to specify a RMI connector port. Currently a random port is used that prevents this tool from being used behind a firewall or in a container. New CSR [3] was created for this change and it needs to be reviewed as well. Man pages for jstatd will be updated in a separate issue. Testing: Mach5 tier1-tier3 and sun/tools/jstatd/* tests succeeded. Mach5 tier5 tests are in progress. [1] Webrev: http://cr.openjdk.java.net/~dtitov/8196729/webrev.01/ [2] Jira issue: https://bugs.openjdk.java.net/browse/JDK-8196729 [3] CSR : https://bugs.openjdk.java.net/browse/JDK-8238357 Thank you, Daniil From chris.plummer at oracle.com Fri Jan 31 21:45:54 2020 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 31 Jan 2020 13:45:54 -0800 Subject: RFR: 8196729: Add jstatd option to specify RMI connector port In-Reply-To: References: Message-ID: <34e9a3e4-1635-19df-bcbb-b239c6feee64@oracle.com> Hi Daniil, Just want to make sure I understand what communications are going on here. Your concern is when the jstat and jstatd processes are on different sides of the firewall. When you launch jstatd, you specify the socket port it will receive requests on, and when you launch jstat, you must specify this same socket port, so no firewall problem there assuming the firewall is configured to allow communication over that port. However, once the request is received by jstatd, data can be communicated via RMI rather than over the specified socket port. By default jstatd was choosing a random RMI port, and I assume this RMI port was communicated to the jstat process via the initial socket port. This presents a problem for firewall configuration, since the firewall configuration cannot know the RMI port that will be used. So now you're allowing the rmi port to also be specified. Am I close? :) Chris On 1/31/20 1:08 PM, Daniil Titov wrote: > Please review change [1] that adds a new command line option to jstatd tool to specify a RMI connector port. > > Currently a random port is used that prevents this tool from being used behind a firewall or in a container. > > New CSR [3] was created for this change and it needs to be reviewed as well. > > Man pages for jstatd will be updated in a separate issue. > > Testing: Mach5 tier1-tier3 and sun/tools/jstatd/* tests succeeded. Mach5 tier5 tests are in progress. > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8196729/webrev.01/ > [2] Jira issue: https://bugs.openjdk.java.net/browse/JDK-8196729 > [3] CSR : https://bugs.openjdk.java.net/browse/JDK-8238357 > > Thank you, > Daniil > > > From daniil.x.titov at oracle.com Fri Jan 31 22:14:48 2020 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 31 Jan 2020 14:14:48 -0800 Subject: RFR: 8196729: Add jstatd option to specify RMI connector port In-Reply-To: <34e9a3e4-1635-19df-bcbb-b239c6feee64@oracle.com> References: <34e9a3e4-1635-19df-bcbb-b239c6feee64@oracle.com> Message-ID: <4B822AF4-BDA2-42B8-B3E8-F4232ECA4784@oracle.com> Hi Chris, Thank you for describing this in such details! Your description is correct. In addition, apart from jstat there is jps tool that also can communicate with jstatd and currently it faces the same problems if jstatd is deployed behind a firewall or in a container: after successful connection to RMI registry the further communication fails since jstatd chooses a random RMI port that is not published by the container or might be blocked by a firewall configuration. Best regards, Daniil ?On 1/31/20, 1:45 PM, "Chris Plummer" wrote: Hi Daniil, Just want to make sure I understand what communications are going on here. Your concern is when the jstat and jstatd processes are on different sides of the firewall. When you launch jstatd, you specify the socket port it will receive requests on, and when you launch jstat, you must specify this same socket port, so no firewall problem there assuming the firewall is configured to allow communication over that port. However, once the request is received by jstatd, data can be communicated via RMI rather than over the specified socket port. By default jstatd was choosing a random RMI port, and I assume this RMI port was communicated to the jstat process via the initial socket port. This presents a problem for firewall configuration, since the firewall configuration cannot know the RMI port that will be used. So now you're allowing the rmi port to also be specified. Am I close? :) Chris On 1/31/20 1:08 PM, Daniil Titov wrote: > Please review change [1] that adds a new command line option to jstatd tool to specify a RMI connector port. > > Currently a random port is used that prevents this tool from being used behind a firewall or in a container. > > New CSR [3] was created for this change and it needs to be reviewed as well. > > Man pages for jstatd will be updated in a separate issue. > > Testing: Mach5 tier1-tier3 and sun/tools/jstatd/* tests succeeded. Mach5 tier5 tests are in progress. > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8196729/webrev.01/ > [2] Jira issue: https://bugs.openjdk.java.net/browse/JDK-8196729 > [3] CSR : https://bugs.openjdk.java.net/browse/JDK-8238357 > > Thank you, > Daniil > > >