From daniel.daugherty at oracle.com Tue Dec 1 01:24:06 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 30 Nov 2015 18:24:06 -0700 Subject: CompiledMethodLoad and DynamicCodeGenerated events fired after VMDeath event In-Reply-To: References: Message-ID: <565CF6B6.8010104@oracle.com> Carsten, Maybe this bug: JDK-8067876 demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java fails due to 112(JVMTI_ERROR_WRONG_PHASE) https://bugs.openjdk.java.net/browse/JDK-8067876 at least for the JVM/TI phase part... Dan On 11/30/15 3:27 PM, Carsten Varming wrote: > Dear Serviceability list, > > I recently ran into an issue discussed in 2009 > (http://mail.openjdk.java.net/pipermail/serviceability-dev/2009-February/000736.html) > where the JVMTI events CompiledMethodLoad and DynamicCodeGenerated are > emitted after the VM has switched to the dead phase. Is there a bug > for this issue somewhere (I was unable to find one). > > I suggest we fix the issue by shutting down the service thread just > before emitting the VMDeath event in > hotspot/src/share/vm/runtime/java.cpp:before_exit. I have put a patch > here http://cr.openjdk.java.net/~cvarming/service_thread.hotspot.00/ > . > With the patch before_exit request the service thread to shut down in > much the same way before_exit requests the watcher thread to shut > down. The service thread will complete any outstanding work before > recognizing the request to shut down. > > The patch also fixes a minor issue with the watcher thread where > enrolling a task after shutdown can start a new watcher thread. > > The patch also contains a test with a JVMTI agent that checks that > events are fired in the right phases as specified in the JVMTI doc > (http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html). I > started with a few basic events. I can add more events if desired. > > I also had to fix make/common/TestFilesCompilation.gmk in the top repo > to enable C++ for tests with native code. See > http://cr.openjdk.java.net/~cvarming/service_thread.toplevel.00/ > > > Let me know what you think, > Carsten From jaroslav.bachorik at oracle.com Tue Dec 1 10:06:55 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 1 Dec 2015 11:06:55 +0100 Subject: [pong] Re: jmx-dev RFR 8142398: ManagementAgent.status diagnostic command only outputs the specifically set properties In-Reply-To: <5643644B.2080102@oracle.com> References: <5643644B.2080102@oracle.com> Message-ID: <565D713F.20407@oracle.com> On 11.11.2015 16:52, Jaroslav Bachorik wrote: > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8142398 > Webrev: http://cr.openjdk.java.net/~jbachorik/8142398/webrev.00 > > This patch adds the list of the default agent properties with the info > whether the default value has been overridden to the > ManagementAgent.status DCMD output. > > Thanks, > > -JB- From sgehwolf at redhat.com Tue Dec 1 10:17:09 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Dec 2015 11:17:09 +0100 Subject: [PING] RFR 6425769: jmx remote bind address In-Reply-To: <1447061525.3551.3.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> Message-ID: <1448965029.4309.10.camel@redhat.com> On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > > Hi, > > > > Updated webrev with jtreg test in Java: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ > > bug:?https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > I believe this updated webrev addresses all concerns and > > incorporates > > suggestions brought up by Jaroslav and Daniel. > > > > I'm still looking for a sponsor and a hotspot/servicability-dev > > reviewer. Could somebody maintaining javax.rmi.ssl have a look at > > this > > as well? Thank you! > > Ping? Friendly reminder that I still need reviewers and a sponsor for > this. Anyone? > Thanks, > Severin > > > Cheers, > > Severin > > > > On Tue, 2015-11-03 at 15:45 +0100, Jaroslav Bachorik wrote: > > > On 2.11.2015 19:06, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Thanks Jaroslav and Daniel for the reviews! Comments inline. > > > > > > > > On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote: > > > > > Hi, > > > > > > > > > > On 2.11.2015 16:19, Daniel Fuchs wrote: > > > > > > Hi Severin, > > > > > > > > > > > > Adding serviceability-dev at openjdk.java.net into the loop - > > > > > > that's > > > > > > a better alias than hotspot-dev for this kind of changes - > > > > > > maybe > > > > > > someone from serviceability-dev will offer to sponsor :-) > > > > > > > > > > > > I will let serviceability team members comment on the > > > > > > hotspot > > > > > > changes. > > > > > > > > > > > > ConnectorBootstrap.java > > > > > > > > > > > > I have one suggestion and one concern: > > > > > > > > > > > > Suggestion: I would suggest to reuse 'csf' (Client Socket > > > > > > Factory) > > > > > > and > > > > > > ssf??(Server Socket Factory) variables rather than > > > > > > introduce > > > > > > the > > > > > > two > > > > > > new variables rmiServerSocketFactory and > > > > > > rmiClientSocketFactory. > > > > > > You might want to create a new boolean 'useSocketFactory' > > > > > > variable, > > > > > > if that makes the code more readable. > > > > > > > > > > > > Concern: If I understand correctly how RMI socket factories > > > > > > work, > > > > > > the client socket factory will be serialized and sent to > > > > > > the > > > > > > client > > > > > > side. This is problematic for interoperability, as the > > > > > > class > > > > > > may > > > > > > not > > > > > > present in the remote client - if the remote client is e.g. > > > > > > jdk > > > > > > 8. > > > > > > > > > > > > As far as I can see, your new DefaultClientSocketFactory > > > > > > doesn't do > > > > > > anything useful - so I would suggest to simply get rid of > > > > > > it, > > > > > > and > > > > > > only > > > > > > set the Server Socket Factory when SSL is not involved. > > > > > > > > Thanks. Fixed in updated webrev. > > > > > > > > > > Tests: > > > > > > > > > > > > Concerning the tests - we're trying to get rid of shell > > > > > > scripts > > > > > > rather than introducing new ones :-) > > > > > > Could the test be rewritten in pure java using the Process > > > > > > API? > > > > > > > > > > > > I believe there's even a test library that will let you do > > > > > > that > > > > > > easily jdk/test/lib/testlibrary/jdk/testlibrary/ > > > > > > (see ProcessTools.java) > > > > > > > > It'll take me a bit to rewrite the test in pure Java, but > > > > should > > > > be > > > > fine. This is not yet fixed in the updated webrev. > > > > > > > > > > Other: > > > > > > > > > > > > Also - I believe the new option should be documented in: > > > > > > src/java.management/share/conf/management.properties > > > > > > > > Docs have been updated > > > > in src/java.management/share/conf/management.properties. > > > > > > > > > I share Daniel's concerns. Also, the part of the changeset is > > > > > related > > > > > to javax.rmi.ssl - someone maintaining this library should > > > > > also > > > > > comment here. > > > > > > > > > > Also, the change is introducing new API (system property) and > > > > > changing the existing one (adding SslRmiServerSocketFactory > > > > > public > > > > > constructors) so compatibility review process will have to be > > > > > involved. > > > > > > > > OK. What exactly is there for me to do? I'm not familiar with > > > > this > > > > process. Note that the intent would be to get this backported > > > > to > > > > JDK 8. > > > Not much for you. But for the potential Oracle sponsor this means > > > she > > > will have to remember to go through some extra hoops before > > > integrating your patch. > > > > I see. Thanks for clarifying it. > > > > > -JB- > > > > > > > > > > > New webrev at: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/ > > > > > > > > Thanks, > > > > Severin > > > > > > > > > -JB- > > > > > > > > > > > > best regards, > > > > > > > > > > > > -- daniel > > > > > > > > > > > > On 02/11/15 11:38, Severin Gehwolf wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Here is a patch addressing JDK-6425769. The issue is that > > > > > > > the > > > > > > > JMX > > > > > > > agent > > > > > > > binds to the wildcard address by default, preventing > > > > > > > users > > > > > > > to > > > > > > > use > > > > > > > system properties for JMX agents on multi-homed hosts. > > > > > > > Given > > > > > > > a > > > > > > > host > > > > > > > with local network interfaces, 192.168.0.1 and > > > > > > > 192.168.0.2 > > > > > > > say, > > > > > > > it's > > > > > > > impossible to start two JMX agents binding to fixed ports > > > > > > > but > > > > > > > to > > > > > > > different network interfaces, 192.168.0.1:{9111,9112} and > > > > > > > 192.168.0.2:{9111,9112} say. > > > > > > > > > > > > > > The JDK would bind to all local interfaces by default. In > > > > > > > the > > > > > > > above > > > > > > > example to 192.168.0.1 *and* 192.168.0.2. The effect is > > > > > > > that > > > > > > > the > > > > > > > second > > > > > > > Java process would get a "Connection refused" error > > > > > > > because > > > > > > > another > > > > > > > process has already been bound to the specified JMX/RMI > > > > > > > port > > > > > > > pairs. > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > > > > > 64 > > > > > > > 25 > > > > > > > 769/ > > > > > > > 00/ > > > > > > > > > > > > > > Testing done: > > > > > > > jdk_jmx and jdk_management tests all pass after this > > > > > > > change > > > > > > > (no > > > > > > > regressions). There is also a new JTREG test which fails > > > > > > > prior > > > > > > > this > > > > > > > change and passes after. Updates to the diagnostic > > > > > > > command > > > > > > > have > > > > > > > been > > > > > > > tested manually. > > > > > > > > > > > > > > I understand that, if approved, the JDK and hotspot > > > > > > > changes > > > > > > > should get > > > > > > > pushed together? Hotspot changes are fairly trivial since > > > > > > > it's > > > > > > > only a > > > > > > > doc-update for the new JDK property in the relevant > > > > > > > diagnostic > > > > > > > command. > > > > > > > > > > > > > > Could someone please review and sponsor this change? > > > > > > > Please > > > > > > > let > > > > > > > me know > > > > > > > if there are questions. > > > > > > > > > > > > > > Thanks, > > > > > > > Severin > > > > > > > > > > > > > > > > > > > > > > > > > > > > From jaroslav.bachorik at oracle.com Tue Dec 1 11:33:38 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 1 Dec 2015 12:33:38 +0100 Subject: [PING] RFR 6425769: jmx remote bind address In-Reply-To: <1448965029.4309.10.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> Message-ID: <565D8592.6020701@oracle.com> On 1.12.2015 11:17, Severin Gehwolf wrote: > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: >> On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: >>> Hi, >>> >>> Updated webrev with jtreg test in Java: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-6425769 >>> >>> I believe this updated webrev addresses all concerns and >>> incorporates >>> suggestions brought up by Jaroslav and Daniel. >>> >>> I'm still looking for a sponsor and a hotspot/servicability-dev >>> reviewer. Could somebody maintaining javax.rmi.ssl have a look at >>> this >>> as well? Thank you! >> >> Ping? Friendly reminder that I still need reviewers and a sponsor for >> this. > > Anyone? I'm sorry for not spotting this earlier: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi-ssl-factory-changes/jdk/src/java.management/share/classes/sun/management/jmxremote/ConnectorBootstrap.java.sdiff.html * L442 - the log would contain 'com.sun.management.jmxremote.host = null' if host is not specified; might be better not to print this out at all Other than that the change looks good to me. If no one else is volunteering I may sponsor this change. Cheers, -JB- > >> Thanks, >> Severin >> >>> Cheers, >>> Severin >>> >>> On Tue, 2015-11-03 at 15:45 +0100, Jaroslav Bachorik wrote: >>>> On 2.11.2015 19:06, Severin Gehwolf wrote: >>>>> Hi, >>>>> >>>>> Thanks Jaroslav and Daniel for the reviews! Comments inline. >>>>> >>>>> On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote: >>>>>> Hi, >>>>>> >>>>>> On 2.11.2015 16:19, Daniel Fuchs wrote: >>>>>>> Hi Severin, >>>>>>> >>>>>>> Adding serviceability-dev at openjdk.java.net into the loop - >>>>>>> that's >>>>>>> a better alias than hotspot-dev for this kind of changes - >>>>>>> maybe >>>>>>> someone from serviceability-dev will offer to sponsor :-) >>>>>>> >>>>>>> I will let serviceability team members comment on the >>>>>>> hotspot >>>>>>> changes. >>>>>>> >>>>>>> ConnectorBootstrap.java >>>>>>> >>>>>>> I have one suggestion and one concern: >>>>>>> >>>>>>> Suggestion: I would suggest to reuse 'csf' (Client Socket >>>>>>> Factory) >>>>>>> and >>>>>>> ssf (Server Socket Factory) variables rather than >>>>>>> introduce >>>>>>> the >>>>>>> two >>>>>>> new variables rmiServerSocketFactory and >>>>>>> rmiClientSocketFactory. >>>>>>> You might want to create a new boolean 'useSocketFactory' >>>>>>> variable, >>>>>>> if that makes the code more readable. >>>>>>> >>>>>>> Concern: If I understand correctly how RMI socket factories >>>>>>> work, >>>>>>> the client socket factory will be serialized and sent to >>>>>>> the >>>>>>> client >>>>>>> side. This is problematic for interoperability, as the >>>>>>> class >>>>>>> may >>>>>>> not >>>>>>> present in the remote client - if the remote client is e.g. >>>>>>> jdk >>>>>>> 8. >>>>>>> >>>>>>> As far as I can see, your new DefaultClientSocketFactory >>>>>>> doesn't do >>>>>>> anything useful - so I would suggest to simply get rid of >>>>>>> it, >>>>>>> and >>>>>>> only >>>>>>> set the Server Socket Factory when SSL is not involved. >>>>> >>>>> Thanks. Fixed in updated webrev. >>>>> >>>>>>> Tests: >>>>>>> >>>>>>> Concerning the tests - we're trying to get rid of shell >>>>>>> scripts >>>>>>> rather than introducing new ones :-) >>>>>>> Could the test be rewritten in pure java using the Process >>>>>>> API? >>>>>>> >>>>>>> I believe there's even a test library that will let you do >>>>>>> that >>>>>>> easily jdk/test/lib/testlibrary/jdk/testlibrary/ >>>>>>> (see ProcessTools.java) >>>>> >>>>> It'll take me a bit to rewrite the test in pure Java, but >>>>> should >>>>> be >>>>> fine. This is not yet fixed in the updated webrev. >>>>> >>>>>>> Other: >>>>>>> >>>>>>> Also - I believe the new option should be documented in: >>>>>>> src/java.management/share/conf/management.properties >>>>> >>>>> Docs have been updated >>>>> in src/java.management/share/conf/management.properties. >>>>> >>>>>> I share Daniel's concerns. Also, the part of the changeset is >>>>>> related >>>>>> to javax.rmi.ssl - someone maintaining this library should >>>>>> also >>>>>> comment here. >>>>>> >>>>>> Also, the change is introducing new API (system property) and >>>>>> changing the existing one (adding SslRmiServerSocketFactory >>>>>> public >>>>>> constructors) so compatibility review process will have to be >>>>>> involved. >>>>> >>>>> OK. What exactly is there for me to do? I'm not familiar with >>>>> this >>>>> process. Note that the intent would be to get this backported >>>>> to >>>>> JDK 8. >>>> Not much for you. But for the potential Oracle sponsor this means >>>> she >>>> will have to remember to go through some extra hoops before >>>> integrating your patch. >>> >>> I see. Thanks for clarifying it. >>> >>>> -JB- >>>> >>>>> >>>>> New webrev at: >>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/ >>>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>>> -JB- >>>>>>> >>>>>>> best regards, >>>>>>> >>>>>>> -- daniel >>>>>>> >>>>>>> On 02/11/15 11:38, Severin Gehwolf wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Here is a patch addressing JDK-6425769. The issue is that >>>>>>>> the >>>>>>>> JMX >>>>>>>> agent >>>>>>>> binds to the wildcard address by default, preventing >>>>>>>> users >>>>>>>> to >>>>>>>> use >>>>>>>> system properties for JMX agents on multi-homed hosts. >>>>>>>> Given >>>>>>>> a >>>>>>>> host >>>>>>>> with local network interfaces, 192.168.0.1 and >>>>>>>> 192.168.0.2 >>>>>>>> say, >>>>>>>> it's >>>>>>>> impossible to start two JMX agents binding to fixed ports >>>>>>>> but >>>>>>>> to >>>>>>>> different network interfaces, 192.168.0.1:{9111,9112} and >>>>>>>> 192.168.0.2:{9111,9112} say. >>>>>>>> >>>>>>>> The JDK would bind to all local interfaces by default. In >>>>>>>> the >>>>>>>> above >>>>>>>> example to 192.168.0.1 *and* 192.168.0.2. The effect is >>>>>>>> that >>>>>>>> the >>>>>>>> second >>>>>>>> Java process would get a "Connection refused" error >>>>>>>> because >>>>>>>> another >>>>>>>> process has already been bound to the specified JMX/RMI >>>>>>>> port >>>>>>>> pairs. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 >>>>>>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- >>>>>>>> 64 >>>>>>>> 25 >>>>>>>> 769/ >>>>>>>> 00/ >>>>>>>> >>>>>>>> Testing done: >>>>>>>> jdk_jmx and jdk_management tests all pass after this >>>>>>>> change >>>>>>>> (no >>>>>>>> regressions). There is also a new JTREG test which fails >>>>>>>> prior >>>>>>>> this >>>>>>>> change and passes after. Updates to the diagnostic >>>>>>>> command >>>>>>>> have >>>>>>>> been >>>>>>>> tested manually. >>>>>>>> >>>>>>>> I understand that, if approved, the JDK and hotspot >>>>>>>> changes >>>>>>>> should get >>>>>>>> pushed together? Hotspot changes are fairly trivial since >>>>>>>> it's >>>>>>>> only a >>>>>>>> doc-update for the new JDK property in the relevant >>>>>>>> diagnostic >>>>>>>> command. >>>>>>>> >>>>>>>> Could someone please review and sponsor this change? >>>>>>>> Please >>>>>>>> let >>>>>>>> me know >>>>>>>> if there are questions. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Severin >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From sgehwolf at redhat.com Tue Dec 1 13:19:05 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Dec 2015 14:19:05 +0100 Subject: [PING] RFR 6425769: jmx remote bind address In-Reply-To: <565D8592.6020701@oracle.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> <565D8592.6020701@oracle.com> Message-ID: <1448975945.4309.16.camel@redhat.com> Hi Jaroslav, On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: > On 1.12.2015 11:17, Severin Gehwolf wrote: > > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > > > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Updated webrev with jtreg test in Java: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ > > > > bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > > > > I believe this updated webrev addresses all concerns and > > > > incorporates > > > > suggestions brought up by Jaroslav and Daniel. > > > > > > > > I'm still looking for a sponsor and a hotspot/servicability-dev > > > > reviewer. Could somebody maintaining javax.rmi.ssl have a look at > > > > this > > > > as well? Thank you! > > > > > > Ping? Friendly reminder that I still need reviewers and a sponsor for > > > this. > > > > Anyone? > > I'm sorry for not spotting this earlier: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi-ssl-factory-changes/jdk/src/java.management/share/classes/sun/management/jmxremote/ConnectorBootstrap.java.sdiff.html > * L442 - the log would contain 'com.sun.management.jmxremote.host =? > null' if host is not specified; might be better not to print this out at all Updated webrev which does not print 'com.sun.management.jmxremote.host = null' if unset: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/05/ > Other than that the change looks good to me. If no one else is > volunteering I may sponsor this change. Thank you! Cheers, Severin > Cheers, > > -JB- From yasuenag at gmail.com Tue Dec 1 14:35:53 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 1 Dec 2015 23:35:53 +0900 Subject: RFR: JDK-8144332: HSDB could not terminate when close button is pushed. Message-ID: <565DB049.1010506@gmail.com> Hi all, When I ran HSDB through jhsdb, I could not terminate it through window close button. HSDB starts WorkerThread. It will be terminated when Exit menu is selected. However, it will not be shotdown when HSDB is terminated through close button. I've created a patch and uploaded webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8144332/webrev.00/ Could you review it? I'm jdk 9 committer, however, I could not access JPRT. Thus I need a sponsor. Could you help? Thanks, Yasumasa From jaroslav.bachorik at oracle.com Tue Dec 1 17:33:52 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 1 Dec 2015 18:33:52 +0100 Subject: RFR 8144308: com/sun/jdi/SuspendThreadTest.java failed with "transport error 202: send failed: Broken pipe" Message-ID: <565DDA00.8090007@oracle.com> Please, review the following simple test change Issue : https://bugs.openjdk.java.net/browse/JDK-8144308 Webrev: http://cr.openjdk.java.net/~jbachorik/8144308/webrev.00 The test keeps the debuggee spinning in a loop and does not stop it once the testing is over. While the harness usually takes care of this, occasionally it fails while trying to do that. The fix is to add a loop invariant variable and set it to false once we are done with the debugee and it is ok for it to finish. Thanks, -JB- From jaroslav.bachorik at oracle.com Tue Dec 1 17:51:32 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 1 Dec 2015 18:51:32 +0100 Subject: RFR 8141526: Allow to collect stdout/stderr from the FinalizationRunner even before the process returns In-Reply-To: <565C269F.1050206@oracle.com> References: <563CD13B.8040800@oracle.com> <56562D60.80306@oracle.com> <565C269F.1050206@oracle.com> Message-ID: <565DDE24.1030902@oracle.com> On 30.11.2015 11:36, Jaroslav Bachorik wrote: > On 25.11.2015 22:51, Dmitry Samersoff wrote: >> Jaroslav, >> >> Looks good for me. > > Thanks! Could I have someone from outside of svc to take a look at this > as well? The change needs to augment the hotspot test library with some > features from the jdk hotspot library. And in order not to duplicate the > code it consolidate these library classes into the shared library. Last call - if I am not hearing any objections I am going to integrate this patch tomorrow. Regards, -JB- > > >> >> PS: I found a bug in canPtraceAttachLinux not related to your changes - >> it's probably my mistake: >> >> 181 if (userName.equals("root")) { >> 182 return true; >> 183 } >> >> shouldn't be there. >> >> Could you file a separate CR and assign it to me? > > Will do. > > -JB- > >> >> -Dmitry >> >> On 2015-11-06 19:11, Jaroslav Bachorik wrote: >>> [wider audience included] >>> >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8141526 >>> Webrev: >>> top> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00 >>> hotspot> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/hotspot >>> jdk> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/jdk >>> >>> After the fix for https://bugs.openjdk.java.net/browse/JDK-8135188 we >>> are not able to get the debug info about the run of the launcher >>> FinalizationRunner application in case it gets stuck and harness times >>> out. This is because the stdout/err of the application started via >>> ProcessTools.executeProcess() is collected only after the application >>> has exited. >>> >>> The solution is to use ProcessTools.startProcess() and consume the >>> application stdout/err in a streaming mode. Because this method has only >>> been available in the 'jdk' version of ProcessTools and not in the >>> 'hotspot' one I decided to merge both of those versions and place the >>> merged version into the shared location 'test/lib/share/classes/'. >>> During this I decided to change the package for the shared ProcessTools >>> class to be 'jdk.test.lib.process' to be more in line with the way this >>> shared library is structured. I had to move few other lib classes >>> required by ProcessTools to the shared lib as well. All the moved lib >>> classes have been marked as deprecated in their original location. >>> >>> >>> Thanks, >>> >>> -JB- >>> >> >> > From alexhenrie24 at gmail.com Tue Dec 1 22:04:31 2015 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Tue, 01 Dec 2015 15:04:31 -0700 Subject: [PATCH resend] Skip the null pointer check before calling realloc Message-ID: # HG changeset patch # User Alex Henrie # Date 1447827030 25200 # Tue Nov 17 23:10:30 2015 -0700 # Node ID c5da6196db70a4cb3069cb1a81bfb7ce12c46019 # Parent 8c9484fe1bb22b13e873ef8fcaeeff234e4dabca Skip the null pointer check before calling realloc. "If ptr is a null pointer, realloc() shall be equivalent to malloc() for the specified size." http://pubs.opengroup.org/onlinepubs/9699919799/functions/realloc.html Also, sizeof(char*) is more correct here than sizeof(char**), although in practice it doesn't make a difference. diff --git a/src/java.instrument/share/native/libinstrument/InvocationAdapter.c b/src/java.instrument/share/native/libinstrument/InvocationAdapter.c --- a/src/java.instrument/share/native/libinstrument/InvocationAdapter.c +++ b/src/java.instrument/share/native/libinstrument/InvocationAdapter.c @@ -519,21 +519,17 @@ splitPathList(const char* str, int* path int count = 0; char** segments = NULL; char* c = (char*) str; while (*c != '\0') { while (*c == ' ') c++; /* skip leading spaces */ if (*c == '\0') { break; } - if (segments == NULL) { - segments = (char**)malloc( sizeof(char**) ); - } else { - segments = (char**)realloc( segments, (count+1)*sizeof(char**) ); - } + segments = (char**)realloc( segments, (count+1)*sizeof(char*) ); jplis_assert(segments != (char**)NULL); segments[count++] = c; c = strchr(c, ' '); if (c == NULL) { break; } *c = '\0'; c++; From jini.george at oracle.com Wed Dec 2 03:33:38 2015 From: jini.george at oracle.com (Jini George) Date: Tue, 1 Dec 2015 19:33:38 -0800 (PST) Subject: RFR : JDK-8139985: JNI exception pending in jdk/src/jdk/hprof/agent/share/native/libhprof/ Message-ID: <917c40dc-007b-427b-963a-9f631046e8b4@default> Hi all, This is a review request for the following defect related to Parfait cleanup: https://bugs.openjdk.java.net/browse/JDK-8139985 (JNI exception pending in jdk/src/jdk/hprof/agent/share/native/libhprof/) http://cr.openjdk.java.net/~dsamersoff/sponsorship/jingeorg/JDK-8139985/webrev.02/ This has been done for JDK8 only given that the hprof agent has been removed for JDK9. I used the already available CHECK_EXCEPTIONS and END_CHECK_EXCEPTIONS macros in hprof_util.c. Using these macros directly in the other files did not help with removing the parfait error messages there, due to the module dependencies being omitted because of cycles in the Module Dependency Graph. Thanks in advance, - Jini Susan George. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Wed Dec 2 09:13:07 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 2 Dec 2015 12:13:07 +0300 Subject: RFR : JDK-8139985: JNI exception pending in jdk/src/jdk/hprof/agent/share/native/libhprof/ In-Reply-To: <917c40dc-007b-427b-963a-9f631046e8b4@default> References: <917c40dc-007b-427b-963a-9f631046e8b4@default> Message-ID: <565EB623.8070106@oracle.com> Jini, Looks good for me. (Reviewed) -Dmitry On 2015-12-02 06:33, Jini George wrote: > Hi all, > > This is a review request for the followingdefectrelated to Parfait cleanup: > > _https://bugs.openjdk.java.net/browse/JDK-8139985_ (JNI exception > pending in jdk/src/jdk/hprof/agent/share/native/libhprof/) > > _http://cr.openjdk.java.net/~dsamersoff/sponsorship/jingeorg/JDK-8139985/webrev.02/_ > > Thishas been done for JDK8 only given thatthe hprof agent has been > removed for JDK9.I used the already available CHECK_EXCEPTIONS and > END_CHECK_EXCEPTIONS macros in hprof_util.c. Using these macros directly > in the other files did not help with removing the parfait error messages > there, due to the module dependencies being omitted because of cycles in > the Module Dependency Graph. > > Thanks in advance, > > - Jini Susan George. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jini.george at oracle.com Wed Dec 2 09:21:41 2015 From: jini.george at oracle.com (Jini George) Date: Wed, 2 Dec 2015 01:21:41 -0800 (PST) Subject: RFR : JDK-8139985: JNI exception pending in jdk/src/jdk/hprof/agent/share/native/libhprof/ In-Reply-To: <565EB623.8070106@oracle.com> References: <917c40dc-007b-427b-963a-9f631046e8b4@default> <565EB623.8070106@oracle.com> Message-ID: <567b1e16-6d0a-4e97-97be-fa09533f6a67@default> Thank you Dmitry. -jini > -----Original Message----- > From: Dmitry Samersoff > Sent: Wednesday, December 02, 2015 2:43 PM > To: Jini George; serviceability-dev at openjdk.java.net > Subject: Re: RFR : JDK-8139985: JNI exception pending in > jdk/src/jdk/hprof/agent/share/native/libhprof/ > > Jini, > > Looks good for me. (Reviewed) > > -Dmitry > > > On 2015-12-02 06:33, Jini George wrote: > > Hi all, > > > > This is a review request for the followingdefectrelated to Parfait > cleanup: > > > > _https://bugs.openjdk.java.net/browse/JDK-8139985_ (JNI exception > > pending in jdk/src/jdk/hprof/agent/share/native/libhprof/) > > > > _http://cr.openjdk.java.net/~dsamersoff/sponsorship/jingeorg/JDK- > 81399 > > 85/webrev.02/_ > > > > Thishas been done for JDK8 only given thatthe hprof agent has been > > removed for JDK9.I used the already available CHECK_EXCEPTIONS and > > END_CHECK_EXCEPTIONS macros in hprof_util.c. Using these macros > > directly in the other files did not help with removing the parfait > > error messages there, due to the module dependencies being omitted > > because of cycles in the Module Dependency Graph. > > > > Thanks in advance, > > > > - Jini Susan George. > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Wed Dec 2 12:56:17 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 2 Dec 2015 13:56:17 +0100 Subject: RFR : JDK-8139985: JNI exception pending in jdk/src/jdk/hprof/agent/share/native/libhprof/ In-Reply-To: <917c40dc-007b-427b-963a-9f631046e8b4@default> References: <917c40dc-007b-427b-963a-9f631046e8b4@default> Message-ID: <6F64672D-A52C-4ADE-9A0D-74A832CF0D04@oracle.com> Looks good! Thanks, /Staffan > On 2 dec. 2015, at 04:33, Jini George wrote: > > Hi all, > > This is a review request for the following defect related to Parfait cleanup: > > https://bugs.openjdk.java.net/browse/JDK-8139985 (JNI exception pending in jdk/src/jdk/hprof/agent/share/native/libhprof/) > > http://cr.openjdk.java.net/~dsamersoff/sponsorship/jingeorg/JDK-8139985/webrev.02/ > > This has been done for JDK8 only given that the hprof agent has been removed for JDK9. I used the already available CHECK_EXCEPTIONS and END_CHECK_EXCEPTIONS macros in hprof_util.c. Using these macros directly in the other files did not help with removing the parfait error messages there, due to the module dependencies being omitted because of cycles in the Module Dependency Graph. > > > Thanks in advance, > > - Jini Susan George. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.larsson at oracle.com Wed Dec 2 13:41:28 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 2 Dec 2015 14:41:28 +0100 Subject: RFR: 8144220: UL does not support full path names for log files on windows Message-ID: <565EF508.4030805@oracle.com> Hi, Please review the following patch to allow full path names for log files on windows. The full path to files will on windows contain a colon (from the C:\ part), and there used to be no way to avoid that colon from being parsed as the delimiter for the next -Xlog: option. With this patch it is now possible to avoid this by giving the path within quotation marks, for example: -Xlog:all:"C:\out.log". Any colons within quotes will not be parsed as delimiters for -Xlog. Webrev: http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8144220 Testing: New test through RBT. Thanks, Marcus From bengt.rutisson at oracle.com Wed Dec 2 13:59:37 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 2 Dec 2015 14:59:37 +0100 Subject: RFR: 8144220: UL does not support full path names for log files on windows In-Reply-To: <565EF508.4030805@oracle.com> References: <565EF508.4030805@oracle.com> Message-ID: <565EF949.7030208@oracle.com> Hi Marcus, On 2015-12-02 14:41, Marcus Larsson wrote: > Hi, > > Please review the following patch to allow full path names for log > files on windows. > > The full path to files will on windows contain a colon (from the C:\ > part), and there used to be no way to avoid that colon from being > parsed as the delimiter for the next -Xlog: option. With this patch it > is now possible to avoid this by giving the path within quotation > marks, for example: -Xlog:all:"C:\out.log". Any colons within quotes > will not be parsed as delimiters for -Xlog. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00/ As far as I can tell this looks good. I would like to have a few more cases in the test though. The way you have designed your test you can easily test for cases that are wrong too. For example non-closed quotes etc. Could you add a couple of more test cases? Maybe: -Xlog:all=trace:" -Xlog:all=trace:"" -Xlog:all=trace:""" Thanks, Bengt > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8144220 > > Testing: > New test through RBT. > > Thanks, > Marcus From marcus.larsson at oracle.com Wed Dec 2 14:28:01 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 2 Dec 2015 15:28:01 +0100 Subject: RFR: 8144220: UL does not support full path names for log files on windows In-Reply-To: <565EF949.7030208@oracle.com> References: <565EF508.4030805@oracle.com> <565EF949.7030208@oracle.com> Message-ID: <565EFFF1.8090407@oracle.com> Hi Bengt, Thanks for looking at this. On 2015-12-02 14:59, Bengt Rutisson wrote: > > Hi Marcus, > > On 2015-12-02 14:41, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to allow full path names for log >> files on windows. >> >> The full path to files will on windows contain a colon (from the C:\ >> part), and there used to be no way to avoid that colon from being >> parsed as the delimiter for the next -Xlog: option. With this patch >> it is now possible to avoid this by giving the path within quotation >> marks, for example: -Xlog:all:"C:\out.log". Any colons within quotes >> will not be parsed as delimiters for -Xlog. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00/ > > As far as I can tell this looks good. > > I would like to have a few more cases in the test though. The way you > have designed your test you can easily test for cases that are wrong > too. For example non-closed quotes etc. > > Could you add a couple of more test cases? Maybe: > > -Xlog:all=trace:" > -Xlog:all=trace:"" > -Xlog:all=trace:""" Good point, I'll add more cases to the test. I actually wrote some unit tests for this as well, so there are a few additional tests waiting to be checked in once we have unit test support. Thanks, Marcus > > Thanks, > Bengt > >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8144220 >> >> Testing: >> New test through RBT. >> >> Thanks, >> Marcus > From bengt.rutisson at oracle.com Wed Dec 2 17:26:50 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 2 Dec 2015 18:26:50 +0100 Subject: RFR: 8144220: UL does not support full path names for log files on windows In-Reply-To: <565EFFF1.8090407@oracle.com> References: <565EF508.4030805@oracle.com> <565EF949.7030208@oracle.com> <565EFFF1.8090407@oracle.com> Message-ID: <565F29DA.2060804@oracle.com> Hi Marcus, On 2015-12-02 15:28, Marcus Larsson wrote: > Hi Bengt, > > Thanks for looking at this. > > On 2015-12-02 14:59, Bengt Rutisson wrote: >> >> Hi Marcus, >> >> On 2015-12-02 14:41, Marcus Larsson wrote: >>> Hi, >>> >>> Please review the following patch to allow full path names for log >>> files on windows. >>> >>> The full path to files will on windows contain a colon (from the C:\ >>> part), and there used to be no way to avoid that colon from being >>> parsed as the delimiter for the next -Xlog: option. With this patch >>> it is now possible to avoid this by giving the path within quotation >>> marks, for example: -Xlog:all:"C:\out.log". Any colons within quotes >>> will not be parsed as delimiters for -Xlog. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00/ >> >> As far as I can tell this looks good. >> >> I would like to have a few more cases in the test though. The way you >> have designed your test you can easily test for cases that are wrong >> too. For example non-closed quotes etc. >> >> Could you add a couple of more test cases? Maybe: >> >> -Xlog:all=trace:" >> -Xlog:all=trace:"" >> -Xlog:all=trace:""" > > Good point, I'll add more cases to the test. > > I actually wrote some unit tests for this as well, so there are a few > additional tests waiting to be checked in once we have unit test support. Great! This really seems like something that is much better tested in unit tests. Thanks, Bengt > > Thanks, > Marcus > >> >> Thanks, >> Bengt >> >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8144220 >>> >>> Testing: >>> New test through RBT. >>> >>> Thanks, >>> Marcus >> > From yasuenag at gmail.com Thu Dec 3 03:33:46 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 3 Dec 2015 12:33:46 +0900 Subject: PING: RFR: JDK-8140556: Add force rotation option to VM.log jcmd In-Reply-To: <56487FB7.9020908@gmail.com> References: <562101D8.5080909@gmail.com> <562DF8D4.40501@oracle.com> <562EBF4B.4020607@gmail.com> <562F6B46.5050500@oracle.com> <563226AB.2030206@gmail.com> <5632341F.4060400@oracle.com> <56338125.9030802@gmail.com> <56338D58.9090709@oracle.com> <5634D9FC.6080502@gmail.com> <5636C66A.6020304@oracle.com> <563765FC.2090804@gmail.com> <563ACD6F.1050600@gmail.com> <563AD1F2.6060109@oracle.com> <563B69F9.5090102@oracle.com> <563B6CA0.9040107@gmail.com> <56487FB7.9020908@gmail.com> Message-ID: PING: Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.04/ I need reviewer and sponsor. Thanks, Yasumasa 2015/11/15 21:50 "Yasumasa Suenaga" : > > PING: Could you review it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.04/ > > Yasumasa > > > On 2015/11/05 23:50, Yasumasa Suenaga wrote: >>>> >>>> _post_initialized would be a more accurate name. >> >> >> I've fixed it in new webrev: >> http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.04/ >> >> I will send changeset to Marcus if this changeset is reviewed. >> >> >> Thanks. >> >> Yasumasa >> >> >> On 2015/11/05 23:38, Marcus Larsson wrote: >>> >>> Hey, >>> >>> On 2015-11-05 04:50, David Holmes wrote: >>>> >>>> On 5/11/2015 1:30 PM, Yasumasa Suenaga wrote: >>>>> >>>>> I've uploaded new webrev: >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.03/ >>>>> >>>>> I added _initialized to LogConfiguration. >>>>> LogConfiguration::post_initialize() will be called after main thread >>>>> initialization. >>>>> So _initialized set to true in this function, and we can check this flag >>>>> at rotation. >>>>> >>>>> Could you review it? >>> >>> >>> Looks OK to me. This is much better than checking for Thread::current() != NULL in is_rotatable(), IMHO. >>> >>>> >>>> _post_initialized would be a more accurate name. >>>> >>>> This of course works, but I don't know whether the additional delay in allowing rotation will impact anything. >>> >>> >>> It shouldn't. If anyone ever generates that much logging during startup they will have to accept that the first rotated log won't be properly sized, that's all. >>> >>> Thanks, >>> Marcus >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2015/11/02 22:32, Yasumasa Suenaga wrote: >>>>>> >>>>>> Marcus, David, >>>>>> >>>>>> I've uploaded new webrev: >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.02/ >>>>>> >>>>>> Could you review it? >>>>>> >>>>>> >>>>>>>>>>> Still missing the renaming of rotate_all_logfile to >>>>>>>>>>> rotate_all_outputs. >>>>>> >>>>>> >>>>>> I've fixed. >>>>>> >>>>>> >>>>>>>>> Small typo, please make that is_rotatable(). >>>>>> >>>>>> >>>>>> I've added, and have used at LogConfiguration::rotate_all_outputs(). >>>>>> >>>>>> >>>>>>> You can't safely lock a mutex until the current thread has attached >>>>>>> to the VM and Thread::current() returns non-null (that is what >>>>>>> Thread::initialize_thread_local_storage() currently does). You may >>>>>>> get away with it, particularly in product builds, during VM >>>>>>> initialization, as the fast-lock path doesn't require access to >>>>>>> Thread::current(). >>>>>> >>>>>> >>>>>> I will check whether Thread::current() is NULL or not at >>>>>> LogFileOutput::is_rotatable() >>>>>> is_rotatable() is called at LogFileOutput::rotate() before locking >>>>>> _rotation_lock. >>>>>> So we can avoid crash/assert which is related to TLS. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2015/11/02 11:11, David Holmes wrote: >>>>>>> >>>>>>> On 1/11/2015 1:10 AM, Yasumasa Suenaga wrote: >>>>>>>>> >>>>>>>>> This in turn means that we are logging before the thread local storage >>>>>>>>> has been initialized, and the JVM will crash/hit the assert because we >>>>>>>>> are trying to take the rotation lock. >>>>>>>> >>>>>>>> >>>>>>>> I guess that you are saying about class member (not TLS - e.g. >>>>>>>> pthread_setspecific()). >>>>>>> >>>>>>> >>>>>>> You can't safely lock a mutex until the current thread has attached >>>>>>> to the VM and Thread::current() returns non-null (that is what >>>>>>> Thread::initialize_thread_local_storage() currently does). You may >>>>>>> get away with it, particularly in product builds, during VM >>>>>>> initialization, as the fast-lock path doesn't require access to >>>>>>> Thread::current(). >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Most of fields (include _rotation_lock) in LogFileOutput are >>>>>>>> initialized >>>>>>>> at c'tor. >>>>>>>> Other field (_stream) is initialized at LogFileOutput::initialize(). >>>>>>>> >>>>>>>> We can avoid problem if we can move initialize() to c'tor because >>>>>>>> LogFileOutput >>>>>>>> will be instantiated at LogConfiguration::new_output(). >>>>>>>> >>>>>>>> Currently, LogFileOutput will be added to LogConfiguration::_outputs >>>>>>>> and >>>>>>>> to LogTagSet after calling LogFileOutput::initialize(). >>>>>>>> I wonder why we cannot avoid crash/assert with current >>>>>>>> implementation... >>>>>>>> >>>>>>>> >>>>>>>> I will keep current implementation about _rotation_lock if the above is >>>>>>>> incorrect. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2015/10/31 0:31, Marcus Larsson wrote: >>>>>>>>> >>>>>>>>> Hey, >>>>>>>>> >>>>>>>>> On 2015-10-30 15:39, Yasumasa Suenaga wrote: >>>>>>>>>> >>>>>>>>>> Hi Marcus, >>>>>>>>>> >>>>>>>>>> Thank you for your comment. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Still missing the renaming of rotate_all_logfile to >>>>>>>>>>> rotate_all_outputs. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Sorry, I will fix. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> This rotate function works I guess, but it will probably need some >>>>>>>>>>> rework once there are other types of log outputs (rotate doesn't >>>>>>>>>>> make sense on all types of log outputs). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I will add is_rotetable() to LogOutput as virtual function. >>>>>>>>>> This function return false (can not rotate) by default, return true >>>>>>>>>> if _file_count is >>>>>>>>>> greater than 0 in LogFileOutput. >>>>>>>>>> >>>>>>>>>> LogConfiguration::rotate_all_outputs() will rotate if this function >>>>>>>>>> returns true. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Small typo, please make that is_rotatable(). >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> If we configure a rotated file output and then log something on that >>>>>>>>>>> output before thread local storage initialization is complete, we >>>>>>>>>>> will crash/hit an assert. The previous implementation avoided this >>>>>>>>>>> as long as no rotation was needed before this initialization was >>>>>>>>>>> complete. (This can be triggered using the following arguments >>>>>>>>>>> "-Xlog:all=trace:file.txt::filesize=10,filecount=2 -Xlog:invalid", >>>>>>>>>>> for example.) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I do not think so. >>>>>>>>>> Each -Xlog option creates unique instance of LogOutput (and >>>>>>>>>> subclass). >>>>>>>>>> So they are isolated. >>>>>>>>> >>>>>>>>> >>>>>>>>> My example includes a second (and intentionally incorrect) -Xlog >>>>>>>>> option only to trigger logging on the newly configured rotating >>>>>>>>> LogFileOutput. This will cause some logging about the invalid -Xlog >>>>>>>>> argument, and this logging happens during the argument parsing. This >>>>>>>>> in turn means that we are logging before the thread local storage has >>>>>>>>> been initialized, and the JVM will crash/hit the assert because we are >>>>>>>>> trying to take the rotation lock. This has nothing to do with >>>>>>>>> concurrent fprintfs or freopens, even if that is a problem. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> However, we might have to rotate at safepoint. >>>>>>>>> >>>>>>>>> >>>>>>>>> Doing stuff at a safepoint will not give us much in this case. There >>>>>>>>> are threads that continue execution through a safepoint, which means >>>>>>>>> we will see log calls being made even during this time. >>>>>>>>> >>>>>>>>>> Currently, LogOutput might be used by multiple threads concurrently. >>>>>>>>>> If we rotate log when another thread is writing string to output, we >>>>>>>>>> encounter unexpected behavior. >>>>>>>>>> >>>>>>>>>> LogFileOutput::rotate() uses freopen(). >>>>>>>>>> LogFileStreamOutput::write() uses vfprintf() through jio_fprintf(). >>>>>>>>>> freopen() and vfprintf() are not atomic. >>>>>>>>> >>>>>>>>> >>>>>>>>> You're right. There seems to be an overlooked concurrency issue with >>>>>>>>> vfprintfs during freopen. I don't think we should resolve this as part >>>>>>>>> of this particular fix, so instead I'll create a separate issue for >>>>>>>>> it. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think that cause of crash/assertion which you say is it. >>>>>>>>>> (GC log will be rotated at safepoint.) >>>>>>>>>> >>>>>>>>> >>>>>>>>> See my comment above for what crash/assert I'm talking about. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Marcus >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2015/10/29 23:58, Marcus Larsson wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On 2015-10-29 15:01, Yasumasa Suenaga wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Marcus, >>>>>>>>>>>> >>>>>>>>>>>> Thank you for your comment. >>>>>>>>>>>> >>>>>>>>>>>>> I'll sponsor it. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thank you so much! >>>>>>>>>>>> I've uploaded new webrev: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Still missing the renaming of rotate_all_logfile to >>>>>>>>>>> rotate_all_outputs. >>>>>>>>>>> >>>>>>>>>>>>> logConfiguration.cpp/hpp: >>>>>>>>>>>>> >>>>>>>>>>>>> * I don't think we should rely on the archive_name or the output's >>>>>>>>>>>>> name to decide whether or not an output should be rotated. It >>>>>>>>>>>>> would be better to introduce an is_rotated() test function in >>>>>>>>>>>>> LogOutput that could be used here. >>>>>>>>>>>>> >>>>>>>>>>>>> * rotate_all_logfile() should be renamed to rotate_all_outputs(). >>>>>>>>>>>>> Currently there are only LogFileOutputs (other than >>>>>>>>>>>>> stdout/stderr), but in the future there might be other types of >>>>>>>>>>>>> outputs so I prefer having a more general name. >>>>>>>>>>>>> Also, please use static_cast instead of the >>>>>>>>>>>>> C-style cast. (Additional logic will be required here once more >>>>>>>>>>>>> types of log outputs are added, but I don't think we need to worry >>>>>>>>>>>>> about this right now.) >>>>>>>>>>>>> >>>>>>>>>>>>> * Don't print an error if an output is not rotatable, since it's >>>>>>>>>>>>> not an error to have some log outputs rotated while others are >>>>>>>>>>>>> not. If you really want some traceability here I suggest adding >>>>>>>>>>>>> log messages on trace level, tagged with 'logging'. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I added LogOutput::rotate(bool) as virtual function. >>>>>>>>>>>> This function works nothing by default, but will rotate all logs at >>>>>>>>>>>> LogFileOutput. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This rotate function works I guess, but it will probably need some >>>>>>>>>>> rework once there are other types of log outputs (rotate doesn't >>>>>>>>>>> make sense on all types of log outputs). >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If true is passed to this function, all files will be rotated. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> logDiagnosticCommand.cpp/hpp: >>>>>>>>>>>>> >>>>>>>>>>>>> * I think the description could be improved to something like >>>>>>>>>>>>> "Lists current log configuration, enables/disables/configures a >>>>>>>>>>>>> log output, or disables/rotates all logs." >>>>>>>>>>>>> >>>>>>>>>>>>> * The rotate option description should clarify that all logs will >>>>>>>>>>>>> be rotated ("current log" is too ambiguous). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I've fixed. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Great, thanks! >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> logFileOutput.cpp/hpp: >>>>>>>>>>>>> >>>>>>>>>>>>> * Moving the MutexLocker like this introduces a race condition >>>>>>>>>>>>> where a log might be rotated multiple times by different threads, >>>>>>>>>>>>> instead of just once. >>>>>>>>>>>>> Instead of making the rotate() function public and moving the >>>>>>>>>>>>> mutexlocker, I suggest adding something like a public >>>>>>>>>>>>> force_rotation() function that grabs the lock and calls the >>>>>>>>>>>>> private rotate(). >>>>>>>>>>>>> >>>>>>>>>>>>> * Given the addition of is_rotated() in LogOutput, then >>>>>>>>>>>>> get_archive_name() should be removed. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I moved MutexLocker and should_rotate() to rotate(). >>>>>>>>>>>> I think this change can avoid race condition. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> There is a subtle problem with taking the lock to check if we should >>>>>>>>>>> rotate. If we configure a rotated file output and then log something >>>>>>>>>>> on that output before thread local storage initialization is >>>>>>>>>>> complete, we will crash/hit an assert. The previous implementation >>>>>>>>>>> avoided this as long as no rotation was needed before this >>>>>>>>>>> initialization was complete. (This can be triggered using the >>>>>>>>>>> following arguments >>>>>>>>>>> "-Xlog:all=trace:file.txt::filesize=10,filecount=2 -Xlog:invalid", >>>>>>>>>>> for example.) >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Marcus >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2015/10/27 21:17, Marcus Larsson wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> On 2015-10-27 01:03, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Marcus, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you for replying. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I filed this feature to JBS and change subject of this email. >>>>>>>>>>>>>> Could you be a sponsor and review it? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I'll sponsor it. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> logConfiguration.cpp/hpp: >>>>>>>>>>>>> >>>>>>>>>>>>> * I don't think we should rely on the archive_name or the output's >>>>>>>>>>>>> name to decide whether or not an output should be rotated. It >>>>>>>>>>>>> would be better to introduce an is_rotated() test function in >>>>>>>>>>>>> LogOutput that could be used here. >>>>>>>>>>>>> >>>>>>>>>>>>> * rotate_all_logfile() should be renamed to rotate_all_outputs(). >>>>>>>>>>>>> Currently there are only LogFileOutputs (other than >>>>>>>>>>>>> stdout/stderr), but in the future there might be other types of >>>>>>>>>>>>> outputs so I prefer having a more general name. >>>>>>>>>>>>> Also, please use static_cast instead of the >>>>>>>>>>>>> C-style cast. (Additional logic will be required here once more >>>>>>>>>>>>> types of log outputs are added, but I don't think we need to worry >>>>>>>>>>>>> about this right now.) >>>>>>>>>>>>> >>>>>>>>>>>>> * Don't print an error if an output is not rotatable, since it's >>>>>>>>>>>>> not an error to have some log outputs rotated while others are >>>>>>>>>>>>> not. If you really want some traceability here I suggest adding >>>>>>>>>>>>> log messages on trace level, tagged with 'logging'. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> logDiagnosticCommand.cpp/hpp: >>>>>>>>>>>>> >>>>>>>>>>>>> * I think the description could be improved to something like >>>>>>>>>>>>> "Lists current log configuration, enables/disables/configures a >>>>>>>>>>>>> log output, or disables/rotates all logs." >>>>>>>>>>>>> >>>>>>>>>>>>> * The rotate option description should clarify that all logs will >>>>>>>>>>>>> be rotated ("current log" is too ambiguous). >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> logFileOutput.cpp/hpp: >>>>>>>>>>>>> >>>>>>>>>>>>> * Moving the MutexLocker like this introduces a race condition >>>>>>>>>>>>> where a log might be rotated multiple times by different threads, >>>>>>>>>>>>> instead of just once. >>>>>>>>>>>>> Instead of making the rotate() function public and moving the >>>>>>>>>>>>> mutexlocker, I suggest adding something like a public >>>>>>>>>>>>> force_rotation() function that grabs the lock and calls the >>>>>>>>>>>>> private rotate(). >>>>>>>>>>>>> >>>>>>>>>>>>> * Given the addition of is_rotated() in LogOutput, then >>>>>>>>>>>>> get_archive_name() should be removed. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Marcus >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2015/10/26 18:56, Marcus Larsson wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sorry for my late reply. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think being able to force rotation via jcmd seems like a good >>>>>>>>>>>>>>> feature. Files are currently opened in append mode so it should >>>>>>>>>>>>>>> already be possible to use external log rotation tools by >>>>>>>>>>>>>>> copying and truncating the files. Still I think it would be nice >>>>>>>>>>>>>>> to provide the jcmd for rotation as well. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I can see some small issues with the implementation, but we can >>>>>>>>>>>>>>> deal with that during the review. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Marcus >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2015-10-26 00:26, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Have you ever seen my change? >>>>>>>>>>>>>>>> I (and my customers) need log rotation function via external >>>>>>>>>>>>>>>> tool. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I want to merge it by Feature Complete. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> 2015/10/16 22:55 "Yasumasa Suenaga" : >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I contributed JDK-7090324: gclog rotation via external tool >>>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>>> synchronized with >>>>>>>>>>>>>>>>> logrotated tool on Linux. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think JEP 158 is in progress. >>>>>>>>>>>>>>>>> However, this JEP does not contain log rotation via external >>>>>>>>>>>>>>>>> tool in the >>>>>>>>>>>>>>>>> spec. >>>>>>>>>>>>>>>>> I want to rotate logs via jcmd in this JEP. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I've updated a patch for it: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/jvmlogging-logrotate/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This patch provides new option "rotate" in VM.log command. >>>>>>>>>>>>>>>>> If this change can be accepted, I will file it to JBS and send >>>>>>>>>>>>>>>>> RFR. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheleswer.sahu at oracle.com Thu Dec 3 06:58:23 2015 From: cheleswer.sahu at oracle.com (cheleswer sahu) Date: Thu, 3 Dec 2015 12:28:23 +0530 Subject: RFR[ 9u-dev] JDK-8138745: Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot In-Reply-To: <5656A689.3010006@oracle.com> References: <5655AC56.4080204@oracle.com> <56569C08.7010406@oracle.com> <5656A689.3010006@oracle.com> Message-ID: <565FE80F.2030603@oracle.com> Hi, Thanks David and Staffan for your comments. Please review the code changes in the updated webrev below http://cr.openjdk.java.net/~kevinw/8138745/webrev.01/ Regards, Cheleswer On 11/26/2015 11:58 AM, David Holmes wrote: > Sorry forgot the tests .... > > test/runtime/ErrorHandling/TestExitOnOutOfMemoryError.java > > This test is checking that new Object[Integer.MAX_VALUE]; caused the > "Requested array size exceeds VM limit" failure _but_ it doesn't > actually do anything to verify that the VM terminated because of the > ExitOnOutOfMemory flag. I suggest: > > a) augment the termination message in the VM as I suggested earlier so > that you can be sure you hit the termination code > b) check for a zero/non-zero return code as appropriate > c) Add: throw new Error("OOME was not triggered"); after line 41. > d) Put a try/catch(OOME) around the allocation and throw an Error if > you get to the catch block > > That way we will get a test failure when Arrays 2.0 allows such > massive arrays to be created :) > > Similar considerations for TestCrashOnOutOfMemoryError.java, but you > also need to disable core dump generation. > > David > ----- > > On 26/11/2015 3:43 PM, David Holmes wrote: >> Hi, >> >> On 25/11/2015 10:40 PM, cheleswer sahu wrote: >>> Hi, >>> >>> Please review the code changes for >>> "https://bugs.openjdk.java.net/browse/JDK-8138745". >>> Web review link: >>> http://cr.openjdk.java.net/~kevinw/8138745/webrev.00/ >>> >>> >>> >>> Enhancement Brief: >>> ExitOnOutOfMemoryError: When user enable this option, the JVM exits on >>> the first occurrence of an out-of-memory error. It can be used if user >>> prefer restarting an instance of the JVM rather than handling out of >>> memory errors. >>> >>> CrashOnOutOfMemoryError: If this option is enabled, when an >>> out-of-memory error occurs, the JVM crashes and produces text and >>> binary >>> crash files. >> >> The term "crash" is not very appropriate - crashes are bad things. Abort >> may have been a better choice. >> >>> For more details please refer http://ccc.us.oracle.com/8138745 >> >> This is not accessible outside of Oracle. >> >> A few minor comments: >> >> src/share/vm/runtime/globals.hpp >> >> + "JVM crashes and produces text and binary crash files") >> >> Terminology should be consistent with other options that control core >> dump. Should also say "on first occurrence of an out-of-memory error". >> >> src/share/vm/utilities/debug.cpp: >> >> 308 if (CrashOnOutOfMemoryError) { >> 309 tty->print_cr("java.lang.OutOfMemoryError: %s", message); >> 310 fatal("OutOfMemory encountered: %s", message); >> 311 } >> >> don't really need the tty->print when using the fatal. Though you may >> want to use the j.l.OOME form of the message for consistency. Might also >> be useful for both Crash and Exit to include in the logged messages the >> fact that these flags were involved - something like: >> >> "Terminating due to java.lang.OutOfMemoryError: %s" >> "Aborting due to java.lang.OutOfMemoryError: %s" >> >> Thanks, >> David >> ----- >> >>> >>> Regards, >>> Cheleswer >>> From marcus.larsson at oracle.com Thu Dec 3 10:11:16 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 3 Dec 2015 11:11:16 +0100 Subject: RFR: 8144220: UL does not support full path names for log files on windows In-Reply-To: <565EF508.4030805@oracle.com> References: <565EF508.4030805@oracle.com> Message-ID: <56601544.8070203@oracle.com> Hi, New webrev: http://cr.openjdk.java.net/~mlarsson/8144220/webrev.01/ Incremental: http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00-01/ Added more test cases to the test, and renamed it to TestQuotedLogOutputs. The updated test found that partially quoted output names that didn't start with the quote character were accepted. This has been fixed. Test passes in RBT. Thanks, Marcus On 2015-12-02 14:41, Marcus Larsson wrote: > Hi, > > Please review the following patch to allow full path names for log > files on windows. > > The full path to files will on windows contain a colon (from the C:\ > part), and there used to be no way to avoid that colon from being > parsed as the delimiter for the next -Xlog: option. With this patch it > is now possible to avoid this by giving the path within quotation > marks, for example: -Xlog:all:"C:\out.log". Any colons within quotes > will not be parsed as delimiters for -Xlog. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8144220 > > Testing: > New test through RBT. > > Thanks, > Marcus From marcus.larsson at oracle.com Thu Dec 3 10:13:37 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 3 Dec 2015 11:13:37 +0100 Subject: PING: RFR: JDK-8140556: Add force rotation option to VM.log jcmd In-Reply-To: References: <562101D8.5080909@gmail.com> <562DF8D4.40501@oracle.com> <562EBF4B.4020607@gmail.com> <562F6B46.5050500@oracle.com> <563226AB.2030206@gmail.com> <5632341F.4060400@oracle.com> <56338125.9030802@gmail.com> <56338D58.9090709@oracle.com> <5634D9FC.6080502@gmail.com> <5636C66A.6020304@oracle.com> <563765FC.2090804@gmail.com> <563ACD6F.1050600@gmail.com> <563AD1F2.6060109@oracle.com> <563B69F9.5090102@oracle.com> <563B6CA0.9040107@gmail.com> <56487FB7.9020908@gmail.com> Message-ID: <566015D1.60000@oracle.com> Hi, On 2015-12-03 04:33, Yasumasa Suenaga wrote: > > PING: Could you review it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.04/ > > > I need reviewer and sponsor. > Looks good. I'll sponsor. Regards, Marcus > Thanks, > > Yasumasa > > 2015/11/15 21:50 "Yasumasa Suenaga" >: > > > > PING: Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.04/ > > > > > Yasumasa > > > > > > On 2015/11/05 23:50, Yasumasa Suenaga wrote: > >>>> > >>>> _post_initialized would be a more accurate name. > >> > >> > >> I've fixed it in new webrev: > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.04/ > > >> > >> I will send changeset to Marcus if this changeset is reviewed. > >> > >> > >> Thanks. > >> > >> Yasumasa > >> > >> > >> On 2015/11/05 23:38, Marcus Larsson wrote: > >>> > >>> Hey, > >>> > >>> On 2015-11-05 04:50, David Holmes wrote: > >>>> > >>>> On 5/11/2015 1:30 PM, Yasumasa Suenaga wrote: > >>>>> > >>>>> I've uploaded new webrev: > >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.03/ > > >>>>> > >>>>> I added _initialized to LogConfiguration. > >>>>> LogConfiguration::post_initialize() will be called after main thread > >>>>> initialization. > >>>>> So _initialized set to true in this function, and we can check > this flag > >>>>> at rotation. > >>>>> > >>>>> Could you review it? > >>> > >>> > >>> Looks OK to me. This is much better than checking for > Thread::current() != NULL in is_rotatable(), IMHO. > >>> > >>>> > >>>> _post_initialized would be a more accurate name. > >>>> > >>>> This of course works, but I don't know whether the additional > delay in allowing rotation will impact anything. > >>> > >>> > >>> It shouldn't. If anyone ever generates that much logging during > startup they will have to accept that the first rotated log won't be > properly sized, that's all. > >>> > >>> Thanks, > >>> Marcus > >>> > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Yasumasa > >>>>> > >>>>> > >>>>> On 2015/11/02 22:32, Yasumasa Suenaga wrote: > >>>>>> > >>>>>> Marcus, David, > >>>>>> > >>>>>> I've uploaded new webrev: > >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.02/ > > >>>>>> > >>>>>> Could you review it? > >>>>>> > >>>>>> > >>>>>>>>>>> Still missing the renaming of rotate_all_logfile to > >>>>>>>>>>> rotate_all_outputs. > >>>>>> > >>>>>> > >>>>>> I've fixed. > >>>>>> > >>>>>> > >>>>>>>>> Small typo, please make that is_rotatable(). > >>>>>> > >>>>>> > >>>>>> I've added, and have used at > LogConfiguration::rotate_all_outputs(). > >>>>>> > >>>>>> > >>>>>>> You can't safely lock a mutex until the current thread has > attached > >>>>>>> to the VM and Thread::current() returns non-null (that is what > >>>>>>> Thread::initialize_thread_local_storage() currently does). You may > >>>>>>> get away with it, particularly in product builds, during VM > >>>>>>> initialization, as the fast-lock path doesn't require access to > >>>>>>> Thread::current(). > >>>>>> > >>>>>> > >>>>>> I will check whether Thread::current() is NULL or not at > >>>>>> LogFileOutput::is_rotatable() > >>>>>> is_rotatable() is called at LogFileOutput::rotate() before locking > >>>>>> _rotation_lock. > >>>>>> So we can avoid crash/assert which is related to TLS. > >>>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Yasumasa > >>>>>> > >>>>>> > >>>>>> On 2015/11/02 11:11, David Holmes wrote: > >>>>>>> > >>>>>>> On 1/11/2015 1:10 AM, Yasumasa Suenaga wrote: > >>>>>>>>> > >>>>>>>>> This in turn means that we are logging before the thread > local storage > >>>>>>>>> has been initialized, and the JVM will crash/hit the assert > because we > >>>>>>>>> are trying to take the rotation lock. > >>>>>>>> > >>>>>>>> > >>>>>>>> I guess that you are saying about class member (not TLS - e.g. > >>>>>>>> pthread_setspecific()). > >>>>>>> > >>>>>>> > >>>>>>> You can't safely lock a mutex until the current thread has > attached > >>>>>>> to the VM and Thread::current() returns non-null (that is what > >>>>>>> Thread::initialize_thread_local_storage() currently does). You may > >>>>>>> get away with it, particularly in product builds, during VM > >>>>>>> initialization, as the fast-lock path doesn't require access to > >>>>>>> Thread::current(). > >>>>>>> > >>>>>>> David > >>>>>>> > >>>>>>>> Most of fields (include _rotation_lock) in LogFileOutput are > >>>>>>>> initialized > >>>>>>>> at c'tor. > >>>>>>>> Other field (_stream) is initialized at > LogFileOutput::initialize(). > >>>>>>>> > >>>>>>>> We can avoid problem if we can move initialize() to c'tor because > >>>>>>>> LogFileOutput > >>>>>>>> will be instantiated at LogConfiguration::new_output(). > >>>>>>>> > >>>>>>>> Currently, LogFileOutput will be added to > LogConfiguration::_outputs > >>>>>>>> and > >>>>>>>> to LogTagSet after calling LogFileOutput::initialize(). > >>>>>>>> I wonder why we cannot avoid crash/assert with current > >>>>>>>> implementation... > >>>>>>>> > >>>>>>>> > >>>>>>>> I will keep current implementation about _rotation_lock if > the above is > >>>>>>>> incorrect. > >>>>>>>> > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> > >>>>>>>> Yasumasa > >>>>>>>> > >>>>>>>> > >>>>>>>> On 2015/10/31 0:31, Marcus Larsson wrote: > >>>>>>>>> > >>>>>>>>> Hey, > >>>>>>>>> > >>>>>>>>> On 2015-10-30 15:39, Yasumasa Suenaga wrote: > >>>>>>>>>> > >>>>>>>>>> Hi Marcus, > >>>>>>>>>> > >>>>>>>>>> Thank you for your comment. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Still missing the renaming of rotate_all_logfile to > >>>>>>>>>>> rotate_all_outputs. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Sorry, I will fix. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks! > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> This rotate function works I guess, but it will probably > need some > >>>>>>>>>>> rework once there are other types of log outputs (rotate > doesn't > >>>>>>>>>>> make sense on all types of log outputs). > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I will add is_rotetable() to LogOutput as virtual function. > >>>>>>>>>> This function return false (can not rotate) by default, > return true > >>>>>>>>>> if _file_count is > >>>>>>>>>> greater than 0 in LogFileOutput. > >>>>>>>>>> > >>>>>>>>>> LogConfiguration::rotate_all_outputs() will rotate if this > function > >>>>>>>>>> returns true. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> Small typo, please make that is_rotatable(). > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> If we configure a rotated file output and then log > something on that > >>>>>>>>>>> output before thread local storage initialization is > complete, we > >>>>>>>>>>> will crash/hit an assert. The previous implementation > avoided this > >>>>>>>>>>> as long as no rotation was needed before this > initialization was > >>>>>>>>>>> complete. (This can be triggered using the following arguments > >>>>>>>>>>> "-Xlog:all=trace:file.txt::filesize=10,filecount=2 > -Xlog:invalid", > >>>>>>>>>>> for example.) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I do not think so. > >>>>>>>>>> Each -Xlog option creates unique instance of LogOutput (and > >>>>>>>>>> subclass). > >>>>>>>>>> So they are isolated. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> My example includes a second (and intentionally incorrect) -Xlog > >>>>>>>>> option only to trigger logging on the newly configured rotating > >>>>>>>>> LogFileOutput. This will cause some logging about the > invalid -Xlog > >>>>>>>>> argument, and this logging happens during the argument > parsing. This > >>>>>>>>> in turn means that we are logging before the thread local > storage has > >>>>>>>>> been initialized, and the JVM will crash/hit the assert > because we are > >>>>>>>>> trying to take the rotation lock. This has nothing to do with > >>>>>>>>> concurrent fprintfs or freopens, even if that is a problem. > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> However, we might have to rotate at safepoint. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Doing stuff at a safepoint will not give us much in this > case. There > >>>>>>>>> are threads that continue execution through a safepoint, > which means > >>>>>>>>> we will see log calls being made even during this time. > >>>>>>>>> > >>>>>>>>>> Currently, LogOutput might be used by multiple threads > concurrently. > >>>>>>>>>> If we rotate log when another thread is writing string to > output, we > >>>>>>>>>> encounter unexpected behavior. > >>>>>>>>>> > >>>>>>>>>> LogFileOutput::rotate() uses freopen(). > >>>>>>>>>> LogFileStreamOutput::write() uses vfprintf() through > jio_fprintf(). > >>>>>>>>>> freopen() and vfprintf() are not atomic. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> You're right. There seems to be an overlooked concurrency > issue with > >>>>>>>>> vfprintfs during freopen. I don't think we should resolve > this as part > >>>>>>>>> of this particular fix, so instead I'll create a separate > issue for > >>>>>>>>> it. > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I think that cause of crash/assertion which you say is it. > >>>>>>>>>> (GC log will be rotated at safepoint.) > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> See my comment above for what crash/assert I'm talking about. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Marcus > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> > >>>>>>>>>> Yasumasa > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 2015/10/29 23:58, Marcus Larsson wrote: > >>>>>>>>>>> > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> On 2015-10-29 15:01, Yasumasa Suenaga wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Hi Marcus, > >>>>>>>>>>>> > >>>>>>>>>>>> Thank you for your comment. > >>>>>>>>>>>> > >>>>>>>>>>>>> I'll sponsor it. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Thank you so much! > >>>>>>>>>>>> I've uploaded new webrev: > >>>>>>>>>>>> > >>>>>>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.01/ > > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Still missing the renaming of rotate_all_logfile to > >>>>>>>>>>> rotate_all_outputs. > >>>>>>>>>>> > >>>>>>>>>>>>> logConfiguration.cpp/hpp: > >>>>>>>>>>>>> > >>>>>>>>>>>>> * I don't think we should rely on the archive_name or > the output's > >>>>>>>>>>>>> name to decide whether or not an output should be > rotated. It > >>>>>>>>>>>>> would be better to introduce an is_rotated() test > function in > >>>>>>>>>>>>> LogOutput that could be used here. > >>>>>>>>>>>>> > >>>>>>>>>>>>> * rotate_all_logfile() should be renamed to > rotate_all_outputs(). > >>>>>>>>>>>>> Currently there are only LogFileOutputs (other than > >>>>>>>>>>>>> stdout/stderr), but in the future there might be other > types of > >>>>>>>>>>>>> outputs so I prefer having a more general name. > >>>>>>>>>>>>> Also, please use static_cast instead of the > >>>>>>>>>>>>> C-style cast. (Additional logic will be required here > once more > >>>>>>>>>>>>> types of log outputs are added, but I don't think we > need to worry > >>>>>>>>>>>>> about this right now.) > >>>>>>>>>>>>> > >>>>>>>>>>>>> * Don't print an error if an output is not rotatable, > since it's > >>>>>>>>>>>>> not an error to have some log outputs rotated while > others are > >>>>>>>>>>>>> not. If you really want some traceability here I suggest > adding > >>>>>>>>>>>>> log messages on trace level, tagged with 'logging'. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> I added LogOutput::rotate(bool) as virtual function. > >>>>>>>>>>>> This function works nothing by default, but will rotate > all logs at > >>>>>>>>>>>> LogFileOutput. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> This rotate function works I guess, but it will probably > need some > >>>>>>>>>>> rework once there are other types of log outputs (rotate > doesn't > >>>>>>>>>>> make sense on all types of log outputs). > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> If true is passed to this function, all files will be > rotated. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> logDiagnosticCommand.cpp/hpp: > >>>>>>>>>>>>> > >>>>>>>>>>>>> * I think the description could be improved to something > like > >>>>>>>>>>>>> "Lists current log configuration, > enables/disables/configures a > >>>>>>>>>>>>> log output, or disables/rotates all logs." > >>>>>>>>>>>>> > >>>>>>>>>>>>> * The rotate option description should clarify that all > logs will > >>>>>>>>>>>>> be rotated ("current log" is too ambiguous). > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> I've fixed. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Great, thanks! > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> logFileOutput.cpp/hpp: > >>>>>>>>>>>>> > >>>>>>>>>>>>> * Moving the MutexLocker like this introduces a race > condition > >>>>>>>>>>>>> where a log might be rotated multiple times by different > threads, > >>>>>>>>>>>>> instead of just once. > >>>>>>>>>>>>> Instead of making the rotate() function public and > moving the > >>>>>>>>>>>>> mutexlocker, I suggest adding something like a public > >>>>>>>>>>>>> force_rotation() function that grabs the lock and calls the > >>>>>>>>>>>>> private rotate(). > >>>>>>>>>>>>> > >>>>>>>>>>>>> * Given the addition of is_rotated() in LogOutput, then > >>>>>>>>>>>>> get_archive_name() should be removed. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> I moved MutexLocker and should_rotate() to rotate(). > >>>>>>>>>>>> I think this change can avoid race condition. > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> There is a subtle problem with taking the lock to check if > we should > >>>>>>>>>>> rotate. If we configure a rotated file output and then log > something > >>>>>>>>>>> on that output before thread local storage initialization is > >>>>>>>>>>> complete, we will crash/hit an assert. The previous > implementation > >>>>>>>>>>> avoided this as long as no rotation was needed before this > >>>>>>>>>>> initialization was complete. (This can be triggered using the > >>>>>>>>>>> following arguments > >>>>>>>>>>> "-Xlog:all=trace:file.txt::filesize=10,filecount=2 > -Xlog:invalid", > >>>>>>>>>>> for example.) > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> Marcus > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks, > >>>>>>>>>>>> > >>>>>>>>>>>> Yasumasa > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On 2015/10/27 21:17, Marcus Larsson wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Hi, > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 2015-10-27 01:03, Yasumasa Suenaga wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi Marcus, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thank you for replying. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I filed this feature to JBS and change subject of this > email. > >>>>>>>>>>>>>> Could you be a sponsor and review it? > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> I'll sponsor it. > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.00/ > > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> logConfiguration.cpp/hpp: > >>>>>>>>>>>>> > >>>>>>>>>>>>> * I don't think we should rely on the archive_name or > the output's > >>>>>>>>>>>>> name to decide whether or not an output should be > rotated. It > >>>>>>>>>>>>> would be better to introduce an is_rotated() test > function in > >>>>>>>>>>>>> LogOutput that could be used here. > >>>>>>>>>>>>> > >>>>>>>>>>>>> * rotate_all_logfile() should be renamed to > rotate_all_outputs(). > >>>>>>>>>>>>> Currently there are only LogFileOutputs (other than > >>>>>>>>>>>>> stdout/stderr), but in the future there might be other > types of > >>>>>>>>>>>>> outputs so I prefer having a more general name. > >>>>>>>>>>>>> Also, please use static_cast instead of the > >>>>>>>>>>>>> C-style cast. (Additional logic will be required here > once more > >>>>>>>>>>>>> types of log outputs are added, but I don't think we > need to worry > >>>>>>>>>>>>> about this right now.) > >>>>>>>>>>>>> > >>>>>>>>>>>>> * Don't print an error if an output is not rotatable, > since it's > >>>>>>>>>>>>> not an error to have some log outputs rotated while > others are > >>>>>>>>>>>>> not. If you really want some traceability here I suggest > adding > >>>>>>>>>>>>> log messages on trace level, tagged with 'logging'. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> logDiagnosticCommand.cpp/hpp: > >>>>>>>>>>>>> > >>>>>>>>>>>>> * I think the description could be improved to something > like > >>>>>>>>>>>>> "Lists current log configuration, > enables/disables/configures a > >>>>>>>>>>>>> log output, or disables/rotates all logs." > >>>>>>>>>>>>> > >>>>>>>>>>>>> * The rotate option description should clarify that all > logs will > >>>>>>>>>>>>> be rotated ("current log" is too ambiguous). > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> logFileOutput.cpp/hpp: > >>>>>>>>>>>>> > >>>>>>>>>>>>> * Moving the MutexLocker like this introduces a race > condition > >>>>>>>>>>>>> where a log might be rotated multiple times by different > threads, > >>>>>>>>>>>>> instead of just once. > >>>>>>>>>>>>> Instead of making the rotate() function public and > moving the > >>>>>>>>>>>>> mutexlocker, I suggest adding something like a public > >>>>>>>>>>>>> force_rotation() function that grabs the lock and calls the > >>>>>>>>>>>>> private rotate(). > >>>>>>>>>>>>> > >>>>>>>>>>>>> * Given the addition of is_rotated() in LogOutput, then > >>>>>>>>>>>>> get_archive_name() should be removed. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>> Marcus > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Yasumasa > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 2015/10/26 18:56, Marcus Larsson wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Sorry for my late reply. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I think being able to force rotation via jcmd seems > like a good > >>>>>>>>>>>>>>> feature. Files are currently opened in append mode so > it should > >>>>>>>>>>>>>>> already be possible to use external log rotation tools by > >>>>>>>>>>>>>>> copying and truncating the files. Still I think it > would be nice > >>>>>>>>>>>>>>> to provide the jcmd for rotation as well. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I can see some small issues with the implementation, > but we can > >>>>>>>>>>>>>>> deal with that during the review. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> Marcus > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 2015-10-26 00:26, Yasumasa Suenaga wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Hi all, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Have you ever seen my change? > >>>>>>>>>>>>>>>> I (and my customers) need log rotation function via > external > >>>>>>>>>>>>>>>> tool. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I want to merge it by Feature Complete. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Yasumasa > >>>>>>>>>>>>>>>> 2015/10/16 22:55 "Yasumasa Suenaga" > >: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Hi all, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I contributed JDK-7090324: gclog rotation via > external tool > >>>>>>>>>>>>>>>>> to be > >>>>>>>>>>>>>>>>> synchronized with > >>>>>>>>>>>>>>>>> logrotated tool on Linux. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I think JEP 158 is in progress. > >>>>>>>>>>>>>>>>> However, this JEP does not contain log rotation via > external > >>>>>>>>>>>>>>>>> tool in the > >>>>>>>>>>>>>>>>> spec. > >>>>>>>>>>>>>>>>> I want to rotate logs via jcmd in this JEP. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I've updated a patch for it: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/jvmlogging-logrotate/ > > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> This patch provides new option "rotate" in VM.log > command. > >>>>>>>>>>>>>>>>> If this change can be accepted, I will file it to > JBS and send > >>>>>>>>>>>>>>>>> RFR. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Yasumasa > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Thu Dec 3 11:09:12 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 3 Dec 2015 12:09:12 +0100 Subject: RFR 8141526: Allow to collect stdout/stderr from the FinalizationRunner even before the process returns In-Reply-To: <56562D60.80306@oracle.com> References: <563CD13B.8040800@oracle.com> <56562D60.80306@oracle.com> Message-ID: <566022D8.5000706@oracle.com> On 25.11.2015 22:51, Dmitry Samersoff wrote: > Jaroslav, > > Looks good for me. > > PS: I found a bug in canPtraceAttachLinux not related to your changes - > it's probably my mistake: > > 181 if (userName.equals("root")) { > 182 return true; > 183 } > > shouldn't be there. > > Could you file a separate CR and assign it to me? Actually, it is the result of my merge of the hotspot and jdk version of Platform.java. I will just remove it from there: http://cr.openjdk.java.net/~jbachorik/8141526/webrev.01 -JB- > > -Dmitry > > On 2015-11-06 19:11, Jaroslav Bachorik wrote: >> [wider audience included] >> >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8141526 >> Webrev: >> top> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00 >> hotspot> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/hotspot >> jdk> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/jdk >> >> After the fix for https://bugs.openjdk.java.net/browse/JDK-8135188 we >> are not able to get the debug info about the run of the launcher >> FinalizationRunner application in case it gets stuck and harness times >> out. This is because the stdout/err of the application started via >> ProcessTools.executeProcess() is collected only after the application >> has exited. >> >> The solution is to use ProcessTools.startProcess() and consume the >> application stdout/err in a streaming mode. Because this method has only >> been available in the 'jdk' version of ProcessTools and not in the >> 'hotspot' one I decided to merge both of those versions and place the >> merged version into the shared location 'test/lib/share/classes/'. >> During this I decided to change the package for the shared ProcessTools >> class to be 'jdk.test.lib.process' to be more in line with the way this >> shared library is structured. I had to move few other lib classes >> required by ProcessTools to the shared lib as well. All the moved lib >> classes have been marked as deprecated in their original location. >> >> >> Thanks, >> >> -JB- >> > > From ecki at zusammenkunft.net Thu Dec 3 11:23:51 2015 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Thu, 3 Dec 2015 12:23:51 +0100 Subject: RFR[ 9u-dev] JDK-8138745: Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot In-Reply-To: <565FE80F.2030603@oracle.com> References: <5655AC56.4080204@oracle.com> <56569C08.7010406@oracle.com> <5656A689.3010006@oracle.com> <565FE80F.2030603@oracle.com> Message-ID: <47205f2d-26df-47f6-9528-71840149d803.maildroid@localhost> Hello, I think "binary crash file" is not a clear wording, it made me wonder if this is a hprof heap dump. It should explicitely say "sytem core dump, when enabled". (The webrev below did not contain actual crash-code, is it already commited?). BTW, rejecting large array allocations could be argued that it is not a situation where you want/need the exit. That might not be the best test case? I agree with Abort* as the better naming Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: cheleswer sahu To: David Holmes , serviceability-dev at openjdk.java.net, Staffan Larsen Cc: Rajendrakumar Pallath Sent: Do., 03 Dez. 2015 8:28 Subject: Re: RFR[ 9u-dev] JDK-8138745: Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot Hi, Thanks David and Staffan for your comments. Please review the code changes in the updated webrev below http://cr.openjdk.java.net/~kevinw/8138745/webrev.01/ Regards, Cheleswer On 11/26/2015 11:58 AM, David Holmes wrote: > Sorry forgot the tests .... > > test/runtime/ErrorHandling/TestExitOnOutOfMemoryError.java > > This test is checking that new Object[Integer.MAX_VALUE]; caused the > "Requested array size exceeds VM limit" failure _but_ it doesn't > actually do anything to verify that the VM terminated because of the > ExitOnOutOfMemory flag. I suggest: > > a) augment the termination message in the VM as I suggested earlier so > that you can be sure you hit the termination code > b) check for a zero/non-zero return code as appropriate > c) Add: throw new Error("OOME was not triggered"); after line 41. > d) Put a try/catch(OOME) around the allocation and throw an Error if > you get to the catch block > > That way we will get a test failure when Arrays 2.0 allows such > massive arrays to be created :) > > Similar considerations for TestCrashOnOutOfMemoryError.java, but you > also need to disable core dump generation. > > David > ----- > > On 26/11/2015 3:43 PM, David Holmes wrote: >> Hi, >> >> On 25/11/2015 10:40 PM, cheleswer sahu wrote: >>> Hi, >>> >>> Please review the code changes for >>> "https://bugs.openjdk.java.net/browse/JDK-8138745". >>> Web review link: >>> http://cr.openjdk.java.net/~kevinw/8138745/webrev.00/ >>> >>> >>> >>> Enhancement Brief: >>> ExitOnOutOfMemoryError: When user enable this option, the JVM exits on >>> the first occurrence of an out-of-memory error. It can be used if user >>> prefer restarting an instance of the JVM rather than handling out of >>> memory errors. >>> >>> CrashOnOutOfMemoryError: If this option is enabled, when an >>> out-of-memory error occurs, the JVM crashes and produces text and >>> binary >>> crash files. >> >> The term "crash" is not very appropriate - crashes are bad things. Abort >> may have been a better choice. >> >>> For more details please refer http://ccc.us.oracle.com/8138745 >> >> This is not accessible outside of Oracle. >> >> A few minor comments: >> >> src/share/vm/runtime/globals.hpp >> >> + "JVM crashes and produces text and binary crash files") >> >> Terminology should be consistent with other options that control core >> dump. Should also say "on first occurrence of an out-of-memory error". >> >> src/share/vm/utilities/debug.cpp: >> >> 308 if (CrashOnOutOfMemoryError) { >> 309 tty->print_cr("java.lang.OutOfMemoryError: %s", message); >> 310 fatal("OutOfMemory encountered: %s", message); >> 311 } >> >> don't really need the tty->print when using the fatal. Though you may >> want to use the j.l.OOME form of the message for consistency. Might also >> be useful for both Crash and Exit to include in the logged messages the >> fact that these flags were involved - something like: >> >> "Terminating due to java.lang.OutOfMemoryError: %s" >> "Aborting due to java.lang.OutOfMemoryError: %s" >> >> Thanks, >> David >> ----- >> >>> >>> Regards, >>> Cheleswer >>> From staffan.larsen at oracle.com Thu Dec 3 12:14:33 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 3 Dec 2015 13:14:33 +0100 Subject: PING: RFR: JDK-8140556: Add force rotation option to VM.log jcmd In-Reply-To: References: <562101D8.5080909@gmail.com> <562DF8D4.40501@oracle.com> <562EBF4B.4020607@gmail.com> <562F6B46.5050500@oracle.com> <563226AB.2030206@gmail.com> <5632341F.4060400@oracle.com> <56338125.9030802@gmail.com> <56338D58.9090709@oracle.com> <5634D9FC.6080502@gmail.com> <5636C66A.6020304@oracle.com> <563765FC.2090804@gmail.com> <563ACD6F.1050600@gmail.com> <563AD1F2.6060109@oracle.com> <563B69F9.5090102@oracle.com> <563B6CA0.9040107@gmail.com> <56487FB7.9020908@gmail.com> Message-ID: Looks good! Thanks, /Staffan > On 3 dec. 2015, at 04:33, Yasumasa Suenaga wrote: > > PING: Could you review it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.04/ > > I need reviewer and sponsor. > > Thanks, > > Yasumasa > > 2015/11/15 21:50 "Yasumasa Suenaga" : >> >> PING: Could you review it? >> http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.04/ >> >> Yasumasa >> >> >> On 2015/11/05 23:50, Yasumasa Suenaga wrote: >>>>> >>>>> _post_initialized would be a more accurate name. >>> >>> >>> I've fixed it in new webrev: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.04/ >>> >>> I will send changeset to Marcus if this changeset is reviewed. >>> >>> >>> Thanks. >>> >>> Yasumasa >>> >>> >>> On 2015/11/05 23:38, Marcus Larsson wrote: >>>> >>>> Hey, >>>> >>>> On 2015-11-05 04:50, David Holmes wrote: >>>>> >>>>> On 5/11/2015 1:30 PM, Yasumasa Suenaga wrote: >>>>>> >>>>>> I've uploaded new webrev: >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.03/ >>>>>> >>>>>> I added _initialized to LogConfiguration. >>>>>> LogConfiguration::post_initialize() will be called after main thread >>>>>> initialization. >>>>>> So _initialized set to true in this function, and we can check this > flag >>>>>> at rotation. >>>>>> >>>>>> Could you review it? >>>> >>>> >>>> Looks OK to me. This is much better than checking for Thread::current() > != NULL in is_rotatable(), IMHO. >>>> >>>>> >>>>> _post_initialized would be a more accurate name. >>>>> >>>>> This of course works, but I don't know whether the additional delay in > allowing rotation will impact anything. >>>> >>>> >>>> It shouldn't. If anyone ever generates that much logging during startup > they will have to accept that the first rotated log won't be properly > sized, that's all. >>>> >>>> Thanks, >>>> Marcus >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2015/11/02 22:32, Yasumasa Suenaga wrote: >>>>>>> >>>>>>> Marcus, David, >>>>>>> >>>>>>> I've uploaded new webrev: >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.02/ >>>>>>> >>>>>>> Could you review it? >>>>>>> >>>>>>> >>>>>>>>>>>> Still missing the renaming of rotate_all_logfile to >>>>>>>>>>>> rotate_all_outputs. >>>>>>> >>>>>>> >>>>>>> I've fixed. >>>>>>> >>>>>>> >>>>>>>>>> Small typo, please make that is_rotatable(). >>>>>>> >>>>>>> >>>>>>> I've added, and have used at LogConfiguration::rotate_all_outputs(). >>>>>>> >>>>>>> >>>>>>>> You can't safely lock a mutex until the current thread has attached >>>>>>>> to the VM and Thread::current() returns non-null (that is what >>>>>>>> Thread::initialize_thread_local_storage() currently does). You may >>>>>>>> get away with it, particularly in product builds, during VM >>>>>>>> initialization, as the fast-lock path doesn't require access to >>>>>>>> Thread::current(). >>>>>>> >>>>>>> >>>>>>> I will check whether Thread::current() is NULL or not at >>>>>>> LogFileOutput::is_rotatable() >>>>>>> is_rotatable() is called at LogFileOutput::rotate() before locking >>>>>>> _rotation_lock. >>>>>>> So we can avoid crash/assert which is related to TLS. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2015/11/02 11:11, David Holmes wrote: >>>>>>>> >>>>>>>> On 1/11/2015 1:10 AM, Yasumasa Suenaga wrote: >>>>>>>>>> >>>>>>>>>> This in turn means that we are logging before the thread local > storage >>>>>>>>>> has been initialized, and the JVM will crash/hit the assert > because we >>>>>>>>>> are trying to take the rotation lock. >>>>>>>>> >>>>>>>>> >>>>>>>>> I guess that you are saying about class member (not TLS - e.g. >>>>>>>>> pthread_setspecific()). >>>>>>>> >>>>>>>> >>>>>>>> You can't safely lock a mutex until the current thread has attached >>>>>>>> to the VM and Thread::current() returns non-null (that is what >>>>>>>> Thread::initialize_thread_local_storage() currently does). You may >>>>>>>> get away with it, particularly in product builds, during VM >>>>>>>> initialization, as the fast-lock path doesn't require access to >>>>>>>> Thread::current(). >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> Most of fields (include _rotation_lock) in LogFileOutput are >>>>>>>>> initialized >>>>>>>>> at c'tor. >>>>>>>>> Other field (_stream) is initialized at > LogFileOutput::initialize(). >>>>>>>>> >>>>>>>>> We can avoid problem if we can move initialize() to c'tor because >>>>>>>>> LogFileOutput >>>>>>>>> will be instantiated at LogConfiguration::new_output(). >>>>>>>>> >>>>>>>>> Currently, LogFileOutput will be added to > LogConfiguration::_outputs >>>>>>>>> and >>>>>>>>> to LogTagSet after calling LogFileOutput::initialize(). >>>>>>>>> I wonder why we cannot avoid crash/assert with current >>>>>>>>> implementation... >>>>>>>>> >>>>>>>>> >>>>>>>>> I will keep current implementation about _rotation_lock if the > above is >>>>>>>>> incorrect. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2015/10/31 0:31, Marcus Larsson wrote: >>>>>>>>>> >>>>>>>>>> Hey, >>>>>>>>>> >>>>>>>>>> On 2015-10-30 15:39, Yasumasa Suenaga wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Marcus, >>>>>>>>>>> >>>>>>>>>>> Thank you for your comment. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Still missing the renaming of rotate_all_logfile to >>>>>>>>>>>> rotate_all_outputs. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Sorry, I will fix. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> This rotate function works I guess, but it will probably need > some >>>>>>>>>>>> rework once there are other types of log outputs (rotate doesn't >>>>>>>>>>>> make sense on all types of log outputs). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I will add is_rotetable() to LogOutput as virtual function. >>>>>>>>>>> This function return false (can not rotate) by default, return > true >>>>>>>>>>> if _file_count is >>>>>>>>>>> greater than 0 in LogFileOutput. >>>>>>>>>>> >>>>>>>>>>> LogConfiguration::rotate_all_outputs() will rotate if this > function >>>>>>>>>>> returns true. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Small typo, please make that is_rotatable(). >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> If we configure a rotated file output and then log something on > that >>>>>>>>>>>> output before thread local storage initialization is complete, > we >>>>>>>>>>>> will crash/hit an assert. The previous implementation avoided > this >>>>>>>>>>>> as long as no rotation was needed before this initialization was >>>>>>>>>>>> complete. (This can be triggered using the following arguments >>>>>>>>>>>> "-Xlog:all=trace:file.txt::filesize=10,filecount=2 > -Xlog:invalid", >>>>>>>>>>>> for example.) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I do not think so. >>>>>>>>>>> Each -Xlog option creates unique instance of LogOutput (and >>>>>>>>>>> subclass). >>>>>>>>>>> So they are isolated. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> My example includes a second (and intentionally incorrect) -Xlog >>>>>>>>>> option only to trigger logging on the newly configured rotating >>>>>>>>>> LogFileOutput. This will cause some logging about the invalid > -Xlog >>>>>>>>>> argument, and this logging happens during the argument parsing. > This >>>>>>>>>> in turn means that we are logging before the thread local storage > has >>>>>>>>>> been initialized, and the JVM will crash/hit the assert because > we are >>>>>>>>>> trying to take the rotation lock. This has nothing to do with >>>>>>>>>> concurrent fprintfs or freopens, even if that is a problem. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> However, we might have to rotate at safepoint. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Doing stuff at a safepoint will not give us much in this case. > There >>>>>>>>>> are threads that continue execution through a safepoint, which > means >>>>>>>>>> we will see log calls being made even during this time. >>>>>>>>>> >>>>>>>>>>> Currently, LogOutput might be used by multiple threads > concurrently. >>>>>>>>>>> If we rotate log when another thread is writing string to > output, we >>>>>>>>>>> encounter unexpected behavior. >>>>>>>>>>> >>>>>>>>>>> LogFileOutput::rotate() uses freopen(). >>>>>>>>>>> LogFileStreamOutput::write() uses vfprintf() through > jio_fprintf(). >>>>>>>>>>> freopen() and vfprintf() are not atomic. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> You're right. There seems to be an overlooked concurrency issue > with >>>>>>>>>> vfprintfs during freopen. I don't think we should resolve this as > part >>>>>>>>>> of this particular fix, so instead I'll create a separate issue > for >>>>>>>>>> it. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I think that cause of crash/assertion which you say is it. >>>>>>>>>>> (GC log will be rotated at safepoint.) >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> See my comment above for what crash/assert I'm talking about. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Marcus >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2015/10/29 23:58, Marcus Larsson wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> On 2015-10-29 15:01, Yasumasa Suenaga wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Marcus, >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you for your comment. >>>>>>>>>>>>> >>>>>>>>>>>>>> I'll sponsor it. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you so much! >>>>>>>>>>>>> I've uploaded new webrev: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Still missing the renaming of rotate_all_logfile to >>>>>>>>>>>> rotate_all_outputs. >>>>>>>>>>>> >>>>>>>>>>>>>> logConfiguration.cpp/hpp: >>>>>>>>>>>>>> >>>>>>>>>>>>>> * I don't think we should rely on the archive_name or the > output's >>>>>>>>>>>>>> name to decide whether or not an output should be rotated. It >>>>>>>>>>>>>> would be better to introduce an is_rotated() test function in >>>>>>>>>>>>>> LogOutput that could be used here. >>>>>>>>>>>>>> >>>>>>>>>>>>>> * rotate_all_logfile() should be renamed to > rotate_all_outputs(). >>>>>>>>>>>>>> Currently there are only LogFileOutputs (other than >>>>>>>>>>>>>> stdout/stderr), but in the future there might be other types > of >>>>>>>>>>>>>> outputs so I prefer having a more general name. >>>>>>>>>>>>>> Also, please use static_cast instead of the >>>>>>>>>>>>>> C-style cast. (Additional logic will be required here once > more >>>>>>>>>>>>>> types of log outputs are added, but I don't think we need to > worry >>>>>>>>>>>>>> about this right now.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Don't print an error if an output is not rotatable, since > it's >>>>>>>>>>>>>> not an error to have some log outputs rotated while others are >>>>>>>>>>>>>> not. If you really want some traceability here I suggest > adding >>>>>>>>>>>>>> log messages on trace level, tagged with 'logging'. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I added LogOutput::rotate(bool) as virtual function. >>>>>>>>>>>>> This function works nothing by default, but will rotate all > logs at >>>>>>>>>>>>> LogFileOutput. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This rotate function works I guess, but it will probably need > some >>>>>>>>>>>> rework once there are other types of log outputs (rotate doesn't >>>>>>>>>>>> make sense on all types of log outputs). >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> If true is passed to this function, all files will be rotated. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> logDiagnosticCommand.cpp/hpp: >>>>>>>>>>>>>> >>>>>>>>>>>>>> * I think the description could be improved to something like >>>>>>>>>>>>>> "Lists current log configuration, enables/disables/configures > a >>>>>>>>>>>>>> log output, or disables/rotates all logs." >>>>>>>>>>>>>> >>>>>>>>>>>>>> * The rotate option description should clarify that all logs > will >>>>>>>>>>>>>> be rotated ("current log" is too ambiguous). >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I've fixed. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Great, thanks! >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> logFileOutput.cpp/hpp: >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Moving the MutexLocker like this introduces a race condition >>>>>>>>>>>>>> where a log might be rotated multiple times by different > threads, >>>>>>>>>>>>>> instead of just once. >>>>>>>>>>>>>> Instead of making the rotate() function public and moving the >>>>>>>>>>>>>> mutexlocker, I suggest adding something like a public >>>>>>>>>>>>>> force_rotation() function that grabs the lock and calls the >>>>>>>>>>>>>> private rotate(). >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Given the addition of is_rotated() in LogOutput, then >>>>>>>>>>>>>> get_archive_name() should be removed. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I moved MutexLocker and should_rotate() to rotate(). >>>>>>>>>>>>> I think this change can avoid race condition. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> There is a subtle problem with taking the lock to check if we > should >>>>>>>>>>>> rotate. If we configure a rotated file output and then log > something >>>>>>>>>>>> on that output before thread local storage initialization is >>>>>>>>>>>> complete, we will crash/hit an assert. The previous > implementation >>>>>>>>>>>> avoided this as long as no rotation was needed before this >>>>>>>>>>>> initialization was complete. (This can be triggered using the >>>>>>>>>>>> following arguments >>>>>>>>>>>> "-Xlog:all=trace:file.txt::filesize=10,filecount=2 > -Xlog:invalid", >>>>>>>>>>>> for example.) >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Marcus >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2015/10/27 21:17, Marcus Larsson wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2015-10-27 01:03, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Marcus, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you for replying. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I filed this feature to JBS and change subject of this email. >>>>>>>>>>>>>>> Could you be a sponsor and review it? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'll sponsor it. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8140556/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> logConfiguration.cpp/hpp: >>>>>>>>>>>>>> >>>>>>>>>>>>>> * I don't think we should rely on the archive_name or the > output's >>>>>>>>>>>>>> name to decide whether or not an output should be rotated. It >>>>>>>>>>>>>> would be better to introduce an is_rotated() test function in >>>>>>>>>>>>>> LogOutput that could be used here. >>>>>>>>>>>>>> >>>>>>>>>>>>>> * rotate_all_logfile() should be renamed to > rotate_all_outputs(). >>>>>>>>>>>>>> Currently there are only LogFileOutputs (other than >>>>>>>>>>>>>> stdout/stderr), but in the future there might be other types > of >>>>>>>>>>>>>> outputs so I prefer having a more general name. >>>>>>>>>>>>>> Also, please use static_cast instead of the >>>>>>>>>>>>>> C-style cast. (Additional logic will be required here once > more >>>>>>>>>>>>>> types of log outputs are added, but I don't think we need to > worry >>>>>>>>>>>>>> about this right now.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Don't print an error if an output is not rotatable, since > it's >>>>>>>>>>>>>> not an error to have some log outputs rotated while others are >>>>>>>>>>>>>> not. If you really want some traceability here I suggest > adding >>>>>>>>>>>>>> log messages on trace level, tagged with 'logging'. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> logDiagnosticCommand.cpp/hpp: >>>>>>>>>>>>>> >>>>>>>>>>>>>> * I think the description could be improved to something like >>>>>>>>>>>>>> "Lists current log configuration, enables/disables/configures > a >>>>>>>>>>>>>> log output, or disables/rotates all logs." >>>>>>>>>>>>>> >>>>>>>>>>>>>> * The rotate option description should clarify that all logs > will >>>>>>>>>>>>>> be rotated ("current log" is too ambiguous). >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> logFileOutput.cpp/hpp: >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Moving the MutexLocker like this introduces a race condition >>>>>>>>>>>>>> where a log might be rotated multiple times by different > threads, >>>>>>>>>>>>>> instead of just once. >>>>>>>>>>>>>> Instead of making the rotate() function public and moving the >>>>>>>>>>>>>> mutexlocker, I suggest adding something like a public >>>>>>>>>>>>>> force_rotation() function that grabs the lock and calls the >>>>>>>>>>>>>> private rotate(). >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Given the addition of is_rotated() in LogOutput, then >>>>>>>>>>>>>> get_archive_name() should be removed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Marcus >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2015/10/26 18:56, Marcus Larsson wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sorry for my late reply. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think being able to force rotation via jcmd seems like a > good >>>>>>>>>>>>>>>> feature. Files are currently opened in append mode so it > should >>>>>>>>>>>>>>>> already be possible to use external log rotation tools by >>>>>>>>>>>>>>>> copying and truncating the files. Still I think it would be > nice >>>>>>>>>>>>>>>> to provide the jcmd for rotation as well. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I can see some small issues with the implementation, but we > can >>>>>>>>>>>>>>>> deal with that during the review. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Marcus >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2015-10-26 00:26, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Have you ever seen my change? >>>>>>>>>>>>>>>>> I (and my customers) need log rotation function via > external >>>>>>>>>>>>>>>>> tool. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I want to merge it by Feature Complete. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>> 2015/10/16 22:55 "Yasumasa Suenaga" : >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I contributed JDK-7090324: gclog rotation via external > tool >>>>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>>>> synchronized with >>>>>>>>>>>>>>>>>> logrotated tool on Linux. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I think JEP 158 is in progress. >>>>>>>>>>>>>>>>>> However, this JEP does not contain log rotation via > external >>>>>>>>>>>>>>>>>> tool in the >>>>>>>>>>>>>>>>>> spec. >>>>>>>>>>>>>>>>>> I want to rotate logs via jcmd in this JEP. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I've updated a patch for it: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/jvmlogging-logrotate/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> This patch provides new option "rotate" in VM.log command. >>>>>>>>>>>>>>>>>> If this change can be accepted, I will file it to JBS and > send >>>>>>>>>>>>>>>>>> RFR. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>> From dmitry.samersoff at oracle.com Thu Dec 3 12:29:19 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 3 Dec 2015 15:29:19 +0300 Subject: RFR 8141526: Allow to collect stdout/stderr from the FinalizationRunner even before the process returns In-Reply-To: <566022D8.5000706@oracle.com> References: <563CD13B.8040800@oracle.com> <56562D60.80306@oracle.com> <566022D8.5000706@oracle.com> Message-ID: <5660359F.7000702@oracle.com> Jaroslav, Looks good for me! -Dmitry On 2015-12-03 14:09, Jaroslav Bachorik wrote: > On 25.11.2015 22:51, Dmitry Samersoff wrote: >> Jaroslav, >> >> Looks good for me. >> >> PS: I found a bug in canPtraceAttachLinux not related to your changes - >> it's probably my mistake: >> >> 181 if (userName.equals("root")) { >> 182 return true; >> 183 } >> >> shouldn't be there. >> >> Could you file a separate CR and assign it to me? > > Actually, it is the result of my merge of the hotspot and jdk version of > Platform.java. I will just remove it from there: > http://cr.openjdk.java.net/~jbachorik/8141526/webrev.01 > > -JB- > >> >> -Dmitry >> >> On 2015-11-06 19:11, Jaroslav Bachorik wrote: >>> [wider audience included] >>> >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8141526 >>> Webrev: >>> top> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00 >>> hotspot> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/hotspot >>> jdk> http://cr.openjdk.java.net/~jbachorik/8141526/webrev.00/jdk >>> >>> After the fix for https://bugs.openjdk.java.net/browse/JDK-8135188 we >>> are not able to get the debug info about the run of the launcher >>> FinalizationRunner application in case it gets stuck and harness times >>> out. This is because the stdout/err of the application started via >>> ProcessTools.executeProcess() is collected only after the application >>> has exited. >>> >>> The solution is to use ProcessTools.startProcess() and consume the >>> application stdout/err in a streaming mode. Because this method has only >>> been available in the 'jdk' version of ProcessTools and not in the >>> 'hotspot' one I decided to merge both of those versions and place the >>> merged version into the shared location 'test/lib/share/classes/'. >>> During this I decided to change the package for the shared ProcessTools >>> class to be 'jdk.test.lib.process' to be more in line with the way this >>> shared library is structured. I had to move few other lib classes >>> required by ProcessTools to the shared lib as well. All the moved lib >>> classes have been marked as deprecated in their original location. >>> >>> >>> Thanks, >>> >>> -JB- >>> >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From bengt.rutisson at oracle.com Thu Dec 3 12:32:09 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 3 Dec 2015 13:32:09 +0100 Subject: RFR: 8144220: UL does not support full path names for log files on windows In-Reply-To: <56601544.8070203@oracle.com> References: <565EF508.4030805@oracle.com> <56601544.8070203@oracle.com> Message-ID: <56603649.8010208@oracle.com> Hi Marcus, On 2015-12-03 11:11, Marcus Larsson wrote: > Hi, > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8144220/webrev.01/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00-01/ Looks good. One small detail: I think the test should have the annotation "@bug 8144220". No need for a new webrev for that. Thanks, Bengt > > Added more test cases to the test, and renamed it to > TestQuotedLogOutputs. > The updated test found that partially quoted output names that didn't > start > with the quote character were accepted. This has been fixed. > > Test passes in RBT. > > Thanks, > Marcus > > On 2015-12-02 14:41, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to allow full path names for log >> files on windows. >> >> The full path to files will on windows contain a colon (from the C:\ >> part), and there used to be no way to avoid that colon from being >> parsed as the delimiter for the next -Xlog: option. With this patch >> it is now possible to avoid this by giving the path within quotation >> marks, for example: -Xlog:all:"C:\out.log". Any colons within quotes >> will not be parsed as delimiters for -Xlog. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8144220 >> >> Testing: >> New test through RBT. >> >> Thanks, >> Marcus > From marcus.larsson at oracle.com Thu Dec 3 12:43:37 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 3 Dec 2015 13:43:37 +0100 Subject: RFR: 8144220: UL does not support full path names for log files on windows In-Reply-To: <56603649.8010208@oracle.com> References: <565EF508.4030805@oracle.com> <56601544.8070203@oracle.com> <56603649.8010208@oracle.com> Message-ID: <566038F9.5010507@oracle.com> Hi, On 2015-12-03 13:32, Bengt Rutisson wrote: > > Hi Marcus, > > On 2015-12-03 11:11, Marcus Larsson wrote: >> Hi, >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8144220/webrev.01/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00-01/ > > Looks good. One small detail: I think the test should have the > annotation "@bug 8144220". No need for a new webrev for that. Great, thanks! I'll add that before pushing. Regards, Marcus > > Thanks, > Bengt > >> >> Added more test cases to the test, and renamed it to >> TestQuotedLogOutputs. >> The updated test found that partially quoted output names that didn't >> start >> with the quote character were accepted. This has been fixed. >> >> Test passes in RBT. >> >> Thanks, >> Marcus >> >> On 2015-12-02 14:41, Marcus Larsson wrote: >>> Hi, >>> >>> Please review the following patch to allow full path names for log >>> files on windows. >>> >>> The full path to files will on windows contain a colon (from the C:\ >>> part), and there used to be no way to avoid that colon from being >>> parsed as the delimiter for the next -Xlog: option. With this patch >>> it is now possible to avoid this by giving the path within quotation >>> marks, for example: -Xlog:all:"C:\out.log". Any colons within quotes >>> will not be parsed as delimiters for -Xlog. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8144220 >>> >>> Testing: >>> New test through RBT. >>> >>> Thanks, >>> Marcus >> > From dmitry.samersoff at oracle.com Thu Dec 3 20:01:06 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 3 Dec 2015 23:01:06 +0300 Subject: RFR(S): JDK-8131694 backout the fix for JDK-8131331 when JDK-8131693 is fixed Message-ID: <56609F82.8040707@oracle.com> Everybody, Please review: http://cr.openjdk.java.net/~dsamersoff/JDK-8131694/webrev.01/ -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.daugherty at oracle.com Thu Dec 3 21:50:08 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 3 Dec 2015 14:50:08 -0700 Subject: RFR(S): JDK-8131694 backout the fix for JDK-8131331 when JDK-8131693 is fixed In-Reply-To: <56609F82.8040707@oracle.com> References: <56609F82.8040707@oracle.com> Message-ID: <5660B910.3080102@oracle.com> On 12/3/15 1:01 PM, Dmitry Samersoff wrote: > Everybody, > > Please review: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8131694/webrev.01/ src/share/vm/runtime/vframe.cpp No comments. The backout of the fix for JDK-8131331 looks fine. Did you run the tmtools test suite to verify? Are there other tests that depend on thread dump format that should be run? Dan > > -Dmitry > From poonam.bajaj at oracle.com Thu Dec 3 22:31:18 2015 From: poonam.bajaj at oracle.com (Poonam Bajaj Parhar) Date: Thu, 03 Dec 2015 14:31:18 -0800 Subject: RFR: JDK-8140031: SA: Searching for a value in Threads does not work Message-ID: <5660C2B6.8030708@oracle.com> Hello, Please review the changes for the following fix: Bug: JDK-8140031: SA: Searching for a value in Threads does not work Fix: These changes improve the threads related commands in clhsdb 1. 'threads' command now prints the detailed information about threads. 2. 'thread' command now prints the detailed info along with its ID. 3. fixed the Stack base address. getBaseOfStackPointer() gives null base pointer. 4. Fixed the output of searching for a value in thread stacks. Webrev: http://cr.openjdk.java.net/~poonam/8140031/webrev.00/ Output after changes: hsdb> search threads 0x00000007a2211ec8 found on the stack of thread 30682 at 0x00007f8b45acdc68 hsdb> mem 0x00007f8b45acdc68 0x00007f8b45acdc68: 0x00000007a2211ec8 hsdb> thread 30682 Thread 30682 Address 0x00007f8be85f2000 State: BLOCKED Stack in use by Java: 0x00007f8b45accef0 .. 0x00007f8b45acf7c0 Base of Stack: 0x00007f8b45ad1000 Last_Java_SP: 0x00007f8b45accef0 Last_Java_FP: null Last_Java_PC: 0x00007f8ca6e672d1 Thread id: 30682 hsdb> threads 21344 [STANDBY] ExecuteThread: '521' for queue: 'weblogic.kernel.Default (self-tuning)' State: BLOCKED Stack in use by Java: 0x00007f8b37bb92d0 .. 0x00007f8b37bba840 Base of Stack: 0x00007f8b37bbc000 Last_Java_SP: 0x00007f8b37bb92d0 Last_Java_FP: null Last_Java_PC: null Thread id: 21344 ... 21336 [STANDBY] ExecuteThread: '520' for queue: 'weblogic.kernel.Default (self-tuning)' State: BLOCKED Stack in use by Java: 0x00007f8b41adabb0 .. 0x00007f8b41ae17c0 Base of Stack: 0x00007f8b41ae3000 Last_Java_SP: 0x00007f8b41adabb0 Last_Java_FP: null Last_Java_PC: null Thread id: 21336 ... 21227 [STANDBY] ExecuteThread: '519' for queue: 'weblogic.kernel.Default (self-tuning)' State: BLOCKED Stack in use by Java: 0x00007f8b424e4b30 .. 0x00007f8b424eb740 Base of Stack: 0x00007f8b424ed000 Last_Java_SP: 0x00007f8b424e4b30 Last_Java_FP: null Last_Java_PC: null Thread id: 21227 ... Testing: Tested CLHSDB with a core file and executed thread, threads and search threads commands. Thanks, Poonam From dmitry.samersoff at oracle.com Thu Dec 3 23:52:18 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 4 Dec 2015 02:52:18 +0300 Subject: RFR: JDK-8140031: SA: Searching for a value in Threads does not work In-Reply-To: <5660C2B6.8030708@oracle.com> References: <5660C2B6.8030708@oracle.com> Message-ID: <5660D5B2.1090505@oracle.com> Poonam, Thank you for fixing it. Looks good for me! -Dmitry On 2015-12-04 01:31, Poonam Bajaj Parhar wrote: > Hello, > > Please review the changes for the following fix: > > Bug: JDK-8140031: SA: Searching for a value in Threads does not work > > Fix: These changes improve the threads related commands in clhsdb > 1. 'threads' command now prints the detailed information about threads. > 2. 'thread' command now prints the detailed info along with its ID. > 3. fixed the Stack base address. getBaseOfStackPointer() gives null base > pointer. > 4. Fixed the output of searching for a value in thread stacks. > > Webrev: http://cr.openjdk.java.net/~poonam/8140031/webrev.00/ > > Output after changes: > hsdb> search threads 0x00000007a2211ec8 > found on the stack of thread 30682 at 0x00007f8b45acdc68 > hsdb> mem 0x00007f8b45acdc68 > 0x00007f8b45acdc68: 0x00000007a2211ec8 > hsdb> thread 30682 > Thread 30682 Address 0x00007f8be85f2000 > State: BLOCKED > Stack in use by Java: 0x00007f8b45accef0 .. 0x00007f8b45acf7c0 > Base of Stack: 0x00007f8b45ad1000 > Last_Java_SP: 0x00007f8b45accef0 > Last_Java_FP: null > Last_Java_PC: 0x00007f8ca6e672d1 > Thread id: 30682 > hsdb> threads > 21344 [STANDBY] ExecuteThread: '521' for queue: 'weblogic.kernel.Default > (self-tuning)' > State: BLOCKED > Stack in use by Java: 0x00007f8b37bb92d0 .. 0x00007f8b37bba840 > Base of Stack: 0x00007f8b37bbc000 > Last_Java_SP: 0x00007f8b37bb92d0 > Last_Java_FP: null > Last_Java_PC: null > Thread id: 21344 > ... > 21336 [STANDBY] ExecuteThread: '520' for queue: 'weblogic.kernel.Default > (self-tuning)' > State: BLOCKED > Stack in use by Java: 0x00007f8b41adabb0 .. 0x00007f8b41ae17c0 > Base of Stack: 0x00007f8b41ae3000 > Last_Java_SP: 0x00007f8b41adabb0 > Last_Java_FP: null > Last_Java_PC: null > Thread id: 21336 > ... > 21227 [STANDBY] ExecuteThread: '519' for queue: 'weblogic.kernel.Default > (self-tuning)' > State: BLOCKED > Stack in use by Java: 0x00007f8b424e4b30 .. 0x00007f8b424eb740 > Base of Stack: 0x00007f8b424ed000 > Last_Java_SP: 0x00007f8b424e4b30 > Last_Java_FP: null > Last_Java_PC: null > Thread id: 21227 > ... > > Testing: > Tested CLHSDB with a core file and executed thread, threads and search > threads commands. > > Thanks, > Poonam > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From marcus.larsson at oracle.com Fri Dec 4 14:46:01 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 4 Dec 2015 15:46:01 +0100 Subject: RFR: 8144146: Unified Logging tags cannot be reserved keywords Message-ID: <5661A729.1050206@oracle.com> Hi, Please review the following patch to allow C++ reserved keywords to be used as UL tags. This allows usage of a 'class' tag, for example. Tags are now automatically prefixed with underscores by the macros. This means they will still be referred to without underscores when used, but avoid keyword conflicts. Webrev: http://cr.openjdk.java.net/~mlarsson/8144146/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8144146 Testing: JPRT testset hotspot Thanks, Marcus From dmitry.samersoff at oracle.com Fri Dec 4 18:16:05 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 4 Dec 2015 21:16:05 +0300 Subject: RFR(S): JDK-8131694 backout the fix for JDK-8131331 when JDK-8131693 is fixed In-Reply-To: <5660B910.3080102@oracle.com> References: <56609F82.8040707@oracle.com> <5660B910.3080102@oracle.com> Message-ID: <5661D865.3040707@oracle.com> Dan, I run RBT job with vm.tmtools testset. Is it enough? -Dmitry On 2015-12-04 00:50, Daniel D. Daugherty wrote: > On 12/3/15 1:01 PM, Dmitry Samersoff wrote: >> Everybody, >> >> Please review: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8131694/webrev.01/ > > src/share/vm/runtime/vframe.cpp > No comments. > > The backout of the fix for JDK-8131331 looks fine. > > Did you run the tmtools test suite to verify? Are there other tests > that depend on thread dump format that should be run? > > Dan > > >> >> -Dmitry >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.daugherty at oracle.com Fri Dec 4 18:19:22 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 4 Dec 2015 11:19:22 -0700 Subject: RFR(S): JDK-8131694 backout the fix for JDK-8131331 when JDK-8131693 is fixed In-Reply-To: <5661D865.3040707@oracle.com> References: <56609F82.8040707@oracle.com> <5660B910.3080102@oracle.com> <5661D865.3040707@oracle.com> Message-ID: <5661D92A.2090606@oracle.com> I believe so... but I'm not a Serviceability expert :-) Dan On 12/4/15 11:16 AM, Dmitry Samersoff wrote: > Dan, > > I run RBT job with vm.tmtools testset. > > Is it enough? > > -Dmitry > > On 2015-12-04 00:50, Daniel D. Daugherty wrote: >> On 12/3/15 1:01 PM, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please review: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8131694/webrev.01/ >> src/share/vm/runtime/vframe.cpp >> No comments. >> >> The backout of the fix for JDK-8131331 looks fine. >> >> Did you run the tmtools test suite to verify? Are there other tests >> that depend on thread dump format that should be run? >> >> Dan >> >> >>> -Dmitry >>> > From david.holmes at oracle.com Mon Dec 7 06:26:40 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2015 16:26:40 +1000 Subject: RFR: 8144146: Unified Logging tags cannot be reserved keywords In-Reply-To: <5661A729.1050206@oracle.com> References: <5661A729.1050206@oracle.com> Message-ID: <566526A0.7090507@oracle.com> Hi Marcus, On 5/12/2015 12:46 AM, Marcus Larsson wrote: > Hi, > > Please review the following patch to allow C++ reserved keywords to be > used as UL tags. This allows usage of a 'class' tag, for example. > > Tags are now automatically prefixed with underscores by the macros. This > means they will still be referred to without underscores when used, but > avoid keyword conflicts. Does the list of available tags show them with or without underscores? Thanks, David > Webrev: > http://cr.openjdk.java.net/~mlarsson/8144146/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8144146 > > Testing: > JPRT testset hotspot > > Thanks, > Marcus From marcus.larsson at oracle.com Mon Dec 7 07:58:49 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 7 Dec 2015 08:58:49 +0100 Subject: RFR: 8144146: Unified Logging tags cannot be reserved keywords In-Reply-To: <566526A0.7090507@oracle.com> References: <5661A729.1050206@oracle.com> <566526A0.7090507@oracle.com> Message-ID: <56653C39.60403@oracle.com> Hi David, On 2015-12-07 07:26, David Holmes wrote: > Hi Marcus, > > On 5/12/2015 12:46 AM, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to allow C++ reserved keywords to be >> used as UL tags. This allows usage of a 'class' tag, for example. >> >> Tags are now automatically prefixed with underscores by the macros. This >> means they will still be referred to without underscores when used, but >> avoid keyword conflicts. > > Does the list of available tags show them with or without underscores? Without. Essentially, everything (configuration, printing/listing) will work just like before, but "internally" the tags will be prefixed with the underscore. Thanks, Marcus > > Thanks, > David > >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8144146/webrev.00/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8144146 >> >> Testing: >> JPRT testset hotspot >> >> Thanks, >> Marcus From jaroslav.bachorik at oracle.com Mon Dec 7 08:43:48 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 7 Dec 2015 09:43:48 +0100 Subject: [ping] Re: RFR 8144308: com/sun/jdi/SuspendThreadTest.java failed with "transport error 202: send failed: Broken pipe" In-Reply-To: <565DDA00.8090007@oracle.com> References: <565DDA00.8090007@oracle.com> Message-ID: <566546C4.2080105@oracle.com> On 1.12.2015 18:33, Jaroslav Bachorik wrote: > Please, review the following simple test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8144308 > Webrev: http://cr.openjdk.java.net/~jbachorik/8144308/webrev.00 > > The test keeps the debuggee spinning in a loop and does not stop it once > the testing is over. While the harness usually takes care of this, > occasionally it fails while trying to do that. > > The fix is to add a loop invariant variable and set it to false once we > are done with the debugee and it is ok for it to finish. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Mon Dec 7 08:46:32 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 7 Dec 2015 09:46:32 +0100 Subject: [preview] Adding java.lang.Runtime.getVMArguments() method In-Reply-To: <56584AB7.8020002@oracle.com> References: <5654952C.5080108@oracle.com> <5654F687.8040709@gmail.com> <5165C720-3F7E-4BDF-A3D5-9604507EBA36@oracle.com> <56551BEA.5040900@oracle.com> <5656F1A0.1070100@oracle.com> <5656F430.7080509@oracle.com> <56584AB7.8020002@oracle.com> Message-ID: <56654768.6080406@oracle.com> On 27.11.2015 13:21, Jaroslav Bachorik wrote: > On 26.11.2015 12:59, Jaroslav Bachorik wrote: >> On 26.11.2015 12:48, Jaroslav Bachorik wrote: >>> On 25.11.2015 04:11, Mandy Chung wrote: >>>> >>>> > On Nov 24, 2015, at 6:24 PM, David Holmes >>>> wrote: >>>> > >>>> > On 25/11/2015 10:06 AM, Mandy Chung wrote: >>>> >> >>>> >>> On Nov 24, 2015, at 3:45 PM, Peter Levart >>>> wrote: >>>> >>> >>>> >>> >>>> >>> >>>> >>> On 11/24/2015 05:49 PM, Jaroslav Bachorik wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>> while working on an issue to clean up a code in java.base module >>>> using reflection to access RuntimeMXBean (from java.management module) >>>> in order to get hold of the VM arguments (yes, this won't work with >>>> module boundaries in place) it was pointed out that this functionality >>>> should be available in java.base without going through JMX. >>>> >>> >>>> >>> Isn't the following JDK9 API already providing that: >>>> >>> >>>> >>> ProcessHandle.current().info().arguments(); >>>> >> >>>> >> This is what I also start going after. >>>> >> >>>> >> The launcher does some job on the command-line before passing to >>>> the VM, e.g. @argfile support that expands the options specified in >>>> the file, add -Djava.class.path and some system properties passing to >>>> the VM, take out -J if they are JDK tool launchers etc. >>>> > >>>> > I haven't looked at the two APIs but the command-line is potentially >>>> very different from the "VM arguments". The VM can get its arguments >>>> from the command-line, the launcher, options file and environment >>>> variables. >>>> >>>> Right - that?s what I was pointing out. In any case, I think it would >>>> need to think through the cases that Mark bring up. >>> I checked ProcessHandle.Info.arguments() and it indeed extract the >>> arguments from command line. In addition to omitting the arguments set >>> by the channels different than the command-line there is also a risk of >>> truncated command line - an example of the command-line reported for a >>> jtreg test in debug mode is in the attachment. The command-line seems to >> >> ... ok. now the attachment ... >> >>> be restricted to 4096 characters on linux (PATH_MAX) so any arguments >>> specified after this limit will be missed. >>> >>> In the light of this - wouldn't it make sense to use the functionality >>> available in RuntimeMXBean.getInputArguments() to fill the arguments >>> array reported by ProcessHandle.Info.arguments() method (instead of >>> extending j.l.Runtime with just another method)? > > This doesn't seem to be a good idea. While this would work for > ProcessHandle.current() it might be problematic for process handles for > foreign processes. We would need to treat JVM processes differently to > retrieve the same set of VM arguments as what is provided by > RuntimeMXBean.getInputArguments() now. > > Adding j.l.Runtime.getVmArguments() method seems like the best thing we > can do - the VM arguments are related to the current runtime and doing > this it allows for decoupling from java.management. Any further thoughts on this? Any objections against moving this functionality to j.l.Runtime since implementing this in ProcessHandle would lead to inconsistency between the arguments reported for 'current()' and other processes? Thanks, -JB- > > -JB- > > >>> >>> -JB- >>> >>> >>>> >>>> Mandy >>>> >>> >> > From staffan.larsen at oracle.com Mon Dec 7 09:22:25 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 7 Dec 2015 10:22:25 +0100 Subject: RFR 8144308: com/sun/jdi/SuspendThreadTest.java failed with "transport error 202: send failed: Broken pipe" In-Reply-To: <565DDA00.8090007@oracle.com> References: <565DDA00.8090007@oracle.com> Message-ID: <2F8A3D20-B887-4964-8850-7E2087CF3A6B@oracle.com> Looks good! Thanks, /Staffan > On 1 dec. 2015, at 18:33, Jaroslav Bachorik wrote: > > Please, review the following simple test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8144308 > Webrev: http://cr.openjdk.java.net/~jbachorik/8144308/webrev.00 > > The test keeps the debuggee spinning in a loop and does not stop it once the testing is over. While the harness usually takes care of this, occasionally it fails while trying to do that. > > The fix is to add a loop invariant variable and set it to false once we are done with the debugee and it is ok for it to finish. > > Thanks, > > -JB- From david.holmes at oracle.com Mon Dec 7 11:16:33 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2015 21:16:33 +1000 Subject: RFR: 8144146: Unified Logging tags cannot be reserved keywords In-Reply-To: <56653C39.60403@oracle.com> References: <5661A729.1050206@oracle.com> <566526A0.7090507@oracle.com> <56653C39.60403@oracle.com> Message-ID: <56656A91.1070700@oracle.com> On 7/12/2015 5:58 PM, Marcus Larsson wrote: > Hi David, > > On 2015-12-07 07:26, David Holmes wrote: >> Hi Marcus, >> >> On 5/12/2015 12:46 AM, Marcus Larsson wrote: >>> Hi, >>> >>> Please review the following patch to allow C++ reserved keywords to be >>> used as UL tags. This allows usage of a 'class' tag, for example. >>> >>> Tags are now automatically prefixed with underscores by the macros. This >>> means they will still be referred to without underscores when used, but >>> avoid keyword conflicts. >> >> Does the list of available tags show them with or without underscores? > > Without. > Essentially, everything (configuration, printing/listing) will work just > like before, but "internally" the tags will be prefixed with the > underscore. Okay - looks good then. Thanks, David > Thanks, > Marcus > >> >> Thanks, >> David >> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8144146/webrev.00/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8144146 >>> >>> Testing: >>> JPRT testset hotspot >>> >>> Thanks, >>> Marcus > From david.holmes at oracle.com Mon Dec 7 11:20:12 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2015 21:20:12 +1000 Subject: [preview] Adding java.lang.Runtime.getVMArguments() method In-Reply-To: <56654768.6080406@oracle.com> References: <5654952C.5080108@oracle.com> <5654F687.8040709@gmail.com> <5165C720-3F7E-4BDF-A3D5-9604507EBA36@oracle.com> <56551BEA.5040900@oracle.com> <5656F1A0.1070100@oracle.com> <5656F430.7080509@oracle.com> <56584AB7.8020002@oracle.com> <56654768.6080406@oracle.com> Message-ID: <56656B6C.9040806@oracle.com> On 7/12/2015 6:46 PM, Jaroslav Bachorik wrote: > On 27.11.2015 13:21, Jaroslav Bachorik wrote: >> On 26.11.2015 12:59, Jaroslav Bachorik wrote: >>> On 26.11.2015 12:48, Jaroslav Bachorik wrote: >>>> On 25.11.2015 04:11, Mandy Chung wrote: >>>>> >>>>> > On Nov 24, 2015, at 6:24 PM, David Holmes >>>>> wrote: >>>>> > >>>>> > On 25/11/2015 10:06 AM, Mandy Chung wrote: >>>>> >> >>>>> >>> On Nov 24, 2015, at 3:45 PM, Peter Levart >>>>> wrote: >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> On 11/24/2015 05:49 PM, Jaroslav Bachorik wrote: >>>>> >>>> Hi, >>>>> >>>> >>>>> >>>> while working on an issue to clean up a code in java.base module >>>>> using reflection to access RuntimeMXBean (from java.management module) >>>>> in order to get hold of the VM arguments (yes, this won't work with >>>>> module boundaries in place) it was pointed out that this functionality >>>>> should be available in java.base without going through JMX. >>>>> >>> >>>>> >>> Isn't the following JDK9 API already providing that: >>>>> >>> >>>>> >>> ProcessHandle.current().info().arguments(); >>>>> >> >>>>> >> This is what I also start going after. >>>>> >> >>>>> >> The launcher does some job on the command-line before passing to >>>>> the VM, e.g. @argfile support that expands the options specified in >>>>> the file, add -Djava.class.path and some system properties passing to >>>>> the VM, take out -J if they are JDK tool launchers etc. >>>>> > >>>>> > I haven't looked at the two APIs but the command-line is potentially >>>>> very different from the "VM arguments". The VM can get its arguments >>>>> from the command-line, the launcher, options file and environment >>>>> variables. >>>>> >>>>> Right - that?s what I was pointing out. In any case, I think it would >>>>> need to think through the cases that Mark bring up. >>>> I checked ProcessHandle.Info.arguments() and it indeed extract the >>>> arguments from command line. In addition to omitting the arguments set >>>> by the channels different than the command-line there is also a risk of >>>> truncated command line - an example of the command-line reported for a >>>> jtreg test in debug mode is in the attachment. The command-line >>>> seems to >>> >>> ... ok. now the attachment ... >>> >>>> be restricted to 4096 characters on linux (PATH_MAX) so any arguments >>>> specified after this limit will be missed. >>>> >>>> In the light of this - wouldn't it make sense to use the functionality >>>> available in RuntimeMXBean.getInputArguments() to fill the arguments >>>> array reported by ProcessHandle.Info.arguments() method (instead of >>>> extending j.l.Runtime with just another method)? >> >> This doesn't seem to be a good idea. While this would work for >> ProcessHandle.current() it might be problematic for process handles for >> foreign processes. We would need to treat JVM processes differently to >> retrieve the same set of VM arguments as what is provided by >> RuntimeMXBean.getInputArguments() now. >> >> Adding j.l.Runtime.getVmArguments() method seems like the best thing we >> can do - the VM arguments are related to the current runtime and doing >> this it allows for decoupling from java.management. > > Any further thoughts on this? Any objections against moving this > functionality to j.l.Runtime since implementing this in ProcessHandle > would lead to inconsistency between the arguments reported for > 'current()' and other processes? I was left unclear as to the exact intent of the API - which "arguments" does it provide? Commandline? launcher? VM? Thanks, David > Thanks, > > -JB- > >> >> -JB- >> >> >>>> >>>> -JB- >>>> >>>> >>>>> >>>>> Mandy >>>>> >>>> >>> >> > From jaroslav.bachorik at oracle.com Mon Dec 7 11:23:48 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 7 Dec 2015 12:23:48 +0100 Subject: [preview] Adding java.lang.Runtime.getVMArguments() method In-Reply-To: <56656B6C.9040806@oracle.com> References: <5654952C.5080108@oracle.com> <5654F687.8040709@gmail.com> <5165C720-3F7E-4BDF-A3D5-9604507EBA36@oracle.com> <56551BEA.5040900@oracle.com> <5656F1A0.1070100@oracle.com> <5656F430.7080509@oracle.com> <56584AB7.8020002@oracle.com> <56654768.6080406@oracle.com> <56656B6C.9040806@oracle.com> Message-ID: <56656C44.8050207@oracle.com> On 7.12.2015 12:20, David Holmes wrote: > On 7/12/2015 6:46 PM, Jaroslav Bachorik wrote: > > On 27.11.2015 13:21, Jaroslav Bachorik wrote: > >> On 26.11.2015 12:59, Jaroslav Bachorik wrote: > >>> On 26.11.2015 12:48, Jaroslav Bachorik wrote: > >>>> On 25.11.2015 04:11, Mandy Chung wrote: > >>>>> > >>>>> > On Nov 24, 2015, at 6:24 PM, David Holmes > >>>>> wrote: > >>>>> > > >>>>> > On 25/11/2015 10:06 AM, Mandy Chung wrote: > >>>>> >> > >>>>> >>> On Nov 24, 2015, at 3:45 PM, Peter Levart > >>>>> > >>>>> wrote: > >>>>> >>> > >>>>> >>> > >>>>> >>> > >>>>> >>> On 11/24/2015 05:49 PM, Jaroslav Bachorik wrote: > >>>>> >>>> Hi, > >>>>> >>>> > >>>>> >>>> while working on an issue to clean up a code in java.base module > >>>>> using reflection to access RuntimeMXBean (from java.management > >>>>> module) > >>>>> in order to get hold of the VM arguments (yes, this won't work with > >>>>> module boundaries in place) it was pointed out that this > >>>>> functionality > >>>>> should be available in java.base without going through JMX. > >>>>> >>> > >>>>> >>> Isn't the following JDK9 API already providing that: > >>>>> >>> > >>>>> >>> ProcessHandle.current().info().arguments(); > >>>>> >> > >>>>> >> This is what I also start going after. > >>>>> >> > >>>>> >> The launcher does some job on the command-line before passing to > >>>>> the VM, e.g. @argfile support that expands the options specified in > >>>>> the file, add -Djava.class.path and some system properties passing to > >>>>> the VM, take out -J if they are JDK tool launchers etc. > >>>>> > > >>>>> > I haven't looked at the two APIs but the command-line is > >>>>> potentially > >>>>> very different from the "VM arguments". The VM can get its arguments > >>>>> from the command-line, the launcher, options file and environment > >>>>> variables. > >>>>> > >>>>> Right - that?s what I was pointing out. In any case, I think it > >>>>> would > >>>>> need to think through the cases that Mark bring up. > >>>> I checked ProcessHandle.Info.arguments() and it indeed extract the > >>>> arguments from command line. In addition to omitting the arguments set > >>>> by the channels different than the command-line there is also a > >>>> risk of > >>>> truncated command line - an example of the command-line reported for a > >>>> jtreg test in debug mode is in the attachment. The command-line > >>>> seems to > >>> > >>> ... ok. now the attachment ... > >>> > >>>> be restricted to 4096 characters on linux (PATH_MAX) so any arguments > >>>> specified after this limit will be missed. > >>>> > >>>> In the light of this - wouldn't it make sense to use the functionality > >>>> available in RuntimeMXBean.getInputArguments() to fill the arguments > >>>> array reported by ProcessHandle.Info.arguments() method (instead of > >>>> extending j.l.Runtime with just another method)? > >> > >> This doesn't seem to be a good idea. While this would work for > >> ProcessHandle.current() it might be problematic for process handles for > >> foreign processes. We would need to treat JVM processes differently to > >> retrieve the same set of VM arguments as what is provided by > >> RuntimeMXBean.getInputArguments() now. > >> > >> Adding j.l.Runtime.getVmArguments() method seems like the best thing we > >> can do - the VM arguments are related to the current runtime and doing > >> this it allows for decoupling from java.management. > > > > Any further thoughts on this? Any objections against moving this > > functionality to j.l.Runtime since implementing this in ProcessHandle > > would lead to inconsistency between the arguments reported for > > 'current()' and other processes? > > I was left unclear as to the exact intent of the API - which "arguments" > does it provide? Commandline? launcher? VM? The same as http://docs.oracle.com/javase/8/docs/api/java/lang/management/RuntimeMXBean.html#getInputArguments-- Basically, this is about moving the RuntimeMXBean.getInputArguments() to a place which would not require dependency on java.management in order to get the VM input arguments. -JB- > > Thanks, > David > > > Thanks, > > > > -JB- > > > >> > >> -JB- > >> > >> > >>>> > >>>> -JB- > >>>> > >>>> > >>>>> > >>>>> Mandy > >>>>> > >>>> > >>> > >> > > From marcus.larsson at oracle.com Mon Dec 7 12:23:19 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 7 Dec 2015 13:23:19 +0100 Subject: RFR: 8144146: Unified Logging tags cannot be reserved keywords In-Reply-To: <56656A91.1070700@oracle.com> References: <5661A729.1050206@oracle.com> <566526A0.7090507@oracle.com> <56653C39.60403@oracle.com> <56656A91.1070700@oracle.com> Message-ID: <56657A37.7000808@oracle.com> On 2015-12-07 12:16, David Holmes wrote: > On 7/12/2015 5:58 PM, Marcus Larsson wrote: >> Hi David, >> >> On 2015-12-07 07:26, David Holmes wrote: >>> Hi Marcus, >>> >>> On 5/12/2015 12:46 AM, Marcus Larsson wrote: >>>> Hi, >>>> >>>> Please review the following patch to allow C++ reserved keywords to be >>>> used as UL tags. This allows usage of a 'class' tag, for example. >>>> >>>> Tags are now automatically prefixed with underscores by the macros. >>>> This >>>> means they will still be referred to without underscores when used, >>>> but >>>> avoid keyword conflicts. >>> >>> Does the list of available tags show them with or without underscores? >> >> Without. >> Essentially, everything (configuration, printing/listing) will work just >> like before, but "internally" the tags will be prefixed with the >> underscore. > > Okay - looks good then. Thanks! Regards, Marcus > > Thanks, > David > > >> Thanks, >> Marcus >> >>> >>> Thanks, >>> David >>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8144146/webrev.00/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8144146 >>>> >>>> Testing: >>>> JPRT testset hotspot >>>> >>>> Thanks, >>>> Marcus >> From staffan.larsen at oracle.com Mon Dec 7 14:43:07 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 7 Dec 2015 15:43:07 +0100 Subject: RFR: 8144146: Unified Logging tags cannot be reserved keywords In-Reply-To: <5661A729.1050206@oracle.com> References: <5661A729.1050206@oracle.com> Message-ID: <447E5E8C-3942-47DB-820A-1664EADAADA7@oracle.com> Looks good! Thanks, /Staffan > On 4 dec. 2015, at 15:46, Marcus Larsson wrote: > > Hi, > > Please review the following patch to allow C++ reserved keywords to be used as UL tags. This allows usage of a 'class' tag, for example. > > Tags are now automatically prefixed with underscores by the macros. This means they will still be referred to without underscores when used, but avoid keyword conflicts. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8144146/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8144146 > > Testing: > JPRT testset hotspot > > Thanks, > Marcus From marcus.larsson at oracle.com Mon Dec 7 15:47:06 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 7 Dec 2015 16:47:06 +0100 Subject: RFR: 8144146: Unified Logging tags cannot be reserved keywords In-Reply-To: <447E5E8C-3942-47DB-820A-1664EADAADA7@oracle.com> References: <5661A729.1050206@oracle.com> <447E5E8C-3942-47DB-820A-1664EADAADA7@oracle.com> Message-ID: <5665A9FA.7040401@oracle.com> Thanks Staffan! Marcus On 2015-12-07 15:43, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 4 dec. 2015, at 15:46, Marcus Larsson wrote: >> >> Hi, >> >> Please review the following patch to allow C++ reserved keywords to be used as UL tags. This allows usage of a 'class' tag, for example. >> >> Tags are now automatically prefixed with underscores by the macros. This means they will still be referred to without underscores when used, but avoid keyword conflicts. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8144146/webrev.00/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8144146 >> >> Testing: >> JPRT testset hotspot >> >> Thanks, >> Marcus From Roger.Riggs at oracle.com Mon Dec 7 15:54:07 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 7 Dec 2015 10:54:07 -0500 Subject: [preview] Adding java.lang.Runtime.getVMArguments() method In-Reply-To: <56656C44.8050207@oracle.com> References: <5654952C.5080108@oracle.com> <5654F687.8040709@gmail.com> <5165C720-3F7E-4BDF-A3D5-9604507EBA36@oracle.com> <56551BEA.5040900@oracle.com> <5656F1A0.1070100@oracle.com> <5656F430.7080509@oracle.com> <56584AB7.8020002@oracle.com> <56654768.6080406@oracle.com> <56656B6C.9040806@oracle.com> <56656C44.8050207@oracle.com> Message-ID: <5665AB9F.5070504@oracle.com> Hi Jaroslav, Is this just to accommodate the test library? I found no other references in java.base. If so, then perhaps it can be placed in another package that the tests routinely need access to. Does this fit the scope of the WhiteBox? Thanks, Roger On 12/07/2015 06:23 AM, Jaroslav Bachorik wrote: ... >> >> Adding j.l.Runtime.getVmArguments() method seems like the best >> thing we >> >> can do - the VM arguments are related to the current runtime and >> doing >> >> this it allows for decoupling from java.management. >> > >> > Any further thoughts on this? Any objections against moving this >> > functionality to j.l.Runtime since implementing this in ProcessHandle >> > would lead to inconsistency between the arguments reported for >> > 'current()' and other processes? >> >> I was left unclear as to the exact intent of the API - which "arguments" >> does it provide? Commandline? launcher? VM? > The same as > http://docs.oracle.com/javase/8/docs/api/java/lang/management/RuntimeMXBean.html#getInputArguments-- > Basically, this is about moving the RuntimeMXBean.getInputArguments() > to a place which would not require dependency on java.management in > order to get the VM input arguments. > > > -JB- > From serguei.spitsyn at oracle.com Mon Dec 7 20:54:53 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 7 Dec 2015 12:54:53 -0800 Subject: [ping] Re: RFR 8144308: com/sun/jdi/SuspendThreadTest.java failed with "transport error 202: send failed: Broken pipe" In-Reply-To: <566546C4.2080105@oracle.com> References: <565DDA00.8090007@oracle.com> <566546C4.2080105@oracle.com> Message-ID: <5665F21D.4020500@oracle.com> Hi Jaroslav, Looks good. Would it more clean with the "volatile" keyword ? 45 public static boolean active = true; Thanks, Serguei On 12/7/15 00:43, Jaroslav Bachorik wrote: > On 1.12.2015 18:33, Jaroslav Bachorik wrote: >> Please, review the following simple test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8144308 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8144308/webrev.00 >> >> The test keeps the debuggee spinning in a loop and does not stop it once >> the testing is over. While the harness usually takes care of this, >> occasionally it fails while trying to do that. >> >> The fix is to add a loop invariant variable and set it to false once we >> are done with the debugee and it is ok for it to finish. >> >> Thanks, >> >> -JB- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Dec 7 23:06:11 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Dec 2015 09:06:11 +1000 Subject: RFR[ 9u-dev] JDK-8138745: Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot In-Reply-To: <565FE80F.2030603@oracle.com> References: <5655AC56.4080204@oracle.com> <56569C08.7010406@oracle.com> <5656A689.3010006@oracle.com> <565FE80F.2030603@oracle.com> Message-ID: <566610E3.1090104@oracle.com> Hi Cheleswer, Thanks. Just a few minor updates ... On 3/12/2015 4:58 PM, cheleswer sahu wrote: > Hi, > Thanks David and Staffan for your comments. Please review the code > changes in the updated webrev below > http://cr.openjdk.java.net/~kevinw/8138745/webrev.01/ src/share/vm/runtime/globals.hpp As I said previously this terminology: + "JVM aborts and produces text and binary crash files on the " \ should be consistent with what we already use. So I suggest: + "JVM aborts, producing an error log and core/mini dump, on the " \ In the tests either "throw new Error(...)" or "throw new RuntimeException(...)" but don't switch between them. test/runtime/ErrorHandling/TestExitOnOutOfMemoryError.java 45 } catch (OutOfMemoryError err) { 46 throw err; 47 } should be: 45 } catch (OutOfMemoryError err) { 46 throw new Error("OOME didn't terminate JVM!"); 47 } --- test/runtime/ErrorHandling/TestCrashOnOutOfMemoryError.java 50 } catch (OutOfMemoryError err) { 51 throw err; 52 } should be: 50 } catch (OutOfMemoryError err) { 51 throw new Error("OOME didn't abort JVM!"); 52 } Here: 55 ProcessBuilder pb = ProcessTools.createJavaProcessBuilder("-XX:+CrashOnOutOfMemoryError", 56 "-Xmx64m", TestCrashOnOutOfMemoryError.class.getName(),"throwOOME"); you also need to disable core dump generation: -XX:-CreateCoredumpOnCrash otherwise you may run into issues with core dumps taking a long time to generate and the test times out. 64 /* Actual output should look like this: "should look _something_ like this". The actual text will depend on the OS and its core dump processing. Thanks, David > Regards, > Cheleswer > > On 11/26/2015 11:58 AM, David Holmes wrote: >> Sorry forgot the tests .... >> >> test/runtime/ErrorHandling/TestExitOnOutOfMemoryError.java >> >> This test is checking that new Object[Integer.MAX_VALUE]; caused the >> "Requested array size exceeds VM limit" failure _but_ it doesn't >> actually do anything to verify that the VM terminated because of the >> ExitOnOutOfMemory flag. I suggest: >> >> a) augment the termination message in the VM as I suggested earlier so >> that you can be sure you hit the termination code >> b) check for a zero/non-zero return code as appropriate >> c) Add: throw new Error("OOME was not triggered"); after line 41. >> d) Put a try/catch(OOME) around the allocation and throw an Error if >> you get to the catch block >> >> That way we will get a test failure when Arrays 2.0 allows such >> massive arrays to be created :) >> >> Similar considerations for TestCrashOnOutOfMemoryError.java, but you >> also need to disable core dump generation. >> >> David >> ----- >> >> On 26/11/2015 3:43 PM, David Holmes wrote: >>> Hi, >>> >>> On 25/11/2015 10:40 PM, cheleswer sahu wrote: >>>> Hi, >>>> >>>> Please review the code changes for >>>> "https://bugs.openjdk.java.net/browse/JDK-8138745". >>>> Web review link: >>>> http://cr.openjdk.java.net/~kevinw/8138745/webrev.00/ >>>> >>>> >>>> >>>> Enhancement Brief: >>>> ExitOnOutOfMemoryError: When user enable this option, the JVM exits on >>>> the first occurrence of an out-of-memory error. It can be used if user >>>> prefer restarting an instance of the JVM rather than handling out of >>>> memory errors. >>>> >>>> CrashOnOutOfMemoryError: If this option is enabled, when an >>>> out-of-memory error occurs, the JVM crashes and produces text and >>>> binary >>>> crash files. >>> >>> The term "crash" is not very appropriate - crashes are bad things. Abort >>> may have been a better choice. >>> >>>> For more details please refer http://ccc.us.oracle.com/8138745 >>> >>> This is not accessible outside of Oracle. >>> >>> A few minor comments: >>> >>> src/share/vm/runtime/globals.hpp >>> >>> + "JVM crashes and produces text and binary crash files") >>> >>> Terminology should be consistent with other options that control core >>> dump. Should also say "on first occurrence of an out-of-memory error". >>> >>> src/share/vm/utilities/debug.cpp: >>> >>> 308 if (CrashOnOutOfMemoryError) { >>> 309 tty->print_cr("java.lang.OutOfMemoryError: %s", message); >>> 310 fatal("OutOfMemory encountered: %s", message); >>> 311 } >>> >>> don't really need the tty->print when using the fatal. Though you may >>> want to use the j.l.OOME form of the message for consistency. Might also >>> be useful for both Crash and Exit to include in the logged messages the >>> fact that these flags were involved - something like: >>> >>> "Terminating due to java.lang.OutOfMemoryError: %s" >>> "Aborting due to java.lang.OutOfMemoryError: %s" >>> >>> Thanks, >>> David >>> ----- >>> >>>> >>>> Regards, >>>> Cheleswer >>>> > From david.holmes at oracle.com Tue Dec 8 03:38:10 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Dec 2015 13:38:10 +1000 Subject: [ping] Re: RFR 8144308: com/sun/jdi/SuspendThreadTest.java failed with "transport error 202: send failed: Broken pipe" In-Reply-To: <5665F21D.4020500@oracle.com> References: <565DDA00.8090007@oracle.com> <566546C4.2080105@oracle.com> <5665F21D.4020500@oracle.com> Message-ID: <566650A2.7000407@oracle.com> On 8/12/2015 6:54 AM, serguei.spitsyn at oracle.com wrote: > Hi Jaroslav, > > Looks good. > Would it more clean with the "volatile" keyword ? > > 45 public static boolean active = true; If set and read in different threads then it must be volatile. Else C2 can turn it into an if-check outside an infinite loop. David > Thanks, > Serguei > > > On 12/7/15 00:43, Jaroslav Bachorik wrote: >> On 1.12.2015 18:33, Jaroslav Bachorik wrote: >>> Please, review the following simple test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8144308 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8144308/webrev.00 >>> >>> The test keeps the debuggee spinning in a loop and does not stop it once >>> the testing is over. While the harness usually takes care of this, >>> occasionally it fails while trying to do that. >>> >>> The fix is to add a loop invariant variable and set it to false once we >>> are done with the debugee and it is ok for it to finish. >>> >>> Thanks, >>> >>> -JB- >> > From david.holmes at oracle.com Tue Dec 8 03:42:01 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Dec 2015 13:42:01 +1000 Subject: [preview] Adding java.lang.Runtime.getVMArguments() method In-Reply-To: <5665AB9F.5070504@oracle.com> References: <5654952C.5080108@oracle.com> <5654F687.8040709@gmail.com> <5165C720-3F7E-4BDF-A3D5-9604507EBA36@oracle.com> <56551BEA.5040900@oracle.com> <5656F1A0.1070100@oracle.com> <5656F430.7080509@oracle.com> <56584AB7.8020002@oracle.com> <56654768.6080406@oracle.com> <56656B6C.9040806@oracle.com> <56656C44.8050207@oracle.com> <5665AB9F.5070504@oracle.com> Message-ID: <56665189.4050501@oracle.com> On 8/12/2015 1:54 AM, Roger Riggs wrote: > Hi Jaroslav, > > Is this just to accommodate the test library? I found no other > references in java.base. > > If so, then perhaps it can be placed in another package that the tests > routinely need access to. > Does this fit the scope of the WhiteBox? The original mail states: "it was pointed out that this functionality should be available in java.base without going through JMX. " But I question that statement - why should it be available without going through JMX? This kind of system introspection is a management/monitoring function and so rightly belongs in JMX in my opinion. David ----- > Thanks, Roger > > > > On 12/07/2015 06:23 AM, Jaroslav Bachorik wrote: > ... >>> >> Adding j.l.Runtime.getVmArguments() method seems like the best >>> thing we >>> >> can do - the VM arguments are related to the current runtime and >>> doing >>> >> this it allows for decoupling from java.management. >>> > >>> > Any further thoughts on this? Any objections against moving this >>> > functionality to j.l.Runtime since implementing this in ProcessHandle >>> > would lead to inconsistency between the arguments reported for >>> > 'current()' and other processes? >>> >>> I was left unclear as to the exact intent of the API - which "arguments" >>> does it provide? Commandline? launcher? VM? >> The same as >> http://docs.oracle.com/javase/8/docs/api/java/lang/management/RuntimeMXBean.html#getInputArguments-- >> >> Basically, this is about moving the RuntimeMXBean.getInputArguments() >> to a place which would not require dependency on java.management in >> order to get the VM input arguments. >> >> >> -JB- >> > From mandy.chung at oracle.com Tue Dec 8 03:52:09 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 7 Dec 2015 19:52:09 -0800 Subject: [preview] Adding java.lang.Runtime.getVMArguments() method In-Reply-To: <56665189.4050501@oracle.com> References: <5654952C.5080108@oracle.com> <5654F687.8040709@gmail.com> <5165C720-3F7E-4BDF-A3D5-9604507EBA36@oracle.com> <56551BEA.5040900@oracle.com> <5656F1A0.1070100@oracle.com> <5656F430.7080509@oracle.com> <56584AB7.8020002@oracle.com> <56654768.6080406@oracle.com> <56656B6C.9040806@oracle.com> <56656C44.8050207@oracle.com> <5665AB9F.5070504@oracle.com> <56665189.4050501@oracle.com> Message-ID: <2210BADD-BA86-4EA6-BAB3-59824033FB0A@oracle.com> > On Dec 7, 2015, at 7:42 PM, David Holmes wrote: > > On 8/12/2015 1:54 AM, Roger Riggs wrote: >> Hi Jaroslav, >> >> Is this just to accommodate the test library? I found no other >> references in java.base. >> >> If so, then perhaps it can be placed in another package that the tests >> routinely need access to. >> Does this fit the scope of the WhiteBox? > > The original mail states: "it was pointed out that this functionality should be available in java.base without going through JMX. " But I question that statement - why should it be available without going through JMX? This kind of system introspection is a management/monitoring function and so rightly belongs in JMX in my opinion. +1 The concerning dependency I?m aware is an internal feature that I think it should look into an alternative to eliminate such dependency. Mandy From jaroslav.bachorik at oracle.com Tue Dec 8 10:16:34 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 8 Dec 2015 11:16:34 +0100 Subject: [ping] Re: RFR 8144308: com/sun/jdi/SuspendThreadTest.java failed with "transport error 202: send failed: Broken pipe" In-Reply-To: <566650A2.7000407@oracle.com> References: <565DDA00.8090007@oracle.com> <566546C4.2080105@oracle.com> <5665F21D.4020500@oracle.com> <566650A2.7000407@oracle.com> Message-ID: <5666AE02.1090005@oracle.com> On 8.12.2015 04:38, David Holmes wrote: > On 8/12/2015 6:54 AM, serguei.spitsyn at oracle.com wrote: >> Hi Jaroslav, >> >> Looks good. >> Would it more clean with the "volatile" keyword ? >> >> 45 public static boolean active = true; > > If set and read in different threads then it must be volatile. Else C2 > can turn it into an if-check outside an infinite loop. The code is run under debugger only. The method also contains a breakpoint. My guess would be C2 would not do any optimization here - is my assumption correct? -JB- > > David > >> Thanks, >> Serguei >> >> >> On 12/7/15 00:43, Jaroslav Bachorik wrote: >>> On 1.12.2015 18:33, Jaroslav Bachorik wrote: >>>> Please, review the following simple test change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8144308 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8144308/webrev.00 >>>> >>>> The test keeps the debuggee spinning in a loop and does not stop it >>>> once >>>> the testing is over. While the harness usually takes care of this, >>>> occasionally it fails while trying to do that. >>>> >>>> The fix is to add a loop invariant variable and set it to false once we >>>> are done with the debugee and it is ok for it to finish. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> From jaroslav.bachorik at oracle.com Tue Dec 8 10:24:10 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 8 Dec 2015 11:24:10 +0100 Subject: [preview] Adding java.lang.Runtime.getVMArguments() method In-Reply-To: <2210BADD-BA86-4EA6-BAB3-59824033FB0A@oracle.com> References: <5654952C.5080108@oracle.com> <5654F687.8040709@gmail.com> <5165C720-3F7E-4BDF-A3D5-9604507EBA36@oracle.com> <56551BEA.5040900@oracle.com> <5656F1A0.1070100@oracle.com> <5656F430.7080509@oracle.com> <56584AB7.8020002@oracle.com> <56654768.6080406@oracle.com> <56656B6C.9040806@oracle.com> <56656C44.8050207@oracle.com> <5665AB9F.5070504@oracle.com> <56665189.4050501@oracle.com> <2210BADD-BA86-4EA6-BAB3-59824033FB0A@oracle.com> Message-ID: <5666AFCA.1080004@oracle.com> On 8.12.2015 04:52, Mandy Chung wrote: > >> On Dec 7, 2015, at 7:42 PM, David Holmes wrote: >> >> On 8/12/2015 1:54 AM, Roger Riggs wrote: >>> Hi Jaroslav, >>> >>> Is this just to accommodate the test library? I found no other >>> references in java.base. >>> >>> If so, then perhaps it can be placed in another package that the tests >>> routinely need access to. >>> Does this fit the scope of the WhiteBox? >> >> The original mail states: "it was pointed out that this functionality should be available in java.base without going through JMX. " But I question that statement - why should it be available without going through JMX? This kind of system introspection is a management/monitoring function and so rightly belongs in JMX in my opinion. > > +1 > > The concerning dependency I?m aware is an internal feature that I think it should look into an alternative to eliminate such dependency. I can introduce a new native method in the affected class that would call the refactored JVM method to get the VM input arguments. Not very nice but it would work. -JB- > > Mandy > From serguei.spitsyn at oracle.com Tue Dec 8 10:33:03 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 8 Dec 2015 02:33:03 -0800 Subject: [ping] Re: RFR 8144308: com/sun/jdi/SuspendThreadTest.java failed with "transport error 202: send failed: Broken pipe" In-Reply-To: <5666AE02.1090005@oracle.com> References: <565DDA00.8090007@oracle.com> <566546C4.2080105@oracle.com> <5665F21D.4020500@oracle.com> <566650A2.7000407@oracle.com> <5666AE02.1090005@oracle.com> Message-ID: <5666B1DF.1040409@oracle.com> On 12/8/15 02:16, Jaroslav Bachorik wrote: > On 8.12.2015 04:38, David Holmes wrote: >> On 8/12/2015 6:54 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Jaroslav, >>> >>> Looks good. >>> Would it more clean with the "volatile" keyword ? >>> >>> 45 public static boolean active = true; >> >> If set and read in different threads then it must be volatile. Else C2 >> can turn it into an if-check outside an infinite loop. > > The code is run under debugger only. The method also contains a > breakpoint. My guess would be C2 would not do any optimization here - > is my assumption correct? I agree. The code of SuspendThreadTarg.main() will be executed in the interpreter. However, adding the "volatile" keyword does not harm. Moreover, it would self-explain the role of the "active" field. Thanks, Serguei > > -JB- > >> >> David >> >>> Thanks, >>> Serguei >>> >>> >>> On 12/7/15 00:43, Jaroslav Bachorik wrote: >>>> On 1.12.2015 18:33, Jaroslav Bachorik wrote: >>>>> Please, review the following simple test change >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8144308 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8144308/webrev.00 >>>>> >>>>> The test keeps the debuggee spinning in a loop and does not stop it >>>>> once >>>>> the testing is over. While the harness usually takes care of this, >>>>> occasionally it fails while trying to do that. >>>>> >>>>> The fix is to add a loop invariant variable and set it to false >>>>> once we >>>>> are done with the debugee and it is ok for it to finish. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.gronlund at oracle.com Tue Dec 8 10:35:38 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 8 Dec 2015 02:35:38 -0800 (PST) Subject: RFR(L): 8140485: Class load and creation clean up In-Reply-To: <565E15B1.1040008@oracle.com> References: <8e840172-533d-4122-a231-5aeac6730445@default> <2540c70d-5d78-4276-a41e-4057fbfb5528@default> <564E98A8.40209@oracle.com> <1bee9d19-50f9-4602-9062-92793d6dc21f@default> <565E15B1.1040008@oracle.com> Message-ID: <5b8529e4-d6f2-4442-8c49-5da5f0f2cd49@default> Harold, Coleen and Serguei, Thanks for your help in reviewing so far. I have created an updated changeset which I intend to push if you are ok with it, please see: http://cr.openjdk.java.net/~mgronlun/8140485/unified/unified_review/webrev05/ Coleen, I went back to the CheckIntrinsic piece, and true, it was lost in the merging - thanks for pointing this out. I have refactored that piece into a static function. In addition, I reworked the is_public() member function to become is_internal() instead. I have removed the explicit usages of the class_loader oop - thanks again. Where needed this will be picked up from the ClassLoaderData. I have attempted to pack the fields better for ClassFileParser - thanks. Harold, Thanks for your help in reviewing this! About your comments: 1. In classLoader.cpp could you add comments explaining why no_verification is specified to the ClassFileStream constructor? [MG] Although these streams are currently loaded by the primordial class loader (which is the reason I construct them passing no_verification) and a comment such as "// the primordial class loader loads classes from a trusted repository" would be useful - I have now reconsidered this: I will now pass ClassFileStream::verify when constructing these streams as well - the verification setting will be recalculated (updated and set) after stream creation at least twice before reaching the verification code. For most of these streams, the recalculated verification setting done after construction will be no_verification. It might be prudent in light of security to construct the streams defaulting to verify. This is also the default parameter for the ClassFileStream - however, I am passing them to be explicit. 2. Could you replace "invariant" with a more interesting message where appropriate in some of the asserts? [MG] I agree that this would probably be helpful, but after I started an attempt in doing this, I realized that it would take quite some time to come up with some descriptive messages - maybe it would be ok to take this after integration? 3. In reflection.cpp, could you replace the switch statement in get_mirror_from_signature() with an if/else statement? [MG] Done! Runtime/ParallelClassLoading tests completed. JPRT checkin dry-run completed. Thanks for your help /Markus -----Original Message----- From: harold seigel Sent: den 1 december 2015 22:49 To: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(L): 8140485: Class load and creation clean up Hi Markus, The restructuring looks good! I just have a few minor comments. 1. In classLoader.cpp could you add comments explaining why no_verification is specified to the ClassFileStream constructor? 2. Could you replace "invariant" with a more interesting message where appropriate in some of the asserts? 3. In reflection.cpp, could you replace the switch statement in get_mirror_from_signature() with an if/else statement? Thanks! Harold On 11/20/2015 1:27 PM, Markus Gronlund wrote: > Hi Coleen, > > Many, many thanks for taking on this large change. > > Thanks for the feedback, I have updated like this: > > ClassFactory::create(...) -> KlassFactory::create_from_stream(...) > > // "Klass" better signifies internal representation (metadata) compared to "Class" which has a more classfile contextual association. Fixed. > // In addition, I have removed all overloaded create_from_stream() > functions, reducing them to a single create_from_stream(). The caller will // have to pass NULL on unused parameters with this tradeoff. > > // renaming > ClassFileParser::instance_klass(...) -> > ClassFileParser::create_instance_klass(...) > > ClassFileParser::fill_instance(...) -> > ClassFileParser::fill_instance_klass(...) > > // moved the parse_stream() and post_process_stream() into the ClassFileParser constructor (process() removed) - thanks! > > Here is an updated webrev: > > http://cr.openjdk.java.net/~mgronlun/8140485/unified/unified_review/we > brev03/ > > Many thanks again > Markus > > > -----Original Message----- > From: Coleen Phillimore > Sent: den 20 november 2015 04:51 > To: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(L): 8140485: Class load and creation clean up > > > Hi, More comments on classFileParser. > > It seems like the ClassFileParser::process is unnecessary as a > function. I think the 3 lines should be imported into > ClassFileParser::ClassFileParser and it makes sense there. > >> Summary: >> >> Reduce the visibility of CFP impl methods by internal linkage instead of external linkage. >> >> Comment: >> >> In my opinion, we should attempt to break the pattern of having private functions declared in header files when the private function does not need to reach inside "this". > Yes, I agree and appreciate moving all of these functions static and internal in CFP. > > Coleen > > > On 11/12/15 7:08 AM, Markus Gronlund wrote: >> Hi again, >> >> I have reworked and simplified this clean up/refactoring suggestion: >> >> Updated high-level description: >> http://cr.openjdk.java.net/~mgronlun/8140485/unified/unified_review/8 >> 1 >> 40485_updated.jpg >> >> Updated webrev: >> http://cr.openjdk.java.net/~mgronlun/8140485/unified/unified_review/w >> e >> brev02/ >> >> Updated patch: >> http://cr.openjdk.java.net/~mgronlun/8140485/unified/unified_review/8 >> 1 >> 40485_open_unified_updated.patch >> >> Thanks in advance >> Markus >> >> >> -----Original Message----- >> From: Markus Gronlund >> Sent: den 27 oktober 2015 13:21 >> To: hotspot-runtime-dev at openjdk.java.net; >> serviceability-dev at openjdk.net >> Subject: RFR(L): 8140485: Class load and creation clean up >> >> Greetings, >> >> >> >> I have spent some time refactoring and cleaning up parts of the class load and creation sequence and code. >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8140485 >> >> Overview: >> >> There are quite a lot of changes here - hopefully it will not be a deterrent of taking this on- first of all, a lot of changes are mechanical and applicable to "form" more than content- for example, variable, parameter and member function "constness". Same applies to other "domino changes", for example when moving an included header from a .hpp file (maybe replacing with a fwd decl instead). >> >> >> >> I have tried to stage the changes for easier overview / review (including a high level diagram). The patches/webrevs are split into a patch series of 7 patches (there is also a unified patch). >> >> >> >> Use case: >> >> My initial use case for starting all of this clean up / refactoring work is a need to reuse mechanics of the class parsing and creation sequence. >> >> >> >> Cleanup / refactoring objectives: >> >> >> >> - Allow for class parsing implementation reuse >> >> - Decouple class parsing and Klass creation >> >> - Decouple JVMTI class file load hook from ClassFileParser >> >> - Add compiler assisted read-only intent in order to assist future refactoring attempts >> >> - "componentify" ClassFileParser / apply to Klass/IK/AK creations >> >> - Take advantage of some optimizations opportunities (constructors and underlying "calloc" memory) >> >> - Maintain class load performance >> >> >> >> High level diagram explaining the updated suggested sequence (high level): >> >> http://cr.openjdk.java.net/~mgronlun/8140485/8140485_Class_load_and_c >> r eation_cleanup_high_level_sequence.jpg >> >> >> >> Split webrevs/patches for easier overview / review (do note that not all of these splits will compile individually - there is a unified patch link that includes everything, pls see below): >> >> >> >> Sequence: "first" (order of changes) >> >> Name: "8140485_1_unified entry point" >> >> Link: >> http://cr.openjdk.java.net/~mgronlun/8140485/split/first/webrev01/ >> >> Summary: >> >> Split out JVMTI agent CFLH from CFP - moved to SD::create_vm_representation_prologue(). >> >> Channel all class loading via a unified entry point - >> SD::create_vm_representation() >> >> Split out ClassPathEntry into own header. >> >> Creation of new class ClassPathFileStream (specialized ClassPathStream) to retain ClassLoaderExt::Context functionality in the refactored code. >> >> "Need verify" property is carried within the CFS itself. >> >> Comment: >> >> SystemDictionary::load_instance_class() will now have a call to >> "load_class_from_classpath" - the relevance of this name might need >> to be modified (modules etc?) >> >> >> >> Sequence: "second" >> >> Name: "8140485_2_read_only_class_file_stream" >> >> Link: >> http://cr.openjdk.java.net/~mgronlun/8140485/split/second/webrev01/ >> >> Summary: >> >> The underlying bytestream (buffer) in a CFS representation should not be altered (advertently or inadvertently) once created, made read-only. >> >> Comment: >> >> Modifications should work with copies. >> >> >> >> Sequence: "third" >> >> Name: "8140485_3_componentify_class_file_parser" >> >> Link: >> http://cr.openjdk.java.net/~mgronlun/8140485/split/third/webrev01/ >> >> Summary: >> >> In order to allow for code refactoring of CFP - stack allocated variables are modified into fields. The entire CFP acts as a generic RAII class for the allocated structures (note CHECK macros). >> >> I have not fulfilled refactoring of some of the longest methods since it's is hard to really understand the impact of the inlining I guess we are after here.. >> >> The performance work done so far indicated improvements in still passing parameters instead of reading the fields directly (so you might still see "fat" methods taking a lot of parameters even though the fields are set). >> >> >> "Consts everywhere.." >> >> One of the real hard issues trying to refactor this code is the lack of expressed read-only intent - it's hard to determine (both on reading but more importantly when compiling) what can/should change. >> >> Yes, I have entered the "const" rabbit hole related to this code (in some cases it might even be termed gratuitous (event 'consting' function parameter pointers in some cases for example)) - hopefully this will help in upcoming attempts to refactor/simplify this code. >> >> >> >> Accessors - CFP becomes a data container to be used in constructors >> (see change seven). In addition, you will now have a possibility to >> fetch data from a parser without creating a fullblown Klass >> >> >> >> Comment: >> >> I think the code could be improved and more refactoring could be >> accomplished by introducing a Metaspace allocation RAII class - this >> would allow the functions to decouple even more that is currently >> (might be next steps) >> >> >> >> Sequence: "fourth" >> >> Name: "8140485_4_hide_impl_details_class_file_parser" >> >> Link: >> http://cr.openjdk.java.net/~mgronlun/8140485/split/fourth/webrev01/ >> >> Summary: >> >> Reduce the visibility of CFP impl methods by internal linkage instead of external linkage. >> >> Comment: >> >> In my opinion, we should attempt to break the pattern of having private functions declared in header files when the private function does not need to reach inside "this". >> >> (that is, it can use an external interface alt. might not need access >> at all (helpers)) >> >> >> >> Sequence: "fifth" >> >> Name: "8140485_5_update_entry_point" >> >> Link: >> http://cr.openjdk.java.net/~mgronlun/8140485/split/fifth/webrev01/ >> >> Summary: >> >> Update signatures. Remove the parameter passing where not needed >> ("parsed_name" reference for example) >> >> >> >> Sequence: "sixth" >> >> Name: "8140485_6_types_const_includes_repercussions" >> >> Link: >> http://cr.openjdk.java.net/~mgronlun/8140485/split/sixth/webrev01/ >> >> Summary: >> >> Rippling effects of stronger constness. >> >> Forward includes where can be applied. This revealed other code modules not having includes -added. >> >> Downcasting of const qualified types (applied Scott Meyers idiom of >> dual const_cast additions (see Effective C++)) >> >> >> >> Sequence: "seventh" >> >> Name: "8140485_7_applied_use_in_constructors_and_some_optimizations" >> >> Link: >> http://cr.openjdk.java.net/~mgronlun/8140485/split/seventh/webrev01/ >> >> Summary: >> >> Take advantage of above modifications to gain direct upshots in other areas. Use CFP as the data container when constructing Klass/IK/AK. >> >> Optimizations: Reduce/optimize Klass/InstanceKlass/ArrayKlass/ConstantPool constructors by using underlying invariant on "calloc" equivalent MetaspaceObj allocations. >> >> >> >> Unified change/patch: >> >> Webrev: >> http://cr.openjdk.java.net/~mgronlun/8140485/unified/webrev01/ >> >> Patch: >> http://cr.openjdk.java.net/~mgronlun/8140485/unified/8140485_unified. >> p >> atch >> >> Summary: >> >> Unified (folded) patch for easier application/imports, for >> compilation/try out >> >> >> >> Testing: >> >> I have done targeted testing during development especially using the >> "runtime/ParallelClassLoading" test suite in order to ensure >> functional equivalency. JPRT testing. Performance tests (see below) >> >> >> >> Performance: >> >> Unstructured: >> >> I have used Java Flight Recorder (JFR), which envelops the class loading sequence with high resolution timers - I have used this information to ensure performance has been stable regarding the changes. >> >> >> >> Structured: >> >> Startup/footprint-benchmarks (Linux32, Linux64, Windows32, Windows64, >> Solaris SPARC-T) >> >> >> >> It is hard to read anything decisive around these (the effects most >> likely hides in noise), but at least determine that the changes do >> not introduce anything statistically significant (+/-) (both time and >> space) >> >> Thanks in advance >> >> Markus >> >> From cheleswer.sahu at oracle.com Tue Dec 8 11:26:50 2015 From: cheleswer.sahu at oracle.com (cheleswer sahu) Date: Tue, 8 Dec 2015 16:56:50 +0530 Subject: RFR[ 9u-dev] JDK-8138745: Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot In-Reply-To: <566610E3.1090104@oracle.com> References: <5655AC56.4080204@oracle.com> <56569C08.7010406@oracle.com> <5656A689.3010006@oracle.com> <565FE80F.2030603@oracle.com> <566610E3.1090104@oracle.com> Message-ID: <5666BE7A.4050100@oracle.com> Hi David, Please review the code changes in updated webrev http://cr.openjdk.java.net/~kevinw/8138745/webrev.02/ Regards, Cheleswer On 12/8/2015 4:36 AM, David Holmes wrote: > Hi Cheleswer, > > Thanks. Just a few minor updates ... > > On 3/12/2015 4:58 PM, cheleswer sahu wrote: >> Hi, >> Thanks David and Staffan for your comments. Please review the code >> changes in the updated webrev below >> http://cr.openjdk.java.net/~kevinw/8138745/webrev.01/ > > src/share/vm/runtime/globals.hpp > > As I said previously this terminology: > > + "JVM aborts and produces text and binary crash files on > the " \ > > should be consistent with what we already use. So I suggest: > > + "JVM aborts, producing an error log and core/mini dump, on > the " \ > > > In the tests either "throw new Error(...)" or "throw new > RuntimeException(...)" but don't switch between them. > > test/runtime/ErrorHandling/TestExitOnOutOfMemoryError.java > > 45 } catch (OutOfMemoryError err) { > 46 throw err; > 47 } > > should be: > > 45 } catch (OutOfMemoryError err) { > 46 throw new Error("OOME didn't terminate JVM!"); > 47 } > > --- > > test/runtime/ErrorHandling/TestCrashOnOutOfMemoryError.java > > 50 } catch (OutOfMemoryError err) { > 51 throw err; > 52 } > > should be: > > 50 } catch (OutOfMemoryError err) { > 51 throw new Error("OOME didn't abort JVM!"); > 52 } > > > Here: > > 55 ProcessBuilder pb = > ProcessTools.createJavaProcessBuilder("-XX:+CrashOnOutOfMemoryError", > 56 "-Xmx64m", > TestCrashOnOutOfMemoryError.class.getName(),"throwOOME"); > > you also need to disable core dump generation: > -XX:-CreateCoredumpOnCrash otherwise you may run into issues with > core dumps taking a long time to generate and the test times out. > > > 64 /* Actual output should look like this: > > "should look _something_ like this". The actual text will depend on > the OS and its core dump processing. > > Thanks, > David > > >> Regards, >> Cheleswer >> >> On 11/26/2015 11:58 AM, David Holmes wrote: >>> Sorry forgot the tests .... >>> >>> test/runtime/ErrorHandling/TestExitOnOutOfMemoryError.java >>> >>> This test is checking that new Object[Integer.MAX_VALUE]; caused the >>> "Requested array size exceeds VM limit" failure _but_ it doesn't >>> actually do anything to verify that the VM terminated because of the >>> ExitOnOutOfMemory flag. I suggest: >>> >>> a) augment the termination message in the VM as I suggested earlier so >>> that you can be sure you hit the termination code >>> b) check for a zero/non-zero return code as appropriate >>> c) Add: throw new Error("OOME was not triggered"); after line 41. >>> d) Put a try/catch(OOME) around the allocation and throw an Error if >>> you get to the catch block >>> >>> That way we will get a test failure when Arrays 2.0 allows such >>> massive arrays to be created :) >>> >>> Similar considerations for TestCrashOnOutOfMemoryError.java, but you >>> also need to disable core dump generation. >>> >>> David >>> ----- >>> >>> On 26/11/2015 3:43 PM, David Holmes wrote: >>>> Hi, >>>> >>>> On 25/11/2015 10:40 PM, cheleswer sahu wrote: >>>>> Hi, >>>>> >>>>> Please review the code changes for >>>>> "https://bugs.openjdk.java.net/browse/JDK-8138745". >>>>> Web review link: >>>>> http://cr.openjdk.java.net/~kevinw/8138745/webrev.00/ >>>>> >>>>> >>>>> >>>>> >>>>> Enhancement Brief: >>>>> ExitOnOutOfMemoryError: When user enable this option, the JVM >>>>> exits on >>>>> the first occurrence of an out-of-memory error. It can be used if >>>>> user >>>>> prefer restarting an instance of the JVM rather than handling out of >>>>> memory errors. >>>>> >>>>> CrashOnOutOfMemoryError: If this option is enabled, when an >>>>> out-of-memory error occurs, the JVM crashes and produces text and >>>>> binary >>>>> crash files. >>>> >>>> The term "crash" is not very appropriate - crashes are bad things. >>>> Abort >>>> may have been a better choice. >>>> >>>>> For more details please refer http://ccc.us.oracle.com/8138745 >>>> >>>> This is not accessible outside of Oracle. >>>> >>>> A few minor comments: >>>> >>>> src/share/vm/runtime/globals.hpp >>>> >>>> + "JVM crashes and produces text and binary crash files") >>>> >>>> Terminology should be consistent with other options that control core >>>> dump. Should also say "on first occurrence of an out-of-memory error". >>>> >>>> src/share/vm/utilities/debug.cpp: >>>> >>>> 308 if (CrashOnOutOfMemoryError) { >>>> 309 tty->print_cr("java.lang.OutOfMemoryError: %s", message); >>>> 310 fatal("OutOfMemory encountered: %s", message); >>>> 311 } >>>> >>>> don't really need the tty->print when using the fatal. Though you may >>>> want to use the j.l.OOME form of the message for consistency. Might >>>> also >>>> be useful for both Crash and Exit to include in the logged messages >>>> the >>>> fact that these flags were involved - something like: >>>> >>>> "Terminating due to java.lang.OutOfMemoryError: %s" >>>> "Aborting due to java.lang.OutOfMemoryError: %s" >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>> Regards, >>>>> Cheleswer >>>>> >> From rachel.protacio at oracle.com Tue Dec 8 15:42:24 2015 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Tue, 8 Dec 2015 10:42:24 -0500 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging Message-ID: <5666FA60.7060702@oracle.com> Hello, Please review my conversion of -XX:+TraceExceptions to -Xlog:exceptions=info. The existing (product) flag is aliased to the logging flag at the info level. If you have any questions on the alias table (in the arguments.cpp and .hpp files), Max will chime in as he is the one who implemented that portion. Open webrev: http://cr.openjdk.java.net/~rprotacio/8141211/ Bug: https://bugs.openjdk.java.net/browse/JDK-8141211 Testing: jtreg, JPRT, jck vm tests, refworkload performance tests, rbt quick & non-colo tests Thank you! Rachel From Roger.Riggs at oracle.com Tue Dec 8 16:01:21 2015 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 8 Dec 2015 11:01:21 -0500 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <5666FA60.7060702@oracle.com> References: <5666FA60.7060702@oracle.com> Message-ID: <5666FED1.9090007@oracle.com> Hi, Are the aliases listed in the -XX usage help? +TraceExceptions is so much easier to understand and use than the new flag. Thanks, Roger On 12/08/2015 10:42 AM, Rachel Protacio wrote: > Hello, > > Please review my conversion of -XX:+TraceExceptions to > -Xlog:exceptions=info. The existing (product) flag is aliased to the > logging flag at the info level. > > If you have any questions on the alias table (in the arguments.cpp and > .hpp files), Max will chime in as he is the one who implemented that > portion. > > Open webrev: http://cr.openjdk.java.net/~rprotacio/8141211/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8141211 > > Testing: jtreg, JPRT, jck vm tests, refworkload performance tests, rbt > quick & non-colo tests > > Thank you! > Rachel From coleen.phillimore at oracle.com Tue Dec 8 16:44:35 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 8 Dec 2015 11:44:35 -0500 Subject: RFR(L): 8140485: Class load and creation clean up In-Reply-To: <5b8529e4-d6f2-4442-8c49-5da5f0f2cd49@default> References: <8e840172-533d-4122-a231-5aeac6730445@default> <2540c70d-5d78-4276-a41e-4057fbfb5528@default> <564E98A8.40209@oracle.com> <1bee9d19-50f9-4602-9062-92793d6dc21f@default> <565E15B1.1040008@oracle.com> <5b8529e4-d6f2-4442-8c49-5da5f0f2cd49@default> Message-ID: <566708F3.70401@oracle.com> On 12/8/15 5:35 AM, Markus Gronlund wrote: > Harold, Coleen and Serguei, > > Thanks for your help in reviewing so far. > > I have created an updated changeset which I intend to push if you are ok with it, please see: > > http://cr.openjdk.java.net/~mgronlun/8140485/unified/unified_review/webrev05/ > > > Coleen, > > I went back to the CheckIntrinsic piece, and true, it was lost in the merging - thanks for pointing this out. > I have refactored that piece into a static function. Very nice. Not your change but I wonder how efficient is it to additionally iterate through the methods for each class file parsed to check for intrinsics. > > In addition, I reworked the is_public() member function to become is_internal() instead. > > I have removed the explicit usages of the class_loader oop - thanks again. Where needed this will be picked up from the ClassLoaderData. > > I have attempted to pack the fields better for ClassFileParser - thanks. This all looks great and a much needed cleanup to this code! Coleen > > > Harold, > > Thanks for your help in reviewing this! > > About your comments: > > 1. In classLoader.cpp could you add comments explaining why no_verification is specified to the ClassFileStream constructor? > > [MG] Although these streams are currently loaded by the primordial class loader (which is the reason I construct them passing no_verification) and a comment such as "// the primordial class loader loads classes from a trusted repository" would be useful - I have now reconsidered this: > > I will now pass ClassFileStream::verify when constructing these streams as well - the verification setting will be recalculated (updated and set) after stream creation at least twice before reaching the verification code. For most of these streams, the recalculated verification setting done after construction will be no_verification. It might be prudent in light of security to construct the streams defaulting to verify. This is also the default parameter for the ClassFileStream - however, I am passing them to be explicit. > > 2. Could you replace "invariant" with a more interesting message where appropriate in some of the asserts? > > [MG] I agree that this would probably be helpful, but after I started an attempt in doing this, I realized that it would take quite some time to come up with some descriptive messages - maybe it would be ok to take this after integration? > > 3. In reflection.cpp, could you replace the switch statement in > get_mirror_from_signature() with an if/else statement? > > [MG] Done! > > Runtime/ParallelClassLoading tests completed. > > JPRT checkin dry-run completed. > > Thanks for your help > > /Markus > > > > -----Original Message----- > From: harold seigel > Sent: den 1 december 2015 22:49 > To: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(L): 8140485: Class load and creation clean up > > Hi Markus, > > The restructuring looks good! > > I just have a few minor comments. > > 1. In classLoader.cpp could you add comments explaining why no_verification is specified to the ClassFileStream constructor? > > 2. Could you replace "invariant" with a more interesting message where appropriate in some of the asserts? > > 3. In reflection.cpp, could you replace the switch statement in > get_mirror_from_signature() with an if/else statement? > > Thanks! Harold > > On 11/20/2015 1:27 PM, Markus Gronlund wrote: >> Hi Coleen, >> >> Many, many thanks for taking on this large change. >> >> Thanks for the feedback, I have updated like this: >> >> ClassFactory::create(...) -> KlassFactory::create_from_stream(...) >> >> // "Klass" better signifies internal representation (metadata) compared to "Class" which has a more classfile contextual association. Fixed. >> // In addition, I have removed all overloaded create_from_stream() >> functions, reducing them to a single create_from_stream(). The caller will // have to pass NULL on unused parameters with this tradeoff. >> >> // renaming >> ClassFileParser::instance_klass(...) -> >> ClassFileParser::create_instance_klass(...) >> >> ClassFileParser::fill_instance(...) -> >> ClassFileParser::fill_instance_klass(...) >> >> // moved the parse_stream() and post_process_stream() into the ClassFileParser constructor (process() removed) - thanks! >> >> Here is an updated webrev: >> >> http://cr.openjdk.java.net/~mgronlun/8140485/unified/unified_review/we >> brev03/ >> >> Many thanks again >> Markus >> >> >> -----Original Message----- >> From: Coleen Phillimore >> Sent: den 20 november 2015 04:51 >> To: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR(L): 8140485: Class load and creation clean up >> >> >> Hi, More comments on classFileParser. >> >> It seems like the ClassFileParser::process is unnecessary as a >> function. I think the 3 lines should be imported into >> ClassFileParser::ClassFileParser and it makes sense there. >> >>> Summary: >>> >>> Reduce the visibility of CFP impl methods by internal linkage instead of external linkage. >>> >>> Comment: >>> >>> In my opinion, we should attempt to break the pattern of having private functions declared in header files when the private function does not need to reach inside "this". >> Yes, I agree and appreciate moving all of these functions static and internal in CFP. >> >> Coleen >> >> >> On 11/12/15 7:08 AM, Markus Gronlund wrote: >>> Hi again, >>> >>> I have reworked and simplified this clean up/refactoring suggestion: >>> >>> Updated high-level description: >>> http://cr.openjdk.java.net/~mgronlun/8140485/unified/unified_review/8 >>> 1 >>> 40485_updated.jpg >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~mgronlun/8140485/unified/unified_review/w >>> e >>> brev02/ >>> >>> Updated patch: >>> http://cr.openjdk.java.net/~mgronlun/8140485/unified/unified_review/8 >>> 1 >>> 40485_open_unified_updated.patch >>> >>> Thanks in advance >>> Markus >>> >>> >>> -----Original Message----- >>> From: Markus Gronlund >>> Sent: den 27 oktober 2015 13:21 >>> To: hotspot-runtime-dev at openjdk.java.net; >>> serviceability-dev at openjdk.net >>> Subject: RFR(L): 8140485: Class load and creation clean up >>> >>> Greetings, >>> >>> >>> >>> I have spent some time refactoring and cleaning up parts of the class load and creation sequence and code. >>> >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8140485 >>> >>> Overview: >>> >>> There are quite a lot of changes here - hopefully it will not be a deterrent of taking this on- first of all, a lot of changes are mechanical and applicable to "form" more than content- for example, variable, parameter and member function "constness". Same applies to other "domino changes", for example when moving an included header from a .hpp file (maybe replacing with a fwd decl instead). >>> >>> >>> >>> I have tried to stage the changes for easier overview / review (including a high level diagram). The patches/webrevs are split into a patch series of 7 patches (there is also a unified patch). >>> >>> >>> >>> Use case: >>> >>> My initial use case for starting all of this clean up / refactoring work is a need to reuse mechanics of the class parsing and creation sequence. >>> >>> >>> >>> Cleanup / refactoring objectives: >>> >>> >>> >>> - Allow for class parsing implementation reuse >>> >>> - Decouple class parsing and Klass creation >>> >>> - Decouple JVMTI class file load hook from ClassFileParser >>> >>> - Add compiler assisted read-only intent in order to assist future refactoring attempts >>> >>> - "componentify" ClassFileParser / apply to Klass/IK/AK creations >>> >>> - Take advantage of some optimizations opportunities (constructors and underlying "calloc" memory) >>> >>> - Maintain class load performance >>> >>> >>> >>> High level diagram explaining the updated suggested sequence (high level): >>> >>> http://cr.openjdk.java.net/~mgronlun/8140485/8140485_Class_load_and_c >>> r eation_cleanup_high_level_sequence.jpg >>> >>> >>> >>> Split webrevs/patches for easier overview / review (do note that not all of these splits will compile individually - there is a unified patch link that includes everything, pls see below): >>> >>> >>> >>> Sequence: "first" (order of changes) >>> >>> Name: "8140485_1_unified entry point" >>> >>> Link: >>> http://cr.openjdk.java.net/~mgronlun/8140485/split/first/webrev01/ >>> >>> Summary: >>> >>> Split out JVMTI agent CFLH from CFP - moved to SD::create_vm_representation_prologue(). >>> >>> Channel all class loading via a unified entry point - >>> SD::create_vm_representation() >>> >>> Split out ClassPathEntry into own header. >>> >>> Creation of new class ClassPathFileStream (specialized ClassPathStream) to retain ClassLoaderExt::Context functionality in the refactored code. >>> >>> "Need verify" property is carried within the CFS itself. >>> >>> Comment: >>> >>> SystemDictionary::load_instance_class() will now have a call to >>> "load_class_from_classpath" - the relevance of this name might need >>> to be modified (modules etc?) >>> >>> >>> >>> Sequence: "second" >>> >>> Name: "8140485_2_read_only_class_file_stream" >>> >>> Link: >>> http://cr.openjdk.java.net/~mgronlun/8140485/split/second/webrev01/ >>> >>> Summary: >>> >>> The underlying bytestream (buffer) in a CFS representation should not be altered (advertently or inadvertently) once created, made read-only. >>> >>> Comment: >>> >>> Modifications should work with copies. >>> >>> >>> >>> Sequence: "third" >>> >>> Name: "8140485_3_componentify_class_file_parser" >>> >>> Link: >>> http://cr.openjdk.java.net/~mgronlun/8140485/split/third/webrev01/ >>> >>> Summary: >>> >>> In order to allow for code refactoring of CFP - stack allocated variables are modified into fields. The entire CFP acts as a generic RAII class for the allocated structures (note CHECK macros). >>> >>> I have not fulfilled refactoring of some of the longest methods since it's is hard to really understand the impact of the inlining I guess we are after here.. >>> >>> The performance work done so far indicated improvements in still passing parameters instead of reading the fields directly (so you might still see "fat" methods taking a lot of parameters even though the fields are set). >>> >>> >>> "Consts everywhere.." >>> >>> One of the real hard issues trying to refactor this code is the lack of expressed read-only intent - it's hard to determine (both on reading but more importantly when compiling) what can/should change. >>> >>> Yes, I have entered the "const" rabbit hole related to this code (in some cases it might even be termed gratuitous (event 'consting' function parameter pointers in some cases for example)) - hopefully this will help in upcoming attempts to refactor/simplify this code. >>> >>> >>> >>> Accessors - CFP becomes a data container to be used in constructors >>> (see change seven). In addition, you will now have a possibility to >>> fetch data from a parser without creating a fullblown Klass >>> >>> >>> >>> Comment: >>> >>> I think the code could be improved and more refactoring could be >>> accomplished by introducing a Metaspace allocation RAII class - this >>> would allow the functions to decouple even more that is currently >>> (might be next steps) >>> >>> >>> >>> Sequence: "fourth" >>> >>> Name: "8140485_4_hide_impl_details_class_file_parser" >>> >>> Link: >>> http://cr.openjdk.java.net/~mgronlun/8140485/split/fourth/webrev01/ >>> >>> Summary: >>> >>> Reduce the visibility of CFP impl methods by internal linkage instead of external linkage. >>> >>> Comment: >>> >>> In my opinion, we should attempt to break the pattern of having private functions declared in header files when the private function does not need to reach inside "this". >>> >>> (that is, it can use an external interface alt. might not need access >>> at all (helpers)) >>> >>> >>> >>> Sequence: "fifth" >>> >>> Name: "8140485_5_update_entry_point" >>> >>> Link: >>> http://cr.openjdk.java.net/~mgronlun/8140485/split/fifth/webrev01/ >>> >>> Summary: >>> >>> Update signatures. Remove the parameter passing where not needed >>> ("parsed_name" reference for example) >>> >>> >>> >>> Sequence: "sixth" >>> >>> Name: "8140485_6_types_const_includes_repercussions" >>> >>> Link: >>> http://cr.openjdk.java.net/~mgronlun/8140485/split/sixth/webrev01/ >>> >>> Summary: >>> >>> Rippling effects of stronger constness. >>> >>> Forward includes where can be applied. This revealed other code modules not having includes -added. >>> >>> Downcasting of const qualified types (applied Scott Meyers idiom of >>> dual const_cast additions (see Effective C++)) >>> >>> >>> >>> Sequence: "seventh" >>> >>> Name: "8140485_7_applied_use_in_constructors_and_some_optimizations" >>> >>> Link: >>> http://cr.openjdk.java.net/~mgronlun/8140485/split/seventh/webrev01/ >>> >>> Summary: >>> >>> Take advantage of above modifications to gain direct upshots in other areas. Use CFP as the data container when constructing Klass/IK/AK. >>> >>> Optimizations: Reduce/optimize Klass/InstanceKlass/ArrayKlass/ConstantPool constructors by using underlying invariant on "calloc" equivalent MetaspaceObj allocations. >>> >>> >>> >>> Unified change/patch: >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mgronlun/8140485/unified/webrev01/ >>> >>> Patch: >>> http://cr.openjdk.java.net/~mgronlun/8140485/unified/8140485_unified. >>> p >>> atch >>> >>> Summary: >>> >>> Unified (folded) patch for easier application/imports, for >>> compilation/try out >>> >>> >>> >>> Testing: >>> >>> I have done targeted testing during development especially using the >>> "runtime/ParallelClassLoading" test suite in order to ensure >>> functional equivalency. JPRT testing. Performance tests (see below) >>> >>> >>> >>> Performance: >>> >>> Unstructured: >>> >>> I have used Java Flight Recorder (JFR), which envelops the class loading sequence with high resolution timers - I have used this information to ensure performance has been stable regarding the changes. >>> >>> >>> >>> Structured: >>> >>> Startup/footprint-benchmarks (Linux32, Linux64, Windows32, Windows64, >>> Solaris SPARC-T) >>> >>> >>> >>> It is hard to read anything decisive around these (the effects most >>> likely hides in noise), but at least determine that the changes do >>> not introduce anything statistically significant (+/-) (both time and >>> space) >>> >>> Thanks in advance >>> >>> Markus >>> >>> From chris.plummer at oracle.com Tue Dec 8 19:14:45 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 8 Dec 2015 11:14:45 -0800 Subject: [RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and nonstatic_oopmap on 32-bit systems In-Reply-To: <5666A8CA.3040004@oracle.com> References: <56620D85.8090204@oracle.com> <5666A8CA.3040004@oracle.com> Message-ID: <56672C25.7010909@oracle.com> [Adding serviceability-dev at openjdk.java.net] Hi Mikael, Thanks for pointing this out. I'll look into it some more. Are there any tests that should be failing as a result of this? I get the feeling no, since I see other issues here that existed before my change. For example, this code is not returning the proper size if the class is anonymous or is an interface. It needs to add 1 extra word in that case. See size() in instanceKlass.hpp. Another difference from the VM code is alignObjectSize() is being used by getSize(), but headerSize is set using alignObjectOffset(). The VM code uses align_object_offset in both cases. // Align the object size. public static long alignObjectSize(long size) { return VM.getVM().alignUp(size, VM.getVM().getMinObjAlignmentInBytes()); } // All vm's align longs, so pad out certain offsets. public static long alignObjectOffset(long offset) { return VM.getVM().alignUp(offset, VM.getVM().getBytesPerLong()); } So the difference here is in the use of getMinObjAlignmentInBytes (not what the VM does) vs getBytesPerLong (what the VM uses): public int getObjectAlignmentInBytes() { if (objectAlignmentInBytes == 0) { Flag flag = getCommandLineFlag("ObjectAlignmentInBytes"); objectAlignmentInBytes = (flag == null) ? 8 : (int)flag.getIntx(); } return objectAlignmentInBytes; } So this seems wrong for use in any InstanceKlass size or embedded field offset calculation. It is probably a remnant of when class metadata was stored in the java heap, and the size of InstanceKlass had to be padded out to the minimum heap object alignment. At least it is harmless if ObjectAlignmentInBytes is not set, and if set it is only supported for 64-bit: lp64_product(intx, ObjectAlignmentInBytes, 8, \ "Default object alignment in bytes, 8 is minimum") \ range(8, 256) \ constraint(ObjectAlignmentInBytesConstraintFunc,AtParse) \ I'll get these cleaned up, but it sure would be nice if there was a way to reliably test it. thanks, Chris On 12/8/15 1:54 AM, Mikael Gerdin wrote: > Hi Chris, > > Not a review but I'm fairly sure that you need to update the > serviceability agent to reflect these changes, see for example: > > public long getSize() { > return Oop.alignObjectSize( > getHeaderSize() + > Oop.alignObjectOffset(getVtableLen()) + > Oop.alignObjectOffset(getItableLen()) + > Oop.alignObjectOffset(getNonstaticOopMapSize())); > } > > in InstanceKlass.java > > /Mikael > > On 2015-12-04 23:02, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8143608 >> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/ >> >> A bit of background would help. The InstanceKlass object has a number of >> variable length fields that are laid out after the declared fields. When >> an InstanceKlass object is allocated, extra memory is allocated for it >> to leave room for these fields. The first three of these fields are >> vtable, itable, and nonstatic_oopmap. They are all arrays of HeapWord >> sized values, which means void* size, which means they only need 32-bit >> alignment on 32-bit systems. However, they have always been 64-bit >> aligned. This webrev removes the forced 64-bit alignment on 32-bit >> systems, saving footprint. >> >> This change affects all 32-bit platforms. It should have no net impact >> on 64-bit platforms since the fields remain (naturally) 64-bit aligned >> (unless of course I've introduced a bug). The intent is to not change >> what is done for 64-bit platforms. >> >> BTW, there is a change to AARCH64, which may seem odd at first. It just >> removes an "if" block where the condition should always have evaluated >> to false, so it should have no net affect. >> >> Tested with JPRT "-testset hotspot". Please let me know if you think >> there are any additional tests that should be run. >> >> thanks, >> >> Chris >> > From yasuenag at gmail.com Wed Dec 9 00:59:29 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 9 Dec 2015 09:59:29 +0900 Subject: RFR: JDK-8144965: Show oop pointer in call frame at HSDB. Message-ID: <56677CF1.2030802@gmail.com> Hi all, I use HSDB / CLHSDB when I have to analyze coredump image. For example, if JVM is crashed in static JNI method (e.g. ZIP archive operation), I want to find oop (like "this" pointer) address from upper call frame. We can find it from stack, however, it is hard. So I want to show it in each call frame as possible. I've uploaded a webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8144965/webrev.00/ I'm jdk 9 committer, however, I could not access JPRT. Thus I need a sponsor. Could you help? I want to show Inspect window when oop address is clicked in HSDB. However, it seems hard because HTMLGenerator is generating text, does not have window control. Thus I propose to show oop address. Thanks, Yasumasa From yasuenag at gmail.com Wed Dec 9 01:01:55 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 9 Dec 2015 10:01:55 +0900 Subject: [PING] RFR: JDK-8144332: HSDB could not terminate when close button is pushed. In-Reply-To: <565DB049.1010506@gmail.com> References: <565DB049.1010506@gmail.com> Message-ID: <56677D83.4040506@gmail.com> Ping: Please review it. http://cr.openjdk.java.net/~ysuenaga/JDK-8144332/webrev.00/ Thanks, Yasumasa On 2015/12/01 23:35, Yasumasa Suenaga wrote: > Hi all, > > When I ran HSDB through jhsdb, I could not terminate it through window close button. > HSDB starts WorkerThread. It will be terminated when Exit menu is selected. > However, it will not be shotdown when HSDB is terminated through close button. > > I've created a patch and uploaded webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8144332/webrev.00/ > > Could you review it? > > I'm jdk 9 committer, however, I could not access JPRT. > Thus I need a sponsor. > > Could you help? > > > Thanks, > > Yasumasa > From david.holmes at oracle.com Wed Dec 9 03:53:25 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Dec 2015 13:53:25 +1000 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <5666FA60.7060702@oracle.com> References: <5666FA60.7060702@oracle.com> Message-ID: <5667A5B5.6080701@oracle.com> Hi Rachel, On 9/12/2015 1:42 AM, Rachel Protacio wrote: > Hello, > > Please review my conversion of -XX:+TraceExceptions to > -Xlog:exceptions=info. The existing (product) flag is aliased to the > logging flag at the info level. Q: how does use of ttyLocker map into UL? I see an awful lot of multi-line logging blocks that are going to be completely messed up without locking! src/share/vm/opto/runtime.cpp 1239 ResourceMark rm; What requires the introduction of the ResourceMark? --- src/share/vm/runtime/thread.cpp 2084 if (log_is_enabled(Info, exceptions)) { 2085 ResourceMark rm; An extra leading space has crept in at +2085 2087 logstream->print("Async. exception installed at runtime exit (" INTPTR_FORMAT ")", p2i(this)); 2088 if (has_last_Java_frame()) { 2089 frame f = last_frame(); 2090 logstream->print(" (pc: " INTPTR_FORMAT " sp: " INTPTR_FORMAT " )", p2i(f.pc()), p2i(f.sp())); 2091 } Indention of these lines is wrong at #2088 and #2089 - need an additional space. 2092 logstream->print_cr(" of type: %s", InstanceKlass::cast(_pending_async_exception->klass())->external_name()); Why did the InstanceKlass::cast need to be introduced ?? --- test/runtime/CommandLine/TraceExceptionsTest.java You improved the readability of the source code by breaking the @summary over two lines, but IIRC jtreg will write the summary into the test log with all the additional spaces you added, as the summary extends until the next tag. --- test/runtime/logging/ExceptionsTest.java Can you avoid the code duplication please. Also perhaps you could/should also check there are no logging statements present when logging is supposed to be disabled. I'm guessing the other logging tests haven't considered this. ?? > If you have any questions on the alias table (in the arguments.cpp and > .hpp files), Max will chime in as he is the one who implemented that > portion. Okay some general questions. First I would expect that aliased logging options are also marked deprecated so that we can eventually make them obsolete and remove them. Secondly, arguably if someone specifies -XX:-TraceExceptions it should disable exception logging - which may have been turned on by -Xlog:all. Which leads to: how does the position of -XX:+/-TraceExceptions interact with the position of -Xlog:xxx on the command-line (or the other argument introducing mechanisms) ? src/share/vm/runtime/arguments.cpp 2743 if(lookup_logging_aliases(option->optionString, aliased_logging_option)){ Need space after "if", and before { Thanks, David ----- > Open webrev: http://cr.openjdk.java.net/~rprotacio/8141211/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8141211 > > Testing: jtreg, JPRT, jck vm tests, refworkload performance tests, rbt > quick & non-colo tests > > Thank you! > Rachel From david.holmes at oracle.com Wed Dec 9 04:22:37 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Dec 2015 14:22:37 +1000 Subject: RFR[ 9u-dev] JDK-8138745: Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot In-Reply-To: <5666BE7A.4050100@oracle.com> References: <5655AC56.4080204@oracle.com> <56569C08.7010406@oracle.com> <5656A689.3010006@oracle.com> <565FE80F.2030603@oracle.com> <566610E3.1090104@oracle.com> <5666BE7A.4050100@oracle.com> Message-ID: <5667AC8D.90309@oracle.com> On 8/12/2015 9:26 PM, cheleswer sahu wrote: > Hi David, > Please review the code changes in updated webrev > http://cr.openjdk.java.net/~kevinw/8138745/webrev.02/ Looks good! Only one more thing I forgot to mention - no new webrev needed. When you use the testlibrary you also need to ensure it gets built, so you need to add: jdk.test.lib.* to your @build lines. Thanks, David > Regards, > Cheleswer > > On 12/8/2015 4:36 AM, David Holmes wrote: >> Hi Cheleswer, >> >> Thanks. Just a few minor updates ... >> >> On 3/12/2015 4:58 PM, cheleswer sahu wrote: >>> Hi, >>> Thanks David and Staffan for your comments. Please review the code >>> changes in the updated webrev below >>> http://cr.openjdk.java.net/~kevinw/8138745/webrev.01/ >> >> src/share/vm/runtime/globals.hpp >> >> As I said previously this terminology: >> >> + "JVM aborts and produces text and binary crash files on >> the " \ >> >> should be consistent with what we already use. So I suggest: >> >> + "JVM aborts, producing an error log and core/mini dump, on >> the " \ >> >> >> In the tests either "throw new Error(...)" or "throw new >> RuntimeException(...)" but don't switch between them. >> >> test/runtime/ErrorHandling/TestExitOnOutOfMemoryError.java >> >> 45 } catch (OutOfMemoryError err) { >> 46 throw err; >> 47 } >> >> should be: >> >> 45 } catch (OutOfMemoryError err) { >> 46 throw new Error("OOME didn't terminate JVM!"); >> 47 } >> >> --- >> >> test/runtime/ErrorHandling/TestCrashOnOutOfMemoryError.java >> >> 50 } catch (OutOfMemoryError err) { >> 51 throw err; >> 52 } >> >> should be: >> >> 50 } catch (OutOfMemoryError err) { >> 51 throw new Error("OOME didn't abort JVM!"); >> 52 } >> >> >> Here: >> >> 55 ProcessBuilder pb = >> ProcessTools.createJavaProcessBuilder("-XX:+CrashOnOutOfMemoryError", >> 56 "-Xmx64m", >> TestCrashOnOutOfMemoryError.class.getName(),"throwOOME"); >> >> you also need to disable core dump generation: >> -XX:-CreateCoredumpOnCrash otherwise you may run into issues with >> core dumps taking a long time to generate and the test times out. >> >> >> 64 /* Actual output should look like this: >> >> "should look _something_ like this". The actual text will depend on >> the OS and its core dump processing. >> >> Thanks, >> David >> >> >>> Regards, >>> Cheleswer >>> >>> On 11/26/2015 11:58 AM, David Holmes wrote: >>>> Sorry forgot the tests .... >>>> >>>> test/runtime/ErrorHandling/TestExitOnOutOfMemoryError.java >>>> >>>> This test is checking that new Object[Integer.MAX_VALUE]; caused the >>>> "Requested array size exceeds VM limit" failure _but_ it doesn't >>>> actually do anything to verify that the VM terminated because of the >>>> ExitOnOutOfMemory flag. I suggest: >>>> >>>> a) augment the termination message in the VM as I suggested earlier so >>>> that you can be sure you hit the termination code >>>> b) check for a zero/non-zero return code as appropriate >>>> c) Add: throw new Error("OOME was not triggered"); after line 41. >>>> d) Put a try/catch(OOME) around the allocation and throw an Error if >>>> you get to the catch block >>>> >>>> That way we will get a test failure when Arrays 2.0 allows such >>>> massive arrays to be created :) >>>> >>>> Similar considerations for TestCrashOnOutOfMemoryError.java, but you >>>> also need to disable core dump generation. >>>> >>>> David >>>> ----- >>>> >>>> On 26/11/2015 3:43 PM, David Holmes wrote: >>>>> Hi, >>>>> >>>>> On 25/11/2015 10:40 PM, cheleswer sahu wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the code changes for >>>>>> "https://bugs.openjdk.java.net/browse/JDK-8138745". >>>>>> Web review link: >>>>>> http://cr.openjdk.java.net/~kevinw/8138745/webrev.00/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Enhancement Brief: >>>>>> ExitOnOutOfMemoryError: When user enable this option, the JVM >>>>>> exits on >>>>>> the first occurrence of an out-of-memory error. It can be used if >>>>>> user >>>>>> prefer restarting an instance of the JVM rather than handling out of >>>>>> memory errors. >>>>>> >>>>>> CrashOnOutOfMemoryError: If this option is enabled, when an >>>>>> out-of-memory error occurs, the JVM crashes and produces text and >>>>>> binary >>>>>> crash files. >>>>> >>>>> The term "crash" is not very appropriate - crashes are bad things. >>>>> Abort >>>>> may have been a better choice. >>>>> >>>>>> For more details please refer http://ccc.us.oracle.com/8138745 >>>>> >>>>> This is not accessible outside of Oracle. >>>>> >>>>> A few minor comments: >>>>> >>>>> src/share/vm/runtime/globals.hpp >>>>> >>>>> + "JVM crashes and produces text and binary crash files") >>>>> >>>>> Terminology should be consistent with other options that control core >>>>> dump. Should also say "on first occurrence of an out-of-memory error". >>>>> >>>>> src/share/vm/utilities/debug.cpp: >>>>> >>>>> 308 if (CrashOnOutOfMemoryError) { >>>>> 309 tty->print_cr("java.lang.OutOfMemoryError: %s", message); >>>>> 310 fatal("OutOfMemory encountered: %s", message); >>>>> 311 } >>>>> >>>>> don't really need the tty->print when using the fatal. Though you may >>>>> want to use the j.l.OOME form of the message for consistency. Might >>>>> also >>>>> be useful for both Crash and Exit to include in the logged messages >>>>> the >>>>> fact that these flags were involved - something like: >>>>> >>>>> "Terminating due to java.lang.OutOfMemoryError: %s" >>>>> "Aborting due to java.lang.OutOfMemoryError: %s" >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Regards, >>>>>> Cheleswer >>>>>> >>> > From jaroslav.bachorik at oracle.com Wed Dec 9 08:38:07 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 9 Dec 2015 09:38:07 +0100 Subject: [PING] RFR: JDK-8144332: HSDB could not terminate when close button is pushed. In-Reply-To: <56677D83.4040506@gmail.com> References: <565DB049.1010506@gmail.com> <56677D83.4040506@gmail.com> Message-ID: <5667E86F.7080307@oracle.com> On 9.12.2015 02:01, Yasumasa Suenaga wrote: > Ping: > > Please review it. > http://cr.openjdk.java.net/~ysuenaga/JDK-8144332/webrev.00/ Looks good! -JB- > > > Thanks, > > Yasumasa > > > On 2015/12/01 23:35, Yasumasa Suenaga wrote: >> Hi all, >> >> When I ran HSDB through jhsdb, I could not terminate it through window close button. >> HSDB starts WorkerThread. It will be terminated when Exit menu is selected. >> However, it will not be shotdown when HSDB is terminated through close button. >> >> I've created a patch and uploaded webrev: >> http://cr.openjdk.java.net/~ysuenaga/JDK-8144332/webrev.00/ >> >> Could you review it? >> >> I'm jdk 9 committer, however, I could not access JPRT. >> Thus I need a sponsor. >> >> Could you help? >> >> >> Thanks, >> >> Yasumasa >> From jaroslav.bachorik at oracle.com Wed Dec 9 08:45:10 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 9 Dec 2015 09:45:10 +0100 Subject: RFR: JDK-8144965: Show oop pointer in call frame at HSDB. In-Reply-To: <56677CF1.2030802@gmail.com> References: <56677CF1.2030802@gmail.com> Message-ID: <5667EA16.6000303@oracle.com> On 9.12.2015 01:59, Yasumasa Suenaga wrote: > Hi all, > > I use HSDB / CLHSDB when I have to analyze coredump image. > For example, if JVM is crashed in static JNI method (e.g. ZIP archive operation), > I want to find oop (like "this" pointer) address from upper call frame. > > We can find it from stack, however, it is hard. > So I want to show it in each call frame as possible. > > > I've uploaded a webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8144965/webrev.00/ > > I'm jdk 9 committer, however, I could not access JPRT. > Thus I need a sponsor. > > Could you help? > > > I want to show Inspect window when oop address is clicked in HSDB. > However, it seems hard because HTMLGenerator is generating text, does not have > window control. > > Thus I propose to show oop address. http://cr.openjdk.java.net/~ysuenaga/JDK-8144965/webrev.00/agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java.frames.html L1926 - vf.getLocals().oopHandleAt(0) may return null; the result should be checked before calling toString() on it -JB- > > > Thanks, > > Yasumasa > From yasuenag at gmail.com Wed Dec 9 12:43:27 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 9 Dec 2015 21:43:27 +0900 Subject: RFR: JDK-8144965: Show oop pointer in call frame at HSDB. In-Reply-To: <5667EA16.6000303@oracle.com> References: <56677CF1.2030802@gmail.com> <5667EA16.6000303@oracle.com> Message-ID: <566821EF.8070003@gmail.com> Hi Jaroslav, Thank you for your comment. > L1926 - vf.getLocals().oopHandleAt(0) may return null; the result should > be checked before calling toString() on it I've fixed it in new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8144965/webrev.01/ Could you review again? Thanks, Yasumasa On 2015/12/09 17:45, Jaroslav Bachorik wrote: > On 9.12.2015 01:59, Yasumasa Suenaga wrote: >> Hi all, >> >> I use HSDB / CLHSDB when I have to analyze coredump image. >> For example, if JVM is crashed in static JNI method (e.g. ZIP archive operation), >> I want to find oop (like "this" pointer) address from upper call frame. >> >> We can find it from stack, however, it is hard. >> So I want to show it in each call frame as possible. >> >> >> I've uploaded a webrev: >> http://cr.openjdk.java.net/~ysuenaga/JDK-8144965/webrev.00/ >> >> I'm jdk 9 committer, however, I could not access JPRT. >> Thus I need a sponsor. >> >> Could you help? >> >> >> I want to show Inspect window when oop address is clicked in HSDB. >> However, it seems hard because HTMLGenerator is generating text, does not have >> window control. >> >> Thus I propose to show oop address. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8144965/webrev.00/agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java.frames.html > L1926 - vf.getLocals().oopHandleAt(0) may return null; the result should > be checked before calling toString() on it > > -JB- > >> >> >> Thanks, >> >> Yasumasa >> > From sgehwolf at redhat.com Wed Dec 9 13:55:02 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 09 Dec 2015 14:55:02 +0100 Subject: [PING-2] RFR 6425769: jmx remote bind address In-Reply-To: <1448975945.4309.16.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> <565D8592.6020701@oracle.com> <1448975945.4309.16.camel@redhat.com> Message-ID: <1449669302.3543.62.camel@redhat.com> On Tue, 2015-12-01 at 14:19 +0100, Severin Gehwolf wrote: > Hi Jaroslav, > > On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: > > On 1.12.2015 11:17, Severin Gehwolf wrote: > > > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > > > > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > > > > > Hi, > > > > > > > > > > Updated webrev with jtreg test in Java: > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ > > > > > bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > > > > > > I believe this updated webrev addresses all concerns and > > > > > incorporates > > > > > suggestions brought up by Jaroslav and Daniel. > > > > > > > > > > I'm still looking for a sponsor and a hotspot/servicability- > > > > > dev > > > > > reviewer. Could somebody maintaining javax.rmi.ssl have a > > > > > look at > > > > > this > > > > > as well? Thank you! > > > > > > > > Ping? Friendly reminder that I still need reviewers and a > > > > sponsor for > > > > this. > > > > > > Anyone? > > > > I'm sorry for not spotting this earlier: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi- > > ssl-factory- > > changes/jdk/src/java.management/share/classes/sun/management/jmxrem > > ote/ConnectorBootstrap.java.sdiff.html > > * L442 - the log would contain 'com.sun.management.jmxremote.host > > =? > > null' if host is not specified; might be better not to print this > > out at all > > Updated webrev which does not print > 'com.sun.management.jmxremote.host = null' if unset: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/05/ > > > Other than that the change looks good to me. If no one else is > > volunteering I may sponsor this change. > > Thank you! Jaroslav, are you still willing to sponsor this? There hasn't been much movement :-/ Thanks, Severin From jaroslav.bachorik at oracle.com Wed Dec 9 13:58:02 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 9 Dec 2015 14:58:02 +0100 Subject: [PING-2] RFR 6425769: jmx remote bind address In-Reply-To: <1449669302.3543.62.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> <565D8592.6020701@oracle.com> <1448975945.4309.16.camel@redhat.com> <1449669302.3543.62.camel@redhat.com> Message-ID: <5668336A.3010406@oracle.com> On 9.12.2015 14:55, Severin Gehwolf wrote: > On Tue, 2015-12-01 at 14:19 +0100, Severin Gehwolf wrote: >> Hi Jaroslav, >> >> On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: >>> On 1.12.2015 11:17, Severin Gehwolf wrote: >>>> On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: >>>>> On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: >>>>>> Hi, >>>>>> >>>>>> Updated webrev with jtreg test in Java: >>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6425769 >>>>>> >>>>>> I believe this updated webrev addresses all concerns and >>>>>> incorporates >>>>>> suggestions brought up by Jaroslav and Daniel. >>>>>> >>>>>> I'm still looking for a sponsor and a hotspot/servicability- >>>>>> dev >>>>>> reviewer. Could somebody maintaining javax.rmi.ssl have a >>>>>> look at >>>>>> this >>>>>> as well? Thank you! >>>>> >>>>> Ping? Friendly reminder that I still need reviewers and a >>>>> sponsor for >>>>> this. >>>> >>>> Anyone? >>> >>> I'm sorry for not spotting this earlier: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi- >>> ssl-factory- >>> changes/jdk/src/java.management/share/classes/sun/management/jmxrem >>> ote/ConnectorBootstrap.java.sdiff.html >>> * L442 - the log would contain 'com.sun.management.jmxremote.host >>> = >>> null' if host is not specified; might be better not to print this >>> out at all >> >> Updated webrev which does not print >> 'com.sun.management.jmxremote.host = null' if unset: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/05/ >> >>> Other than that the change looks good to me. If no one else is >>> volunteering I may sponsor this change. >> >> Thank you! > > Jaroslav, are you still willing to sponsor this? There hasn't been much > movement :-/ Sure. I need to start the compatibility review process before integration and it might take some time. -JB- > > Thanks, > Severin > From jaroslav.bachorik at oracle.com Wed Dec 9 13:58:57 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 9 Dec 2015 14:58:57 +0100 Subject: RFR: JDK-8144965: Show oop pointer in call frame at HSDB. In-Reply-To: <566821EF.8070003@gmail.com> References: <56677CF1.2030802@gmail.com> <5667EA16.6000303@oracle.com> <566821EF.8070003@gmail.com> Message-ID: <566833A1.5070604@oracle.com> On 9.12.2015 13:43, Yasumasa Suenaga wrote: > Hi Jaroslav, > > Thank you for your comment. > >> L1926 - vf.getLocals().oopHandleAt(0) may return null; the result should >> be checked before calling toString() on it > > I've fixed it in new webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8144965/webrev.01/ Ok. Looks good! -JB- > > > Could you review again? > > > Thanks, > > Yasumasa > > > On 2015/12/09 17:45, Jaroslav Bachorik wrote: >> On 9.12.2015 01:59, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I use HSDB / CLHSDB when I have to analyze coredump image. >>> For example, if JVM is crashed in static JNI method (e.g. ZIP archive operation), >>> I want to find oop (like "this" pointer) address from upper call frame. >>> >>> We can find it from stack, however, it is hard. >>> So I want to show it in each call frame as possible. >>> >>> >>> I've uploaded a webrev: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8144965/webrev.00/ >>> >>> I'm jdk 9 committer, however, I could not access JPRT. >>> Thus I need a sponsor. >>> >>> Could you help? >>> >>> >>> I want to show Inspect window when oop address is clicked in HSDB. >>> However, it seems hard because HTMLGenerator is generating text, does not have >>> window control. >>> >>> Thus I propose to show oop address. >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8144965/webrev.00/agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java.frames.html >> L1926 - vf.getLocals().oopHandleAt(0) may return null; the result should >> be checked before calling toString() on it >> >> -JB- >> >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >> From sgehwolf at redhat.com Wed Dec 9 14:13:01 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 09 Dec 2015 15:13:01 +0100 Subject: [PING-2] RFR 6425769: jmx remote bind address In-Reply-To: <5668336A.3010406@oracle.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> <565D8592.6020701@oracle.com> <1448975945.4309.16.camel@redhat.com> <1449669302.3543.62.camel@redhat.com> <5668336A.3010406@oracle.com> Message-ID: <1449670381.3543.63.camel@redhat.com> On Wed, 2015-12-09 at 14:58 +0100, Jaroslav Bachorik wrote: > On 9.12.2015 14:55, Severin Gehwolf wrote: > > On Tue, 2015-12-01 at 14:19 +0100, Severin Gehwolf wrote: > > > Hi Jaroslav, > > > > > > On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: > > > > On 1.12.2015 11:17, Severin Gehwolf wrote: > > > > > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > > > > > > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Updated webrev with jtreg test in Java: > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/ > > > > > > > 02/ > > > > > > > bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > > > > > > > > > > I believe this updated webrev addresses all concerns and > > > > > > > incorporates > > > > > > > suggestions brought up by Jaroslav and Daniel. > > > > > > > > > > > > > > I'm still looking for a sponsor and a > > > > > > > hotspot/servicability- > > > > > > > dev > > > > > > > reviewer. Could somebody maintaining javax.rmi.ssl have a > > > > > > > look at > > > > > > > this > > > > > > > as well? Thank you! > > > > > > > > > > > > Ping? Friendly reminder that I still need reviewers and a > > > > > > sponsor for > > > > > > this. > > > > > > > > > > Anyone? > > > > > > > > I'm sorry for not spotting this earlier: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no- > > > > rmi- > > > > ssl-factory- > > > > changes/jdk/src/java.management/share/classes/sun/management/jm > > > > xrem > > > > ote/ConnectorBootstrap.java.sdiff.html > > > > * L442 - the log would contain > > > > 'com.sun.management.jmxremote.host > > > > = > > > > null' if host is not specified; might be better not to print > > > > this > > > > out at all > > > > > > Updated webrev which does not print > > > 'com.sun.management.jmxremote.host = null' if unset: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/05/ > > > > > > > Other than that the change looks good to me. If no one else is > > > > volunteering I may sponsor this change. > > > > > > Thank you! > > > > Jaroslav, are you still willing to sponsor this? There hasn't been > > much > > movement :-/ > > Sure. I need to start the compatibility review process before > integration and it might take some time. OK. Thanks for the heads-up! Cheers, Severin > -JB- > > > > > Thanks, > > Severin > > > From mikael.gerdin at oracle.com Wed Dec 9 16:48:56 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 9 Dec 2015 17:48:56 +0100 Subject: [RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and nonstatic_oopmap on 32-bit systems In-Reply-To: <56672C25.7010909@oracle.com> References: <56620D85.8090204@oracle.com> <5666A8CA.3040004@oracle.com> <56672C25.7010909@oracle.com> Message-ID: <56685B78.5030106@oracle.com> On 2015-12-08 20:14, Chris Plummer wrote: > [Adding serviceability-dev at openjdk.java.net] > > Hi Mikael, > > Thanks for pointing this out. I'll look into it some more. Are there any > tests that should be failing as a result of this? I get the feeling no, > since I see other issues here that existed before my change. For > example, this code is not returning the proper size if the class is > anonymous or is an interface. It needs to add 1 extra word in that case. > See size() in instanceKlass.hpp. > > Another difference from the VM code is alignObjectSize() is being used > by getSize(), but headerSize is set using alignObjectOffset(). The VM > code uses align_object_offset in both cases. > > // Align the object size. > public static long alignObjectSize(long size) { > return VM.getVM().alignUp(size, > VM.getVM().getMinObjAlignmentInBytes()); > } > > // All vm's align longs, so pad out certain offsets. > public static long alignObjectOffset(long offset) { > return VM.getVM().alignUp(offset, VM.getVM().getBytesPerLong()); > } > > So the difference here is in the use of getMinObjAlignmentInBytes (not > what the VM does) vs getBytesPerLong (what the VM uses): > > public int getObjectAlignmentInBytes() { > if (objectAlignmentInBytes == 0) { > Flag flag = getCommandLineFlag("ObjectAlignmentInBytes"); > objectAlignmentInBytes = (flag == null) ? 8 : (int)flag.getIntx(); > } > return objectAlignmentInBytes; > } > > So this seems wrong for use in any InstanceKlass size or embedded field > offset calculation. It is probably a remnant of when class metadata was > stored in the java heap, and the size of InstanceKlass had to be padded > out to the minimum heap object alignment. At least it is harmless if > ObjectAlignmentInBytes is not set, and if set it is only supported for > 64-bit: > > lp64_product(intx, ObjectAlignmentInBytes, > 8, \ > "Default object alignment in bytes, 8 is > minimum") \ > range(8, > 256) \ > constraint(ObjectAlignmentInBytesConstraintFunc,AtParse) \ > > I'll get these cleaned up, but it sure would be nice if there was a way > to reliably test it. I'd say that it's quite possible to test it! Create a whitebox.cpp entry point for determining the size of a class. Run a java program calling the entry point and printing the InstanceKlass size as computed by calling InstanceKlass::size() on a set of pre-determined set of complex and simple classes (vtables, itables, anonymous, etc.) Have the java program wait after it's finished printing. Launch the SA agent and attach it to the process. Through several layers of magic, execute the incantation: mgerdin at mgerdin03:~/work/repos/hg/jdk9/hs-rt-work/hotspot$ ../build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java sun.jvm.hotspot.CLHSDB 6211 Attaching to process 6211, please wait... hsdb> jseval "sapkg.utilities.SystemDictionaryHelper.findInstanceKlass('java/lang/Object').getSize();" 472 You could also create a javascript source file in the test directory which performs the appropriate calls and do hsdb> jsload /path/to/file.js hsdb> jseval "doit()" where file.js: doit = function() { sd = sapkg.utilities.SystemDictionaryHelper; do_klass = function(name) { writeln(sd.findInstanceKlass(name).getSize()); } do_klass('java/lang/Object'); do_klass('java/lang/Class'); } The only problem is that the test can't reliably execute on unconfigured os x setups because of OS level security requirements for attaching to processes. After detaching HSDB with the "quit" command you tell the debugged java process to terminate, for example by printing some string on its stdin. Easy, right? :) /Mikael > > thanks, > > Chris > > On 12/8/15 1:54 AM, Mikael Gerdin wrote: >> Hi Chris, >> >> Not a review but I'm fairly sure that you need to update the >> serviceability agent to reflect these changes, see for example: >> >> public long getSize() { >> return Oop.alignObjectSize( >> getHeaderSize() + >> Oop.alignObjectOffset(getVtableLen()) + >> Oop.alignObjectOffset(getItableLen()) + >> Oop.alignObjectOffset(getNonstaticOopMapSize())); >> } >> >> in InstanceKlass.java >> >> /Mikael >> >> On 2015-12-04 23:02, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8143608 >>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/ >>> >>> A bit of background would help. The InstanceKlass object has a number of >>> variable length fields that are laid out after the declared fields. When >>> an InstanceKlass object is allocated, extra memory is allocated for it >>> to leave room for these fields. The first three of these fields are >>> vtable, itable, and nonstatic_oopmap. They are all arrays of HeapWord >>> sized values, which means void* size, which means they only need 32-bit >>> alignment on 32-bit systems. However, they have always been 64-bit >>> aligned. This webrev removes the forced 64-bit alignment on 32-bit >>> systems, saving footprint. >>> >>> This change affects all 32-bit platforms. It should have no net impact >>> on 64-bit platforms since the fields remain (naturally) 64-bit aligned >>> (unless of course I've introduced a bug). The intent is to not change >>> what is done for 64-bit platforms. >>> >>> BTW, there is a change to AARCH64, which may seem odd at first. It just >>> removes an "if" block where the condition should always have evaluated >>> to false, so it should have no net affect. >>> >>> Tested with JPRT "-testset hotspot". Please let me know if you think >>> there are any additional tests that should be run. >>> >>> thanks, >>> >>> Chris >>> >> > From rachel.protacio at oracle.com Wed Dec 9 18:05:17 2015 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 9 Dec 2015 13:05:17 -0500 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <5667A5B5.6080701@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> Message-ID: <56686D5D.4030400@oracle.com> Hi, Thanks for the review. Replies inline. Updated webrev: http://cr.openjdk.java.net/~rprotacio/8141211.01/ On 12/8/2015 10:53 PM, David Holmes wrote: > Hi Rachel, > > On 9/12/2015 1:42 AM, Rachel Protacio wrote: >> Hello, >> >> Please review my conversion of -XX:+TraceExceptions to >> -Xlog:exceptions=info. The existing (product) flag is aliased to the >> logging flag at the info level. > > Q: how does use of ttyLocker map into UL? I see an awful lot of > multi-line logging blocks that are going to be completely messed up > without locking! My impression was that the logging works as-is, but I will check in with Marcus. > > src/share/vm/opto/runtime.cpp > > 1239 ResourceMark rm; > > What requires the introduction of the ResourceMark? That's because I'm passing in a LogHandle output stream. Each of those require a ResourceMark. > > --- > > src/share/vm/runtime/thread.cpp > > 2084 if (log_is_enabled(Info, exceptions)) { > 2085 ResourceMark rm; > > An extra leading space has crept in at +2085 > > 2087 logstream->print("Async. exception installed at runtime > exit (" INTPTR_FORMAT ")", p2i(this)); > 2088 if (has_last_Java_frame()) { > 2089 frame f = last_frame(); > 2090 logstream->print(" (pc: " INTPTR_FORMAT " sp: " > INTPTR_FORMAT " )", p2i(f.pc()), p2i(f.sp())); > 2091 } > > Indention of these lines is wrong at #2088 and #2089 - need an > additional space. Thanks for catching those! > > 2092 logstream->print_cr(" of type: %s", > InstanceKlass::cast(_pending_async_exception->klass())->external_name()); > > Why did the InstanceKlass::cast need to be introduced ?? Thanks for noticing. I believe someone else's changeset modified that line so the merging didn't update it. I've removed the cast. > > --- > > test/runtime/CommandLine/TraceExceptionsTest.java > > You improved the readability of the source code by breaking the > @summary over two lines, but IIRC jtreg will write the summary into > the test log with all the additional spaces you added, as the summary > extends until the next tag. Ok, I didn't realize that - I've put it back as it was. > > --- > > test/runtime/logging/ExceptionsTest.java > > Can you avoid the code duplication please. > > Also perhaps you could/should also check there are no logging > statements present when logging is supposed to be disabled. I'm > guessing the other logging tests haven't considered this. ?? Good points. I've added a check. > >> If you have any questions on the alias table (in the arguments.cpp and >> .hpp files), Max will chime in as he is the one who implemented that >> portion. > > Okay some general questions. > > First I would expect that aliased logging options are also marked > deprecated so that we can eventually make them obsolete and remove them. Not sure about this one. Max? Coleen? > > Secondly, arguably if someone specifies -XX:-TraceExceptions it should > disable exception logging - which may have been turned on by -Xlog:all. > > Which leads to: how does the position of -XX:+/-TraceExceptions > interact with the position of -Xlog:xxx on the command-line (or the > other argument introducing mechanisms) ? Very true, I had forgotten about the option to turn it off. Have added an entry in the alias table to that effect. > > src/share/vm/runtime/arguments.cpp > > 2743 if(lookup_logging_aliases(option->optionString, > aliased_logging_option)){ > > Need space after "if", and before { Done. Thanks, Rachel > > Thanks, > David > ----- > > >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8141211/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8141211 >> >> Testing: jtreg, JPRT, jck vm tests, refworkload performance tests, rbt >> quick & non-colo tests >> >> Thank you! >> Rachel From rachel.protacio at oracle.com Wed Dec 9 18:12:50 2015 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 9 Dec 2015 13:12:50 -0500 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <5667A5B5.6080701@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> Message-ID: <56686F22.4080104@oracle.com> Hi, (Sorry if this sent twice. Thunderbird is acting up.) Thanks for the review. Replies inline. Updated webrev: http://cr.openjdk.java.net/~rprotacio/8141211.01/ On 12/8/2015 10:53 PM, David Holmes wrote: > Hi Rachel, > > On 9/12/2015 1:42 AM, Rachel Protacio wrote: >> Hello, >> >> Please review my conversion of -XX:+TraceExceptions to >> -Xlog:exceptions=info. The existing (product) flag is aliased to the >> logging flag at the info level. > > Q: how does use of ttyLocker map into UL? I see an awful lot of > multi-line logging blocks that are going to be completely messed up > without locking! I assumed that UL worked as-is for these instances, but I will check in with Marcus. > > src/share/vm/opto/runtime.cpp > > 1239 ResourceMark rm; > > What requires the introduction of the ResourceMark? A ResourceMark is necessary before using LogHandle output streams. > > --- > > src/share/vm/runtime/thread.cpp > > 2084 if (log_is_enabled(Info, exceptions)) { > 2085 ResourceMark rm; > > An extra leading space has crept in at +2085 > > 2087 logstream->print("Async. exception installed at runtime > exit (" INTPTR_FORMAT ")", p2i(this)); > 2088 if (has_last_Java_frame()) { > 2089 frame f = last_frame(); > 2090 logstream->print(" (pc: " INTPTR_FORMAT " sp: " > INTPTR_FORMAT " )", p2i(f.pc()), p2i(f.sp())); > 2091 } > > Indention of these lines is wrong at #2088 and #2089 - need an > additional space. Thanks for catching these! > > 2092 logstream->print_cr(" of type: %s", > InstanceKlass::cast(_pending_async_exception->klass())->external_name()); > > Why did the InstanceKlass::cast need to be introduced ?? That was a vestige from code before a new changeset at the same line, i.e. my merging the repo didn't catch this. I've gotten rid of the cast. > > --- > > test/runtime/CommandLine/TraceExceptionsTest.java > > You improved the readability of the source code by breaking the > @summary over two lines, but IIRC jtreg will write the summary into > the test log with all the additional spaces you added, as the summary > extends until the next tag. Ok, I didn't realize that! I've undone that change. > > --- > > test/runtime/logging/ExceptionsTest.java > > Can you avoid the code duplication please. > > Also perhaps you could/should also check there are no logging > statements present when logging is supposed to be disabled. I'm > guessing the other logging tests haven't considered this. ?? Good points. I've added a check. > >> If you have any questions on the alias table (in the arguments.cpp and >> .hpp files), Max will chime in as he is the one who implemented that >> portion. > > Okay some general questions. > > First I would expect that aliased logging options are also marked > deprecated so that we can eventually make them obsolete and remove them. I'm not sure about this one. Coleen? Max? > > Secondly, arguably if someone specifies -XX:-TraceExceptions it should > disable exception logging - which may have been turned on by -Xlog:all. > > Which leads to: how does the position of -XX:+/-TraceExceptions > interact with the position of -Xlog:xxx on the command-line (or the > other argument introducing mechanisms) ? Very true. I've added an entry in the alias table to that effect. > > src/share/vm/runtime/arguments.cpp > > 2743 if(lookup_logging_aliases(option->optionString, > aliased_logging_option)){ > > Need space after "if", and before { Done. Thanks, Rachel > > Thanks, > David > ----- > > >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8141211/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8141211 >> >> Testing: jtreg, JPRT, jck vm tests, refworkload performance tests, rbt >> quick & non-colo tests >> >> Thank you! >> Rachel From jaroslav.bachorik at oracle.com Thu Dec 10 11:07:08 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 10 Dec 2015 12:07:08 +0100 Subject: [ding] Re: jmx-dev RFR 8142398: ManagementAgent.status diagnostic command only outputs the specifically set properties In-Reply-To: <5643644B.2080102@oracle.com> References: <5643644B.2080102@oracle.com> Message-ID: <56695CDC.90302@oracle.com> On 11.11.2015 16:52, Jaroslav Bachorik wrote: > Please, review the following change Pretty please - it's been sitting here unnoticed for almost 30 days despite regular pings. Shouldn't be that hard ... -JB- > > Issue : https://bugs.openjdk.java.net/browse/JDK-8142398 > Webrev: http://cr.openjdk.java.net/~jbachorik/8142398/webrev.00 > > This patch adds the list of the default agent properties with the info > whether the default value has been overridden to the > ManagementAgent.status DCMD output. > > Thanks, > > -JB- From staffan.larsen at oracle.com Thu Dec 10 11:24:22 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 10 Dec 2015 12:24:22 +0100 Subject: [ding] jmx-dev RFR 8142398: ManagementAgent.status diagnostic command only outputs the specifically set properties In-Reply-To: <56695CDC.90302@oracle.com> References: <5643644B.2080102@oracle.com> <56695CDC.90302@oracle.com> Message-ID: <5191A7FD-0F8C-48F1-AE03-E910DF41C397@oracle.com> Looks good! Thanks, /Staffan > On 10 dec. 2015, at 12:07, Jaroslav Bachorik wrote: > > On 11.11.2015 16:52, Jaroslav Bachorik wrote: >> Please, review the following change > > Pretty please - it's been sitting here unnoticed for almost 30 days despite regular pings. Shouldn't be that hard ... > > -JB- > >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8142398 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8142398/webrev.00 >> >> This patch adds the list of the default agent properties with the info >> whether the default value has been overridden to the >> ManagementAgent.status DCMD output. >> >> Thanks, >> >> -JB- > From staffan.larsen at oracle.com Thu Dec 10 13:19:10 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 10 Dec 2015 14:19:10 +0100 Subject: RFR: JDK-8145099 Better error message when SA can't attach to a process Message-ID: Please review this patch to add a better error message to SA when it fails to attach to a process on linux. Currently the error says "Can't attach to the process?. After this change the message will look something like: "Can't attach to the process: ptrace(PTRACE_ATTACH, ..) failed for 28417: Operation not permitted? webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/ bug: https://bugs.openjdk.java.net/browse/JDK-8145099 Thanks, /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: From kubota.yuji at gmail.com Thu Dec 10 13:40:47 2015 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Thu, 10 Dec 2015 22:40:47 +0900 Subject: Potential infinite waiting at JMXConnection#createConnection In-Reply-To: References: <5547A67C.70304@oracle.com> <5549E41C.1020202@oracle.com> <5549F191.2000601@oracle.com> Message-ID: Hi Shanliang and all, Sorry my reply is too late. But, finally, I reproduced this issue by following test program! :) Could you please review test program and my patch ? The test program includes some files, but I do not have an account of openjdk, so I push it on icedtea server as below. http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/file/e31044f0804f The test program starts a simple sleep server program (JMXSSLServer) on external jdb process with a breakpoint at sun.security.ssl.ServerHandshaker.clientHello set. It then starts a client process (JMXSSLCient) which tries to connect the sleep/jdb process. ServerHandshaker.clientHello responds to the client hello message and sends SSL record back. By setting breakpont in that function, we can emulate this issue in which client keeps waiting SSL record from server. Now, JMXConnectorFactory.connect() ignores sun.rmi.transport.tcp.responseTimeout, so wait the response (SSL record) from server INFINITELY. Once my patch (jdk9.patch) was added, then the client will return 0 when the connection timeout happen by sun.rmi.transport.tcp.responseTimeout. And test program returns the client's return code. You can reproduce infinite waiting by the below. * hg clone http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/ * cd fixLoopAtJMXConnectorFactory/testProgram * set JAVA_HOME * mvn package * setting debugcontrol.properties if you need. * *NOTE* This test program will stop for "debugcontroltest.stop_time" ms. * ${JAVA_HOME}/bin/java -cp .:target/debugcontrol-1.0-SNAPSHOT.jar debugcontrol.DebugController * The result by JDK without my patch. The client throws java.net.ConnectException after sending quit to jdb. ------ [INFO] Server process args args[0] /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.fc23.x86_64/bin/jdb : : cli-out: [INFO] Service URL: service:jmx:rmi:///jndi/rmi://localhost:9876/jmxrmi ser-err: Set deferred breakpoint sun.security.ssl.ServerHandshaker.clientHello ser-out: ser-err: Breakpoint hit: "thread=RMI TCP Connection(2)-127.0.0.1", sun.security.ssl.ServerHandshaker.clientHello(), line=339 bci=0 ser-out: [INFO] sending quit to jdb ser-err: RMI TCP Connection(2)-127.0.0.1[1] cli-err: java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is: cli-err: java.net.ConnectException: Connection refused cli-err: at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619) cli-err: at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216) cli-err: at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202) cli-err: at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:130) cli-err: at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown Source) cli-err: at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2432) cli-err: at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:308) cli-err: at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270) cli-err: at debugcontrol.client.JMXSSLClient.execute(JMXSSLClient.java:51) cli-err: at debugcontrol.client.JMXSSLClient.main(JMXSSLClient.java:34) cli-err: Caused by: java.net.ConnectException: Connection refused cli-err: at java.net.PlainSocketImpl.socketConnect(Native Method) cli-err: at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) cli-err: at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) cli-err: at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) cli-err: at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) cli-err: at java.net.Socket.connect(Socket.java:589) cli-err: at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668) cli-err: at sun.security.ssl.SSLSocketImpl.(SSLSocketImpl.java:427) cli-err: at sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:88) cli-err: at javax.rmi.ssl.SslRMIClientSocketFactory.createSocket(SslRMIClientSocketFactory.java:121) cli-err: at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613) cli-err: ... 9 more [INFO] Thu Dec 10 16:16:50 JST 2015 Client done. Result code: 2 [INFO] Client took 114462 msec. * By JDK 9 with my patch. The client got java.net.SocketTimeoutException after the connection timeout happen, then return 0. ------ [INFO] Server process args args[0] /workspace/jdk9-netdev-patch/build/linux-x86_64-normal-server-release/jdk/bin/jdb args[1] -classpath args[2] target/classes args[3] -J-Duser.language=en args[4] -Dcom.sun.management.jmxremote.port=9876 args[5] -Dcom.sun.management.jmxremote.password.file=jmxremote.password args[6] -Djavax.net.ssl.keyStore=jmx-test-cert.pkcs12 args[7] -Djavax.net.ssl.keyStoreType=pkcs12 args[8] -Djavax.net.ssl.keyStorePassword=changeit args[9] debugcontrol.server.JMXSSLServer ser-out: Initializing jdb ... ser-err: > Deferring breakpoint sun.security.ssl.ServerHandshaker.clientHello. ser-out: It will be set after the class is loaded. ser-err: > run debugcontrol.server.JMXSSLServer ser-err: Set uncaught java.lang.Throwable ser-out: Set deferred uncaught java.lang.Throwable ser-err: > ser-out: VM Started: [INFO] Server launched then sleep... [INFO] Client process args: args[0] /workspace/jdk9-netdev-patch/build/linux-x86_64-normal-server-release/jdk/bin/java args[1] -classpath args[2] target/classes args[3] -Duser.language=en args[4] -Djavax.net.ssl.trustStore=jmx-test-cert.pkcs12 args[5] -Djavax.net.ssl.trustStoreType=pkcs12 args[6] -Djavax.net.ssl.trustStorePassword=changeit args[7] -Dsun.rmi.transport.tcp.responseTimeout=1000 args[8] -Dsun.rmi.transport.tcp.handshakeTimeout=1000 args[9] debugcontrol.client.JMXSSLClient args[10] localhost args[11] 9876 cli-out: [INFO] Service URL: service:jmx:rmi:///jndi/rmi://localhost:9876/jmxrmi ser-err: Set deferred breakpoint sun.security.ssl.ServerHandshaker.clientHello ser-out: ser-err: Breakpoint hit: "thread=RMI TCP Connection(2)-127.0.0.1", sun.security.ssl.ServerHandshaker.clientHello(), line=356 bci=0 ser-out: cli-out: [INFO] Conglaturation. We got a timeout. [INFO] Thu Dec 10 15:54:39 JST 2015 Client done. Result code: 0 * My patch (no change from the reported) * http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/file/e31044f0804f/jdk9.patch ------ diff --git a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java --- a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java +++ b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java @@ -224,6 +224,22 @@ out.writeByte(TransportConstants.SingleOpProtocol); } else { out.writeByte(TransportConstants.StreamProtocol); + + int usableSoTimeout = 0; + try { + /* + * If socket factory had set a non-zero timeout on its + * own, then restore it instead of using the property- + * configured value. + */ + usableSoTimeout = sock.getSoTimeout(); + if (usableSoTimeout == 0) { + usableSoTimeout = responseTimeout; + } + sock.setSoTimeout(usableSoTimeout); + } catch (Exception e) { + // if we fail to set this, ignore and proceed anyway + } out.flush(); /* @@ -231,9 +247,7 @@ * connection handshake; this also serves to guard against * non-JRMP servers that do not respond (see 4322806). */ - int originalSoTimeout = 0; try { - originalSoTimeout = sock.getSoTimeout(); sock.setSoTimeout(handshakeTimeout); } catch (Exception e) { // if we fail to set this, ignore and proceed anyway @@ -281,14 +295,7 @@ * that a remote method call is permitted to execute. */ try { - /* - * If socket factory had set a non-zero timeout on its - * own, then restore it instead of using the property- - * configured value. - */ - sock.setSoTimeout((originalSoTimeout != 0 ? - originalSoTimeout : - responseTimeout)); + sock.setSoTimeout(usableSoTimeout); } catch (Exception e) { // if we fail to set this, ignore and proceed anyway } Thanks, Yuji From thomas.stuefe at gmail.com Thu Dec 10 13:49:23 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 10 Dec 2015 14:49:23 +0100 Subject: RFR: JDK-8145099 Better error message when SA can't attach to a process In-Reply-To: References: Message-ID: Hi Stefan, Disclaimer: not a "R"eviewer. http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/agent/src/os/linux/LinuxDebuggerLocal.c.udiff.html I am not sure why you pass sizeof(err_buf) - 1 instead of sizeof(err_buf) to Pgrab and sizeof(msg) - 1 instead of sizeof(msg) to snprintf? snprintf will always zero terminate in case of truncation, at least on posix platforms. Otherwise this looks good. Kind Regards, Thomas On Thu, Dec 10, 2015 at 2:19 PM, Staffan Larsen wrote: > Please review this patch to add a better error message to SA when it fails > to attach to a process on linux. Currently the error says "Can't attach to > the process?. After this change the message will look something like: > "Can't attach to the process: ptrace(PTRACE_ATTACH, ..) failed for 28417: > Operation not permitted? > > webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/ > bug: https://bugs.openjdk.java.net/browse/JDK-8145099 > > Thanks, > /Staffan > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu Dec 10 14:22:24 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 10 Dec 2015 15:22:24 +0100 Subject: RFR: JDK-8145099 Better error message when SA can't attach to a process In-Reply-To: References: Message-ID: Hi Thommas, > On 10 dec. 2015, at 14:49, Thomas St?fe wrote: > > Hi Stefan, > > Disclaimer: not a "R"eviewer. > > http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/agent/src/os/linux/LinuxDebuggerLocal.c.udiff.html > > I am not sure why you pass sizeof(err_buf) - 1 instead of sizeof(err_buf) to Pgrab and sizeof(msg) - 1 instead of sizeof(msg) to snprintf? snprintf will always zero terminate in case of truncation, at least on posix platforms. Good point. I was just being overly cautious without thinking. Updated webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.02/ Thanks, /Staffan > > Otherwise this looks good. > > Kind Regards, Thomas > > > On Thu, Dec 10, 2015 at 2:19 PM, Staffan Larsen > wrote: > Please review this patch to add a better error message to SA when it fails to attach to a process on linux. Currently the error says "Can't attach to the process?. After this change the message will look something like: "Can't attach to the process: ptrace(PTRACE_ATTACH, ..) failed for 28417: Operation not permitted? > > webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/ > bug: https://bugs.openjdk.java.net/browse/JDK-8145099 > > Thanks, > /Staffan > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Thu Dec 10 14:26:22 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 10 Dec 2015 15:26:22 +0100 Subject: RFR: JDK-8145099 Better error message when SA can't attach to a process In-Reply-To: References: Message-ID: <56698B8E.2010403@oracle.com> On 10.12.2015 15:22, Staffan Larsen wrote: > Hi Thommas, > >> On 10 dec. 2015, at 14:49, Thomas St?fe > > wrote: >> >> Hi Stefan, >> >> Disclaimer: not a "R"eviewer. >> >> http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/agent/src/os/linux/LinuxDebuggerLocal.c.udiff.html >> >> I am not sure why you pass sizeof(err_buf) - 1 instead of >> sizeof(err_buf) to Pgrab and sizeof(msg) - 1 instead of sizeof(msg) to >> snprintf? snprintf will always zero terminate in case of truncation, >> at least on posix platforms. > > Good point. I was just being overly cautious without thinking. > > Updated webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.02/ Looks good! a nit - copyright years need update. -JB- > > Thanks, > /Staffan > >> >> Otherwise this looks good. >> >> Kind Regards, Thomas >> >> >> On Thu, Dec 10, 2015 at 2:19 PM, Staffan Larsen >> > wrote: >> >> Please review this patch to add a better error message to SA when >> it fails to attach to a process on linux. Currently the error says >> "Can't attach to the process?. After this change the message will >> look something like: "Can't attach to the process: >> ptrace(PTRACE_ATTACH, ..) failed for 28417: Operation not permitted? >> >> webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8145099 >> >> Thanks, >> /Staffan >> >> >> >> > From thomas.stuefe at gmail.com Thu Dec 10 14:27:09 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 10 Dec 2015 15:27:09 +0100 Subject: RFR: JDK-8145099 Better error message when SA can't attach to a process In-Reply-To: References: Message-ID: Hi Staffan, thanks! It also just occurred to me that strerror is not considered threadsafe. Maybe strerror_r() would a better option (depending on the version you use you would have to check the return value for NULL, though). sorry for this piecemeal review. Kind Regards, Thomas On Thu, Dec 10, 2015 at 3:22 PM, Staffan Larsen wrote: > Hi Thommas, > > On 10 dec. 2015, at 14:49, Thomas St?fe wrote: > > Hi Stefan, > > Disclaimer: not a "R"eviewer. > > > http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/agent/src/os/linux/LinuxDebuggerLocal.c.udiff.html > > I am not sure why you pass sizeof(err_buf) - 1 instead of sizeof(err_buf) > to Pgrab and sizeof(msg) - 1 instead of sizeof(msg) to snprintf? snprintf > will always zero terminate in case of truncation, at least on posix > platforms. > > > Good point. I was just being overly cautious without thinking. > > Updated webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.02/ > > Thanks, > /Staffan > > > Otherwise this looks good. > > Kind Regards, Thomas > > > On Thu, Dec 10, 2015 at 2:19 PM, Staffan Larsen > wrote: > >> Please review this patch to add a better error message to SA when it >> fails to attach to a process on linux. Currently the error says "Can't >> attach to the process?. After this change the message will look something >> like: "Can't attach to the process: ptrace(PTRACE_ATTACH, ..) failed for >> 28417: Operation not permitted? >> >> webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8145099 >> >> Thanks, >> /Staffan >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu Dec 10 14:42:50 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 10 Dec 2015 15:42:50 +0100 Subject: RFR: JDK-8145099 Better error message when SA can't attach to a process In-Reply-To: References: Message-ID: Hi Thomas, > On 10 dec. 2015, at 15:27, Thomas St?fe wrote: > > Hi Staffan, > > thanks! > > It also just occurred to me that strerror is not considered threadsafe. Maybe strerror_r() would a better option (depending on the version you use you would have to check the return value for NULL, though). Updated here: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.03/ Thanks, /Staffan > > sorry for this piecemeal review. > > Kind Regards, Thomas > > > > On Thu, Dec 10, 2015 at 3:22 PM, Staffan Larsen > wrote: > Hi Thommas, > >> On 10 dec. 2015, at 14:49, Thomas St?fe > wrote: >> >> Hi Stefan, >> >> Disclaimer: not a "R"eviewer. >> >> http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/agent/src/os/linux/LinuxDebuggerLocal.c.udiff.html >> >> I am not sure why you pass sizeof(err_buf) - 1 instead of sizeof(err_buf) to Pgrab and sizeof(msg) - 1 instead of sizeof(msg) to snprintf? snprintf will always zero terminate in case of truncation, at least on posix platforms. > > Good point. I was just being overly cautious without thinking. > > Updated webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.02/ > > Thanks, > /Staffan > >> >> Otherwise this looks good. >> >> Kind Regards, Thomas >> >> >> On Thu, Dec 10, 2015 at 2:19 PM, Staffan Larsen > wrote: >> Please review this patch to add a better error message to SA when it fails to attach to a process on linux. Currently the error says "Can't attach to the process?. After this change the message will look something like: "Can't attach to the process: ptrace(PTRACE_ATTACH, ..) failed for 28417: Operation not permitted? >> >> webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8145099 >> >> Thanks, >> /Staffan >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Thu Dec 10 14:44:35 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 10 Dec 2015 09:44:35 -0500 Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created in Java application(hotspot) In-Reply-To: <56690FED.8060401@gmx.de> References: <5608201C.4020109@gmx.de> <560B5939.6010100@gmx.de> <118235E4-AD96-4666-8A63-58FB403324BC@oracle.com> <5615798B.2080708@gmx.de> <56690FED.8060401@gmx.de> Message-ID: <56698FD3.9090707@oracle.com> Adding serviceability-dev. They work on this code. Coleen On 12/10/15 12:38 AM, Sebastian Sickelmann wrote: > @Adding hotspot-runtime-dev > > Hi, > > a want to restart a discussion/review-process for on old "bug" JDK-5108778. > I created a webrev which is based on the jdk9/dev repo: > > http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ > > To enable a subrepo review/push-process I created a subtask for the > hotspot part of the change which is JDK-8145061. > > The earlier mentioned jtreg-test(see below) was dropped due to some > initial misunderstandings. > > @Christian: As you initially responded to my first post I want you to > ask if you want to review / sponsor this fix? > > > -- > Sebastian > > > > On 10/07/2015 09:59 PM, Sebastian Sickelmann wrote: >> Please find the webrev hosted on openjdk-infrastructure at: >> >> http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ >> >> For some general discussion on regression-tests for this please find the >> thread in discuss[0][1] and for the general suggestion to make more >> wrapper-type-constructors deprecated find [2] at core-libs-dev. >> >> [0] >> http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html >> [1] http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html >> [2] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html >> >> -- Sebastian >> >> On 09/30/2015 07:50 AM, Christian Thalinger wrote: >>> Sounds good. If you have the final patch, let us know. >>> >>>> On Sep 29, 2015, at 5:38 PM, Sebastian Sickelmann wrote: >>>> >>>> Yes it is the only (non-test) source i could find in hotspot, but i want >>>> to change it in all openjdk sources i can find it. >>>> I thought i really must discuss it part by part in the mailing-lists. >>>> Actually i am working on the issue to save against regression on this. >>>> Thanks Alexandr for this input. So there will be something that >>>> integrates into jtreg for this too. >>>> >>>> -- Sebastian >>>> >>>> >>>> On 09/30/2015 01:11 AM, Christian Thalinger wrote: >>>>> Thanks for volunteering to look into such old bugs! >>>>> >>>>> Is this the only occurrence of that pattern in the hotspot repository? If you want to fix this in hotspot only without the jdk changes described in the RFE (I just changed the type from Bug to Enhancement) then we have to file a new RFE because we can?t close the original one. >>>>> >>>>>> On Sep 27, 2015, at 6:58 AM, Sebastian Sickelmann wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> my name is Sebastian Sickelmann and i signed the OCA. >>>>>> >>>>>> Actually I am searching through the JBS for low hanging fruits. >>>>>> Right now i am looking through the openjdk-sources and try to evaluate >>>>>> if i can make something about JDK-5108778. >>>>>> >>>>>> As I am not an author, I am actually not able to host webrevs on >>>>>> cr.openjdk.java.net. >>>>>> >>>>>> Is there someone who would support at hosting the hotspot-part of >>>>>> JDK-5108778 on cr.openjdk.java.net for reviewing? >>>>>> >>>>>> I placed the hotspot part in my dropbox at: >>>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev/index.html >>>>>> or as zip: >>>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev.zip >>>>>> >>>>>> I executed all jtreg tests in hotspot/test and get no more errors than before the change. >>>>>> >>>>>> -- Sebastian >>>>>> From staffan.larsen at oracle.com Thu Dec 10 14:56:19 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 10 Dec 2015 15:56:19 +0100 Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created in Java application(hotspot) In-Reply-To: <56698FD3.9090707@oracle.com> References: <5608201C.4020109@gmx.de> <560B5939.6010100@gmx.de> <118235E4-AD96-4666-8A63-58FB403324BC@oracle.com> <5615798B.2080708@gmx.de> <56690FED.8060401@gmx.de> <56698FD3.9090707@oracle.com> Message-ID: <104B9ADF-89BB-4B88-A9F7-AD8CC53EDA7A@oracle.com> Looks good! Thanks, /Staffan > On 10 dec. 2015, at 15:44, Coleen Phillimore wrote: > > > Adding serviceability-dev. They work on this code. > Coleen > > > On 12/10/15 12:38 AM, Sebastian Sickelmann wrote: >> @Adding hotspot-runtime-dev >> >> Hi, >> >> a want to restart a discussion/review-process for on old "bug" JDK-5108778. >> I created a webrev which is based on the jdk9/dev repo: >> >> http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ >> >> To enable a subrepo review/push-process I created a subtask for the >> hotspot part of the change which is JDK-8145061. >> >> The earlier mentioned jtreg-test(see below) was dropped due to some >> initial misunderstandings. >> >> @Christian: As you initially responded to my first post I want you to >> ask if you want to review / sponsor this fix? >> >> >> -- >> Sebastian >> >> >> >> On 10/07/2015 09:59 PM, Sebastian Sickelmann wrote: >>> Please find the webrev hosted on openjdk-infrastructure at: >>> >>> http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ >>> >>> For some general discussion on regression-tests for this please find the >>> thread in discuss[0][1] and for the general suggestion to make more >>> wrapper-type-constructors deprecated find [2] at core-libs-dev. >>> >>> [0] >>> http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html >>> [1] http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html >>> [2] >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html >>> >>> -- Sebastian >>> >>> On 09/30/2015 07:50 AM, Christian Thalinger wrote: >>>> Sounds good. If you have the final patch, let us know. >>>> >>>>> On Sep 29, 2015, at 5:38 PM, Sebastian Sickelmann wrote: >>>>> >>>>> Yes it is the only (non-test) source i could find in hotspot, but i want >>>>> to change it in all openjdk sources i can find it. >>>>> I thought i really must discuss it part by part in the mailing-lists. >>>>> Actually i am working on the issue to save against regression on this. >>>>> Thanks Alexandr for this input. So there will be something that >>>>> integrates into jtreg for this too. >>>>> >>>>> -- Sebastian >>>>> >>>>> >>>>> On 09/30/2015 01:11 AM, Christian Thalinger wrote: >>>>>> Thanks for volunteering to look into such old bugs! >>>>>> >>>>>> Is this the only occurrence of that pattern in the hotspot repository? If you want to fix this in hotspot only without the jdk changes described in the RFE (I just changed the type from Bug to Enhancement) then we have to file a new RFE because we can?t close the original one. >>>>>> >>>>>>> On Sep 27, 2015, at 6:58 AM, Sebastian Sickelmann wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> my name is Sebastian Sickelmann and i signed the OCA. >>>>>>> >>>>>>> Actually I am searching through the JBS for low hanging fruits. >>>>>>> Right now i am looking through the openjdk-sources and try to evaluate >>>>>>> if i can make something about JDK-5108778. >>>>>>> >>>>>>> As I am not an author, I am actually not able to host webrevs on >>>>>>> cr.openjdk.java.net. >>>>>>> >>>>>>> Is there someone who would support at hosting the hotspot-part of >>>>>>> JDK-5108778 on cr.openjdk.java.net for reviewing? >>>>>>> >>>>>>> I placed the hotspot part in my dropbox at: >>>>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev/index.html >>>>>>> or as zip: >>>>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev.zip >>>>>>> >>>>>>> I executed all jtreg tests in hotspot/test and get no more errors than before the change. >>>>>>> >>>>>>> -- Sebastian >>>>>>> > From thomas.stuefe at gmail.com Thu Dec 10 14:56:25 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 10 Dec 2015 15:56:25 +0100 Subject: RFR: JDK-8145099 Better error message when SA can't attach to a process In-Reply-To: References: Message-ID: Hi Staffan, this looks fine now, thanks! ..Thomas On Thu, Dec 10, 2015 at 3:42 PM, Staffan Larsen wrote: > Hi Thomas, > > On 10 dec. 2015, at 15:27, Thomas St?fe wrote: > > Hi Staffan, > > thanks! > > It also just occurred to me that strerror is not considered threadsafe. > Maybe strerror_r() would a better option (depending on the version you use > you would have to check the return value for NULL, though). > > > Updated here: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.03/ > > Thanks, > /Staffan > > > sorry for this piecemeal review. > > Kind Regards, Thomas > > > > On Thu, Dec 10, 2015 at 3:22 PM, Staffan Larsen > wrote: > >> Hi Thommas, >> >> On 10 dec. 2015, at 14:49, Thomas St?fe wrote: >> >> Hi Stefan, >> >> Disclaimer: not a "R"eviewer. >> >> >> http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/agent/src/os/linux/LinuxDebuggerLocal.c.udiff.html >> >> I am not sure why you pass sizeof(err_buf) - 1 instead of sizeof(err_buf) >> to Pgrab and sizeof(msg) - 1 instead of sizeof(msg) to snprintf? snprintf >> will always zero terminate in case of truncation, at least on posix >> platforms. >> >> >> Good point. I was just being overly cautious without thinking. >> >> Updated webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.02/ >> >> Thanks, >> /Staffan >> >> >> Otherwise this looks good. >> >> Kind Regards, Thomas >> >> >> On Thu, Dec 10, 2015 at 2:19 PM, Staffan Larsen < >> staffan.larsen at oracle.com> wrote: >> >>> Please review this patch to add a better error message to SA when it >>> fails to attach to a process on linux. Currently the error says "Can't >>> attach to the process?. After this change the message will look something >>> like: "Can't attach to the process: ptrace(PTRACE_ATTACH, ..) failed for >>> 28417: Operation not permitted? >>> >>> webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8145099 >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu Dec 10 15:10:35 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 10 Dec 2015 16:10:35 +0100 Subject: RFR: JDK-8145099 Better error message when SA can't attach to a process In-Reply-To: References: Message-ID: Thanks! > On 10 dec. 2015, at 15:56, Thomas St?fe wrote: > > Hi Staffan, > > this looks fine now, thanks! > > ..Thomas > > On Thu, Dec 10, 2015 at 3:42 PM, Staffan Larsen > wrote: > Hi Thomas, > >> On 10 dec. 2015, at 15:27, Thomas St?fe > wrote: >> >> Hi Staffan, >> >> thanks! >> >> It also just occurred to me that strerror is not considered threadsafe. Maybe strerror_r() would a better option (depending on the version you use you would have to check the return value for NULL, though). > > Updated here: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.03/ > > Thanks, > /Staffan > >> >> sorry for this piecemeal review. >> >> Kind Regards, Thomas >> >> >> >> On Thu, Dec 10, 2015 at 3:22 PM, Staffan Larsen > wrote: >> Hi Thommas, >> >>> On 10 dec. 2015, at 14:49, Thomas St?fe > wrote: >>> >>> Hi Stefan, >>> >>> Disclaimer: not a "R"eviewer. >>> >>> http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/agent/src/os/linux/LinuxDebuggerLocal.c.udiff.html >>> >>> I am not sure why you pass sizeof(err_buf) - 1 instead of sizeof(err_buf) to Pgrab and sizeof(msg) - 1 instead of sizeof(msg) to snprintf? snprintf will always zero terminate in case of truncation, at least on posix platforms. >> >> Good point. I was just being overly cautious without thinking. >> >> Updated webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.02/ >> >> Thanks, >> /Staffan >> >>> >>> Otherwise this looks good. >>> >>> Kind Regards, Thomas >>> >>> >>> On Thu, Dec 10, 2015 at 2:19 PM, Staffan Larsen > wrote: >>> Please review this patch to add a better error message to SA when it fails to attach to a process on linux. Currently the error says "Can't attach to the process?. After this change the message will look something like: "Can't attach to the process: ptrace(PTRACE_ATTACH, ..) failed for 28417: Operation not permitted? >>> >>> webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8145099 >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu Dec 10 15:10:45 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 10 Dec 2015 16:10:45 +0100 Subject: RFR: JDK-8145099 Better error message when SA can't attach to a process In-Reply-To: <56698B8E.2010403@oracle.com> References: <56698B8E.2010403@oracle.com> Message-ID: <08495E87-9C9D-4AD2-ACCD-007E45BB2045@oracle.com> Thanks! > On 10 dec. 2015, at 15:26, Jaroslav Bachorik wrote: > > On 10.12.2015 15:22, Staffan Larsen wrote: >> Hi Thommas, >> >>> On 10 dec. 2015, at 14:49, Thomas St?fe >> > wrote: >>> >>> Hi Stefan, >>> >>> Disclaimer: not a "R"eviewer. >>> >>> http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/agent/src/os/linux/LinuxDebuggerLocal.c.udiff.html >>> >>> I am not sure why you pass sizeof(err_buf) - 1 instead of >>> sizeof(err_buf) to Pgrab and sizeof(msg) - 1 instead of sizeof(msg) to >>> snprintf? snprintf will always zero terminate in case of truncation, >>> at least on posix platforms. >> >> Good point. I was just being overly cautious without thinking. >> >> Updated webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.02/ > > Looks good! a nit - copyright years need update. > > -JB- > >> >> Thanks, >> /Staffan >> >>> >>> Otherwise this looks good. >>> >>> Kind Regards, Thomas >>> >>> >>> On Thu, Dec 10, 2015 at 2:19 PM, Staffan Larsen >>> > wrote: >>> >>> Please review this patch to add a better error message to SA when >>> it fails to attach to a process on linux. Currently the error says >>> "Can't attach to the process?. After this change the message will >>> look something like: "Can't attach to the process: >>> ptrace(PTRACE_ATTACH, ..) failed for 28417: Operation not permitted? >>> >>> webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8145099 >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>> >> > From sebastian.sickelmann at gmx.de Thu Dec 10 16:58:36 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Thu, 10 Dec 2015 17:58:36 +0100 Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created in Java application(hotspot) In-Reply-To: <104B9ADF-89BB-4B88-A9F7-AD8CC53EDA7A@oracle.com> References: <5608201C.4020109@gmx.de> <560B5939.6010100@gmx.de> <118235E4-AD96-4666-8A63-58FB403324BC@oracle.com> <5615798B.2080708@gmx.de> <56690FED.8060401@gmx.de> <56698FD3.9090707@oracle.com> <104B9ADF-89BB-4B88-A9F7-AD8CC53EDA7A@oracle.com> Message-ID: <5669AF3C.1000205@gmx.de> Thanks for the reviews so far. I am not sure how the serviceability thing need to be handled. Should there be a review-result of a serviceability-member? I think nether david or staffan are members of the serviceability-group. If it is not the case here would be the changeset so far. As I am not a committer I would need some support to push this. http://cr.openjdk.java.net/~sebastian/8145061/webrev.00/ Don't be confused i have used the sub-task issue-number for the hotspot sub-patch for this webrev and commit-message, to not sideeffect-close the main-issue in the JBS. -- Sebastian On 12/10/2015 03:56 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 10 dec. 2015, at 15:44, Coleen Phillimore wrote: >> >> >> Adding serviceability-dev. They work on this code. >> Coleen >> >> >> On 12/10/15 12:38 AM, Sebastian Sickelmann wrote: >>> @Adding hotspot-runtime-dev >>> >>> Hi, >>> >>> a want to restart a discussion/review-process for on old "bug" JDK-5108778. >>> I created a webrev which is based on the jdk9/dev repo: >>> >>> http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ >>> >>> To enable a subrepo review/push-process I created a subtask for the >>> hotspot part of the change which is JDK-8145061. >>> >>> The earlier mentioned jtreg-test(see below) was dropped due to some >>> initial misunderstandings. >>> >>> @Christian: As you initially responded to my first post I want you to >>> ask if you want to review / sponsor this fix? >>> >>> >>> -- >>> Sebastian >>> >>> >>> >>> On 10/07/2015 09:59 PM, Sebastian Sickelmann wrote: >>>> Please find the webrev hosted on openjdk-infrastructure at: >>>> >>>> http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ >>>> >>>> For some general discussion on regression-tests for this please find the >>>> thread in discuss[0][1] and for the general suggestion to make more >>>> wrapper-type-constructors deprecated find [2] at core-libs-dev. >>>> >>>> [0] >>>> http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html >>>> [1] http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html >>>> >>>> -- Sebastian >>>> >>>> On 09/30/2015 07:50 AM, Christian Thalinger wrote: >>>>> Sounds good. If you have the final patch, let us know. >>>>> >>>>>> On Sep 29, 2015, at 5:38 PM, Sebastian Sickelmann wrote: >>>>>> >>>>>> Yes it is the only (non-test) source i could find in hotspot, but i want >>>>>> to change it in all openjdk sources i can find it. >>>>>> I thought i really must discuss it part by part in the mailing-lists. >>>>>> Actually i am working on the issue to save against regression on this. >>>>>> Thanks Alexandr for this input. So there will be something that >>>>>> integrates into jtreg for this too. >>>>>> >>>>>> -- Sebastian >>>>>> >>>>>> >>>>>> On 09/30/2015 01:11 AM, Christian Thalinger wrote: >>>>>>> Thanks for volunteering to look into such old bugs! >>>>>>> >>>>>>> Is this the only occurrence of that pattern in the hotspot repository? If you want to fix this in hotspot only without the jdk changes described in the RFE (I just changed the type from Bug to Enhancement) then we have to file a new RFE because we can?t close the original one. >>>>>>> >>>>>>>> On Sep 27, 2015, at 6:58 AM, Sebastian Sickelmann wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> my name is Sebastian Sickelmann and i signed the OCA. >>>>>>>> >>>>>>>> Actually I am searching through the JBS for low hanging fruits. >>>>>>>> Right now i am looking through the openjdk-sources and try to evaluate >>>>>>>> if i can make something about JDK-5108778. >>>>>>>> >>>>>>>> As I am not an author, I am actually not able to host webrevs on >>>>>>>> cr.openjdk.java.net. >>>>>>>> >>>>>>>> Is there someone who would support at hosting the hotspot-part of >>>>>>>> JDK-5108778 on cr.openjdk.java.net for reviewing? >>>>>>>> >>>>>>>> I placed the hotspot part in my dropbox at: >>>>>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev/index.html >>>>>>>> or as zip: >>>>>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev.zip >>>>>>>> >>>>>>>> I executed all jtreg tests in hotspot/test and get no more errors than before the change. >>>>>>>> >>>>>>>> -- Sebastian >>>>>>>> > From staffan.larsen at oracle.com Thu Dec 10 19:51:06 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 10 Dec 2015 20:51:06 +0100 Subject: RFR: JDK-5108778 Too many instances of java.lang.Boolean created in Java application(hotspot) In-Reply-To: <5669AF3C.1000205@gmx.de> References: <5608201C.4020109@gmx.de> <560B5939.6010100@gmx.de> <118235E4-AD96-4666-8A63-58FB403324BC@oracle.com> <5615798B.2080708@gmx.de> <56690FED.8060401@gmx.de> <56698FD3.9090707@oracle.com> <104B9ADF-89BB-4B88-A9F7-AD8CC53EDA7A@oracle.com> <5669AF3C.1000205@gmx.de> Message-ID: <5ED98454-9384-4613-846B-484A9644D57C@oracle.com> > On 10 dec. 2015, at 17:58, Sebastian Sickelmann wrote: > > Thanks for the reviews so far. > > I am not sure how the serviceability thing need to be handled. Should > there be a review-result of a serviceability-member? > I think nether david or staffan are members of the serviceability-group. You need reviews from at least one Reviewer and from someone who works in the serviceability area (it can be the same person). You now have two reviews from two Reviewers one of whom (me) works in the serviceability area, so you are good to go. > If it is not the case here would be the changeset so far. As I am not a > committer I would need some support to push this. > > http://cr.openjdk.java.net/~sebastian/8145061/webrev.00/ If you send me (privately) the ?hg export? output of your patch, with the correct commit message (http://openjdk.java.net/guide/producingChangeset.html#create ), I can push it for you. Thanks, /Staffan > > Don't be confused i have used the sub-task issue-number for the hotspot sub-patch for this webrev and commit-message, to not sideeffect-close the main-issue in the JBS. > > -- > Sebastian > > > On 12/10/2015 03:56 PM, Staffan Larsen wrote: >> Looks good! >> >> Thanks, >> /Staffan >> >>> On 10 dec. 2015, at 15:44, Coleen Phillimore wrote: >>> >>> >>> Adding serviceability-dev. They work on this code. >>> Coleen >>> >>> >>> On 12/10/15 12:38 AM, Sebastian Sickelmann wrote: >>>> @Adding hotspot-runtime-dev >>>> >>>> Hi, >>>> >>>> a want to restart a discussion/review-process for on old "bug" JDK-5108778. >>>> I created a webrev which is based on the jdk9/dev repo: >>>> >>>> http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ >>>> >>>> To enable a subrepo review/push-process I created a subtask for the >>>> hotspot part of the change which is JDK-8145061. >>>> >>>> The earlier mentioned jtreg-test(see below) was dropped due to some >>>> initial misunderstandings. >>>> >>>> @Christian: As you initially responded to my first post I want you to >>>> ask if you want to review / sponsor this fix? >>>> >>>> >>>> -- >>>> Sebastian >>>> >>>> >>>> >>>> On 10/07/2015 09:59 PM, Sebastian Sickelmann wrote: >>>>> Please find the webrev hosted on openjdk-infrastructure at: >>>>> >>>>> http://cr.openjdk.java.net/~sebastian/5108778/hotspot/webrev.00/ >>>>> >>>>> For some general discussion on regression-tests for this please find the >>>>> thread in discuss[0][1] and for the general suggestion to make more >>>>> wrapper-type-constructors deprecated find [2] at core-libs-dev. >>>>> >>>>> [0] >>>>> http://mail.openjdk.java.net/pipermail/discuss/2015-September/003804.html >>>>> [1] http://mail.openjdk.java.net/pipermail/discuss/2015-October/003805.html >>>>> [2] >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/035642.html >>>>> >>>>> -- Sebastian >>>>> >>>>> On 09/30/2015 07:50 AM, Christian Thalinger wrote: >>>>>> Sounds good. If you have the final patch, let us know. >>>>>> >>>>>>> On Sep 29, 2015, at 5:38 PM, Sebastian Sickelmann wrote: >>>>>>> >>>>>>> Yes it is the only (non-test) source i could find in hotspot, but i want >>>>>>> to change it in all openjdk sources i can find it. >>>>>>> I thought i really must discuss it part by part in the mailing-lists. >>>>>>> Actually i am working on the issue to save against regression on this. >>>>>>> Thanks Alexandr for this input. So there will be something that >>>>>>> integrates into jtreg for this too. >>>>>>> >>>>>>> -- Sebastian >>>>>>> >>>>>>> >>>>>>> On 09/30/2015 01:11 AM, Christian Thalinger wrote: >>>>>>>> Thanks for volunteering to look into such old bugs! >>>>>>>> >>>>>>>> Is this the only occurrence of that pattern in the hotspot repository? If you want to fix this in hotspot only without the jdk changes described in the RFE (I just changed the type from Bug to Enhancement) then we have to file a new RFE because we can?t close the original one. >>>>>>>> >>>>>>>>> On Sep 27, 2015, at 6:58 AM, Sebastian Sickelmann wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> my name is Sebastian Sickelmann and i signed the OCA. >>>>>>>>> >>>>>>>>> Actually I am searching through the JBS for low hanging fruits. >>>>>>>>> Right now i am looking through the openjdk-sources and try to evaluate >>>>>>>>> if i can make something about JDK-5108778. >>>>>>>>> >>>>>>>>> As I am not an author, I am actually not able to host webrevs on >>>>>>>>> cr.openjdk.java.net. >>>>>>>>> >>>>>>>>> Is there someone who would support at hosting the hotspot-part of >>>>>>>>> JDK-5108778 on cr.openjdk.java.net for reviewing? >>>>>>>>> >>>>>>>>> I placed the hotspot part in my dropbox at: >>>>>>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev/index.html >>>>>>>>> or as zip: >>>>>>>>> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk/jdk-5108778/hotspot_0/webrev.zip >>>>>>>>> >>>>>>>>> I executed all jtreg tests in hotspot/test and get no more errors than before the change. >>>>>>>>> >>>>>>>>> -- Sebastian >>>>>>>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Dec 10 21:31:27 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 10 Dec 2015 13:31:27 -0800 Subject: [RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and nonstatic_oopmap on 32-bit systems In-Reply-To: <56685B78.5030106@oracle.com> References: <56620D85.8090204@oracle.com> <5666A8CA.3040004@oracle.com> <56672C25.7010909@oracle.com> <56685B78.5030106@oracle.com> Message-ID: <5669EF2F.2000907@oracle.com> Hi Mikael, See comments inline below: On 12/9/15 8:48 AM, Mikael Gerdin wrote: > On 2015-12-08 20:14, Chris Plummer wrote: >> [Adding serviceability-dev at openjdk.java.net] >> >> Hi Mikael, >> >> Thanks for pointing this out. I'll look into it some more. Are there any >> tests that should be failing as a result of this? I get the feeling no, >> since I see other issues here that existed before my change. For >> example, this code is not returning the proper size if the class is >> anonymous or is an interface. It needs to add 1 extra word in that case. >> See size() in instanceKlass.hpp. >> >> Another difference from the VM code is alignObjectSize() is being used >> by getSize(), but headerSize is set using alignObjectOffset(). The VM >> code uses align_object_offset in both cases. >> >> // Align the object size. >> public static long alignObjectSize(long size) { >> return VM.getVM().alignUp(size, >> VM.getVM().getMinObjAlignmentInBytes()); >> } >> >> // All vm's align longs, so pad out certain offsets. >> public static long alignObjectOffset(long offset) { >> return VM.getVM().alignUp(offset, VM.getVM().getBytesPerLong()); >> } >> >> So the difference here is in the use of getMinObjAlignmentInBytes (not >> what the VM does) vs getBytesPerLong (what the VM uses): >> >> public int getObjectAlignmentInBytes() { >> if (objectAlignmentInBytes == 0) { >> Flag flag = getCommandLineFlag("ObjectAlignmentInBytes"); >> objectAlignmentInBytes = (flag == null) ? 8 : >> (int)flag.getIntx(); >> } >> return objectAlignmentInBytes; >> } >> >> So this seems wrong for use in any InstanceKlass size or embedded field >> offset calculation. It is probably a remnant of when class metadata was >> stored in the java heap, and the size of InstanceKlass had to be padded >> out to the minimum heap object alignment. At least it is harmless if >> ObjectAlignmentInBytes is not set, and if set it is only supported for >> 64-bit: >> >> lp64_product(intx, ObjectAlignmentInBytes, >> 8, \ >> "Default object alignment in bytes, 8 is >> minimum") \ >> range(8, >> 256) \ >> constraint(ObjectAlignmentInBytesConstraintFunc,AtParse) \ >> >> I'll get these cleaned up, but it sure would be nice if there was a way >> to reliably test it. > > I'd say that it's quite possible to test it! > Create a whitebox.cpp entry point for determining the size of a class. Ok, but I instead decided to use jcmd with "GC.class_stats KlassBytes" > > Run a java program calling the entry point and printing the > InstanceKlass size as computed by calling InstanceKlass::size() on a > set of pre-determined set of complex and simple classes (vtables, > itables, anonymous, etc.) For now I just did this from the command line to do some quick checking. No test written. > Have the java program wait after it's finished printing. > > Launch the SA agent and attach it to the process. > Through several layers of magic, execute the incantation: > > mgerdin at mgerdin03:~/work/repos/hg/jdk9/hs-rt-work/hotspot$ > ../build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java > sun.jvm.hotspot.CLHSDB 6211 > Attaching to process 6211, please wait... > hsdb> jseval > "sapkg.utilities.SystemDictionaryHelper.findInstanceKlass('java/lang/Object').getSize();" > 472 Ok. I did this to get sizes as SA sees them. They were not just wrong for existing JDK, but in most cases off by a large margin. I did some investigating. This is InstanceKlass.getSize() public long getSize() { return Oop.alignObjectSize(getHeaderSize() + Oop.alignObjectOffset(getVtableLen()) + Oop.alignObjectOffset(getItableLen()) + Oop.alignObjectOffset(getNonstaticOopMapSize())); } The problem is that getHeaderSize() returns the size in bytes, but the others all return the size in words. They need to be multiplied by the word size to get the right value since the caller of getSize() expects the result to be in bytes. So we have multiple problems with SA with respect to the InstanceKlass.getSize() support: * Alignment issues introduced by me. * Some minor other issues like using alignObjectSize when it's not needed, and not taking into account extra fields for interfaces and anonymous classes. * Not multiplying the vtable, itable, and oopMapSize by the number of bytes in a word. * No test available. I'm not too sure how to proceed here w.r.t. my CR. I'm inclined to just make the SA adjustments needed to take into consideration the alignment changes I've made to InstanceKlass, and file a CRs for the rest (one for the existing bugs and one for the lack of any test). Please advise. thanks, Chris > > You could also create a javascript source file in the test directory > which performs the appropriate calls and do > hsdb> jsload /path/to/file.js > hsdb> jseval "doit()" > > where > file.js: > doit = function() { > sd = sapkg.utilities.SystemDictionaryHelper; > do_klass = function(name) { > writeln(sd.findInstanceKlass(name).getSize()); > } > > do_klass('java/lang/Object'); > do_klass('java/lang/Class'); > } > > > The only problem is that the test can't reliably execute on > unconfigured os x setups because of OS level security requirements for > attaching to processes. > > After detaching HSDB with the "quit" command you tell the debugged > java process to terminate, for example by printing some string on its > stdin. > > Easy, right? :) > > /Mikael > >> >> thanks, >> >> Chris >> >> On 12/8/15 1:54 AM, Mikael Gerdin wrote: >>> Hi Chris, >>> >>> Not a review but I'm fairly sure that you need to update the >>> serviceability agent to reflect these changes, see for example: >>> >>> public long getSize() { >>> return Oop.alignObjectSize( >>> getHeaderSize() + >>> Oop.alignObjectOffset(getVtableLen()) + >>> Oop.alignObjectOffset(getItableLen()) + >>> Oop.alignObjectOffset(getNonstaticOopMapSize())); >>> } >>> >>> in InstanceKlass.java >>> >>> /Mikael >>> >>> On 2015-12-04 23:02, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review the following: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8143608 >>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/ >>>> >>>> >>>> A bit of background would help. The InstanceKlass object has a >>>> number of >>>> variable length fields that are laid out after the declared fields. >>>> When >>>> an InstanceKlass object is allocated, extra memory is allocated for it >>>> to leave room for these fields. The first three of these fields are >>>> vtable, itable, and nonstatic_oopmap. They are all arrays of HeapWord >>>> sized values, which means void* size, which means they only need >>>> 32-bit >>>> alignment on 32-bit systems. However, they have always been 64-bit >>>> aligned. This webrev removes the forced 64-bit alignment on 32-bit >>>> systems, saving footprint. >>>> >>>> This change affects all 32-bit platforms. It should have no net impact >>>> on 64-bit platforms since the fields remain (naturally) 64-bit aligned >>>> (unless of course I've introduced a bug). The intent is to not change >>>> what is done for 64-bit platforms. >>>> >>>> BTW, there is a change to AARCH64, which may seem odd at first. It >>>> just >>>> removes an "if" block where the condition should always have evaluated >>>> to false, so it should have no net affect. >>>> >>>> Tested with JPRT "-testset hotspot". Please let me know if you think >>>> there are any additional tests that should be run. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>> >> > From dmitry.samersoff at oracle.com Thu Dec 10 22:20:50 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 11 Dec 2015 01:20:50 +0300 Subject: RFR: JDK-8145099 Better error message when SA can't attach to a process In-Reply-To: References: Message-ID: <5669FAC2.3020805@oracle.com> Staffan, 1. strerror_r comes in two versions - returning string (GNU) and returning int (XSI) To make developers live more interesting GNU version doesn't guarantee to fill buf with appropriate string, so you can't just void return value. Default version tends to be XSI now days and I'm not sure that build system add -D_GNU_SOURCE on all platforms. So you have to add something like #if _POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && ! _GNU_SOURCE use XSI strerror_r #else use GNU strerror_r #endif Or just don't care of threads and use plain strerror - it widely used in hotspot and it doesn't crash on a race. 2. err_buff remains empty if the attach fails at ll.412 of ps_proc.c, but see below. 3. (* just an opinion *) Extra parameters to ptrace_attach/PGrab linux makes in different from other platforms. So I would prefer to have it unchanged - you can either mimic Solaris behavior and add Pgrab_error() function or just move all strerror staff to LinuxDebuggerLocal_attach0 - errno from ptrace_attach/Pgrab is available there. (except calloc case, but if we can't allocate couple of bytes for struct ps_prochandle we most likely will not see the error anyway). -Dmitry On 2015-12-10 18:10, Staffan Larsen wrote: > Thanks! > >> On 10 dec. 2015, at 15:56, Thomas St?fe > > wrote: >> >> Hi Staffan, >> >> this looks fine now, thanks! >> >> ..Thomas >> >> On Thu, Dec 10, 2015 at 3:42 PM, Staffan Larsen >> > wrote: >> >> Hi Thomas, >> >>> On 10 dec. 2015, at 15:27, Thomas St?fe >> > wrote: >>> >>> Hi Staffan, >>> >>> thanks! >>> >>> It also just occurred to me that strerror is not considered >>> threadsafe. Maybe strerror_r() would a better option (depending >>> on the version you use you would have to check the return value >>> for NULL, though). >> >> Updated here: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.03/ >> >> Thanks, >> /Staffan >> >>> >>> sorry for this piecemeal review. >>> >>> Kind Regards, Thomas >>> >>> >>> >>> On Thu, Dec 10, 2015 at 3:22 PM, Staffan Larsen >>> > wrote: >>> >>> Hi Thommas, >>> >>>> On 10 dec. 2015, at 14:49, Thomas St?fe >>>> > >>>> wrote: >>>> >>>> Hi Stefan, >>>> >>>> Disclaimer: not a "R"eviewer. >>>> >>>> http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/agent/src/os/linux/LinuxDebuggerLocal.c.udiff.html >>>> >>>> I am not sure why you pass sizeof(err_buf) - 1 instead of >>>> sizeof(err_buf) to Pgrab and sizeof(msg) - 1 instead of >>>> sizeof(msg) to snprintf? snprintf will always zero terminate >>>> in case of truncation, at least on posix platforms. >>> >>> Good point. I was just being overly cautious without thinking. >>> >>> Updated >>> webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.02/ >>> >>> Thanks, >>> /Staffan >>> >>>> >>>> Otherwise this looks good. >>>> >>>> Kind Regards, Thomas >>>> >>>> >>>> On Thu, Dec 10, 2015 at 2:19 PM, Staffan Larsen >>>> >>> > wrote: >>>> >>>> Please review this patch to add a better error message >>>> to SA when it fails to attach to a process on linux. >>>> Currently the error says "Can't attach to the process?. >>>> After this change the message will look something like: >>>> "Can't attach to the process: ptrace(PTRACE_ATTACH, ..) >>>> failed for 28417: Operation not permitted? >>>> >>>> webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145099 >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> >>>> >>> >>> >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From rachel.protacio at oracle.com Thu Dec 10 22:21:52 2015 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Thu, 10 Dec 2015 17:21:52 -0500 Subject: RFR: 8145153: Convert TraceMonitorInflation to Unified Logging Message-ID: <5669FB00.7070600@oracle.com> Hello! Please review another product flag logging change. This one's pretty small. Converts TraceMonitorInflation to -Xlog:monitorinflation=debug internally, with an alias for the old option. I've again patched in Max's alias table code in the arguments.cpp and .hpp files since my previous changeset with that code is currently on hold. Open webrev: http://cr.openjdk.java.net/~rprotacio/8145153/ Bug: https://bugs.openjdk.java.net/browse/JDK-8145153 Testing: passes jck vm tests, JPRT, and RBT quick and noncolo tests Thank you! Rachel From david.holmes at oracle.com Fri Dec 11 00:53:52 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Dec 2015 10:53:52 +1000 Subject: RFR: 8145153: Convert TraceMonitorInflation to Unified Logging In-Reply-To: <5669FB00.7070600@oracle.com> References: <5669FB00.7070600@oracle.com> Message-ID: <566A1EA0.7080908@oracle.com> Hi Rachel, On 11/12/2015 8:21 AM, Rachel Protacio wrote: > Hello! > > Please review another product flag logging change. This one's pretty > small. Converts TraceMonitorInflation to -Xlog:monitorinflation=debug Conversion looks fine. > internally, with an alias for the old option. I've again patched in > Max's alias table code in the arguments.cpp and .hpp files since my > previous changeset with that code is currently on hold. I still have an unanswered question from the other thread about how the order of options is handled. Primarily whether left-to-right processing prevails? I also strongly believe we should be deprecating these flags at the same time we do the conversion as this is a classic case of deprecation if ever there was one! > Open webrev: http://cr.openjdk.java.net/~rprotacio/8145153/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8145153 On the test, if you use the testlibrary you must also @build it. Also java -version is sufficient to see some inflating/deflating happen, and your sample class does nothing to force inflation. Thanks, David > Testing: passes jck vm tests, JPRT, and RBT quick and noncolo tests > > Thank you! > Rachel From thomas.stuefe at gmail.com Fri Dec 11 06:56:48 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 11 Dec 2015 07:56:48 +0100 Subject: RFR: JDK-8145099 Better error message when SA can't attach to a process In-Reply-To: <5669FAC2.3020805@oracle.com> References: <5669FAC2.3020805@oracle.com> Message-ID: Hi Dmitry, > Or just don't care of threads and use plain strerror - it widely used in > hotspot and it doesn't crash on a race. > > Unfortunately, it does: https://bugs.openjdk.java.net/browse/JDK-8133249 Regards, Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Fri Dec 11 08:12:52 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 11 Dec 2015 09:12:52 +0100 Subject: RFR: JDK-8145099 Better error message when SA can't attach to a process In-Reply-To: <5669FAC2.3020805@oracle.com> References: <5669FAC2.3020805@oracle.com> Message-ID: <3E027BF6-5B65-484D-8A5A-4EACA7F014D7@oracle.com> > On 10 dec. 2015, at 23:20, Dmitry Samersoff wrote: > > Staffan, > > 1. > > strerror_r comes in two versions - returning string (GNU) and returning > int (XSI) > > To make developers live more interesting GNU version doesn't guarantee > to fill buf with appropriate string, so you can't just void return value. > > Default version tends to be XSI now days and I'm not sure that build > system add -D_GNU_SOURCE on all platforms. > > So you have to add something like > > #if _POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && ! _GNU_SOURCE > use XSI strerror_r > #else > use GNU strerror_r > #endif We are getting the _GNU_SOURCE version when building. If that changes in the makefiles somewhere so that we get the XSI version, then this code should not compile - it should issue a warning when assigning an int to char*. > > Or just don't care of threads and use plain strerror - it widely used in > hotspot and it doesn't crash on a race. > > 2. > > err_buff remains empty if the attach fails at ll.412 of ps_proc.c, > but see below. It should get filled in in the ptrace_attach() call. > > 3. (* just an opinion *) > > Extra parameters to ptrace_attach/PGrab linux makes in different from > other platforms. This is all platform specific code - and all the platforms are different. Of course, it would be good if all platforms reported good error message always - and we can continue working on that. Thanks, /Staffan > > So I would prefer to have it unchanged - you can either mimic Solaris > behavior and add Pgrab_error() function or just move all strerror staff > to LinuxDebuggerLocal_attach0 - errno from ptrace_attach/Pgrab is > available there. > > (except calloc case, but if we can't allocate couple of bytes for struct > ps_prochandle we most likely will not see the error anyway). > > > -Dmitry > > > On 2015-12-10 18:10, Staffan Larsen wrote: >> Thanks! >> >>> On 10 dec. 2015, at 15:56, Thomas St?fe >>> >> wrote: >>> >>> Hi Staffan, >>> >>> this looks fine now, thanks! >>> >>> ..Thomas >>> >>> On Thu, Dec 10, 2015 at 3:42 PM, Staffan Larsen >>> >> wrote: >>> >>> Hi Thomas, >>> >>>> On 10 dec. 2015, at 15:27, Thomas St?fe >>>> >> wrote: >>>> >>>> Hi Staffan, >>>> >>>> thanks! >>>> >>>> It also just occurred to me that strerror is not considered >>>> threadsafe. Maybe strerror_r() would a better option (depending >>>> on the version you use you would have to check the return value >>>> for NULL, though). >>> >>> Updated here: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.03/ >>> >>> Thanks, >>> /Staffan >>> >>>> >>>> sorry for this piecemeal review. >>>> >>>> Kind Regards, Thomas >>>> >>>> >>>> >>>> On Thu, Dec 10, 2015 at 3:22 PM, Staffan Larsen >>>> >> wrote: >>>> >>>> Hi Thommas, >>>> >>>>> On 10 dec. 2015, at 14:49, Thomas St?fe >>>>> >> >>>>> wrote: >>>>> >>>>> Hi Stefan, >>>>> >>>>> Disclaimer: not a "R"eviewer. >>>>> >>>>> http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/agent/src/os/linux/LinuxDebuggerLocal.c.udiff.html >>>>> >>>>> I am not sure why you pass sizeof(err_buf) - 1 instead of >>>>> sizeof(err_buf) to Pgrab and sizeof(msg) - 1 instead of >>>>> sizeof(msg) to snprintf? snprintf will always zero terminate >>>>> in case of truncation, at least on posix platforms. >>>> >>>> Good point. I was just being overly cautious without thinking. >>>> >>>> Updated >>>> webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.02/ >>>> >>>> Thanks, >>>> /Staffan >>>> >>>>> >>>>> Otherwise this looks good. >>>>> >>>>> Kind Regards, Thomas >>>>> >>>>> >>>>> On Thu, Dec 10, 2015 at 2:19 PM, Staffan Larsen >>>>> >>>>> >> wrote: >>>>> >>>>> Please review this patch to add a better error message >>>>> to SA when it fails to attach to a process on linux. >>>>> Currently the error says "Can't attach to the process?. >>>>> After this change the message will look something like: >>>>> "Can't attach to the process: ptrace(PTRACE_ATTACH, ..) >>>>> failed for 28417: Operation not permitted? >>>>> >>>>> webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145099 >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Fri Dec 11 10:54:22 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 11 Dec 2015 13:54:22 +0300 Subject: RFR: JDK-8145099 Better error message when SA can't attach to a process In-Reply-To: <3E027BF6-5B65-484D-8A5A-4EACA7F014D7@oracle.com> References: <5669FAC2.3020805@oracle.com> <3E027BF6-5B65-484D-8A5A-4EACA7F014D7@oracle.com> Message-ID: <566AAB5E.5050109@oracle.com> Staffan, > This is all platform specific code - and all the platforms are > different. Of course, it would be good if all platforms reported good > error message always - and we can continue working on that. OK. > It should get filled in in the ptrace_attach() call. if ph->pid == thr->lwp_id at ll. 409 the function return NULL but doesn't touch err_buf. -Dmitry On 2015-12-11 11:12, Staffan Larsen wrote: > >> On 10 dec. 2015, at 23:20, Dmitry Samersoff >> > wrote: >> >> Staffan, >> >> 1. >> >> strerror_r comes in two versions - returning string (GNU) and returning >> int (XSI) >> >> To make developers live more interesting GNU version doesn't guarantee >> to fill buf with appropriate string, so you can't just void return value. >> >> Default version tends to be XSI now days and I'm not sure that build >> system add -D_GNU_SOURCE on all platforms. >> >> So you have to add something like >> >> #if _POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && ! _GNU_SOURCE >> use XSI strerror_r >> #else >> use GNU strerror_r >> #endif > > We are getting the _GNU_SOURCE version when building. If that changes in > the makefiles somewhere so that we get the XSI version, then this code > should not compile - it should issue a warning when assigning an int to > char*. > >> >> Or just don't care of threads and use plain strerror - it widely used in >> hotspot and it doesn't crash on a race. >> >> 2. >> >> err_buff remains empty if the attach fails at ll.412 of ps_proc.c, >> but see below. > > It should get filled in in the ptrace_attach() call. > >> >> 3. (* just an opinion *) >> >> Extra parameters to ptrace_attach/PGrab linux makes in different from >> other platforms. > > This is all platform specific code - and all the platforms are > different. Of course, it would be good if all platforms reported good > error message always - and we can continue working on that. > > Thanks, > /Staffan > >> >> So I would prefer to have it unchanged - you can either mimic Solaris >> behavior and add Pgrab_error() function or just move all strerror staff >> to LinuxDebuggerLocal_attach0 - errno from ptrace_attach/Pgrab is >> available there. >> >> (except calloc case, but if we can't allocate couple of bytes for struct >> ps_prochandle we most likely will not see the error anyway). >> >> >> -Dmitry >> >> >> On 2015-12-10 18:10, Staffan Larsen wrote: >>> Thanks! >>> >>>> On 10 dec. 2015, at 15:56, Thomas St?fe >>> >>>> > wrote: >>>> >>>> Hi Staffan, >>>> >>>> this looks fine now, thanks! >>>> >>>> ..Thomas >>>> >>>> On Thu, Dec 10, 2015 at 3:42 PM, Staffan Larsen >>>> >>> > >>>> wrote: >>>> >>>> Hi Thomas, >>>> >>>>> On 10 dec. 2015, at 15:27, Thomas St?fe >>>> >>>>> > wrote: >>>>> >>>>> Hi Staffan, >>>>> >>>>> thanks! >>>>> >>>>> It also just occurred to me that strerror is not considered >>>>> threadsafe. Maybe strerror_r() would a better option (depending >>>>> on the version you use you would have to check the return value >>>>> for NULL, though). >>>> >>>> Updated here: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.03/ >>>> >>>> Thanks, >>>> /Staffan >>>> >>>>> >>>>> sorry for this piecemeal review. >>>>> >>>>> Kind Regards, Thomas >>>>> >>>>> >>>>> >>>>> On Thu, Dec 10, 2015 at 3:22 PM, Staffan Larsen >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Hi Thommas, >>>>> >>>>>> On 10 dec. 2015, at 14:49, Thomas St?fe >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> Hi Stefan, >>>>>> >>>>>> Disclaimer: not a "R"eviewer. >>>>>> >>>>>> http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/agent/src/os/linux/LinuxDebuggerLocal.c.udiff.html >>>>>> >>>>>> I am not sure why you pass sizeof(err_buf) - 1 instead of >>>>>> sizeof(err_buf) to Pgrab and sizeof(msg) - 1 instead of >>>>>> sizeof(msg) to snprintf? snprintf will always zero terminate >>>>>> in case of truncation, at least on posix platforms. >>>>> >>>>> Good point. I was just being overly cautious without thinking. >>>>> >>>>> Updated >>>>> webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.02/ >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>>> >>>>>> Otherwise this looks good. >>>>>> >>>>>> Kind Regards, Thomas >>>>>> >>>>>> >>>>>> On Thu, Dec 10, 2015 at 2:19 PM, Staffan Larsen >>>>>> >>>>>> > wrote: >>>>>> >>>>>> Please review this patch to add a better error message >>>>>> to SA when it fails to attach to a process on linux. >>>>>> Currently the error says "Can't attach to the process?. >>>>>> After this change the message will look something like: >>>>>> "Can't attach to the process: ptrace(PTRACE_ATTACH, ..) >>>>>> failed for 28417: Operation not permitted? >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/ >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145099 >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Fri Dec 11 11:32:30 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 11 Dec 2015 12:32:30 +0100 Subject: RFR: JDK-8145099 Better error message when SA can't attach to a process In-Reply-To: <566AAB5E.5050109@oracle.com> References: <5669FAC2.3020805@oracle.com> <3E027BF6-5B65-484D-8A5A-4EACA7F014D7@oracle.com> <566AAB5E.5050109@oracle.com> Message-ID: <9A3AE520-3A48-4FD2-9E87-3B55A0CFFA04@oracle.com> > On 11 dec. 2015, at 11:54, Dmitry Samersoff wrote: > > Staffan, > >> This is all platform specific code - and all the platforms are >> different. Of course, it would be good if all platforms reported good >> error message always - and we can continue working on that. > > OK. > >> It should get filled in in the ptrace_attach() call. > > if ph->pid == thr->lwp_id at ll. 409 the function return NULL but > doesn't touch err_buf. if ph->pid == thr->lwp_id the if-statement is skipped and we continue in the while-loop. > > -Dmitry > > On 2015-12-11 11:12, Staffan Larsen wrote: >> >>> On 10 dec. 2015, at 23:20, Dmitry Samersoff >>> > wrote: >>> >>> Staffan, >>> >>> 1. >>> >>> strerror_r comes in two versions - returning string (GNU) and returning >>> int (XSI) >>> >>> To make developers live more interesting GNU version doesn't guarantee >>> to fill buf with appropriate string, so you can't just void return value. >>> >>> Default version tends to be XSI now days and I'm not sure that build >>> system add -D_GNU_SOURCE on all platforms. >>> >>> So you have to add something like >>> >>> #if _POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && ! _GNU_SOURCE >>> use XSI strerror_r >>> #else >>> use GNU strerror_r >>> #endif >> >> We are getting the _GNU_SOURCE version when building. If that changes in >> the makefiles somewhere so that we get the XSI version, then this code >> should not compile - it should issue a warning when assigning an int to >> char*. >> >>> >>> Or just don't care of threads and use plain strerror - it widely used in >>> hotspot and it doesn't crash on a race. >>> >>> 2. >>> >>> err_buff remains empty if the attach fails at ll.412 of ps_proc.c, >>> but see below. >> >> It should get filled in in the ptrace_attach() call. >> >>> >>> 3. (* just an opinion *) >>> >>> Extra parameters to ptrace_attach/PGrab linux makes in different from >>> other platforms. >> >> This is all platform specific code - and all the platforms are >> different. Of course, it would be good if all platforms reported good >> error message always - and we can continue working on that. >> >> Thanks, >> /Staffan >> >>> >>> So I would prefer to have it unchanged - you can either mimic Solaris >>> behavior and add Pgrab_error() function or just move all strerror staff >>> to LinuxDebuggerLocal_attach0 - errno from ptrace_attach/Pgrab is >>> available there. >>> >>> (except calloc case, but if we can't allocate couple of bytes for struct >>> ps_prochandle we most likely will not see the error anyway). >>> >>> >>> -Dmitry >>> >>> >>> On 2015-12-10 18:10, Staffan Larsen wrote: >>>> Thanks! >>>> >>>>> On 10 dec. 2015, at 15:56, Thomas St?fe >>>> >>>>> > wrote: >>>>> >>>>> Hi Staffan, >>>>> >>>>> this looks fine now, thanks! >>>>> >>>>> ..Thomas >>>>> >>>>> On Thu, Dec 10, 2015 at 3:42 PM, Staffan Larsen >>>>> >>>> > >>>>> wrote: >>>>> >>>>> Hi Thomas, >>>>> >>>>>> On 10 dec. 2015, at 15:27, Thomas St?fe >>>>> >>>>>> > wrote: >>>>>> >>>>>> Hi Staffan, >>>>>> >>>>>> thanks! >>>>>> >>>>>> It also just occurred to me that strerror is not considered >>>>>> threadsafe. Maybe strerror_r() would a better option (depending >>>>>> on the version you use you would have to check the return value >>>>>> for NULL, though). >>>>> >>>>> Updated here: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.03/ >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>>> >>>>>> sorry for this piecemeal review. >>>>>> >>>>>> Kind Regards, Thomas >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Dec 10, 2015 at 3:22 PM, Staffan Larsen >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> Hi Thommas, >>>>>> >>>>>>> On 10 dec. 2015, at 14:49, Thomas St?fe >>>>>>> >>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Hi Stefan, >>>>>>> >>>>>>> Disclaimer: not a "R"eviewer. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/agent/src/os/linux/LinuxDebuggerLocal.c.udiff.html >>>>>>> >>>>>>> I am not sure why you pass sizeof(err_buf) - 1 instead of >>>>>>> sizeof(err_buf) to Pgrab and sizeof(msg) - 1 instead of >>>>>>> sizeof(msg) to snprintf? snprintf will always zero terminate >>>>>>> in case of truncation, at least on posix platforms. >>>>>> >>>>>> Good point. I was just being overly cautious without thinking. >>>>>> >>>>>> Updated >>>>>> webrev: http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.02/ >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>>> >>>>>>> Otherwise this looks good. >>>>>>> >>>>>>> Kind Regards, Thomas >>>>>>> >>>>>>> >>>>>>> On Thu, Dec 10, 2015 at 2:19 PM, Staffan Larsen >>>>>>> >>>>>>> > wrote: >>>>>>> >>>>>>> Please review this patch to add a better error message >>>>>>> to SA when it fails to attach to a process on linux. >>>>>>> Currently the error says "Can't attach to the process?. >>>>>>> After this change the message will look something like: >>>>>>> "Can't attach to the process: ptrace(PTRACE_ATTACH, ..) >>>>>>> failed for 28417: Operation not permitted? >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~sla/JDK-8145099/webrev.01/ >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8145099 >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From marcus.larsson at oracle.com Fri Dec 11 12:49:15 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 11 Dec 2015 13:49:15 +0100 Subject: [PING] Re: RFR: 8144220: UL does not support full path names for log files on windows In-Reply-To: <56601544.8070203@oracle.com> References: <565EF508.4030805@oracle.com> <56601544.8070203@oracle.com> Message-ID: <566AC64B.2060504@oracle.com> Need another review for this. On 2015-12-03 11:11, Marcus Larsson wrote: > Hi, > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8144220/webrev.01/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00-01/ > > Added more test cases to the test, and renamed it to > TestQuotedLogOutputs. > The updated test found that partially quoted output names that didn't > start > with the quote character were accepted. This has been fixed. > > Test passes in RBT. > > Thanks, > Marcus > > On 2015-12-02 14:41, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to allow full path names for log >> files on windows. >> >> The full path to files will on windows contain a colon (from the C:\ >> part), and there used to be no way to avoid that colon from being >> parsed as the delimiter for the next -Xlog: option. With this patch >> it is now possible to avoid this by giving the path within quotation >> marks, for example: -Xlog:all:"C:\out.log". Any colons within quotes >> will not be parsed as delimiters for -Xlog. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8144220 >> >> Testing: >> New test through RBT. >> >> Thanks, >> Marcus > From staffan.larsen at oracle.com Fri Dec 11 12:58:55 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 11 Dec 2015 13:58:55 +0100 Subject: [PING] RFR: 8144220: UL does not support full path names for log files on windows In-Reply-To: <566AC64B.2060504@oracle.com> References: <565EF508.4030805@oracle.com> <56601544.8070203@oracle.com> <566AC64B.2060504@oracle.com> Message-ID: <9735E82F-B0E2-4223-ACD2-97E0B2548A94@oracle.com> Looks good! Thanks, /Staffan > On 11 dec. 2015, at 13:49, Marcus Larsson wrote: > > Need another review for this. > > On 2015-12-03 11:11, Marcus Larsson wrote: >> Hi, >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8144220/webrev.01/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00-01/ >> >> Added more test cases to the test, and renamed it to TestQuotedLogOutputs. >> The updated test found that partially quoted output names that didn't start >> with the quote character were accepted. This has been fixed. >> >> Test passes in RBT. >> >> Thanks, >> Marcus >> >> On 2015-12-02 14:41, Marcus Larsson wrote: >>> Hi, >>> >>> Please review the following patch to allow full path names for log files on windows. >>> >>> The full path to files will on windows contain a colon (from the C:\ part), and there used to be no way to avoid that colon from being parsed as the delimiter for the next -Xlog: option. With this patch it is now possible to avoid this by giving the path within quotation marks, for example: -Xlog:all:"C:\out.log". Any colons within quotes will not be parsed as delimiters for -Xlog. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8144220 >>> >>> Testing: >>> New test through RBT. >>> >>> Thanks, >>> Marcus >> > From markus.gronlund at oracle.com Fri Dec 11 13:32:55 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Fri, 11 Dec 2015 05:32:55 -0800 (PST) Subject: [PING] Re: RFR: 8144220: UL does not support full path names for log files on windows In-Reply-To: <566AC64B.2060504@oracle.com> References: <565EF508.4030805@oracle.com> <56601544.8070203@oracle.com> <566AC64B.2060504@oracle.com> Message-ID: <7d3dbcfe-265a-4c61-af22-121c367ee79f@default> Hi Marcus, This looks good. Thanks Markus -----Original Message----- From: Marcus Larsson Sent: den 11 december 2015 13:49 To: serviceability-dev at openjdk.java.net Subject: [PING] Re: RFR: 8144220: UL does not support full path names for log files on windows Need another review for this. On 2015-12-03 11:11, Marcus Larsson wrote: > Hi, > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8144220/webrev.01/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00-01/ > > Added more test cases to the test, and renamed it to > TestQuotedLogOutputs. > The updated test found that partially quoted output names that didn't > start with the quote character were accepted. This has been fixed. > > Test passes in RBT. > > Thanks, > Marcus > > On 2015-12-02 14:41, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to allow full path names for log >> files on windows. >> >> The full path to files will on windows contain a colon (from the C:\ >> part), and there used to be no way to avoid that colon from being >> parsed as the delimiter for the next -Xlog: option. With this patch >> it is now possible to avoid this by giving the path within quotation >> marks, for example: -Xlog:all:"C:\out.log". Any colons within quotes >> will not be parsed as delimiters for -Xlog. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8144220 >> >> Testing: >> New test through RBT. >> >> Thanks, >> Marcus > From marcus.larsson at oracle.com Fri Dec 11 14:20:22 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 11 Dec 2015 15:20:22 +0100 Subject: [PING] RFR: 8144220: UL does not support full path names for log files on windows In-Reply-To: <9735E82F-B0E2-4223-ACD2-97E0B2548A94@oracle.com> References: <565EF508.4030805@oracle.com> <56601544.8070203@oracle.com> <566AC64B.2060504@oracle.com> <9735E82F-B0E2-4223-ACD2-97E0B2548A94@oracle.com> Message-ID: <566ADBA6.7000102@oracle.com> Thanks Staffan! On 2015-12-11 13:58, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 11 dec. 2015, at 13:49, Marcus Larsson wrote: >> >> Need another review for this. >> >> On 2015-12-03 11:11, Marcus Larsson wrote: >>> Hi, >>> >>> New webrev: >>> http://cr.openjdk.java.net/~mlarsson/8144220/webrev.01/ >>> >>> Incremental: >>> http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00-01/ >>> >>> Added more test cases to the test, and renamed it to TestQuotedLogOutputs. >>> The updated test found that partially quoted output names that didn't start >>> with the quote character were accepted. This has been fixed. >>> >>> Test passes in RBT. >>> >>> Thanks, >>> Marcus >>> >>> On 2015-12-02 14:41, Marcus Larsson wrote: >>>> Hi, >>>> >>>> Please review the following patch to allow full path names for log files on windows. >>>> >>>> The full path to files will on windows contain a colon (from the C:\ part), and there used to be no way to avoid that colon from being parsed as the delimiter for the next -Xlog: option. With this patch it is now possible to avoid this by giving the path within quotation marks, for example: -Xlog:all:"C:\out.log". Any colons within quotes will not be parsed as delimiters for -Xlog. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8144220 >>>> >>>> Testing: >>>> New test through RBT. >>>> >>>> Thanks, >>>> Marcus From marcus.larsson at oracle.com Fri Dec 11 14:20:31 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 11 Dec 2015 15:20:31 +0100 Subject: [PING] Re: RFR: 8144220: UL does not support full path names for log files on windows In-Reply-To: <7d3dbcfe-265a-4c61-af22-121c367ee79f@default> References: <565EF508.4030805@oracle.com> <56601544.8070203@oracle.com> <566AC64B.2060504@oracle.com> <7d3dbcfe-265a-4c61-af22-121c367ee79f@default> Message-ID: <566ADBAF.3090402@oracle.com> Thanks Markus! On 2015-12-11 14:32, Markus Gronlund wrote: > Hi Marcus, > > This looks good. > > Thanks > Markus > > -----Original Message----- > From: Marcus Larsson > Sent: den 11 december 2015 13:49 > To: serviceability-dev at openjdk.java.net > Subject: [PING] Re: RFR: 8144220: UL does not support full path names for log files on windows > > Need another review for this. > > On 2015-12-03 11:11, Marcus Larsson wrote: >> Hi, >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8144220/webrev.01/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00-01/ >> >> Added more test cases to the test, and renamed it to >> TestQuotedLogOutputs. >> The updated test found that partially quoted output names that didn't >> start with the quote character were accepted. This has been fixed. >> >> Test passes in RBT. >> >> Thanks, >> Marcus >> >> On 2015-12-02 14:41, Marcus Larsson wrote: >>> Hi, >>> >>> Please review the following patch to allow full path names for log >>> files on windows. >>> >>> The full path to files will on windows contain a colon (from the C:\ >>> part), and there used to be no way to avoid that colon from being >>> parsed as the delimiter for the next -Xlog: option. With this patch >>> it is now possible to avoid this by giving the path within quotation >>> marks, for example: -Xlog:all:"C:\out.log". Any colons within quotes >>> will not be parsed as delimiters for -Xlog. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8144220/webrev.00/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8144220 >>> >>> Testing: >>> New test through RBT. >>> >>> Thanks, >>> Marcus From rachel.protacio at oracle.com Fri Dec 11 17:41:50 2015 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Fri, 11 Dec 2015 12:41:50 -0500 Subject: RFR: 8145153: Convert TraceMonitorInflation to Unified Logging In-Reply-To: <566A1EA0.7080908@oracle.com> References: <5669FB00.7070600@oracle.com> <566A1EA0.7080908@oracle.com> Message-ID: <566B0ADE.8050105@oracle.com> Hi David, Thanks for the review! Updated webrev: http://cr.openjdk.java.net/~rprotacio/8145153.01/ On 12/10/2015 7:53 PM, David Holmes wrote: > Hi Rachel, > > On 11/12/2015 8:21 AM, Rachel Protacio wrote: >> Hello! >> >> Please review another product flag logging change. This one's pretty >> small. Converts TraceMonitorInflation to -Xlog:monitorinflation=debug > > Conversion looks fine. > >> internally, with an alias for the old option. I've again patched in >> Max's alias table code in the arguments.cpp and .hpp files since my >> previous changeset with that code is currently on hold. > > I still have an unanswered question from the other thread about how > the order of options is handled. Primarily whether left-to-right > processing prevails? Yes, it works the same as before the change. E.g. java -XX:+TraceMonitorInflation -XX:-TraceMonitorInflation -version produces no logging. > > I also strongly believe we should be deprecating these flags at the > same time we do the conversion as this is a classic case of > deprecation if ever there was one! > >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8145153/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8145153 > > On the test, if you use the testlibrary you must also @build it. > > Also java -version is sufficient to see some inflating/deflating > happen, and your sample class does nothing to force inflation. Thanks for pointing that out. Rachel > > Thanks, > David > > > >> Testing: passes jck vm tests, JPRT, and RBT quick and noncolo tests >> >> Thank you! >> Rachel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rachel.protacio at oracle.com Fri Dec 11 21:38:35 2015 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Fri, 11 Dec 2015 16:38:35 -0500 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <56686F22.4080104@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> Message-ID: <566B425B.5000002@oracle.com> Hello! An update and updated webrev. I've rewritten the two portions of code that had used ttyLockers to print in one function-call, since there is no locker equivalent in UL, plus the fact that it will be easier for users to look for one message's contents without the decorators interrupting the lines. (And I especially tested that the fix prints the whole line correctly.) As mentioned in the other thread, I will file a separate RFE to deprecate this and other product flags being converted to logging. Since my last iteration was on hold/not reviewed yet, I've simply updated it. http://cr.openjdk.java.net/~rprotacio/8141211.01 Thanks, Rachel On 12/9/2015 1:12 PM, Rachel Protacio wrote: > Hi, > > (Sorry if this sent twice. Thunderbird is acting up.) > > Thanks for the review. Replies inline. > Updated webrev: http://cr.openjdk.java.net/~rprotacio/8141211.01/ > > On 12/8/2015 10:53 PM, David Holmes wrote: >> Hi Rachel, >> >> On 9/12/2015 1:42 AM, Rachel Protacio wrote: >>> Hello, >>> >>> Please review my conversion of -XX:+TraceExceptions to >>> -Xlog:exceptions=info. The existing (product) flag is aliased to the >>> logging flag at the info level. >> >> Q: how does use of ttyLocker map into UL? I see an awful lot of >> multi-line logging blocks that are going to be completely messed up >> without locking! > I assumed that UL worked as-is for these instances, but I will check > in with Marcus. >> >> src/share/vm/opto/runtime.cpp >> >> 1239 ResourceMark rm; >> >> What requires the introduction of the ResourceMark? > A ResourceMark is necessary before using LogHandle output streams. >> >> --- >> >> src/share/vm/runtime/thread.cpp >> >> 2084 if (log_is_enabled(Info, exceptions)) { >> 2085 ResourceMark rm; >> >> An extra leading space has crept in at +2085 >> >> 2087 logstream->print("Async. exception installed at runtime >> exit (" INTPTR_FORMAT ")", p2i(this)); >> 2088 if (has_last_Java_frame()) { >> 2089 frame f = last_frame(); >> 2090 logstream->print(" (pc: " INTPTR_FORMAT " sp: " >> INTPTR_FORMAT " )", p2i(f.pc()), p2i(f.sp())); >> 2091 } >> >> Indention of these lines is wrong at #2088 and #2089 - need an >> additional space. > Thanks for catching these! >> >> 2092 logstream->print_cr(" of type: %s", >> InstanceKlass::cast(_pending_async_exception->klass())->external_name()); >> >> Why did the InstanceKlass::cast need to be introduced ?? > That was a vestige from code before a new changeset at the same line, > i.e. my merging the repo didn't catch this. I've gotten rid of the cast. >> >> --- >> >> test/runtime/CommandLine/TraceExceptionsTest.java >> >> You improved the readability of the source code by breaking the >> @summary over two lines, but IIRC jtreg will write the summary into >> the test log with all the additional spaces you added, as the summary >> extends until the next tag. > Ok, I didn't realize that! I've undone that change. >> >> --- >> >> test/runtime/logging/ExceptionsTest.java >> >> Can you avoid the code duplication please. >> >> Also perhaps you could/should also check there are no logging >> statements present when logging is supposed to be disabled. I'm >> guessing the other logging tests haven't considered this. ?? > Good points. I've added a check. >> >>> If you have any questions on the alias table (in the arguments.cpp and >>> .hpp files), Max will chime in as he is the one who implemented that >>> portion. >> >> Okay some general questions. >> >> First I would expect that aliased logging options are also marked >> deprecated so that we can eventually make them obsolete and remove them. > I'm not sure about this one. Coleen? Max? >> >> Secondly, arguably if someone specifies -XX:-TraceExceptions it >> should disable exception logging - which may have been turned on by >> -Xlog:all. >> >> Which leads to: how does the position of -XX:+/-TraceExceptions >> interact with the position of -Xlog:xxx on the command-line (or the >> other argument introducing mechanisms) ? > Very true. I've added an entry in the alias table to that effect. >> >> src/share/vm/runtime/arguments.cpp >> >> 2743 if(lookup_logging_aliases(option->optionString, >> aliased_logging_option)){ >> >> Need space after "if", and before { > Done. > > Thanks, > Rachel >> >> Thanks, >> David >> ----- >> >> >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8141211/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141211 >>> >>> Testing: jtreg, JPRT, jck vm tests, refworkload performance tests, rbt >>> quick & non-colo tests >>> >>> Thank you! >>> Rachel > From david.holmes at oracle.com Mon Dec 14 04:08:51 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Dec 2015 14:08:51 +1000 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <566B425B.5000002@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> Message-ID: <566E40D3.5060305@oracle.com> Hi Rachel, On 12/12/2015 7:38 AM, Rachel Protacio wrote: > Hello! An update and updated webrev. > > I've rewritten the two portions of code that had used ttyLockers to > print in one function-call, since there is no locker equivalent in UL, > plus the fact that it will be easier for users to look for one message's > contents without the decorators interrupting the lines. (And I > especially tested that the fix prints the whole line correctly.) Sorry I'm still seeing ttyLocker removal and use of multiple logging statements in: src/share/vm/interpreter/bytecodeInterpreter.cpp src/share/vm/interpreter/interpreterRuntime.cpp src/share/vm/opto/runtime.cpp which "two portions of code" did you change? I also note that src/share/vm/runtime/thread.cpp was not using ttyLocker but does have multi-part trace output. > As mentioned in the other thread, I will file a separate RFE to > deprecate this and other product flags being converted to logging. > > Since my last iteration was on hold/not reviewed yet, I've simply > updated it. http://cr.openjdk.java.net/~rprotacio/8141211.01 src/share/vm/c1/c1_Runtime1.cpp Nit in original code: 556 " for thread " INTPTR_FORMAT "", the "" before the comma seems superfluous. Thanks, David > Thanks, > Rachel > > On 12/9/2015 1:12 PM, Rachel Protacio wrote: >> Hi, >> >> (Sorry if this sent twice. Thunderbird is acting up.) >> >> Thanks for the review. Replies inline. >> Updated webrev: http://cr.openjdk.java.net/~rprotacio/8141211.01/ >> >> On 12/8/2015 10:53 PM, David Holmes wrote: >>> Hi Rachel, >>> >>> On 9/12/2015 1:42 AM, Rachel Protacio wrote: >>>> Hello, >>>> >>>> Please review my conversion of -XX:+TraceExceptions to >>>> -Xlog:exceptions=info. The existing (product) flag is aliased to the >>>> logging flag at the info level. >>> >>> Q: how does use of ttyLocker map into UL? I see an awful lot of >>> multi-line logging blocks that are going to be completely messed up >>> without locking! >> I assumed that UL worked as-is for these instances, but I will check >> in with Marcus. >>> >>> src/share/vm/opto/runtime.cpp >>> >>> 1239 ResourceMark rm; >>> >>> What requires the introduction of the ResourceMark? >> A ResourceMark is necessary before using LogHandle output streams. >>> >>> --- >>> >>> src/share/vm/runtime/thread.cpp >>> >>> 2084 if (log_is_enabled(Info, exceptions)) { >>> 2085 ResourceMark rm; >>> >>> An extra leading space has crept in at +2085 >>> >>> 2087 logstream->print("Async. exception installed at runtime >>> exit (" INTPTR_FORMAT ")", p2i(this)); >>> 2088 if (has_last_Java_frame()) { >>> 2089 frame f = last_frame(); >>> 2090 logstream->print(" (pc: " INTPTR_FORMAT " sp: " >>> INTPTR_FORMAT " )", p2i(f.pc()), p2i(f.sp())); >>> 2091 } >>> >>> Indention of these lines is wrong at #2088 and #2089 - need an >>> additional space. >> Thanks for catching these! >>> >>> 2092 logstream->print_cr(" of type: %s", >>> InstanceKlass::cast(_pending_async_exception->klass())->external_name()); >>> >>> >>> Why did the InstanceKlass::cast need to be introduced ?? >> That was a vestige from code before a new changeset at the same line, >> i.e. my merging the repo didn't catch this. I've gotten rid of the cast. >>> >>> --- >>> >>> test/runtime/CommandLine/TraceExceptionsTest.java >>> >>> You improved the readability of the source code by breaking the >>> @summary over two lines, but IIRC jtreg will write the summary into >>> the test log with all the additional spaces you added, as the summary >>> extends until the next tag. >> Ok, I didn't realize that! I've undone that change. >>> >>> --- >>> >>> test/runtime/logging/ExceptionsTest.java >>> >>> Can you avoid the code duplication please. >>> >>> Also perhaps you could/should also check there are no logging >>> statements present when logging is supposed to be disabled. I'm >>> guessing the other logging tests haven't considered this. ?? >> Good points. I've added a check. >>> >>>> If you have any questions on the alias table (in the arguments.cpp and >>>> .hpp files), Max will chime in as he is the one who implemented that >>>> portion. >>> >>> Okay some general questions. >>> >>> First I would expect that aliased logging options are also marked >>> deprecated so that we can eventually make them obsolete and remove them. >> I'm not sure about this one. Coleen? Max? >>> >>> Secondly, arguably if someone specifies -XX:-TraceExceptions it >>> should disable exception logging - which may have been turned on by >>> -Xlog:all. >>> >>> Which leads to: how does the position of -XX:+/-TraceExceptions >>> interact with the position of -Xlog:xxx on the command-line (or the >>> other argument introducing mechanisms) ? >> Very true. I've added an entry in the alias table to that effect. >>> >>> src/share/vm/runtime/arguments.cpp >>> >>> 2743 if(lookup_logging_aliases(option->optionString, >>> aliased_logging_option)){ >>> >>> Need space after "if", and before { >> Done. >> >> Thanks, >> Rachel >>> >>> Thanks, >>> David >>> ----- >>> >>> >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8141211/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141211 >>>> >>>> Testing: jtreg, JPRT, jck vm tests, refworkload performance tests, rbt >>>> quick & non-colo tests >>>> >>>> Thank you! >>>> Rachel >> > From david.holmes at oracle.com Mon Dec 14 04:19:30 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Dec 2015 14:19:30 +1000 Subject: RFR: 8145153: Convert TraceMonitorInflation to Unified Logging In-Reply-To: <566B0ADE.8050105@oracle.com> References: <5669FB00.7070600@oracle.com> <566A1EA0.7080908@oracle.com> <566B0ADE.8050105@oracle.com> Message-ID: <566E4352.20400@oracle.com> Hi Rachel, On 12/12/2015 3:41 AM, Rachel Protacio wrote: > Hi David, > > Thanks for the review! Updated webrev: > http://cr.openjdk.java.net/~rprotacio/8145153.01/ You still aren't building the testlibrary in the test. More below ... > On 12/10/2015 7:53 PM, David Holmes wrote: >> Hi Rachel, >> >> On 11/12/2015 8:21 AM, Rachel Protacio wrote: >>> Hello! >>> >>> Please review another product flag logging change. This one's pretty >>> small. Converts TraceMonitorInflation to -Xlog:monitorinflation=debug >> >> Conversion looks fine. >> >>> internally, with an alias for the old option. I've again patched in >>> Max's alias table code in the arguments.cpp and .hpp files since my >>> previous changeset with that code is currently on hold. >> >> I still have an unanswered question from the other thread about how >> the order of options is handled. Primarily whether left-to-right >> processing prevails? > Yes, it works the same as before the change. E.g. > > java -XX:+TraceMonitorInflation -XX:-TraceMonitorInflation -version > > produces no logging. The question is whether: java -XX:+TraceMonitorInflation -Xlog:exceptions=off produces no logging. I'm not sure if -Xlog options are processed as they appear or whether there is a special parsing phase for them. Thanks, David ----- >> >> I also strongly believe we should be deprecating these flags at the >> same time we do the conversion as this is a classic case of >> deprecation if ever there was one! >> >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8145153/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145153 >> >> On the test, if you use the testlibrary you must also @build it. >> >> Also java -version is sufficient to see some inflating/deflating >> happen, and your sample class does nothing to force inflation. > Thanks for pointing that out. > Rachel >> >> Thanks, >> David >> >> >> >>> Testing: passes jck vm tests, JPRT, and RBT quick and noncolo tests >>> >>> Thank you! >>> Rachel > From harsha.wardhana.b at oracle.com Mon Dec 14 07:15:26 2015 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 14 Dec 2015 12:45:26 +0530 Subject: RFR - JDK-7065236 : To interpret case-insensitive string locale independently Message-ID: <566E6C8E.3020409@oracle.com> Hello, Please review the fix for bug JDK-7065236. Issue : https://bugs.openjdk.java.net/browse/JDK-7065236 Webrev : http://cr.openjdk.java.net/~jbachorik/sponsorship/7065236/webrev.00 In order to fix the bug, below were the list of occurrences that needed to be examined for Locale sensitive case conversions. ./javax/management/modelmbean/DescriptorSupport.java: final String lowerInStr = inStr.toLowerCase(); ---- Yes ./javax/management/modelmbean/DescriptorSupport.java: descriptor.put(entry.getKey().toLowerCase(), entry.getValue()); ---- No ./javax/management/remote/JMXServiceURL.java: serviceURL.substring(protoStart, protoEnd).toLowerCase(); ---- Yes ./javax/management/remote/JMXServiceURL.java: this.protocol = protocol.toLowerCase(); ---- Yes ./javax/management/loading/MLetParser.java: atts.put(att.toLowerCase(), val); ---- Yes ./javax/management/loading/MLetContent.java: return attributes.get(name.toLowerCase()); ---- Private Method. Not required ./com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java: return name.substring(0, offset1).toLowerCase() + ---- No ./com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java: return name.substring(0, offset1).toUpperCase() + ---- No ./com/sun/jmx/mbeanserver/Util.java: hash += names[i].toLowerCase().hashCode(); ---- No The occurrences of case conversions marked as 'Yes' were deemed to be Locale Insensitive and hence only those were fixed. Please review and let me know if any other occurrences marked as 'No' also needs to be fixed. Thanks Harsha -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Mon Dec 14 07:32:49 2015 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 14 Dec 2015 13:02:49 +0530 Subject: RFR : JDK-6744127 - NullPointerException at com.sun.tools.jdi.EventRequestManagerImpl.request Message-ID: <566E70A1.10701@oracle.com> Hi All, Please review the fix for bug, Issue : https://bugs.openjdk.java.net/browse/JDK-6744127 Webrev : http://cr.openjdk.java.net/~jbachorik/sponsorship/6744127/webrev.00 The fix synchronizes access to requestList of EventRequestManagerImpl. Thanks Harsha From marcus.larsson at oracle.com Mon Dec 14 08:43:25 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 14 Dec 2015 09:43:25 +0100 Subject: RFR: 8145153: Convert TraceMonitorInflation to Unified Logging In-Reply-To: <566E4352.20400@oracle.com> References: <5669FB00.7070600@oracle.com> <566A1EA0.7080908@oracle.com> <566B0ADE.8050105@oracle.com> <566E4352.20400@oracle.com> Message-ID: <566E812D.8010405@oracle.com> On 2015-12-14 05:19, David Holmes wrote: > Hi Rachel, > > On 12/12/2015 3:41 AM, Rachel Protacio wrote: >> Hi David, >> >> Thanks for the review! Updated webrev: >> http://cr.openjdk.java.net/~rprotacio/8145153.01/ > > You still aren't building the testlibrary in the test. > > More below ... > >> On 12/10/2015 7:53 PM, David Holmes wrote: >>> Hi Rachel, >>> >>> On 11/12/2015 8:21 AM, Rachel Protacio wrote: >>>> Hello! >>>> >>>> Please review another product flag logging change. This one's pretty >>>> small. Converts TraceMonitorInflation to -Xlog:monitorinflation=debug >>> >>> Conversion looks fine. >>> >>>> internally, with an alias for the old option. I've again patched in >>>> Max's alias table code in the arguments.cpp and .hpp files since my >>>> previous changeset with that code is currently on hold. >>> >>> I still have an unanswered question from the other thread about how >>> the order of options is handled. Primarily whether left-to-right >>> processing prevails? >> Yes, it works the same as before the change. E.g. >> >> java -XX:+TraceMonitorInflation -XX:-TraceMonitorInflation -version >> >> produces no logging. > > The question is whether: > > java -XX:+TraceMonitorInflation -Xlog:exceptions=off > > produces no logging. I'm not sure if -Xlog options are processed as > they appear or whether there is a special parsing phase for them. They are processed as they appear, so it should work fine. Marcus > > Thanks, > David > ----- > >>> >>> I also strongly believe we should be deprecating these flags at the >>> same time we do the conversion as this is a classic case of >>> deprecation if ever there was one! >>> >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8145153/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145153 >>> >>> On the test, if you use the testlibrary you must also @build it. >>> >>> Also java -version is sufficient to see some inflating/deflating >>> happen, and your sample class does nothing to force inflation. >> Thanks for pointing that out. >> Rachel >>> >>> Thanks, >>> David >>> >>> >>> >>>> Testing: passes jck vm tests, JPRT, and RBT quick and noncolo tests >>>> >>>> Thank you! >>>> Rachel >> From marcus.larsson at oracle.com Mon Dec 14 10:13:01 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 14 Dec 2015 11:13:01 +0100 Subject: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration Message-ID: <566E962D.8010107@oracle.com> Hi, Please review the following patch to use a semaphore instead of a mutex for the synchronization of log configuration. Using a mutex requires some parts of the VM to be initialized, whereas the semaphores can be used right from the start. This simplifies the code and allows very early log configuration without special cases for early configuration vs reconfiguration after VM init. Webrev: http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8145083 Thanks, Marcus From jaroslav.bachorik at oracle.com Mon Dec 14 12:36:13 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 14 Dec 2015 13:36:13 +0100 Subject: RFR - JDK-7065236 : To interpret case-insensitive string locale independently In-Reply-To: <566E6C8E.3020409@oracle.com> References: <566E6C8E.3020409@oracle.com> Message-ID: <566EB7BD.8020409@oracle.com> On 14.12.2015 08:15, Harsha Wardhana B wrote: > Hello, > > Please review the fix for bug JDK-7065236. > > Issue : > https://bugs.openjdk.java.net/browse/JDK-7065236 > Webrev : http://cr.openjdk.java.net/~jbachorik/sponsorship/7065236/webrev.00 > > In order to fix the bug, below were the list of occurrences that needed > to be examined for Locale sensitive case conversions. > > ./javax/management/modelmbean/DescriptorSupport.java: final String > lowerInStr = inStr.toLowerCase(); ---- Yes > ./javax/management/modelmbean/DescriptorSupport.java: > descriptor.put(entry.getKey().toLowerCase(), entry.getValue()); ---- No > ./javax/management/remote/JMXServiceURL.java: > serviceURL.substring(protoStart, protoEnd).toLowerCase(); ---- Yes > ./javax/management/remote/JMXServiceURL.java: this.protocol = > protocol.toLowerCase(); ---- Yes > ./javax/management/loading/MLetParser.java: atts.put(att.toLowerCase(), > val); ---- Yes > ./javax/management/loading/MLetContent.java: return > attributes.get(name.toLowerCase()); ---- Private > Method. Not required > > ./com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java: return > name.substring(0, offset1).toLowerCase() + ---- No > ./com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java: return > name.substring(0, offset1).toUpperCase() + ---- No > ./com/sun/jmx/mbeanserver/Util.java: hash += > names[i].toLowerCase().hashCode(); ---- No > > The occurrences of case conversions marked as 'Yes' were deemed to be > Locale Insensitive and hence only those were fixed. Please review and > let me know if any other occurrences marked as 'No' also needs to be fixed. The fix looks good. -JB- > > Thanks > Harsha > > From jaroslav.bachorik at oracle.com Mon Dec 14 12:37:30 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 14 Dec 2015 13:37:30 +0100 Subject: RFR : JDK-6744127 - NullPointerException at com.sun.tools.jdi.EventRequestManagerImpl.request In-Reply-To: <566E70A1.10701@oracle.com> References: <566E70A1.10701@oracle.com> Message-ID: <566EB80A.3040508@oracle.com> Hi, On 14.12.2015 08:32, Harsha Wardhana B wrote: > Hi All, > > Please review the fix for bug, > > Issue : https://bugs.openjdk.java.net/browse/JDK-6744127 > Webrev : > http://cr.openjdk.java.net/~jbachorik/sponsorship/6744127/webrev.00 > > The fix synchronizes access to requestList of EventRequestManagerImpl. Looks good! Don't forget to add the 'noreg-hard' label to the issue. -JB- > > Thanks > Harsha > From david.holmes at oracle.com Mon Dec 14 12:53:09 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Dec 2015 22:53:09 +1000 Subject: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration In-Reply-To: <566E962D.8010107@oracle.com> References: <566E962D.8010107@oracle.com> Message-ID: <566EBBB5.9070403@oracle.com> Hi Marcus, Looks good! On 14/12/2015 8:13 PM, Marcus Larsson wrote: > Hi, > > Please review the following patch to use a semaphore instead of a mutex > for the synchronization of log configuration. Using a mutex requires > some parts of the VM to be initialized, whereas the semaphores can be > used right from the start. Not completely true as the timed-wait requires some OS initialization for clocks, but your usage seems to be safe. > This simplifies the code and allows very > early log configuration without special cases for early configuration vs > reconfiguration after VM init. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00/ I can't verify the correctness of reducing the scope of the "locking" (it seems reasonable), but certainly the smaller the critical section the better. The only real comment I have is that a SemaphoreAcquirer utility class would make things a bit neater and ensure you can't forget to signal. Thanks, David > Issue: > https://bugs.openjdk.java.net/browse/JDK-8145083 > > Thanks, > Marcus From ivan.gerasimov at oracle.com Mon Dec 14 14:09:42 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 14 Dec 2015 17:09:42 +0300 Subject: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ... Message-ID: <566ECDA6.1030404@oracle.com> Hello! There was a timeout observed in os_windows.cpp at the line 3945 res = WaitForMultipleObjects(MAXIMUM_WAIT_OBJECTS, handles, FALSE, EXIT_TIMEOUT); This means there were more than 64 threads exiting at the same time and none of the first 64 threads could make any progress during 5 minutes. Sigh. To address this issue I suggest two things: 1) Increase the size of the queue of exiting threads. We'll still have to wait for only the first 64 threads, if the queue is exhausted. But the chances we hit this condition are greatly reduced. 2) Raise process_exiting flag earlier, i.e. before trying to enter the critical section. This should decrease the number of threads, contending for a slot in the 'handles' array during the process exit. Additionally, it is proposed to suspend all the threads, but the one which raised the flag 'process_exiting'. It would be important in a case, when two threads are about to call exit() concurrently. Otherwise, a race could be faced, if the first thread is waiting for all the registered handles, while the second one skips the critical section altogether and calls ::exit(). Build went fine on all platforms. The JTREG tests from 'hotspot' subset all pass. Would you please help review the proposed fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8145127 WEBREV: http://cr.openjdk.java.net/~igerasim/8145127/00/webrev/ Sincerely yours, Ivan From marcus.larsson at oracle.com Mon Dec 14 14:53:44 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 14 Dec 2015 15:53:44 +0100 Subject: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration In-Reply-To: <566E962D.8010107@oracle.com> References: <566E962D.8010107@oracle.com> Message-ID: <566ED7F8.4090204@oracle.com> Hi, New webrev: http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01/ Incremental: http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00-01/ Changes: * Introduced the ConfigurationLocker class for automatic wait/signal in constructor/destructor just like a MutexLocker. * Added an assert to verify that the "lock" is held by the current thread when calling configure_output. * Made the config-string functions in LogOutput protected and LogConfiguration a friend of LogOutput to prevent incorrect usage of these functions. These functions should typically only be used inside configure_output, which now ensures that the lock is held. Thanks, Marcus On 2015-12-14 11:13, Marcus Larsson wrote: > Hi, > > Please review the following patch to use a semaphore instead of a > mutex for the synchronization of log configuration. Using a mutex > requires some parts of the VM to be initialized, whereas the > semaphores can be used right from the start. This simplifies the code > and allows very early log configuration without special cases for > early configuration vs reconfiguration after VM init. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8145083 > > Thanks, > Marcus From marcus.larsson at oracle.com Mon Dec 14 14:54:07 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 14 Dec 2015 15:54:07 +0100 Subject: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration In-Reply-To: <566EBBB5.9070403@oracle.com> References: <566E962D.8010107@oracle.com> <566EBBB5.9070403@oracle.com> Message-ID: <566ED80F.2070509@oracle.com> Hi David, On 2015-12-14 13:53, David Holmes wrote: > Hi Marcus, > > Looks good! Thanks! > > On 14/12/2015 8:13 PM, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to use a semaphore instead of a mutex >> for the synchronization of log configuration. Using a mutex requires >> some parts of the VM to be initialized, whereas the semaphores can be >> used right from the start. > > Not completely true as the timed-wait requires some OS initialization > for clocks, but your usage seems to be safe. Alright, thanks for checking. I'm happy as long as it works in time for argument parsing. > >> This simplifies the code and allows very >> early log configuration without special cases for early configuration vs >> reconfiguration after VM init. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00/ > > I can't verify the correctness of reducing the scope of the "locking" > (it seems reasonable), but certainly the smaller the critical section > the better. > > The only real comment I have is that a SemaphoreAcquirer utility class > would make things a bit neater and ensure you can't forget to signal. I've received similar feedback from others regarding a MutexLocker-like stack object for this, so I've modified the patch to use such instead. Thanks, Marcus > > Thanks, > David > >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8145083 >> >> Thanks, >> Marcus From marcus.larsson at oracle.com Mon Dec 14 15:30:55 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 14 Dec 2015 16:30:55 +0100 Subject: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration In-Reply-To: <566ED7F8.4090204@oracle.com> References: <566E962D.8010107@oracle.com> <566ED7F8.4090204@oracle.com> Message-ID: <566EE0AF.9010905@oracle.com> Hi again, Made some changes to the patch after feedback from Markus Gr?nlund. The ConfigurationLocker and the semaphore have been moved out of the LogConfiguration.hpp and into the .cpp instead. The lock is only used internally by the LogConfiguration so this makes sense. It simplifies the LogConfiguration interface and hides the details of the locking under the hood. New webrev: http://cr.openjdk.java.net/~mlarsson/8145083/webrev.02/ Incremental: http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01-02/ Thanks, Marcus On 2015-12-14 15:53, Marcus Larsson wrote: > Hi, > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00-01/ > > Changes: > * Introduced the ConfigurationLocker class for automatic wait/signal > in constructor/destructor just like a MutexLocker. > * Added an assert to verify that the "lock" is held by the current > thread when calling configure_output. > * Made the config-string functions in LogOutput protected and > LogConfiguration a friend of LogOutput to prevent incorrect usage of > these functions. These functions should typically only be used inside > configure_output, which now ensures that the lock is held. > > Thanks, > Marcus > > > On 2015-12-14 11:13, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to use a semaphore instead of a >> mutex for the synchronization of log configuration. Using a mutex >> requires some parts of the VM to be initialized, whereas the >> semaphores can be used right from the start. This simplifies the code >> and allows very early log configuration without special cases for >> early configuration vs reconfiguration after VM init. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8145083 >> >> Thanks, >> Marcus > From andreas.eriksson at oracle.com Mon Dec 14 15:38:16 2015 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Mon, 14 Dec 2015 16:38:16 +0100 Subject: RFR (M): 8129419: heapDumper.cpp: assert(length_in_bytes > 0) failed: nothing to copy Message-ID: <566EE268.1010803@oracle.com> Hi, Please review this fix for dumping of long arrays, and general cleanup of types in heapDumper.cpp. Problem: At several places in heapDumper.cpp overflows could happen when dumping long arrays. Also the hprof format uses an u4 as a record length field, but arrays can be longer than that (counted in bytes). Fix: Many types that were previously signed are changed to equivalent unsigned types and/or to a larger type to prevent overflow. The bulk of the change though is the addition of calculate_array_max_length, which for a given array returns the number of elements we can dump. That length is then used to truncate arrays that are too long. Whenever an array is truncated a warning is printed: Java HotSpot(TM) 64-Bit Server VM warning: cannot dump array of type object[] with length 1,073,741,823; truncating to length 536,870,908 Much of the rest of the change is moving functions needed by calculate_array_max_length to the DumpWriter or DumperSupport class so that they can be accessed. Added a test that relies on the hprof parser, which also had a couple of overflow problems (top repo changes). I've also run this change against a couple of other tests, but they are problematic in JPRT because they are using large heaps and lots of disk. Bug: 8129419: heapDumper.cpp: assert(length_in_bytes > 0) failed: nothing to copy https://bugs.openjdk.java.net/browse/JDK-8129419 Also fixed in this change is the problems seen in these two bugs: 8133317: Integer overflow in heapDumper.cpp leads to corrupt HPROF dumps https://bugs.openjdk.java.net/browse/JDK-8133317 8144732: VM_HeapDumper hits assert with bad dump_len https://bugs.openjdk.java.net/browse/JDK-8144732 Webrev: Top repo: http://cr.openjdk.java.net/~aeriksso/8129419/webrev.00/jdk9-hs-rt/ Hotspot: http://cr.openjdk.java.net/~aeriksso/8129419/webrev.00/hotspot/ Regards, Andreas From jaroslav.bachorik at oracle.com Mon Dec 14 16:55:42 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 14 Dec 2015 17:55:42 +0100 Subject: RFR 8142398: IllegalAccessException Class sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access a member of class java.lang.management.ManagementFactory (module java.management) Message-ID: <566EF48E.3050300@oracle.com> Please, review the following change Issue : https://bugs.openjdk.java.net/browse/JDK-8138677 Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00 The problem is that the class UsageTrackerClient is accessing RuntimeMXBean.getInputArguments() method via reflection to avoid static dependency. However, with functional module boundaries this fails. Since the functionality provided by RuntimeMXBean.getInputArguments() is not, in fact, specific to the management subsystem, it makes sense to move it out of jmm.h to jvm.h Full suite of SVC tests was run against this change successfully on all platforms. Thanks, -JB- From dmitry.samersoff at oracle.com Mon Dec 14 17:30:47 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 14 Dec 2015 20:30:47 +0300 Subject: RFR (M): 8129419: heapDumper.cpp: assert(length_in_bytes > 0) failed: nothing to copy In-Reply-To: <566EE268.1010803@oracle.com> References: <566EE268.1010803@oracle.com> Message-ID: <566EFCC7.6010106@oracle.com> Andreas, Nice cleanup. Some generic comments below. 1. It would be excellent if you can split webrev into two parts, one part with types cleanup and other part with array truncation related changes or ever push these changes separately as it address different problems. Type cleanup could be reviewed quickly, but review of array truncation requires some time. (We already have two different CRs: JDK-8129419 for type cleanup and JDK-8144732 for array truncation) 2. it might be better to use size_t and jlong (or julong) across all file and get rid of all other types with a few exclusion. 3. Each assert costs some time in nightly testing, so we probably don't need as much asserts. 4. write_internal: There are couple of cases where ::write writes less bytes than requested and doesn't return -1. So we should check if ::write returns a value less that len and if it happens deal with errno - either repeat entire write attempt(EINTR/EAGAIN) or abort writing. 5. we should handle zero-length array in calculate_array_max_length - it's a legitimate case 6. max_juint is less than SegmentedHeapDumpThreshold so non-segmented heapdump can't contain huge array and it's better to check for segmented dump before any other checks. -Dmitry On 2015-12-14 18:38, Andreas Eriksson wrote: > Hi, > > Please review this fix for dumping of long arrays, and general cleanup > of types in heapDumper.cpp. > > Problem: > At several places in heapDumper.cpp overflows could happen when dumping > long arrays. > Also the hprof format uses an u4 as a record length field, but arrays > can be longer than that (counted in bytes). > > Fix: > Many types that were previously signed are changed to equivalent > unsigned types and/or to a larger type to prevent overflow. > The bulk of the change though is the addition of > calculate_array_max_length, which for a given array returns the number > of elements we can dump. That length is then used to truncate arrays > that are too long. > Whenever an array is truncated a warning is printed: > Java HotSpot(TM) 64-Bit Server VM warning: cannot dump array of type > object[] with length 1,073,741,823; truncating to length 536,870,908 > > Much of the rest of the change is moving functions needed by > calculate_array_max_length to the DumpWriter or DumperSupport class so > that they can be accessed. > > Added a test that relies on the hprof parser, which also had a couple of > overflow problems (top repo changes). > I've also run this change against a couple of other tests, but they are > problematic in JPRT because they are using large heaps and lots of disk. > > Bug: > 8129419: heapDumper.cpp: assert(length_in_bytes > 0) failed: nothing to > copy > https://bugs.openjdk.java.net/browse/JDK-8129419 > > Also fixed in this change is the problems seen in these two bugs: > 8133317: Integer overflow in heapDumper.cpp leads to corrupt HPROF dumps > https://bugs.openjdk.java.net/browse/JDK-8133317 > > 8144732: VM_HeapDumper hits assert with bad dump_len > https://bugs.openjdk.java.net/browse/JDK-8144732 > > Webrev: > Top repo: > http://cr.openjdk.java.net/~aeriksso/8129419/webrev.00/jdk9-hs-rt/ > Hotspot: http://cr.openjdk.java.net/~aeriksso/8129419/webrev.00/hotspot/ > > Regards, > Andreas -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From andreas.eriksson at oracle.com Mon Dec 14 18:34:51 2015 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Mon, 14 Dec 2015 19:34:51 +0100 Subject: RFR (M): 8129419: heapDumper.cpp: assert(length_in_bytes > 0) failed: nothing to copy In-Reply-To: <566EFCC7.6010106@oracle.com> References: <566EE268.1010803@oracle.com> <566EFCC7.6010106@oracle.com> Message-ID: <566F0BCB.3000407@oracle.com> Hi Dmitry, thanks for looking at this. On 2015-12-14 18:30, Dmitry Samersoff wrote: > Andreas, > > Nice cleanup. > > Some generic comments below. > > 1. It would be excellent if you can split webrev into two parts, one > part with types cleanup and other part with array truncation related > changes or ever push these changes separately as it address different > problems. > > Type cleanup could be reviewed quickly, but review of array truncation > requires some time. > > (We already have two different CRs: JDK-8129419 for type cleanup and > JDK-8144732 for array truncation) Yes, that's a good point. > > > 2. > it might be better to use size_t and jlong (or julong) across all file > and get rid of all other types with a few exclusion. I'll see what I can do, and we can look at it closer once I've split the type changes into a separate webrev. > 3. > Each assert costs some time in nightly testing, so we probably don't > need as much asserts. Alright. > > 4. write_internal: > > There are couple of cases where ::write writes less bytes than > requested and doesn't return -1. > So we should check if ::write returns a value less that len and if it > happens deal with errno - either repeat entire write > attempt(EINTR/EAGAIN) or abort writing. Actually, I meant to ask about that, but forgot: I tried using os::write, which handles EINTR/EAGAIN if necessary (depending on platform), but Solaris has an assert that fails: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/5a42c1dde332/src/os/solaris/vm/os_solaris.cpp#l5692 It checks that os::write is called by a JavaThread that is in_native, which we are not, since we are in the VM_thread doing a safepoint_op. Does anyone know if that assert is really needed? It's only done for Solaris. > > 5. we should handle zero-length array in calculate_array_max_length - > it's a legitimate case Not sure what you mean here, I believe it does handle zero-length arrays. It should just fall through without taking any of the if-clauses. (Or do you mean that I should add a return immediately at the top if length is zero?) > 6. max_juint is less than SegmentedHeapDumpThreshold so non-segmented > heapdump can't contain huge array and it's better to check for segmented > dump before any other checks. Correct me if I'm wrong here, but SegmentedHeapDumpThreshold could in theory be set so that we have a non-segmented heap dump while still having huge arrays. Not sure if this is worth taking into account, since it most likely would lead to other problems as well, and the flag is develop only, so it can't happen in product builds. What do you think would be best to do here? - Andreas > > -Dmitry > > > On 2015-12-14 18:38, Andreas Eriksson wrote: >> Hi, >> >> Please review this fix for dumping of long arrays, and general cleanup >> of types in heapDumper.cpp. >> >> Problem: >> At several places in heapDumper.cpp overflows could happen when dumping >> long arrays. >> Also the hprof format uses an u4 as a record length field, but arrays >> can be longer than that (counted in bytes). >> >> Fix: >> Many types that were previously signed are changed to equivalent >> unsigned types and/or to a larger type to prevent overflow. >> The bulk of the change though is the addition of >> calculate_array_max_length, which for a given array returns the number >> of elements we can dump. That length is then used to truncate arrays >> that are too long. >> Whenever an array is truncated a warning is printed: >> Java HotSpot(TM) 64-Bit Server VM warning: cannot dump array of type >> object[] with length 1,073,741,823; truncating to length 536,870,908 >> >> Much of the rest of the change is moving functions needed by >> calculate_array_max_length to the DumpWriter or DumperSupport class so >> that they can be accessed. >> >> Added a test that relies on the hprof parser, which also had a couple of >> overflow problems (top repo changes). >> I've also run this change against a couple of other tests, but they are >> problematic in JPRT because they are using large heaps and lots of disk. >> >> Bug: >> 8129419: heapDumper.cpp: assert(length_in_bytes > 0) failed: nothing to >> copy >> https://bugs.openjdk.java.net/browse/JDK-8129419 >> >> Also fixed in this change is the problems seen in these two bugs: >> 8133317: Integer overflow in heapDumper.cpp leads to corrupt HPROF dumps >> https://bugs.openjdk.java.net/browse/JDK-8133317 >> >> 8144732: VM_HeapDumper hits assert with bad dump_len >> https://bugs.openjdk.java.net/browse/JDK-8144732 >> >> Webrev: >> Top repo: >> http://cr.openjdk.java.net/~aeriksso/8129419/webrev.00/jdk9-hs-rt/ >> Hotspot: http://cr.openjdk.java.net/~aeriksso/8129419/webrev.00/hotspot/ >> >> Regards, >> Andreas > From markus.gronlund at oracle.com Mon Dec 14 20:53:24 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Mon, 14 Dec 2015 12:53:24 -0800 (PST) Subject: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration In-Reply-To: <566EE0AF.9010905@oracle.com> References: <566E962D.8010107@oracle.com> <566ED7F8.4090204@oracle.com> <566EE0AF.9010905@oracle.com> Message-ID: Hi Marcus, Thanks for updating the patch. I think you could also move the lock representation, i.e the Semaphore to become a (static) field inside the ConfigurationLocker class - this since you want all entry/exits to go through instances of this object. I know that the other MutexLocker's don't aggregate their lock resource but rather take them as pointer in their constructors. However, I don?t think emulating that behavior is paramount here, so if the semaphore moves into the ConfigurationLocker, another name (for discernment against the other *Lockers) could possibly be used - for example: "ConfigurationLock" which is generic enough for the abstraction letting you change how locking is done underneath should you need to. Thanks Markus -----Original Message----- From: Marcus Larsson Sent: den 14 december 2015 16:31 To: serviceability-dev at openjdk.java.net Cc: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration Hi again, Made some changes to the patch after feedback from Markus Gr?nlund. The ConfigurationLocker and the semaphore have been moved out of the LogConfiguration.hpp and into the .cpp instead. The lock is only used internally by the LogConfiguration so this makes sense. It simplifies the LogConfiguration interface and hides the details of the locking under the hood. New webrev: http://cr.openjdk.java.net/~mlarsson/8145083/webrev.02/ Incremental: http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01-02/ Thanks, Marcus On 2015-12-14 15:53, Marcus Larsson wrote: > Hi, > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00-01/ > > Changes: > * Introduced the ConfigurationLocker class for automatic wait/signal > in constructor/destructor just like a MutexLocker. > * Added an assert to verify that the "lock" is held by the current > thread when calling configure_output. > * Made the config-string functions in LogOutput protected and > LogConfiguration a friend of LogOutput to prevent incorrect usage of > these functions. These functions should typically only be used inside > configure_output, which now ensures that the lock is held. > > Thanks, > Marcus > > > On 2015-12-14 11:13, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to use a semaphore instead of a >> mutex for the synchronization of log configuration. Using a mutex >> requires some parts of the VM to be initialized, whereas the >> semaphores can be used right from the start. This simplifies the code >> and allows very early log configuration without special cases for >> early configuration vs reconfiguration after VM init. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8145083 >> >> Thanks, >> Marcus > From kim.barrett at oracle.com Tue Dec 15 01:17:50 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 14 Dec 2015 20:17:50 -0500 Subject: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration In-Reply-To: <566ED7F8.4090204@oracle.com> References: <566E962D.8010107@oracle.com> <566ED7F8.4090204@oracle.com> Message-ID: <06B981B8-F7A4-44A3-8BF4-4EFECE21AEB5@oracle.com> On Dec 14, 2015, at 9:53 AM, Marcus Larsson wrote: > > Hi, > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00-01/ One minor nit: ------------------------------------------------------------------------------ src/share/vm/logging/logConfiguration.hpp 72 class ConfigurationLocker { Shouldn't this be derived from StackObj? ------------------------------------------------------------------------------ From david.holmes at oracle.com Tue Dec 15 05:41:43 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2015 15:41:43 +1000 Subject: RFR 8142398: IllegalAccessException Class sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access a member of class java.lang.management.ManagementFactory (module java.management) In-Reply-To: <566EF48E.3050300@oracle.com> References: <566EF48E.3050300@oracle.com> Message-ID: <566FA817.3080908@oracle.com> Hi Jaroslav, This movement of functionality seems okay to me. And good to see the JDK 6 code removed :) Thanks, David On 15/12/2015 2:55 AM, Jaroslav Bachorik wrote: > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8138677 > Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00 > > The problem is that the class UsageTrackerClient is accessing > RuntimeMXBean.getInputArguments() method via reflection to avoid static > dependency. However, with functional module boundaries this fails. > > Since the functionality provided by RuntimeMXBean.getInputArguments() is > not, in fact, specific to the management subsystem, it makes sense to > move it out of jmm.h to jvm.h > > Full suite of SVC tests was run against this change successfully on all > platforms. > > > Thanks, > > -JB- From mandy.chung at oracle.com Tue Dec 15 05:57:59 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Dec 2015 21:57:59 -0800 Subject: RFR 8142398: IllegalAccessException Class sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access a member of class java.lang.management.ManagementFactory (module java.management) In-Reply-To: <566EF48E.3050300@oracle.com> References: <566EF48E.3050300@oracle.com> Message-ID: <98F38847-D110-45CB-9E64-B38B41C56444@oracle.com> > On Dec 14, 2015, at 8:55 AM, Jaroslav Bachorik wrote: > > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8138677 > Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00 > > The problem is that the class UsageTrackerClient is accessing RuntimeMXBean.getInputArguments() method via reflection to avoid static dependency. However, with functional module boundaries this fails. > > Since the functionality provided by RuntimeMXBean.getInputArguments() is not, in fact, specific to the management subsystem, it makes sense to move it out of jmm.h to jvm.h > This change looks okay. Mandy From david.holmes at oracle.com Tue Dec 15 06:31:23 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2015 16:31:23 +1000 Subject: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ... In-Reply-To: <566ECDA6.1030404@oracle.com> References: <566ECDA6.1030404@oracle.com> Message-ID: <566FB3BB.4050709@oracle.com> I really wish we had some view inside windows to see exactly what is going wrong here. :( On 15/12/2015 12:09 AM, Ivan Gerasimov wrote: > Hello! > > There was a timeout observed in os_windows.cpp at the line > 3945 res = WaitForMultipleObjects(MAXIMUM_WAIT_OBJECTS, > handles, FALSE, EXIT_TIMEOUT); > > This means there were more than 64 threads exiting at the same time and > none of the first 64 threads could make any progress during 5 minutes. > Sigh. > > To address this issue I suggest two things: > 1) > Increase the size of the queue of exiting threads. > We'll still have to wait for only the first 64 threads, if the queue is > exhausted. > But the chances we hit this condition are greatly reduced. > > 2) > Raise process_exiting flag earlier, i.e. before trying to enter the > critical section. > This should decrease the number of threads, contending for a slot in the > 'handles' array during the process exit. > > Additionally, it is proposed to suspend all the threads, but the one > which raised the flag 'process_exiting'. > It would be important in a case, when two threads are about to call > exit() concurrently. > Otherwise, a race could be faced, if the first thread is waiting for all > the registered handles, while the second one skips the critical section > altogether and calls ::exit(). > > Build went fine on all platforms. The JTREG tests from 'hotspot' subset > all pass. > > Would you please help review the proposed fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8145127 > WEBREV: http://cr.openjdk.java.net/~igerasim/8145127/00/webrev/ Can't quite get my head round the whole strategy, but in this loop: 4033 while (pr_ex != curr_id) { pr_ex is never updated! David ----- > Sincerely yours, > Ivan > From Alan.Bateman at oracle.com Tue Dec 15 07:03:21 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Dec 2015 07:03:21 +0000 Subject: RFR 8142398: IllegalAccessException Class sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access a member of class java.lang.management.ManagementFactory (module java.management) In-Reply-To: <566EF48E.3050300@oracle.com> References: <566EF48E.3050300@oracle.com> Message-ID: <566FBB39.8010806@oracle.com> On 14/12/2015 16:55, Jaroslav Bachorik wrote: > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8138677 > Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00 > > The problem is that the class UsageTrackerClient is accessing > RuntimeMXBean.getInputArguments() method via reflection to avoid > static dependency. However, with functional module boundaries this fails. > > Since the functionality provided by RuntimeMXBean.getInputArguments() > is not, in fact, specific to the management subsystem, it makes sense > to move it out of jmm.h to jvm.h Make sense to me too and the changes look okay. One small thing is that make/share/makefiles/mapfile-vers seems to list the JVM_ functions in alphabetic order, I assume you want to preserve that convention. -Alan. From serguei.spitsyn at oracle.com Tue Dec 15 08:01:16 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 15 Dec 2015 00:01:16 -0800 Subject: RFR : JDK-6744127 - NullPointerException at com.sun.tools.jdi.EventRequestManagerImpl.request In-Reply-To: <566E70A1.10701@oracle.com> References: <566E70A1.10701@oracle.com> Message-ID: <566FC8CC.8030109@oracle.com> Hi Harsha, The fix looks good in general. If I understand correctly, any invoke of the requestList().add(), requestList().remove() or requestList().clear() will be implicitly synchronized on the list object. There only place left where we still need an explicit synchronized statement is the iteration over the list in the body of the method: EventRequest request(int eventCmd, int requestId); I have some minor comments, though. The comment at the line 936 needs a dot at the end. A space is needed after the keywords "synchronized", "while" and "if" (lines: 943, 945 and 947). The space is not needed at the line 946 after the cast. Also, I'd use the for-loop instead of while-loop like this: for (EventRequestImpl er: rl) { if (er.id == requestId) { return er; } } But I leave it up to to you if you like to keep your variant. What tests did you run to make sure the fix does not brake anything? I'd recommend to run the JTreg com/sun/jdi tests and the co-located nsk.jdi.testlist tests. If you already done so, could you, please, share the results? Thank you for fixing this bug! Serguei On 12/13/15 23:32, Harsha Wardhana B wrote: > Hi All, > > Please review the fix for bug, > > Issue : https://bugs.openjdk.java.net/browse/JDK-6744127 > Webrev : > http://cr.openjdk.java.net/~jbachorik/sponsorship/6744127/webrev.00 > > The fix synchronizes access to requestList of EventRequestManagerImpl. > > Thanks > Harsha > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Tue Dec 15 08:16:52 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 15 Dec 2015 09:16:52 +0100 Subject: RFR 8142398: IllegalAccessException Class sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access a member of class java.lang.management.ManagementFactory (module java.management) In-Reply-To: <566FBB39.8010806@oracle.com> References: <566EF48E.3050300@oracle.com> <566FBB39.8010806@oracle.com> Message-ID: <566FCC74.3010101@oracle.com> On 15.12.2015 08:03, Alan Bateman wrote: > > > On 14/12/2015 16:55, Jaroslav Bachorik wrote: >> Please, review the following change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8138677 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00 >> >> The problem is that the class UsageTrackerClient is accessing >> RuntimeMXBean.getInputArguments() method via reflection to avoid >> static dependency. However, with functional module boundaries this fails. >> >> Since the functionality provided by RuntimeMXBean.getInputArguments() >> is not, in fact, specific to the management subsystem, it makes sense >> to move it out of jmm.h to jvm.h > Make sense to me too and the changes look okay. One small thing is that > make/share/makefiles/mapfile-vers seems to list the JVM_ functions in > alphabetic order, I assume you want to preserve that convention. Sure. I will update this before pushing. Slipped my attention - I pasted it there like JVM_GetInputArguments and then renamed it :( Thanks for catching this. -JB- > > -Alan. From kubota.yuji at gmail.com Tue Dec 15 08:23:59 2015 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Tue, 15 Dec 2015 17:23:59 +0900 Subject: HSDB could not terminate when launched on CLI. Message-ID: Hi all, When I ran HSDB by jhsdb on CLI i.e. without x11 display, HSDB could not terminate after throwing HeadlessException. HSDB starts WorkerThread before making the JFrame. If we run HSDB on CLI, HSDB throws HeadlessException when makes the JFrame. Thus, the WorkerThread has never shutdown, then HSDB can not terminate. ----- Exception in thread "main" java.awt.HeadlessException: No X11 DISPLAY variable was set, but this program performed an operation which requires it. at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:205) at java.awt.Window.(Window.java:535) at java.awt.Frame.(Frame.java:422) at javax.swing.JFrame.(JFrame.java:224) at sun.jvm.hotspot.HSDB.run(HSDB.java:140) at sun.jvm.hotspot.HSDB.main(HSDB.java:53) at sun.jvm.hotspot.SALauncher.runHSDB(SALauncher.java:167) at sun.jvm.hotspot.SALauncher.main(SALauncher.java:339) ## Waiting for the shutdown of WorkerThread forever... ### ----- I have created a patch from jdk9/dev/hotspot (changeset: 9625:de592ea5f7ba) as below. Please review it ! diff --git a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java --- a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java +++ b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java @@ -137,15 +137,16 @@ return; } + // Make frame at first, then initialize agent. + frame = new JFrame("HSDB - HotSpot Debugger"); + frame.setSize(800, 600); + frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE); + agent = new HotSpotAgent(); workerThread = new WorkerThread(); attachMenuItems = new java.util.ArrayList(); detachMenuItems = new java.util.ArrayList(); - frame = new JFrame("HSDB - HotSpot Debugger"); - frame.setSize(800, 600); - frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE); - JMenuBar menuBar = new JMenuBar(); // Thanks, Yuji From dmitry.samersoff at oracle.com Tue Dec 15 09:11:32 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 15 Dec 2015 12:11:32 +0300 Subject: HSDB could not terminate when launched on CLI. In-Reply-To: References: Message-ID: <566FD944.4000002@oracle.com> Yuji, I'll take a look. -Dmitry On 2015-12-15 11:23, KUBOTA Yuji wrote: > Hi all, > > When I ran HSDB by jhsdb on CLI i.e. without x11 display, HSDB could > not terminate after throwing HeadlessException. > > HSDB starts WorkerThread before making the JFrame. If we run HSDB on > CLI, HSDB throws HeadlessException when makes the JFrame. Thus, the > WorkerThread has never shutdown, then HSDB can not terminate. > > ----- > Exception in thread "main" java.awt.HeadlessException: > No X11 DISPLAY variable was set, but this program performed an > operation which requires it. > at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:205) > at java.awt.Window.(Window.java:535) > at java.awt.Frame.(Frame.java:422) > at javax.swing.JFrame.(JFrame.java:224) > at sun.jvm.hotspot.HSDB.run(HSDB.java:140) > at sun.jvm.hotspot.HSDB.main(HSDB.java:53) > at sun.jvm.hotspot.SALauncher.runHSDB(SALauncher.java:167) > at sun.jvm.hotspot.SALauncher.main(SALauncher.java:339) > ## Waiting for the shutdown of WorkerThread forever... ### > ----- > > I have created a patch from jdk9/dev/hotspot (changeset: > 9625:de592ea5f7ba) as below. Please review it ! > > diff --git a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java > b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java > --- a/agent/src/share/classes/sun/jvm/hotspot/HSDB.java > +++ b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java > @@ -137,15 +137,16 @@ > return; > } > > + // Make frame at first, then initialize agent. > + frame = new JFrame("HSDB - HotSpot Debugger"); > + frame.setSize(800, 600); > + frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE); > + > agent = new HotSpotAgent(); > workerThread = new WorkerThread(); > attachMenuItems = new java.util.ArrayList(); > detachMenuItems = new java.util.ArrayList(); > > - frame = new JFrame("HSDB - HotSpot Debugger"); > - frame.setSize(800, 600); > - frame.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE); > - > JMenuBar menuBar = new JMenuBar(); > > // > > > Thanks, > Yuji > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From marcus.larsson at oracle.com Tue Dec 15 09:18:49 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 15 Dec 2015 10:18:49 +0100 Subject: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration In-Reply-To: <06B981B8-F7A4-44A3-8BF4-4EFECE21AEB5@oracle.com> References: <566E962D.8010107@oracle.com> <566ED7F8.4090204@oracle.com> <06B981B8-F7A4-44A3-8BF4-4EFECE21AEB5@oracle.com> Message-ID: <566FDAF9.8040205@oracle.com> Hi Kim, On 2015-12-15 02:17, Kim Barrett wrote: > On Dec 14, 2015, at 9:53 AM, Marcus Larsson wrote: >> Hi, >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00-01/ > One minor nit: > > ------------------------------------------------------------------------------ > src/share/vm/logging/logConfiguration.hpp > 72 class ConfigurationLocker { > > Shouldn't this be derived from StackObj? You're right. I resolved this in the latest webrev. Thanks, Marcus > > ------------------------------------------------------------------------------ > From erik.joelsson at oracle.com Tue Dec 15 09:21:14 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 15 Dec 2015 10:21:14 +0100 Subject: RFR 8142398: IllegalAccessException Class sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access a member of class java.lang.management.ManagementFactory (module java.management) In-Reply-To: <566EF48E.3050300@oracle.com> References: <566EF48E.3050300@oracle.com> Message-ID: <566FDB8A.4060209@oracle.com> Build changes look good to me. /Erik On 2015-12-14 17:55, Jaroslav Bachorik wrote: > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8138677 > Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00 > > The problem is that the class UsageTrackerClient is accessing > RuntimeMXBean.getInputArguments() method via reflection to avoid > static dependency. However, with functional module boundaries this fails. > > Since the functionality provided by RuntimeMXBean.getInputArguments() > is not, in fact, specific to the management subsystem, it makes sense > to move it out of jmm.h to jvm.h > > Full suite of SVC tests was run against this change successfully on > all platforms. > > > Thanks, > > -JB- From marcus.larsson at oracle.com Tue Dec 15 09:23:00 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 15 Dec 2015 10:23:00 +0100 Subject: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration In-Reply-To: References: <566E962D.8010107@oracle.com> <566ED7F8.4090204@oracle.com> <566EE0AF.9010905@oracle.com> Message-ID: <566FDBF4.70200@oracle.com> Hi Markus, On 2015-12-14 21:53, Markus Gronlund wrote: > Hi Marcus, > > Thanks for updating the patch. > > I think you could also move the lock representation, i.e the Semaphore to become a (static) field inside the ConfigurationLocker class - this since you want all entry/exits to go through instances of this object. Sounds good, I'll move it. > > I know that the other MutexLocker's don't aggregate their lock resource but rather take them as pointer in their constructors. However, I don?t think emulating that behavior is paramount here, so if the semaphore moves into the ConfigurationLocker, another name (for discernment against the other *Lockers) could possibly be used - for example: "ConfigurationLock" which is generic enough for the abstraction letting you change how locking is done underneath should you need to. Also sounds like a good idea. Thanks for looking at this! Marcus > > Thanks > Markus > > > > > -----Original Message----- > From: Marcus Larsson > Sent: den 14 december 2015 16:31 > To: serviceability-dev at openjdk.java.net > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration > > Hi again, > > Made some changes to the patch after feedback from Markus Gr?nlund. The ConfigurationLocker and the semaphore have been moved out of the LogConfiguration.hpp and into the .cpp instead. The lock is only used internally by the LogConfiguration so this makes sense. It simplifies the LogConfiguration interface and hides the details of the locking under the hood. > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.02/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01-02/ > > Thanks, > Marcus > > On 2015-12-14 15:53, Marcus Larsson wrote: >> Hi, >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00-01/ >> >> Changes: >> * Introduced the ConfigurationLocker class for automatic wait/signal >> in constructor/destructor just like a MutexLocker. >> * Added an assert to verify that the "lock" is held by the current >> thread when calling configure_output. >> * Made the config-string functions in LogOutput protected and >> LogConfiguration a friend of LogOutput to prevent incorrect usage of >> these functions. These functions should typically only be used inside >> configure_output, which now ensures that the lock is held. >> >> Thanks, >> Marcus >> >> >> On 2015-12-14 11:13, Marcus Larsson wrote: >>> Hi, >>> >>> Please review the following patch to use a semaphore instead of a >>> mutex for the synchronization of log configuration. Using a mutex >>> requires some parts of the VM to be initialized, whereas the >>> semaphores can be used right from the start. This simplifies the code >>> and allows very early log configuration without special cases for >>> early configuration vs reconfiguration after VM init. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8145083 >>> >>> Thanks, >>> Marcus From mikael.gerdin at oracle.com Tue Dec 15 09:56:31 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 15 Dec 2015 10:56:31 +0100 Subject: [RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and nonstatic_oopmap on 32-bit systems In-Reply-To: <5669EF2F.2000907@oracle.com> References: <56620D85.8090204@oracle.com> <5666A8CA.3040004@oracle.com> <56672C25.7010909@oracle.com> <56685B78.5030106@oracle.com> <5669EF2F.2000907@oracle.com> Message-ID: <566FE3CF.6040209@oracle.com> Hi Chris, sorry for the late reply. On 2015-12-10 22:31, Chris Plummer wrote: > Hi Mikael, > > See comments inline below: > > On 12/9/15 8:48 AM, Mikael Gerdin wrote: >> On 2015-12-08 20:14, Chris Plummer wrote: >>> [Adding serviceability-dev at openjdk.java.net] >>> >>> Hi Mikael, >>> >>> Thanks for pointing this out. I'll look into it some more. Are there any >>> tests that should be failing as a result of this? I get the feeling no, >>> since I see other issues here that existed before my change. For >>> example, this code is not returning the proper size if the class is >>> anonymous or is an interface. It needs to add 1 extra word in that case. >>> See size() in instanceKlass.hpp. >>> >>> Another difference from the VM code is alignObjectSize() is being used >>> by getSize(), but headerSize is set using alignObjectOffset(). The VM >>> code uses align_object_offset in both cases. >>> >>> // Align the object size. >>> public static long alignObjectSize(long size) { >>> return VM.getVM().alignUp(size, >>> VM.getVM().getMinObjAlignmentInBytes()); >>> } >>> >>> // All vm's align longs, so pad out certain offsets. >>> public static long alignObjectOffset(long offset) { >>> return VM.getVM().alignUp(offset, VM.getVM().getBytesPerLong()); >>> } >>> >>> So the difference here is in the use of getMinObjAlignmentInBytes (not >>> what the VM does) vs getBytesPerLong (what the VM uses): >>> >>> public int getObjectAlignmentInBytes() { >>> if (objectAlignmentInBytes == 0) { >>> Flag flag = getCommandLineFlag("ObjectAlignmentInBytes"); >>> objectAlignmentInBytes = (flag == null) ? 8 : >>> (int)flag.getIntx(); >>> } >>> return objectAlignmentInBytes; >>> } >>> >>> So this seems wrong for use in any InstanceKlass size or embedded field >>> offset calculation. It is probably a remnant of when class metadata was >>> stored in the java heap, and the size of InstanceKlass had to be padded >>> out to the minimum heap object alignment. At least it is harmless if >>> ObjectAlignmentInBytes is not set, and if set it is only supported for >>> 64-bit: >>> >>> lp64_product(intx, ObjectAlignmentInBytes, >>> 8, \ >>> "Default object alignment in bytes, 8 is >>> minimum") \ >>> range(8, >>> 256) \ >>> constraint(ObjectAlignmentInBytesConstraintFunc,AtParse) \ >>> >>> I'll get these cleaned up, but it sure would be nice if there was a way >>> to reliably test it. >> >> I'd say that it's quite possible to test it! >> Create a whitebox.cpp entry point for determining the size of a class. > Ok, but I instead decided to use jcmd with "GC.class_stats KlassBytes" Sounds good. >> >> Run a java program calling the entry point and printing the >> InstanceKlass size as computed by calling InstanceKlass::size() on a >> set of pre-determined set of complex and simple classes (vtables, >> itables, anonymous, etc.) > For now I just did this from the command line to do some quick checking. > No test written. >> Have the java program wait after it's finished printing. >> >> Launch the SA agent and attach it to the process. >> Through several layers of magic, execute the incantation: >> >> mgerdin at mgerdin03:~/work/repos/hg/jdk9/hs-rt-work/hotspot$ >> ../build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java >> sun.jvm.hotspot.CLHSDB 6211 >> Attaching to process 6211, please wait... >> hsdb> jseval >> "sapkg.utilities.SystemDictionaryHelper.findInstanceKlass('java/lang/Object').getSize();" >> >> 472 > Ok. I did this to get sizes as SA sees them. They were not just wrong > for existing JDK, but in most cases off by a large margin. I did some > investigating. This is InstanceKlass.getSize() > > public long getSize() { > return Oop.alignObjectSize(getHeaderSize() + > Oop.alignObjectOffset(getVtableLen()) + > Oop.alignObjectOffset(getItableLen()) + > Oop.alignObjectOffset(getNonstaticOopMapSize())); > } > > The problem is that getHeaderSize() returns the size in bytes, but the > others all return the size in words. They need to be multiplied by the > word size to get the right value since the caller of getSize() expects > the result to be in bytes. Oh, that seems like a familiar problem :) > > So we have multiple problems with SA with respect to the > InstanceKlass.getSize() support: > > * Alignment issues introduced by me. > * Some minor other issues like using alignObjectSize when it's not > needed, and not taking into account extra fields for interfaces and > anonymous classes. > * Not multiplying the vtable, itable, and oopMapSize by the number of > bytes in a word. > * No test available. > > I'm not too sure how to proceed here w.r.t. my CR. I'm inclined to just > make the SA adjustments needed to take into consideration the alignment > changes I've made to InstanceKlass, and file a CRs for the rest (one for > the existing bugs and one for the lack of any test). It would be good if you could at least fix the obvious word size scaling bug, filing follow ups on the extra alignObjectSize and missing extra fields. The main consumer of this is the "jmap -clstats" command which is a supported external interface for querying the sizes of metadata in relation to their ClassLoaders. /Mikael > > Please advise. > > thanks, > > Chris > >> >> You could also create a javascript source file in the test directory >> which performs the appropriate calls and do >> hsdb> jsload /path/to/file.js >> hsdb> jseval "doit()" >> >> where >> file.js: >> doit = function() { >> sd = sapkg.utilities.SystemDictionaryHelper; >> do_klass = function(name) { >> writeln(sd.findInstanceKlass(name).getSize()); >> } >> >> do_klass('java/lang/Object'); >> do_klass('java/lang/Class'); >> } >> >> >> The only problem is that the test can't reliably execute on >> unconfigured os x setups because of OS level security requirements for >> attaching to processes. >> >> After detaching HSDB with the "quit" command you tell the debugged >> java process to terminate, for example by printing some string on its >> stdin. >> >> Easy, right? :) >> >> /Mikael >> >>> >>> thanks, >>> >>> Chris >>> >>> On 12/8/15 1:54 AM, Mikael Gerdin wrote: >>>> Hi Chris, >>>> >>>> Not a review but I'm fairly sure that you need to update the >>>> serviceability agent to reflect these changes, see for example: >>>> >>>> public long getSize() { >>>> return Oop.alignObjectSize( >>>> getHeaderSize() + >>>> Oop.alignObjectOffset(getVtableLen()) + >>>> Oop.alignObjectOffset(getItableLen()) + >>>> Oop.alignObjectOffset(getNonstaticOopMapSize())); >>>> } >>>> >>>> in InstanceKlass.java >>>> >>>> /Mikael >>>> >>>> On 2015-12-04 23:02, Chris Plummer wrote: >>>>> Hello, >>>>> >>>>> Please review the following: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8143608 >>>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/ >>>>> >>>>> >>>>> A bit of background would help. The InstanceKlass object has a >>>>> number of >>>>> variable length fields that are laid out after the declared fields. >>>>> When >>>>> an InstanceKlass object is allocated, extra memory is allocated for it >>>>> to leave room for these fields. The first three of these fields are >>>>> vtable, itable, and nonstatic_oopmap. They are all arrays of HeapWord >>>>> sized values, which means void* size, which means they only need >>>>> 32-bit >>>>> alignment on 32-bit systems. However, they have always been 64-bit >>>>> aligned. This webrev removes the forced 64-bit alignment on 32-bit >>>>> systems, saving footprint. >>>>> >>>>> This change affects all 32-bit platforms. It should have no net impact >>>>> on 64-bit platforms since the fields remain (naturally) 64-bit aligned >>>>> (unless of course I've introduced a bug). The intent is to not change >>>>> what is done for 64-bit platforms. >>>>> >>>>> BTW, there is a change to AARCH64, which may seem odd at first. It >>>>> just >>>>> removes an "if" block where the condition should always have evaluated >>>>> to false, so it should have no net affect. >>>>> >>>>> Tested with JPRT "-testset hotspot". Please let me know if you think >>>>> there are any additional tests that should be run. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>> >>> >> > From marcus.larsson at oracle.com Tue Dec 15 10:25:07 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 15 Dec 2015 11:25:07 +0100 Subject: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration In-Reply-To: <566EE0AF.9010905@oracle.com> References: <566E962D.8010107@oracle.com> <566ED7F8.4090204@oracle.com> <566EE0AF.9010905@oracle.com> Message-ID: <566FEA83.6060105@oracle.com> Hi, New webrev: http://cr.openjdk.java.net/~mlarsson/8145083/webrev.03/ Incremental: http://cr.openjdk.java.net/~mlarsson/8145083/webrev.02-03/ ConfigurationLocker renamed to ConfigurationLock to avoid confusion with the MutexLocker family of classes. Semaphore and locking thread id moved into the ConfigurationLock; added a function to check if current thread has the lock when asserts are enabled. Regards, Marcus On 2015-12-14 16:30, Marcus Larsson wrote: > Hi again, > > Made some changes to the patch after feedback from Markus Gr?nlund. > The ConfigurationLocker and the semaphore have been moved out of the > LogConfiguration.hpp and into the .cpp instead. The lock is only used > internally by the LogConfiguration so this makes sense. It simplifies > the LogConfiguration interface and hides the details of the locking > under the hood. > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.02/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01-02/ > > Thanks, > Marcus > > On 2015-12-14 15:53, Marcus Larsson wrote: >> Hi, >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00-01/ >> >> Changes: >> * Introduced the ConfigurationLocker class for automatic wait/signal >> in constructor/destructor just like a MutexLocker. >> * Added an assert to verify that the "lock" is held by the current >> thread when calling configure_output. >> * Made the config-string functions in LogOutput protected and >> LogConfiguration a friend of LogOutput to prevent incorrect usage of >> these functions. These functions should typically only be used inside >> configure_output, which now ensures that the lock is held. >> >> Thanks, >> Marcus >> >> >> On 2015-12-14 11:13, Marcus Larsson wrote: >>> Hi, >>> >>> Please review the following patch to use a semaphore instead of a >>> mutex for the synchronization of log configuration. Using a mutex >>> requires some parts of the VM to be initialized, whereas the >>> semaphores can be used right from the start. This simplifies the >>> code and allows very early log configuration without special cases >>> for early configuration vs reconfiguration after VM init. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8145083 >>> >>> Thanks, >>> Marcus >> > From markus.gronlund at oracle.com Tue Dec 15 10:58:17 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 15 Dec 2015 02:58:17 -0800 (PST) Subject: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration In-Reply-To: <566FEA83.6060105@oracle.com> References: <566E962D.8010107@oracle.com> <566ED7F8.4090204@oracle.com> <566EE0AF.9010905@oracle.com> <566FEA83.6060105@oracle.com> Message-ID: <15686d26-99f4-449b-b5a8-f342632b2922@default> Hi Marcus, Looks good! One minor thing that you don't need to fix if you don't want to: I would use: class ConfigurationLock { ... debug_only(static bool current_thread_has_lock();) }; to declare the this function in the class, then I would move the definition outside of it (since it's sits inside ASSERT macros). #ifdef ASSERT bool ConfigurationLock::current_thread_has_lock() { return _locking_thread_id == os::current_thread_id(); } #endif I just find it easier to read the class declaration without the macros inside of the class declaration (and since this is debug code, there is no real use of defining inline). As I said, you don?t need to fix this and to post another webrev. Good work! /Markus -----Original Message----- From: Marcus Larsson Sent: den 15 december 2015 11:25 To: serviceability-dev at openjdk.java.net Cc: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration Hi, New webrev: http://cr.openjdk.java.net/~mlarsson/8145083/webrev.03/ Incremental: http://cr.openjdk.java.net/~mlarsson/8145083/webrev.02-03/ ConfigurationLocker renamed to ConfigurationLock to avoid confusion with the MutexLocker family of classes. Semaphore and locking thread id moved into the ConfigurationLock; added a function to check if current thread has the lock when asserts are enabled. Regards, Marcus On 2015-12-14 16:30, Marcus Larsson wrote: > Hi again, > > Made some changes to the patch after feedback from Markus Gr?nlund. > The ConfigurationLocker and the semaphore have been moved out of the > LogConfiguration.hpp and into the .cpp instead. The lock is only used > internally by the LogConfiguration so this makes sense. It simplifies > the LogConfiguration interface and hides the details of the locking > under the hood. > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.02/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01-02/ > > Thanks, > Marcus > > On 2015-12-14 15:53, Marcus Larsson wrote: >> Hi, >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00-01/ >> >> Changes: >> * Introduced the ConfigurationLocker class for automatic wait/signal >> in constructor/destructor just like a MutexLocker. >> * Added an assert to verify that the "lock" is held by the current >> thread when calling configure_output. >> * Made the config-string functions in LogOutput protected and >> LogConfiguration a friend of LogOutput to prevent incorrect usage of >> these functions. These functions should typically only be used inside >> configure_output, which now ensures that the lock is held. >> >> Thanks, >> Marcus >> >> >> On 2015-12-14 11:13, Marcus Larsson wrote: >>> Hi, >>> >>> Please review the following patch to use a semaphore instead of a >>> mutex for the synchronization of log configuration. Using a mutex >>> requires some parts of the VM to be initialized, whereas the >>> semaphores can be used right from the start. This simplifies the >>> code and allows very early log configuration without special cases >>> for early configuration vs reconfiguration after VM init. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8145083 >>> >>> Thanks, >>> Marcus >> > From ivan.gerasimov at oracle.com Tue Dec 15 12:00:57 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 15 Dec 2015 15:00:57 +0300 Subject: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ... In-Reply-To: <566FB3BB.4050709@oracle.com> References: <566ECDA6.1030404@oracle.com> <566FB3BB.4050709@oracle.com> Message-ID: <567000F9.2070603@oracle.com> On 15.12.2015 9:31, David Holmes wrote: > I really wish we had some view inside windows to see exactly what is > going wrong here. :( > Yes, so do I! It would be really helpful to know exactly how this race bug is "implemented". Or, at least, how to deal with it to avoid the return code replacement for sure. > On 15/12/2015 12:09 AM, Ivan Gerasimov wrote: >> Hello! >> >> There was a timeout observed in os_windows.cpp at the line >> 3945 res = WaitForMultipleObjects(MAXIMUM_WAIT_OBJECTS, >> handles, FALSE, EXIT_TIMEOUT); >> >> This means there were more than 64 threads exiting at the same time and >> none of the first 64 threads could make any progress during 5 minutes. >> Sigh. >> >> To address this issue I suggest two things: >> 1) >> Increase the size of the queue of exiting threads. >> We'll still have to wait for only the first 64 threads, if the queue is >> exhausted. >> But the chances we hit this condition are greatly reduced. >> >> 2) >> Raise process_exiting flag earlier, i.e. before trying to enter the >> critical section. >> This should decrease the number of threads, contending for a slot in the >> 'handles' array during the process exit. >> >> Additionally, it is proposed to suspend all the threads, but the one >> which raised the flag 'process_exiting'. >> It would be important in a case, when two threads are about to call >> exit() concurrently. >> Otherwise, a race could be faced, if the first thread is waiting for all >> the registered handles, while the second one skips the critical section >> altogether and calls ::exit(). >> >> Build went fine on all platforms. The JTREG tests from 'hotspot' subset >> all pass. >> >> Would you please help review the proposed fix? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8145127 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8145127/00/webrev/ > > Can't quite get my head round the whole strategy, but in this loop: > > 4033 while (pr_ex != curr_id) { > > pr_ex is never updated! > It's intentional. It's not meant the current thread will ever leave this loop, once enters. The first line of the loop body will effectively suspend the current thread, so it will never call _endthreadex(), exit() or _exit() itself. Just for the extra protection, the SuspendThread() call is wrapped into an infinite loop. Sincerely yours, Ivan From david.holmes at oracle.com Tue Dec 15 12:07:21 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2015 22:07:21 +1000 Subject: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ... In-Reply-To: <567000F9.2070603@oracle.com> References: <566ECDA6.1030404@oracle.com> <566FB3BB.4050709@oracle.com> <567000F9.2070603@oracle.com> Message-ID: <56700279.4000408@oracle.com> On 15/12/2015 10:00 PM, Ivan Gerasimov wrote: > > > On 15.12.2015 9:31, David Holmes wrote: >> I really wish we had some view inside windows to see exactly what is >> going wrong here. :( >> > > Yes, so do I! > It would be really helpful to know exactly how this race bug is > "implemented". > Or, at least, how to deal with it to avoid the return code replacement > for sure. > >> On 15/12/2015 12:09 AM, Ivan Gerasimov wrote: >>> Hello! >>> >>> There was a timeout observed in os_windows.cpp at the line >>> 3945 res = WaitForMultipleObjects(MAXIMUM_WAIT_OBJECTS, >>> handles, FALSE, EXIT_TIMEOUT); >>> >>> This means there were more than 64 threads exiting at the same time and >>> none of the first 64 threads could make any progress during 5 minutes. >>> Sigh. >>> >>> To address this issue I suggest two things: >>> 1) >>> Increase the size of the queue of exiting threads. >>> We'll still have to wait for only the first 64 threads, if the queue is >>> exhausted. >>> But the chances we hit this condition are greatly reduced. >>> >>> 2) >>> Raise process_exiting flag earlier, i.e. before trying to enter the >>> critical section. >>> This should decrease the number of threads, contending for a slot in the >>> 'handles' array during the process exit. >>> >>> Additionally, it is proposed to suspend all the threads, but the one >>> which raised the flag 'process_exiting'. >>> It would be important in a case, when two threads are about to call >>> exit() concurrently. >>> Otherwise, a race could be faced, if the first thread is waiting for all >>> the registered handles, while the second one skips the critical section >>> altogether and calls ::exit(). >>> >>> Build went fine on all platforms. The JTREG tests from 'hotspot' subset >>> all pass. >>> >>> Would you please help review the proposed fix? >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8145127 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8145127/00/webrev/ >> >> Can't quite get my head round the whole strategy, but in this loop: >> >> 4033 while (pr_ex != curr_id) { >> >> pr_ex is never updated! >> > It's intentional. > It's not meant the current thread will ever leave this loop, once enters. > The first line of the loop body will effectively suspend the current > thread, so it will never call _endthreadex(), exit() or _exit() itself. > Just for the extra protection, the SuspendThread() call is wrapped into > an infinite loop. while(true) would convey that much more clearly - and perhaps obviate the need for pr_ex. Thanks, David > Sincerely yours, > Ivan > From dmitry.samersoff at oracle.com Tue Dec 15 12:11:12 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 15 Dec 2015 15:11:12 +0300 Subject: [RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and nonstatic_oopmap on 32-bit systems In-Reply-To: <5669EF2F.2000907@oracle.com> References: <56620D85.8090204@oracle.com> <5666A8CA.3040004@oracle.com> <56672C25.7010909@oracle.com> <56685B78.5030106@oracle.com> <5669EF2F.2000907@oracle.com> Message-ID: <56700360.3060909@oracle.com> Chris, 1. Please file a separate CR for SA (assign it to me) and go ahead with your fix when it become ready. 2. As far as I understand the fix, you just removed explicit alignment for all platforms (not only 32bit) and rely on compiler. I'm a bit scared with it (see David's comments). Also please contact SQE (Leonid Mesnik) about testing of the fix before pushing it. -Dmitry On 2015-12-11 00:31, Chris Plummer wrote: > Hi Mikael, > > See comments inline below: > > On 12/9/15 8:48 AM, Mikael Gerdin wrote: >> On 2015-12-08 20:14, Chris Plummer wrote: >>> [Adding serviceability-dev at openjdk.java.net] >>> >>> Hi Mikael, >>> >>> Thanks for pointing this out. I'll look into it some more. Are there any >>> tests that should be failing as a result of this? I get the feeling no, >>> since I see other issues here that existed before my change. For >>> example, this code is not returning the proper size if the class is >>> anonymous or is an interface. It needs to add 1 extra word in that case. >>> See size() in instanceKlass.hpp. >>> >>> Another difference from the VM code is alignObjectSize() is being used >>> by getSize(), but headerSize is set using alignObjectOffset(). The VM >>> code uses align_object_offset in both cases. >>> >>> // Align the object size. >>> public static long alignObjectSize(long size) { >>> return VM.getVM().alignUp(size, >>> VM.getVM().getMinObjAlignmentInBytes()); >>> } >>> >>> // All vm's align longs, so pad out certain offsets. >>> public static long alignObjectOffset(long offset) { >>> return VM.getVM().alignUp(offset, VM.getVM().getBytesPerLong()); >>> } >>> >>> So the difference here is in the use of getMinObjAlignmentInBytes (not >>> what the VM does) vs getBytesPerLong (what the VM uses): >>> >>> public int getObjectAlignmentInBytes() { >>> if (objectAlignmentInBytes == 0) { >>> Flag flag = getCommandLineFlag("ObjectAlignmentInBytes"); >>> objectAlignmentInBytes = (flag == null) ? 8 : >>> (int)flag.getIntx(); >>> } >>> return objectAlignmentInBytes; >>> } >>> >>> So this seems wrong for use in any InstanceKlass size or embedded field >>> offset calculation. It is probably a remnant of when class metadata was >>> stored in the java heap, and the size of InstanceKlass had to be padded >>> out to the minimum heap object alignment. At least it is harmless if >>> ObjectAlignmentInBytes is not set, and if set it is only supported for >>> 64-bit: >>> >>> lp64_product(intx, ObjectAlignmentInBytes, >>> 8, \ >>> "Default object alignment in bytes, 8 is >>> minimum") \ >>> range(8, >>> 256) \ >>> constraint(ObjectAlignmentInBytesConstraintFunc,AtParse) \ >>> >>> I'll get these cleaned up, but it sure would be nice if there was a way >>> to reliably test it. >> >> I'd say that it's quite possible to test it! >> Create a whitebox.cpp entry point for determining the size of a class. > Ok, but I instead decided to use jcmd with "GC.class_stats KlassBytes" >> >> Run a java program calling the entry point and printing the >> InstanceKlass size as computed by calling InstanceKlass::size() on a >> set of pre-determined set of complex and simple classes (vtables, >> itables, anonymous, etc.) > For now I just did this from the command line to do some quick checking. > No test written. >> Have the java program wait after it's finished printing. >> >> Launch the SA agent and attach it to the process. >> Through several layers of magic, execute the incantation: >> >> mgerdin at mgerdin03:~/work/repos/hg/jdk9/hs-rt-work/hotspot$ >> ../build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java >> sun.jvm.hotspot.CLHSDB 6211 >> Attaching to process 6211, please wait... >> hsdb> jseval >> "sapkg.utilities.SystemDictionaryHelper.findInstanceKlass('java/lang/Object').getSize();" >> >> 472 > Ok. I did this to get sizes as SA sees them. They were not just wrong > for existing JDK, but in most cases off by a large margin. I did some > investigating. This is InstanceKlass.getSize() > > public long getSize() { > return Oop.alignObjectSize(getHeaderSize() + > Oop.alignObjectOffset(getVtableLen()) + > Oop.alignObjectOffset(getItableLen()) + > Oop.alignObjectOffset(getNonstaticOopMapSize())); > } > > The problem is that getHeaderSize() returns the size in bytes, but the > others all return the size in words. They need to be multiplied by the > word size to get the right value since the caller of getSize() expects > the result to be in bytes. > > So we have multiple problems with SA with respect to the > InstanceKlass.getSize() support: > > * Alignment issues introduced by me. > * Some minor other issues like using alignObjectSize when it's not > needed, and not taking into account extra fields for interfaces and > anonymous classes. > * Not multiplying the vtable, itable, and oopMapSize by the number of > bytes in a word. > * No test available. > > I'm not too sure how to proceed here w.r.t. my CR. I'm inclined to just > make the SA adjustments needed to take into consideration the alignment > changes I've made to InstanceKlass, and file a CRs for the rest (one for > the existing bugs and one for the lack of any test). > > Please advise. > > thanks, > > Chris > >> >> You could also create a javascript source file in the test directory >> which performs the appropriate calls and do >> hsdb> jsload /path/to/file.js >> hsdb> jseval "doit()" >> >> where >> file.js: >> doit = function() { >> sd = sapkg.utilities.SystemDictionaryHelper; >> do_klass = function(name) { >> writeln(sd.findInstanceKlass(name).getSize()); >> } >> >> do_klass('java/lang/Object'); >> do_klass('java/lang/Class'); >> } >> >> >> The only problem is that the test can't reliably execute on >> unconfigured os x setups because of OS level security requirements for >> attaching to processes. >> >> After detaching HSDB with the "quit" command you tell the debugged >> java process to terminate, for example by printing some string on its >> stdin. >> >> Easy, right? :) >> >> /Mikael >> >>> >>> thanks, >>> >>> Chris >>> >>> On 12/8/15 1:54 AM, Mikael Gerdin wrote: >>>> Hi Chris, >>>> >>>> Not a review but I'm fairly sure that you need to update the >>>> serviceability agent to reflect these changes, see for example: >>>> >>>> public long getSize() { >>>> return Oop.alignObjectSize( >>>> getHeaderSize() + >>>> Oop.alignObjectOffset(getVtableLen()) + >>>> Oop.alignObjectOffset(getItableLen()) + >>>> Oop.alignObjectOffset(getNonstaticOopMapSize())); >>>> } >>>> >>>> in InstanceKlass.java >>>> >>>> /Mikael >>>> >>>> On 2015-12-04 23:02, Chris Plummer wrote: >>>>> Hello, >>>>> >>>>> Please review the following: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8143608 >>>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/ >>>>> >>>>> >>>>> A bit of background would help. The InstanceKlass object has a >>>>> number of >>>>> variable length fields that are laid out after the declared fields. >>>>> When >>>>> an InstanceKlass object is allocated, extra memory is allocated for it >>>>> to leave room for these fields. The first three of these fields are >>>>> vtable, itable, and nonstatic_oopmap. They are all arrays of HeapWord >>>>> sized values, which means void* size, which means they only need >>>>> 32-bit >>>>> alignment on 32-bit systems. However, they have always been 64-bit >>>>> aligned. This webrev removes the forced 64-bit alignment on 32-bit >>>>> systems, saving footprint. >>>>> >>>>> This change affects all 32-bit platforms. It should have no net impact >>>>> on 64-bit platforms since the fields remain (naturally) 64-bit aligned >>>>> (unless of course I've introduced a bug). The intent is to not change >>>>> what is done for 64-bit platforms. >>>>> >>>>> BTW, there is a change to AARCH64, which may seem odd at first. It >>>>> just >>>>> removes an "if" block where the condition should always have evaluated >>>>> to false, so it should have no net affect. >>>>> >>>>> Tested with JPRT "-testset hotspot". Please let me know if you think >>>>> there are any additional tests that should be run. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>> >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From ivan.gerasimov at oracle.com Tue Dec 15 12:18:57 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 15 Dec 2015 15:18:57 +0300 Subject: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ... In-Reply-To: <56700279.4000408@oracle.com> References: <566ECDA6.1030404@oracle.com> <566FB3BB.4050709@oracle.com> <567000F9.2070603@oracle.com> <56700279.4000408@oracle.com> Message-ID: <56700531.8060701@oracle.com> > > while(true) would convey that much more clearly - and perhaps obviate > the need for pr_ex. > Yes, I can surely transform the code - while (pr_ex != curr_id) { + if (pr_ex != curr_id) { + while (true} { The intention was to save a line :-) I'll use while (true), if it improves readability. Sincerely yours, Ivan From magnus.ihse.bursie at oracle.com Tue Dec 15 13:23:49 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 15 Dec 2015 14:23:49 +0100 Subject: RFR 8142398: IllegalAccessException Class sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access a member of class java.lang.management.ManagementFactory (module java.management) In-Reply-To: <566EF48E.3050300@oracle.com> References: <566EF48E.3050300@oracle.com> Message-ID: <56701465.4060503@oracle.com> On 2015-12-14 17:55, Jaroslav Bachorik wrote: > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8138677 > Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00 > > The problem is that the class UsageTrackerClient is accessing > RuntimeMXBean.getInputArguments() method via reflection to avoid > static dependency. However, with functional module boundaries this fails. > > Since the functionality provided by RuntimeMXBean.getInputArguments() > is not, in fact, specific to the management subsystem, it makes sense > to move it out of jmm.h to jvm.h > > Full suite of SVC tests was run against this change successfully on > all platforms. > > > Thanks, > > -JB- Build changes look good to me. /Magnus From marcus.larsson at oracle.com Tue Dec 15 15:12:31 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 15 Dec 2015 16:12:31 +0100 Subject: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration In-Reply-To: <15686d26-99f4-449b-b5a8-f342632b2922@default> References: <566E962D.8010107@oracle.com> <566ED7F8.4090204@oracle.com> <566EE0AF.9010905@oracle.com> <566FEA83.6060105@oracle.com> <15686d26-99f4-449b-b5a8-f342632b2922@default> Message-ID: <56702DDF.9060407@oracle.com> Hey Markus, On 2015-12-15 11:58, Markus Gronlund wrote: > Hi Marcus, > > Looks good! > > One minor thing that you don't need to fix if you don't want to: > > I would use: > > class ConfigurationLock { > ... > > debug_only(static bool current_thread_has_lock();) > > }; > > to declare the this function in the class, then I would move the definition outside of it (since it's sits inside ASSERT macros). > > #ifdef ASSERT > bool ConfigurationLock::current_thread_has_lock() { > return _locking_thread_id == os::current_thread_id(); > } > #endif > > > I just find it easier to read the class declaration without the macros inside of the class declaration (and since this is debug code, there is no real use of defining inline). As I said, you don?t need to fix this and to post another webrev. I think it's worth another round. :) New webrev: http://cr.openjdk.java.net/~mlarsson/8145083/webrev.04/ Incremental: http://cr.openjdk.java.net/~mlarsson/8145083/webrev.03-04/ Thanks, Marcus > > Good work! > > /Markus > > > > > -----Original Message----- > From: Marcus Larsson > Sent: den 15 december 2015 11:25 > To: serviceability-dev at openjdk.java.net > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration > > Hi, > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.03/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.02-03/ > > ConfigurationLocker renamed to ConfigurationLock to avoid confusion with the MutexLocker family of classes. > Semaphore and locking thread id moved into the ConfigurationLock; added a function to check if current thread has the lock when asserts are enabled. > > Regards, > Marcus > > > On 2015-12-14 16:30, Marcus Larsson wrote: >> Hi again, >> >> Made some changes to the patch after feedback from Markus Gr?nlund. >> The ConfigurationLocker and the semaphore have been moved out of the >> LogConfiguration.hpp and into the .cpp instead. The lock is only used >> internally by the LogConfiguration so this makes sense. It simplifies >> the LogConfiguration interface and hides the details of the locking >> under the hood. >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.02/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01-02/ >> >> Thanks, >> Marcus >> >> On 2015-12-14 15:53, Marcus Larsson wrote: >>> Hi, >>> >>> New webrev: >>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01/ >>> >>> Incremental: >>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00-01/ >>> >>> Changes: >>> * Introduced the ConfigurationLocker class for automatic wait/signal >>> in constructor/destructor just like a MutexLocker. >>> * Added an assert to verify that the "lock" is held by the current >>> thread when calling configure_output. >>> * Made the config-string functions in LogOutput protected and >>> LogConfiguration a friend of LogOutput to prevent incorrect usage of >>> these functions. These functions should typically only be used inside >>> configure_output, which now ensures that the lock is held. >>> >>> Thanks, >>> Marcus >>> >>> >>> On 2015-12-14 11:13, Marcus Larsson wrote: >>>> Hi, >>>> >>>> Please review the following patch to use a semaphore instead of a >>>> mutex for the synchronization of log configuration. Using a mutex >>>> requires some parts of the VM to be initialized, whereas the >>>> semaphores can be used right from the start. This simplifies the >>>> code and allows very early log configuration without special cases >>>> for early configuration vs reconfiguration after VM init. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8145083 >>>> >>>> Thanks, >>>> Marcus From markus.gronlund at oracle.com Tue Dec 15 15:13:46 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 15 Dec 2015 07:13:46 -0800 (PST) Subject: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration In-Reply-To: <56702DDF.9060407@oracle.com> References: <566E962D.8010107@oracle.com> <566ED7F8.4090204@oracle.com> <566EE0AF.9010905@oracle.com> <566FEA83.6060105@oracle.com> <15686d26-99f4-449b-b5a8-f342632b2922@default> <56702DDF.9060407@oracle.com> Message-ID: <2ba7880c-0251-42a1-9233-b43194fb356c@default> Looks good, thanks again for doing all of this. I will be quiet now :-) /Markus -----Original Message----- From: Marcus Larsson Sent: den 15 december 2015 16:13 To: Markus Gronlund Cc: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net Subject: Re: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration Hey Markus, On 2015-12-15 11:58, Markus Gronlund wrote: > Hi Marcus, > > Looks good! > > One minor thing that you don't need to fix if you don't want to: > > I would use: > > class ConfigurationLock { > ... > > debug_only(static bool current_thread_has_lock();) > > }; > > to declare the this function in the class, then I would move the definition outside of it (since it's sits inside ASSERT macros). > > #ifdef ASSERT > bool ConfigurationLock::current_thread_has_lock() { > return _locking_thread_id == os::current_thread_id(); > } > #endif > > > I just find it easier to read the class declaration without the macros inside of the class declaration (and since this is debug code, there is no real use of defining inline). As I said, you don?t need to fix this and to post another webrev. I think it's worth another round. :) New webrev: http://cr.openjdk.java.net/~mlarsson/8145083/webrev.04/ Incremental: http://cr.openjdk.java.net/~mlarsson/8145083/webrev.03-04/ Thanks, Marcus > > Good work! > > /Markus > > > > > -----Original Message----- > From: Marcus Larsson > Sent: den 15 december 2015 11:25 > To: serviceability-dev at openjdk.java.net > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR: 8145083: Use semaphore instead of mutex for > synchronization of Unified Logging configuration > > Hi, > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.03/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.02-03/ > > ConfigurationLocker renamed to ConfigurationLock to avoid confusion with the MutexLocker family of classes. > Semaphore and locking thread id moved into the ConfigurationLock; added a function to check if current thread has the lock when asserts are enabled. > > Regards, > Marcus > > > On 2015-12-14 16:30, Marcus Larsson wrote: >> Hi again, >> >> Made some changes to the patch after feedback from Markus Gr?nlund. >> The ConfigurationLocker and the semaphore have been moved out of the >> LogConfiguration.hpp and into the .cpp instead. The lock is only used >> internally by the LogConfiguration so this makes sense. It simplifies >> the LogConfiguration interface and hides the details of the locking >> under the hood. >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.02/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01-02/ >> >> Thanks, >> Marcus >> >> On 2015-12-14 15:53, Marcus Larsson wrote: >>> Hi, >>> >>> New webrev: >>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01/ >>> >>> Incremental: >>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00-01/ >>> >>> Changes: >>> * Introduced the ConfigurationLocker class for automatic wait/signal >>> in constructor/destructor just like a MutexLocker. >>> * Added an assert to verify that the "lock" is held by the current >>> thread when calling configure_output. >>> * Made the config-string functions in LogOutput protected and >>> LogConfiguration a friend of LogOutput to prevent incorrect usage of >>> these functions. These functions should typically only be used >>> inside configure_output, which now ensures that the lock is held. >>> >>> Thanks, >>> Marcus >>> >>> >>> On 2015-12-14 11:13, Marcus Larsson wrote: >>>> Hi, >>>> >>>> Please review the following patch to use a semaphore instead of a >>>> mutex for the synchronization of log configuration. Using a mutex >>>> requires some parts of the VM to be initialized, whereas the >>>> semaphores can be used right from the start. This simplifies the >>>> code and allows very early log configuration without special cases >>>> for early configuration vs reconfiguration after VM init. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8145083 >>>> >>>> Thanks, >>>> Marcus From marcus.larsson at oracle.com Tue Dec 15 15:39:43 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 15 Dec 2015 16:39:43 +0100 Subject: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration In-Reply-To: <2ba7880c-0251-42a1-9233-b43194fb356c@default> References: <566E962D.8010107@oracle.com> <566ED7F8.4090204@oracle.com> <566EE0AF.9010905@oracle.com> <566FEA83.6060105@oracle.com> <15686d26-99f4-449b-b5a8-f342632b2922@default> <56702DDF.9060407@oracle.com> <2ba7880c-0251-42a1-9233-b43194fb356c@default> Message-ID: <5670343F.5040803@oracle.com> On 2015-12-15 16:13, Markus Gronlund wrote: > Looks good, thanks again for doing all of this. Great, thanks for reviewing! Marcus > > I will be quiet now :-) > > /Markus > > -----Original Message----- > From: Marcus Larsson > Sent: den 15 december 2015 16:13 > To: Markus Gronlund > Cc: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net > Subject: Re: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration > > Hey Markus, > > On 2015-12-15 11:58, Markus Gronlund wrote: >> Hi Marcus, >> >> Looks good! >> >> One minor thing that you don't need to fix if you don't want to: >> >> I would use: >> >> class ConfigurationLock { >> ... >> >> debug_only(static bool current_thread_has_lock();) >> >> }; >> >> to declare the this function in the class, then I would move the definition outside of it (since it's sits inside ASSERT macros). >> >> #ifdef ASSERT >> bool ConfigurationLock::current_thread_has_lock() { >> return _locking_thread_id == os::current_thread_id(); >> } >> #endif >> >> >> I just find it easier to read the class declaration without the macros inside of the class declaration (and since this is debug code, there is no real use of defining inline). As I said, you don?t need to fix this and to post another webrev. > I think it's worth another round. :) > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.04/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.03-04/ > > Thanks, > Marcus > > >> Good work! >> >> /Markus >> >> >> >> >> -----Original Message----- >> From: Marcus Larsson >> Sent: den 15 december 2015 11:25 >> To: serviceability-dev at openjdk.java.net >> Cc: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR: 8145083: Use semaphore instead of mutex for >> synchronization of Unified Logging configuration >> >> Hi, >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.03/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.02-03/ >> >> ConfigurationLocker renamed to ConfigurationLock to avoid confusion with the MutexLocker family of classes. >> Semaphore and locking thread id moved into the ConfigurationLock; added a function to check if current thread has the lock when asserts are enabled. >> >> Regards, >> Marcus >> >> >> On 2015-12-14 16:30, Marcus Larsson wrote: >>> Hi again, >>> >>> Made some changes to the patch after feedback from Markus Gr?nlund. >>> The ConfigurationLocker and the semaphore have been moved out of the >>> LogConfiguration.hpp and into the .cpp instead. The lock is only used >>> internally by the LogConfiguration so this makes sense. It simplifies >>> the LogConfiguration interface and hides the details of the locking >>> under the hood. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.02/ >>> >>> Incremental: >>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01-02/ >>> >>> Thanks, >>> Marcus >>> >>> On 2015-12-14 15:53, Marcus Larsson wrote: >>>> Hi, >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01/ >>>> >>>> Incremental: >>>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00-01/ >>>> >>>> Changes: >>>> * Introduced the ConfigurationLocker class for automatic wait/signal >>>> in constructor/destructor just like a MutexLocker. >>>> * Added an assert to verify that the "lock" is held by the current >>>> thread when calling configure_output. >>>> * Made the config-string functions in LogOutput protected and >>>> LogConfiguration a friend of LogOutput to prevent incorrect usage of >>>> these functions. These functions should typically only be used >>>> inside configure_output, which now ensures that the lock is held. >>>> >>>> Thanks, >>>> Marcus >>>> >>>> >>>> On 2015-12-14 11:13, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> Please review the following patch to use a semaphore instead of a >>>>> mutex for the synchronization of log configuration. Using a mutex >>>>> requires some parts of the VM to be initialized, whereas the >>>>> semaphores can be used right from the start. This simplifies the >>>>> code and allows very early log configuration without special cases >>>>> for early configuration vs reconfiguration after VM init. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00/ >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8145083 >>>>> >>>>> Thanks, >>>>> Marcus From olivier.lagneau at oracle.com Tue Dec 15 18:19:22 2015 From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com) Date: Tue, 15 Dec 2015 19:19:22 +0100 Subject: RFR: JDK-8058865 JMX Test Refactoring Message-ID: <567059AA.90504@oracle.com> Hi, Please review the following changes for task "JDK-8058865 : JMX Test Refactoring" Issue: https://bugs.openjdk.java.net/browse/JDK-8058865 Webrev: http://cr.openjdk.java.net/~olagneau/8058865/webrev.06/ Issue Description: " The majority of the JMX related tests are in JTreg. There is a small bunch of functional tests which are written for DTonga and executed separately for promoted builds. They are a mix of functional, stress and integration tests. They should be ported over the JVM testbase or a stresstest harness." An analysis of the various tests in the JMX Tonga test suite has been done first. The outcome has been a list of functional tests that were relevant for a port to Jtreg environment (tests uncovered by current jdk unit tests). Some of the tests (MonitorThread tests) have shown to be unstable under stressed running context like can be happening with nightly test runs. They will have to be redesigned trying to eliminate the intermittent failure under stressed context, and thus are not part of this port. The list of ported tests is the following, all under jdk/test/javax/management: - MBeanServer/ExceptionTest.java - mxbean/MXBeanExceptionHandlingTest.java - mxbean/MXBeanInteropTest1.java - mxbean/MXBeanInteropTest2.java - mxbean/MXBeanLoadingTest1.java - mxbean/MXBeanNotifTest.java - mxbean/MXBeanWeirdParamTest.java - query/SupportedQueryTypesTest.java - security/AuthorizationTest.java - security/SecurityTest.java This makes it an additional set of ~50 tests, using some utility classes, config and security files, making a total of 46 new files. This is a refactoring of test for jtreg running environment, not a redesign. The tests have been modified to be able to run in this environment. Some of them (MXBeanWeirdParamTest, AuthorizationTest.java,SecurityTest.java) need to be run in a distributed context. They run on a single machine with 2 separate processes: a parent one (running the "mbean" server part) which runs a subprocess process playing the role of the client. An internal review has been done first before this open review. That is the reason for this review number of the webrev (webrev.06). Tests have been checked on jprt with both product and fastdebug builds, and also checked running under stressed conditions. The total run time is between 5 and 10 minutes. Thanks for any feedback, Olivier Lagneau -------------- next part -------------- An HTML attachment was scrubbed... URL: From rachel.protacio at oracle.com Tue Dec 15 20:26:02 2015 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Tue, 15 Dec 2015 15:26:02 -0500 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <566E40D3.5060305@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> Message-ID: <5670775A.4060806@oracle.com> Hi, Thanks for the comments, David. I had messed up my uploading before and had not actually updated the open html. So for real this time, the most recent webrev is at http://cr.openjdk.java.net/~rprotacio/8141211.01/ Of note: - each incident of ttyLocker that involved separate logging lines for the same message have been consolidated to one line - each incident of ttyLocker that involved separate print statements to one logging line has been changed to write to a buffer first, then print the entire line at once to the log stream Retested with JPRT, and the buffer-to-logstream schema in particular works fine. Replies inline. On 12/13/2015 11:08 PM, David Holmes wrote: > Hi Rachel, > > On 12/12/2015 7:38 AM, Rachel Protacio wrote: >> Hello! An update and updated webrev. >> >> I've rewritten the two portions of code that had used ttyLockers to >> print in one function-call, since there is no locker equivalent in UL, >> plus the fact that it will be easier for users to look for one message's >> contents without the decorators interrupting the lines. (And I >> especially tested that the fix prints the whole line correctly.) > > Sorry I'm still seeing ttyLocker removal and use of multiple logging > statements in: > > src/share/vm/interpreter/bytecodeInterpreter.cpp > src/share/vm/interpreter/interpreterRuntime.cpp > src/share/vm/opto/runtime.cpp > > which "two portions of code" did you change? I apologize for that! I messed up with uploading the changeset before. All fixed now in each of those files. > > I also note that src/share/vm/runtime/thread.cpp was not using > ttyLocker but does have multi-part trace output. True. Since a locker was unnecessary in the first place, I think it makes sense to allow this (and other logging, both in UL and the existing tty frameworks) to be printed in multiple steps. What do you think? > >> As mentioned in the other thread, I will file a separate RFE to >> deprecate this and other product flags being converted to logging. >> >> Since my last iteration was on hold/not reviewed yet, I've simply >> updated it. http://cr.openjdk.java.net/~rprotacio/8141211.01 > > src/share/vm/c1/c1_Runtime1.cpp > > Nit in original code: > > 556 " for thread " INTPTR_FORMAT "", > > the "" before the comma seems superfluous. Thanks for pointing that out! Rachel > > Thanks, > David > >> Thanks, >> Rachel >> >> On 12/9/2015 1:12 PM, Rachel Protacio wrote: >>> Hi, >>> >>> (Sorry if this sent twice. Thunderbird is acting up.) >>> >>> Thanks for the review. Replies inline. >>> Updated webrev: http://cr.openjdk.java.net/~rprotacio/8141211.01/ >>> >>> On 12/8/2015 10:53 PM, David Holmes wrote: >>>> Hi Rachel, >>>> >>>> On 9/12/2015 1:42 AM, Rachel Protacio wrote: >>>>> Hello, >>>>> >>>>> Please review my conversion of -XX:+TraceExceptions to >>>>> -Xlog:exceptions=info. The existing (product) flag is aliased to the >>>>> logging flag at the info level. >>>> >>>> Q: how does use of ttyLocker map into UL? I see an awful lot of >>>> multi-line logging blocks that are going to be completely messed up >>>> without locking! >>> I assumed that UL worked as-is for these instances, but I will check >>> in with Marcus. >>>> >>>> src/share/vm/opto/runtime.cpp >>>> >>>> 1239 ResourceMark rm; >>>> >>>> What requires the introduction of the ResourceMark? >>> A ResourceMark is necessary before using LogHandle output streams. >>>> >>>> --- >>>> >>>> src/share/vm/runtime/thread.cpp >>>> >>>> 2084 if (log_is_enabled(Info, exceptions)) { >>>> 2085 ResourceMark rm; >>>> >>>> An extra leading space has crept in at +2085 >>>> >>>> 2087 logstream->print("Async. exception installed at runtime >>>> exit (" INTPTR_FORMAT ")", p2i(this)); >>>> 2088 if (has_last_Java_frame()) { >>>> 2089 frame f = last_frame(); >>>> 2090 logstream->print(" (pc: " INTPTR_FORMAT " sp: " >>>> INTPTR_FORMAT " )", p2i(f.pc()), p2i(f.sp())); >>>> 2091 } >>>> >>>> Indention of these lines is wrong at #2088 and #2089 - need an >>>> additional space. >>> Thanks for catching these! >>>> >>>> 2092 logstream->print_cr(" of type: %s", >>>> InstanceKlass::cast(_pending_async_exception->klass())->external_name()); >>>> >>>> >>>> >>>> Why did the InstanceKlass::cast need to be introduced ?? >>> That was a vestige from code before a new changeset at the same line, >>> i.e. my merging the repo didn't catch this. I've gotten rid of the >>> cast. >>>> >>>> --- >>>> >>>> test/runtime/CommandLine/TraceExceptionsTest.java >>>> >>>> You improved the readability of the source code by breaking the >>>> @summary over two lines, but IIRC jtreg will write the summary into >>>> the test log with all the additional spaces you added, as the summary >>>> extends until the next tag. >>> Ok, I didn't realize that! I've undone that change. >>>> >>>> --- >>>> >>>> test/runtime/logging/ExceptionsTest.java >>>> >>>> Can you avoid the code duplication please. >>>> >>>> Also perhaps you could/should also check there are no logging >>>> statements present when logging is supposed to be disabled. I'm >>>> guessing the other logging tests haven't considered this. ?? >>> Good points. I've added a check. >>>> >>>>> If you have any questions on the alias table (in the arguments.cpp >>>>> and >>>>> .hpp files), Max will chime in as he is the one who implemented that >>>>> portion. >>>> >>>> Okay some general questions. >>>> >>>> First I would expect that aliased logging options are also marked >>>> deprecated so that we can eventually make them obsolete and remove >>>> them. >>> I'm not sure about this one. Coleen? Max? >>>> >>>> Secondly, arguably if someone specifies -XX:-TraceExceptions it >>>> should disable exception logging - which may have been turned on by >>>> -Xlog:all. >>>> >>>> Which leads to: how does the position of -XX:+/-TraceExceptions >>>> interact with the position of -Xlog:xxx on the command-line (or the >>>> other argument introducing mechanisms) ? >>> Very true. I've added an entry in the alias table to that effect. >>>> >>>> src/share/vm/runtime/arguments.cpp >>>> >>>> 2743 if(lookup_logging_aliases(option->optionString, >>>> aliased_logging_option)){ >>>> >>>> Need space after "if", and before { >>> Done. >>> >>> Thanks, >>> Rachel >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> >>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8141211/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141211 >>>>> >>>>> Testing: jtreg, JPRT, jck vm tests, refworkload performance tests, >>>>> rbt >>>>> quick & non-colo tests >>>>> >>>>> Thank you! >>>>> Rachel >>> >> From alexhenrie24 at gmail.com Tue Dec 15 20:43:21 2015 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Tue, 15 Dec 2015 13:43:21 -0700 Subject: [PATCH resend2] Skip the null pointer check before calling realloc Message-ID: <6dca8affef8a4566dfaa.1450212201@localhost.localdomain> # HG changeset patch # User Alex Henrie # Date 1447827030 25200 # Tue Nov 17 23:10:30 2015 -0700 # Node ID 6dca8affef8a4566dfaa36faeb7a14fc4086843a # Parent dc90094c0d66b3df2944da215d93542507c31e60 Skip the null pointer check before calling realloc. "If ptr is a null pointer, realloc() shall be equivalent to malloc() for the specified size." http://pubs.opengroup.org/onlinepubs/9699919799/functions/realloc.html Also, sizeof(char*) is more correct here than sizeof(char**), although in practice it doesn't make a difference. diff --git a/src/java.instrument/share/native/libinstrument/InvocationAdapter.c b/src/java.instrument/share/native/libinstrument/InvocationAdapter.c --- a/src/java.instrument/share/native/libinstrument/InvocationAdapter.c +++ b/src/java.instrument/share/native/libinstrument/InvocationAdapter.c @@ -519,21 +519,17 @@ splitPathList(const char* str, int* path int count = 0; char** segments = NULL; char* c = (char*) str; while (*c != '\0') { while (*c == ' ') c++; /* skip leading spaces */ if (*c == '\0') { break; } - if (segments == NULL) { - segments = (char**)malloc( sizeof(char**) ); - } else { - segments = (char**)realloc( segments, (count+1)*sizeof(char**) ); - } + segments = (char**)realloc( segments, (count+1)*sizeof(char*) ); jplis_assert(segments != (char**)NULL); segments[count++] = c; c = strchr(c, ' '); if (c == NULL) { break; } *c = '\0'; c++; From daniel.daugherty at oracle.com Tue Dec 15 21:56:39 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 15 Dec 2015 14:56:39 -0700 Subject: [PATCH resend2] Skip the null pointer check before calling realloc In-Reply-To: <6dca8affef8a4566dfaa.1450212201@localhost.localdomain> References: <6dca8affef8a4566dfaa.1450212201@localhost.localdomain> Message-ID: <56708C97.9010907@oracle.com> Alex, The following bug was filed to track this issue: JDK-8145278 Memory leak in splitPathList https://bugs.openjdk.java.net/browse/JDK-8145278 I added a comment to that bug report and it turns out that Dmitry had a similar comment back in November... The discussion need to move from the mailing list to the bug report. Dan On 12/15/15 1:43 PM, Alex Henrie wrote: > # HG changeset patch > # User Alex Henrie > # Date 1447827030 25200 > # Tue Nov 17 23:10:30 2015 -0700 > # Node ID 6dca8affef8a4566dfaa36faeb7a14fc4086843a > # Parent dc90094c0d66b3df2944da215d93542507c31e60 > Skip the null pointer check before calling realloc. > > "If ptr is a null pointer, realloc() shall be equivalent to malloc() for > the specified size." > http://pubs.opengroup.org/onlinepubs/9699919799/functions/realloc.html > > Also, sizeof(char*) is more correct here than sizeof(char**), although > in practice it doesn't make a difference. > > diff --git a/src/java.instrument/share/native/libinstrument/InvocationAdapter.c b/src/java.instrument/share/native/libinstrument/InvocationAdapter.c > --- a/src/java.instrument/share/native/libinstrument/InvocationAdapter.c > +++ b/src/java.instrument/share/native/libinstrument/InvocationAdapter.c > @@ -519,21 +519,17 @@ splitPathList(const char* str, int* path > int count = 0; > char** segments = NULL; > char* c = (char*) str; > while (*c != '\0') { > while (*c == ' ') c++; /* skip leading spaces */ > if (*c == '\0') { > break; > } > - if (segments == NULL) { > - segments = (char**)malloc( sizeof(char**) ); > - } else { > - segments = (char**)realloc( segments, (count+1)*sizeof(char**) ); > - } > + segments = (char**)realloc( segments, (count+1)*sizeof(char*) ); > jplis_assert(segments != (char**)NULL); > segments[count++] = c; > c = strchr(c, ' '); > if (c == NULL) { > break; > } > *c = '\0'; > c++; From alexhenrie24 at gmail.com Tue Dec 15 22:04:00 2015 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Tue, 15 Dec 2015 15:04:00 -0700 Subject: [PATCH resend2] Skip the null pointer check before calling realloc In-Reply-To: <56708C97.9010907@oracle.com> References: <6dca8affef8a4566dfaa.1450212201@localhost.localdomain> <56708C97.9010907@oracle.com> Message-ID: 2015-12-15 14:56 GMT-07:00 Daniel D. Daugherty : > The following bug was filed to track this issue: > > JDK-8145278 Memory leak in splitPathList > https://bugs.openjdk.java.net/browse/JDK-8145278 > > I added a comment to that bug report and it turns out > that Dmitry had a similar comment back in November... > > The discussion need to move from the mailing list to > the bug report. According to the JBS Overview [1], I cannot comment on bug reports until I achieve Author status, and according to the the OpenJDK Projects page [2], I cannot obtain Author status until at least two of my patches have been accepted. To date, only one patch of mine has been accepted into OpenJDK. So, even though there are two issues here (first cleaning up the code, second fixing the memory leak) I can't make any comment to that effect in the bug tracker. -Alex [1] https://wiki.openjdk.java.net/display/general/JBS+Overview [2] http://openjdk.java.net/projects/#project-author From daniel.daugherty at oracle.com Tue Dec 15 22:41:21 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 15 Dec 2015 15:41:21 -0700 Subject: [PATCH resend2] Skip the null pointer check before calling realloc In-Reply-To: References: <6dca8affef8a4566dfaa.1450212201@localhost.localdomain> <56708C97.9010907@oracle.com> Message-ID: <56709711.7030202@oracle.com> On 12/15/15 3:04 PM, Alex Henrie wrote: > 2015-12-15 14:56 GMT-07:00 Daniel D. Daugherty : >> The following bug was filed to track this issue: >> >> JDK-8145278 Memory leak in splitPathList >> https://bugs.openjdk.java.net/browse/JDK-8145278 >> >> I added a comment to that bug report and it turns out >> that Dmitry had a similar comment back in November... >> >> The discussion need to move from the mailing list to >> the bug report. > According to the JBS Overview [1], I cannot comment on bug reports > until I achieve Author status, and according to the the OpenJDK > Projects page [2], I cannot obtain Author status until at least two of > my patches have been accepted. To date, only one patch of mine has > been accepted into OpenJDK. So, even though there are two issues here > (first cleaning up the code, second fixing the memory leak) I can't > make any comment to that effect in the bug tracker. > > -Alex > > [1] https://wiki.openjdk.java.net/display/general/JBS+Overview > [2] http://openjdk.java.net/projects/#project-author Alex, Since this is a Serviceability bug, I'll let that team respond from here. Dan From chris.plummer at oracle.com Wed Dec 16 07:40:15 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 15 Dec 2015 23:40:15 -0800 Subject: [RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and nonstatic_oopmap on 32-bit systems In-Reply-To: <566FE3CF.6040209@oracle.com> References: <56620D85.8090204@oracle.com> <5666A8CA.3040004@oracle.com> <56672C25.7010909@oracle.com> <56685B78.5030106@oracle.com> <5669EF2F.2000907@oracle.com> <566FE3CF.6040209@oracle.com> Message-ID: <5671155F.2020109@oracle.com> Hi Mikael, On 12/15/15 1:56 AM, Mikael Gerdin wrote: > Hi Chris, > > sorry for the late reply. > > On 2015-12-10 22:31, Chris Plummer wrote: >> Hi Mikael, >> >> See comments inline below: >> >> On 12/9/15 8:48 AM, Mikael Gerdin wrote: >>> On 2015-12-08 20:14, Chris Plummer wrote: >>>> [Adding serviceability-dev at openjdk.java.net] >>>> >>>> Hi Mikael, >>>> >>>> Thanks for pointing this out. I'll look into it some more. Are >>>> there any >>>> tests that should be failing as a result of this? I get the feeling >>>> no, >>>> since I see other issues here that existed before my change. For >>>> example, this code is not returning the proper size if the class is >>>> anonymous or is an interface. It needs to add 1 extra word in that >>>> case. >>>> See size() in instanceKlass.hpp. >>>> >>>> Another difference from the VM code is alignObjectSize() is being used >>>> by getSize(), but headerSize is set using alignObjectOffset(). The VM >>>> code uses align_object_offset in both cases. >>>> >>>> // Align the object size. >>>> public static long alignObjectSize(long size) { >>>> return VM.getVM().alignUp(size, >>>> VM.getVM().getMinObjAlignmentInBytes()); >>>> } >>>> >>>> // All vm's align longs, so pad out certain offsets. >>>> public static long alignObjectOffset(long offset) { >>>> return VM.getVM().alignUp(offset, VM.getVM().getBytesPerLong()); >>>> } >>>> >>>> So the difference here is in the use of getMinObjAlignmentInBytes (not >>>> what the VM does) vs getBytesPerLong (what the VM uses): >>>> >>>> public int getObjectAlignmentInBytes() { >>>> if (objectAlignmentInBytes == 0) { >>>> Flag flag = getCommandLineFlag("ObjectAlignmentInBytes"); >>>> objectAlignmentInBytes = (flag == null) ? 8 : >>>> (int)flag.getIntx(); >>>> } >>>> return objectAlignmentInBytes; >>>> } >>>> >>>> So this seems wrong for use in any InstanceKlass size or embedded >>>> field >>>> offset calculation. It is probably a remnant of when class metadata >>>> was >>>> stored in the java heap, and the size of InstanceKlass had to be >>>> padded >>>> out to the minimum heap object alignment. At least it is harmless if >>>> ObjectAlignmentInBytes is not set, and if set it is only supported for >>>> 64-bit: >>>> >>>> lp64_product(intx, ObjectAlignmentInBytes, >>>> 8, \ >>>> "Default object alignment in bytes, 8 is >>>> minimum") \ >>>> range(8, >>>> 256) \ >>>> constraint(ObjectAlignmentInBytesConstraintFunc,AtParse) \ >>>> >>>> I'll get these cleaned up, but it sure would be nice if there was a >>>> way >>>> to reliably test it. >>> >>> I'd say that it's quite possible to test it! >>> Create a whitebox.cpp entry point for determining the size of a class. >> Ok, but I instead decided to use jcmd with "GC.class_stats KlassBytes" > > Sounds good. > >>> >>> Run a java program calling the entry point and printing the >>> InstanceKlass size as computed by calling InstanceKlass::size() on a >>> set of pre-determined set of complex and simple classes (vtables, >>> itables, anonymous, etc.) >> For now I just did this from the command line to do some quick checking. >> No test written. >>> Have the java program wait after it's finished printing. >>> >>> Launch the SA agent and attach it to the process. >>> Through several layers of magic, execute the incantation: >>> >>> mgerdin at mgerdin03:~/work/repos/hg/jdk9/hs-rt-work/hotspot$ >>> ../build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java >>> sun.jvm.hotspot.CLHSDB 6211 >>> Attaching to process 6211, please wait... >>> hsdb> jseval >>> "sapkg.utilities.SystemDictionaryHelper.findInstanceKlass('java/lang/Object').getSize();" >>> >>> >>> 472 >> Ok. I did this to get sizes as SA sees them. They were not just wrong >> for existing JDK, but in most cases off by a large margin. I did some >> investigating. This is InstanceKlass.getSize() >> >> public long getSize() { >> return Oop.alignObjectSize(getHeaderSize() + >> Oop.alignObjectOffset(getVtableLen()) + >> Oop.alignObjectOffset(getItableLen()) + >> Oop.alignObjectOffset(getNonstaticOopMapSize())); >> } >> >> The problem is that getHeaderSize() returns the size in bytes, but the >> others all return the size in words. They need to be multiplied by the >> word size to get the right value since the caller of getSize() expects >> the result to be in bytes. > > Oh, that seems like a familiar problem :) > >> >> So we have multiple problems with SA with respect to the >> InstanceKlass.getSize() support: >> >> * Alignment issues introduced by me. >> * Some minor other issues like using alignObjectSize when it's not >> needed, and not taking into account extra fields for interfaces and >> anonymous classes. >> * Not multiplying the vtable, itable, and oopMapSize by the number of >> bytes in a word. >> * No test available. >> >> I'm not too sure how to proceed here w.r.t. my CR. I'm inclined to just >> make the SA adjustments needed to take into consideration the alignment >> changes I've made to InstanceKlass, and file a CRs for the rest (one for >> the existing bugs and one for the lack of any test). > > It would be good if you could at least fix the obvious word size > scaling bug, I've gotten some internal guidance to limit the fixes to just the stuff that needs adjusting, and then file bugs for the rest. > filing follow ups on the extra alignObjectSize and missing extra fields. Ok. It turns out the alignObjectSize() is needed. I missed that that InstanceKlass::size() also does this, and after some internal discussion, it was agreed that it should be kept to make sure that InstanceKlass::size() is consistent with the amount of memory actually allocated for it (after the allocator does padding out to 8-bytes). However, there are some other issues to be addressed in this aligning of the size. It should not be using ObjectAlignmentInBytes, but just be doing 8-byte aligning. I'll file a bug for that, and have it cover both the InstanceKlass and SA work needed for this specific issue. A second bug will be filed for the word size scaling issue, not accounting for the extra word that interface classes and anonymous classes need, and for the lack of any test. > > The main consumer of this is the "jmap -clstats" command which is a > supported external interface for querying the sizes of metadata in > relation to their ClassLoaders. ok. thanks, Chris > > /Mikael > >> >> Please advise. >> >> thanks, >> >> Chris >> >>> >>> You could also create a javascript source file in the test directory >>> which performs the appropriate calls and do >>> hsdb> jsload /path/to/file.js >>> hsdb> jseval "doit()" >>> >>> where >>> file.js: >>> doit = function() { >>> sd = sapkg.utilities.SystemDictionaryHelper; >>> do_klass = function(name) { >>> writeln(sd.findInstanceKlass(name).getSize()); >>> } >>> >>> do_klass('java/lang/Object'); >>> do_klass('java/lang/Class'); >>> } >>> >>> >>> The only problem is that the test can't reliably execute on >>> unconfigured os x setups because of OS level security requirements for >>> attaching to processes. >>> >>> After detaching HSDB with the "quit" command you tell the debugged >>> java process to terminate, for example by printing some string on its >>> stdin. >>> >>> Easy, right? :) >>> >>> /Mikael >>> >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 12/8/15 1:54 AM, Mikael Gerdin wrote: >>>>> Hi Chris, >>>>> >>>>> Not a review but I'm fairly sure that you need to update the >>>>> serviceability agent to reflect these changes, see for example: >>>>> >>>>> public long getSize() { >>>>> return Oop.alignObjectSize( >>>>> getHeaderSize() + >>>>> Oop.alignObjectOffset(getVtableLen()) + >>>>> Oop.alignObjectOffset(getItableLen()) + >>>>> Oop.alignObjectOffset(getNonstaticOopMapSize())); >>>>> } >>>>> >>>>> in InstanceKlass.java >>>>> >>>>> /Mikael >>>>> >>>>> On 2015-12-04 23:02, Chris Plummer wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the following: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8143608 >>>>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/ >>>>>> >>>>>> >>>>>> >>>>>> A bit of background would help. The InstanceKlass object has a >>>>>> number of >>>>>> variable length fields that are laid out after the declared fields. >>>>>> When >>>>>> an InstanceKlass object is allocated, extra memory is allocated >>>>>> for it >>>>>> to leave room for these fields. The first three of these fields are >>>>>> vtable, itable, and nonstatic_oopmap. They are all arrays of >>>>>> HeapWord >>>>>> sized values, which means void* size, which means they only need >>>>>> 32-bit >>>>>> alignment on 32-bit systems. However, they have always been 64-bit >>>>>> aligned. This webrev removes the forced 64-bit alignment on 32-bit >>>>>> systems, saving footprint. >>>>>> >>>>>> This change affects all 32-bit platforms. It should have no net >>>>>> impact >>>>>> on 64-bit platforms since the fields remain (naturally) 64-bit >>>>>> aligned >>>>>> (unless of course I've introduced a bug). The intent is to not >>>>>> change >>>>>> what is done for 64-bit platforms. >>>>>> >>>>>> BTW, there is a change to AARCH64, which may seem odd at first. It >>>>>> just >>>>>> removes an "if" block where the condition should always have >>>>>> evaluated >>>>>> to false, so it should have no net affect. >>>>>> >>>>>> Tested with JPRT "-testset hotspot". Please let me know if you think >>>>>> there are any additional tests that should be run. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>> >>>> >>> >> > From chris.plummer at oracle.com Wed Dec 16 08:11:23 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 16 Dec 2015 00:11:23 -0800 Subject: [RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and nonstatic_oopmap on 32-bit systems In-Reply-To: <56700360.3060909@oracle.com> References: <56620D85.8090204@oracle.com> <5666A8CA.3040004@oracle.com> <56672C25.7010909@oracle.com> <56685B78.5030106@oracle.com> <5669EF2F.2000907@oracle.com> <56700360.3060909@oracle.com> Message-ID: <56711CAB.9030506@oracle.com> Hi Dmitry, On 12/15/15 4:11 AM, Dmitry Samersoff wrote: > Chris, > > 1. Please file a separate CR for SA (assign it to me) and go ahead with > your fix when it become ready. Ok. > > 2. As far as I understand the fix, you just removed explicit alignment > for all platforms (not only 32bit) and rely on compiler. I'm a bit > scared with it (see David's comments). I've pointed a few different reasons why this change has no impact on 64-bit. I'll try to summarize here: sizeof(InstanceKlass) is already natural word aligned (HeapWordSize aligned) because C will round the sizeof a class/struct up to align it with the largest alignment requirement of any field in the class/struct. This is to make sure arrays proper alignment of all fields of all elements in arrays. It also makes sure using ptr++ does the proper increment, and that malloc(sizeof()*count) allocates enough memory. Even if the above were not true, the last field of InstanceKlass is a pointer type, so its size (even without padding) will already be HeapWordSize aligned. And if neither of above were true, then the code is already broken. The alignment macros currently being used already assume alignment to the natural word size (HeapWordSize). The values passed into these macros are in HeapWordSize units. If for any reason the sizeof(InstanceKlass) was not already aligned to HeapWordSize, then when it is converted to HeapWordSize units, you would lose a word and get the wrong results. As for the embedded fields that occur after the InstanceKlass, they are each arrays HeapWordSize items, so as long as sizeof(InstanceKlass) is HeapWordSize aligned, these embedded fields will be also without the need for any explicit alignment. So in summary, the align_object_offset() uses on InstanceKlass fields has always been a no-op on 64-bit, and on 32-bit was used to force these fields to be 64-bit aligned instead of 32-bit aligned. Without them, all fields that align_object_offset() was being used on end up being naturally HeapWordSize aligned. Please let if this alleviates your concerns, because I'm not sure what else I can show you. I'm open to suggestions. > > Also please contact SQE (Leonid Mesnik) about testing of the fix before > pushing it. Ok. thanks, Chris > > -Dmitry > > > On 2015-12-11 00:31, Chris Plummer wrote: >> Hi Mikael, >> >> See comments inline below: >> >> On 12/9/15 8:48 AM, Mikael Gerdin wrote: >>> On 2015-12-08 20:14, Chris Plummer wrote: >>>> [Adding serviceability-dev at openjdk.java.net] >>>> >>>> Hi Mikael, >>>> >>>> Thanks for pointing this out. I'll look into it some more. Are there any >>>> tests that should be failing as a result of this? I get the feeling no, >>>> since I see other issues here that existed before my change. For >>>> example, this code is not returning the proper size if the class is >>>> anonymous or is an interface. It needs to add 1 extra word in that case. >>>> See size() in instanceKlass.hpp. >>>> >>>> Another difference from the VM code is alignObjectSize() is being used >>>> by getSize(), but headerSize is set using alignObjectOffset(). The VM >>>> code uses align_object_offset in both cases. >>>> >>>> // Align the object size. >>>> public static long alignObjectSize(long size) { >>>> return VM.getVM().alignUp(size, >>>> VM.getVM().getMinObjAlignmentInBytes()); >>>> } >>>> >>>> // All vm's align longs, so pad out certain offsets. >>>> public static long alignObjectOffset(long offset) { >>>> return VM.getVM().alignUp(offset, VM.getVM().getBytesPerLong()); >>>> } >>>> >>>> So the difference here is in the use of getMinObjAlignmentInBytes (not >>>> what the VM does) vs getBytesPerLong (what the VM uses): >>>> >>>> public int getObjectAlignmentInBytes() { >>>> if (objectAlignmentInBytes == 0) { >>>> Flag flag = getCommandLineFlag("ObjectAlignmentInBytes"); >>>> objectAlignmentInBytes = (flag == null) ? 8 : >>>> (int)flag.getIntx(); >>>> } >>>> return objectAlignmentInBytes; >>>> } >>>> >>>> So this seems wrong for use in any InstanceKlass size or embedded field >>>> offset calculation. It is probably a remnant of when class metadata was >>>> stored in the java heap, and the size of InstanceKlass had to be padded >>>> out to the minimum heap object alignment. At least it is harmless if >>>> ObjectAlignmentInBytes is not set, and if set it is only supported for >>>> 64-bit: >>>> >>>> lp64_product(intx, ObjectAlignmentInBytes, >>>> 8, \ >>>> "Default object alignment in bytes, 8 is >>>> minimum") \ >>>> range(8, >>>> 256) \ >>>> constraint(ObjectAlignmentInBytesConstraintFunc,AtParse) \ >>>> >>>> I'll get these cleaned up, but it sure would be nice if there was a way >>>> to reliably test it. >>> I'd say that it's quite possible to test it! >>> Create a whitebox.cpp entry point for determining the size of a class. >> Ok, but I instead decided to use jcmd with "GC.class_stats KlassBytes" >>> Run a java program calling the entry point and printing the >>> InstanceKlass size as computed by calling InstanceKlass::size() on a >>> set of pre-determined set of complex and simple classes (vtables, >>> itables, anonymous, etc.) >> For now I just did this from the command line to do some quick checking. >> No test written. >>> Have the java program wait after it's finished printing. >>> >>> Launch the SA agent and attach it to the process. >>> Through several layers of magic, execute the incantation: >>> >>> mgerdin at mgerdin03:~/work/repos/hg/jdk9/hs-rt-work/hotspot$ >>> ../build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java >>> sun.jvm.hotspot.CLHSDB 6211 >>> Attaching to process 6211, please wait... >>> hsdb> jseval >>> "sapkg.utilities.SystemDictionaryHelper.findInstanceKlass('java/lang/Object').getSize();" >>> >>> 472 >> Ok. I did this to get sizes as SA sees them. They were not just wrong >> for existing JDK, but in most cases off by a large margin. I did some >> investigating. This is InstanceKlass.getSize() >> >> public long getSize() { >> return Oop.alignObjectSize(getHeaderSize() + >> Oop.alignObjectOffset(getVtableLen()) + >> Oop.alignObjectOffset(getItableLen()) + >> Oop.alignObjectOffset(getNonstaticOopMapSize())); >> } >> >> The problem is that getHeaderSize() returns the size in bytes, but the >> others all return the size in words. They need to be multiplied by the >> word size to get the right value since the caller of getSize() expects >> the result to be in bytes. >> >> So we have multiple problems with SA with respect to the >> InstanceKlass.getSize() support: >> >> * Alignment issues introduced by me. >> * Some minor other issues like using alignObjectSize when it's not >> needed, and not taking into account extra fields for interfaces and >> anonymous classes. >> * Not multiplying the vtable, itable, and oopMapSize by the number of >> bytes in a word. >> * No test available. >> >> I'm not too sure how to proceed here w.r.t. my CR. I'm inclined to just >> make the SA adjustments needed to take into consideration the alignment >> changes I've made to InstanceKlass, and file a CRs for the rest (one for >> the existing bugs and one for the lack of any test). >> >> Please advise. >> >> thanks, >> >> Chris >> >>> You could also create a javascript source file in the test directory >>> which performs the appropriate calls and do >>> hsdb> jsload /path/to/file.js >>> hsdb> jseval "doit()" >>> >>> where >>> file.js: >>> doit = function() { >>> sd = sapkg.utilities.SystemDictionaryHelper; >>> do_klass = function(name) { >>> writeln(sd.findInstanceKlass(name).getSize()); >>> } >>> >>> do_klass('java/lang/Object'); >>> do_klass('java/lang/Class'); >>> } >>> >>> >>> The only problem is that the test can't reliably execute on >>> unconfigured os x setups because of OS level security requirements for >>> attaching to processes. >>> >>> After detaching HSDB with the "quit" command you tell the debugged >>> java process to terminate, for example by printing some string on its >>> stdin. >>> >>> Easy, right? :) >>> >>> /Mikael >>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 12/8/15 1:54 AM, Mikael Gerdin wrote: >>>>> Hi Chris, >>>>> >>>>> Not a review but I'm fairly sure that you need to update the >>>>> serviceability agent to reflect these changes, see for example: >>>>> >>>>> public long getSize() { >>>>> return Oop.alignObjectSize( >>>>> getHeaderSize() + >>>>> Oop.alignObjectOffset(getVtableLen()) + >>>>> Oop.alignObjectOffset(getItableLen()) + >>>>> Oop.alignObjectOffset(getNonstaticOopMapSize())); >>>>> } >>>>> >>>>> in InstanceKlass.java >>>>> >>>>> /Mikael >>>>> >>>>> On 2015-12-04 23:02, Chris Plummer wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the following: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8143608 >>>>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/ >>>>>> >>>>>> >>>>>> A bit of background would help. The InstanceKlass object has a >>>>>> number of >>>>>> variable length fields that are laid out after the declared fields. >>>>>> When >>>>>> an InstanceKlass object is allocated, extra memory is allocated for it >>>>>> to leave room for these fields. The first three of these fields are >>>>>> vtable, itable, and nonstatic_oopmap. They are all arrays of HeapWord >>>>>> sized values, which means void* size, which means they only need >>>>>> 32-bit >>>>>> alignment on 32-bit systems. However, they have always been 64-bit >>>>>> aligned. This webrev removes the forced 64-bit alignment on 32-bit >>>>>> systems, saving footprint. >>>>>> >>>>>> This change affects all 32-bit platforms. It should have no net impact >>>>>> on 64-bit platforms since the fields remain (naturally) 64-bit aligned >>>>>> (unless of course I've introduced a bug). The intent is to not change >>>>>> what is done for 64-bit platforms. >>>>>> >>>>>> BTW, there is a change to AARCH64, which may seem odd at first. It >>>>>> just >>>>>> removes an "if" block where the condition should always have evaluated >>>>>> to false, so it should have no net affect. >>>>>> >>>>>> Tested with JPRT "-testset hotspot". Please let me know if you think >>>>>> there are any additional tests that should be run. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> > From marcus.larsson at oracle.com Wed Dec 16 08:46:18 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 16 Dec 2015 09:46:18 +0100 Subject: RFR: 8145294: TestLogRotation.java triggers a race in the UL framework Message-ID: <567124DA.204@oracle.com> Hi, Please review the following patch to fix a race in file rotations with UL. Summary: freopen and fwrite are not safe to use concurrently and hence the VM might crash if a thread tries to write during a rotation. Writing and rotating needs to be properly synchronized, but using a Mutex is problematic here because the synchronization must be usable already at argument parse time. The patch replaces the previously used mutexes with semaphores (like with the LogConfiguration_lock case). LogFileOutputs are now rotatable at any time and the LogOutput interface has been simplified to reflect this. Webrev: http://cr.openjdk.java.net/~mlarsson/8145294/ Issue: https://bugs.openjdk.java.net/browse/JDK-8145294 Testing: TestLogRotation in RBT and locally Thanks, Marcus From mikael.gerdin at oracle.com Wed Dec 16 09:01:03 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 16 Dec 2015 10:01:03 +0100 Subject: [RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and nonstatic_oopmap on 32-bit systems In-Reply-To: <5671155F.2020109@oracle.com> References: <56620D85.8090204@oracle.com> <5666A8CA.3040004@oracle.com> <56672C25.7010909@oracle.com> <56685B78.5030106@oracle.com> <5669EF2F.2000907@oracle.com> <566FE3CF.6040209@oracle.com> <5671155F.2020109@oracle.com> Message-ID: <5671284F.6090808@oracle.com> Hi Chris, On 2015-12-16 08:40, Chris Plummer wrote: > Hi Mikael, > > On 12/15/15 1:56 AM, Mikael Gerdin wrote: >> Hi Chris, >> >> sorry for the late reply. >> >> On 2015-12-10 22:31, Chris Plummer wrote: >>> Hi Mikael, >>> >>> See comments inline below: >>> >>> On 12/9/15 8:48 AM, Mikael Gerdin wrote: >>>> On 2015-12-08 20:14, Chris Plummer wrote: >>>>> [Adding serviceability-dev at openjdk.java.net] >>>>> >>>>> Hi Mikael, >>>>> >>>>> Thanks for pointing this out. I'll look into it some more. Are >>>>> there any >>>>> tests that should be failing as a result of this? I get the feeling >>>>> no, >>>>> since I see other issues here that existed before my change. For >>>>> example, this code is not returning the proper size if the class is >>>>> anonymous or is an interface. It needs to add 1 extra word in that >>>>> case. >>>>> See size() in instanceKlass.hpp. >>>>> >>>>> Another difference from the VM code is alignObjectSize() is being used >>>>> by getSize(), but headerSize is set using alignObjectOffset(). The VM >>>>> code uses align_object_offset in both cases. >>>>> >>>>> // Align the object size. >>>>> public static long alignObjectSize(long size) { >>>>> return VM.getVM().alignUp(size, >>>>> VM.getVM().getMinObjAlignmentInBytes()); >>>>> } >>>>> >>>>> // All vm's align longs, so pad out certain offsets. >>>>> public static long alignObjectOffset(long offset) { >>>>> return VM.getVM().alignUp(offset, VM.getVM().getBytesPerLong()); >>>>> } >>>>> >>>>> So the difference here is in the use of getMinObjAlignmentInBytes (not >>>>> what the VM does) vs getBytesPerLong (what the VM uses): >>>>> >>>>> public int getObjectAlignmentInBytes() { >>>>> if (objectAlignmentInBytes == 0) { >>>>> Flag flag = getCommandLineFlag("ObjectAlignmentInBytes"); >>>>> objectAlignmentInBytes = (flag == null) ? 8 : >>>>> (int)flag.getIntx(); >>>>> } >>>>> return objectAlignmentInBytes; >>>>> } >>>>> >>>>> So this seems wrong for use in any InstanceKlass size or embedded >>>>> field >>>>> offset calculation. It is probably a remnant of when class metadata >>>>> was >>>>> stored in the java heap, and the size of InstanceKlass had to be >>>>> padded >>>>> out to the minimum heap object alignment. At least it is harmless if >>>>> ObjectAlignmentInBytes is not set, and if set it is only supported for >>>>> 64-bit: >>>>> >>>>> lp64_product(intx, ObjectAlignmentInBytes, >>>>> 8, \ >>>>> "Default object alignment in bytes, 8 is >>>>> minimum") \ >>>>> range(8, >>>>> 256) \ >>>>> constraint(ObjectAlignmentInBytesConstraintFunc,AtParse) \ >>>>> >>>>> I'll get these cleaned up, but it sure would be nice if there was a >>>>> way >>>>> to reliably test it. >>>> >>>> I'd say that it's quite possible to test it! >>>> Create a whitebox.cpp entry point for determining the size of a class. >>> Ok, but I instead decided to use jcmd with "GC.class_stats KlassBytes" >> >> Sounds good. >> >>>> >>>> Run a java program calling the entry point and printing the >>>> InstanceKlass size as computed by calling InstanceKlass::size() on a >>>> set of pre-determined set of complex and simple classes (vtables, >>>> itables, anonymous, etc.) >>> For now I just did this from the command line to do some quick checking. >>> No test written. >>>> Have the java program wait after it's finished printing. >>>> >>>> Launch the SA agent and attach it to the process. >>>> Through several layers of magic, execute the incantation: >>>> >>>> mgerdin at mgerdin03:~/work/repos/hg/jdk9/hs-rt-work/hotspot$ >>>> ../build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java >>>> sun.jvm.hotspot.CLHSDB 6211 >>>> Attaching to process 6211, please wait... >>>> hsdb> jseval >>>> "sapkg.utilities.SystemDictionaryHelper.findInstanceKlass('java/lang/Object').getSize();" >>>> >>>> >>>> 472 >>> Ok. I did this to get sizes as SA sees them. They were not just wrong >>> for existing JDK, but in most cases off by a large margin. I did some >>> investigating. This is InstanceKlass.getSize() >>> >>> public long getSize() { >>> return Oop.alignObjectSize(getHeaderSize() + >>> Oop.alignObjectOffset(getVtableLen()) + >>> Oop.alignObjectOffset(getItableLen()) + >>> Oop.alignObjectOffset(getNonstaticOopMapSize())); >>> } >>> >>> The problem is that getHeaderSize() returns the size in bytes, but the >>> others all return the size in words. They need to be multiplied by the >>> word size to get the right value since the caller of getSize() expects >>> the result to be in bytes. >> >> Oh, that seems like a familiar problem :) >> >>> >>> So we have multiple problems with SA with respect to the >>> InstanceKlass.getSize() support: >>> >>> * Alignment issues introduced by me. >>> * Some minor other issues like using alignObjectSize when it's not >>> needed, and not taking into account extra fields for interfaces and >>> anonymous classes. >>> * Not multiplying the vtable, itable, and oopMapSize by the number of >>> bytes in a word. >>> * No test available. >>> >>> I'm not too sure how to proceed here w.r.t. my CR. I'm inclined to just >>> make the SA adjustments needed to take into consideration the alignment >>> changes I've made to InstanceKlass, and file a CRs for the rest (one for >>> the existing bugs and one for the lack of any test). >> >> It would be good if you could at least fix the obvious word size >> scaling bug, > I've gotten some internal guidance to limit the fixes to just the stuff > that needs adjusting, and then file bugs for the rest. Ok. >> filing follow ups on the extra alignObjectSize and missing extra fields. > Ok. It turns out the alignObjectSize() is needed. I missed that that > InstanceKlass::size() also does this, and after some internal > discussion, it was agreed that it should be kept to make sure that > InstanceKlass::size() is consistent with the amount of memory actually > allocated for it (after the allocator does padding out to 8-bytes). > However, there are some other issues to be addressed in this aligning of > the size. It should not be using ObjectAlignmentInBytes, but just be > doing 8-byte aligning. I'll file a bug for that, and have it cover both > the InstanceKlass and SA work needed for this specific issue. A second > bug will be filed for the word size scaling issue, not accounting for > the extra word that interface classes and anonymous classes need, and > for the lack of any test. Ok. /Mikael >> >> The main consumer of this is the "jmap -clstats" command which is a >> supported external interface for querying the sizes of metadata in >> relation to their ClassLoaders. > ok. > > thanks, > > Chris >> >> /Mikael >> >>> >>> Please advise. >>> >>> thanks, >>> >>> Chris >>> >>>> >>>> You could also create a javascript source file in the test directory >>>> which performs the appropriate calls and do >>>> hsdb> jsload /path/to/file.js >>>> hsdb> jseval "doit()" >>>> >>>> where >>>> file.js: >>>> doit = function() { >>>> sd = sapkg.utilities.SystemDictionaryHelper; >>>> do_klass = function(name) { >>>> writeln(sd.findInstanceKlass(name).getSize()); >>>> } >>>> >>>> do_klass('java/lang/Object'); >>>> do_klass('java/lang/Class'); >>>> } >>>> >>>> >>>> The only problem is that the test can't reliably execute on >>>> unconfigured os x setups because of OS level security requirements for >>>> attaching to processes. >>>> >>>> After detaching HSDB with the "quit" command you tell the debugged >>>> java process to terminate, for example by printing some string on its >>>> stdin. >>>> >>>> Easy, right? :) >>>> >>>> /Mikael >>>> >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 12/8/15 1:54 AM, Mikael Gerdin wrote: >>>>>> Hi Chris, >>>>>> >>>>>> Not a review but I'm fairly sure that you need to update the >>>>>> serviceability agent to reflect these changes, see for example: >>>>>> >>>>>> public long getSize() { >>>>>> return Oop.alignObjectSize( >>>>>> getHeaderSize() + >>>>>> Oop.alignObjectOffset(getVtableLen()) + >>>>>> Oop.alignObjectOffset(getItableLen()) + >>>>>> Oop.alignObjectOffset(getNonstaticOopMapSize())); >>>>>> } >>>>>> >>>>>> in InstanceKlass.java >>>>>> >>>>>> /Mikael >>>>>> >>>>>> On 2015-12-04 23:02, Chris Plummer wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review the following: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8143608 >>>>>>> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> A bit of background would help. The InstanceKlass object has a >>>>>>> number of >>>>>>> variable length fields that are laid out after the declared fields. >>>>>>> When >>>>>>> an InstanceKlass object is allocated, extra memory is allocated >>>>>>> for it >>>>>>> to leave room for these fields. The first three of these fields are >>>>>>> vtable, itable, and nonstatic_oopmap. They are all arrays of >>>>>>> HeapWord >>>>>>> sized values, which means void* size, which means they only need >>>>>>> 32-bit >>>>>>> alignment on 32-bit systems. However, they have always been 64-bit >>>>>>> aligned. This webrev removes the forced 64-bit alignment on 32-bit >>>>>>> systems, saving footprint. >>>>>>> >>>>>>> This change affects all 32-bit platforms. It should have no net >>>>>>> impact >>>>>>> on 64-bit platforms since the fields remain (naturally) 64-bit >>>>>>> aligned >>>>>>> (unless of course I've introduced a bug). The intent is to not >>>>>>> change >>>>>>> what is done for 64-bit platforms. >>>>>>> >>>>>>> BTW, there is a change to AARCH64, which may seem odd at first. It >>>>>>> just >>>>>>> removes an "if" block where the condition should always have >>>>>>> evaluated >>>>>>> to false, so it should have no net affect. >>>>>>> >>>>>>> Tested with JPRT "-testset hotspot". Please let me know if you think >>>>>>> there are any additional tests that should be run. >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>> >>>>> >>>> >>> >> > From markus.gronlund at oracle.com Wed Dec 16 09:32:59 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Wed, 16 Dec 2015 01:32:59 -0800 (PST) Subject: RFR: 8145294: TestLogRotation.java triggers a race in the UL framework In-Reply-To: <567124DA.204@oracle.com> References: <567124DA.204@oracle.com> Message-ID: <38eaa2ba-5c3a-4a3b-ac8d-6e380e9ac11b@default> Hi Marcus, Looks good, thanks for fixing. As we spoke out-of-band, post this fix, lets figure a way of how to generalize this with some kind of SemaphoreAcquireRelease utility. /Markus -----Original Message----- From: Marcus Larsson Sent: den 16 december 2015 09:46 To: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: RFR: 8145294: TestLogRotation.java triggers a race in the UL framework Hi, Please review the following patch to fix a race in file rotations with UL. Summary: freopen and fwrite are not safe to use concurrently and hence the VM might crash if a thread tries to write during a rotation. Writing and rotating needs to be properly synchronized, but using a Mutex is problematic here because the synchronization must be usable already at argument parse time. The patch replaces the previously used mutexes with semaphores (like with the LogConfiguration_lock case). LogFileOutputs are now rotatable at any time and the LogOutput interface has been simplified to reflect this. Webrev: http://cr.openjdk.java.net/~mlarsson/8145294/ Issue: https://bugs.openjdk.java.net/browse/JDK-8145294 Testing: TestLogRotation in RBT and locally Thanks, Marcus From alexander.kulyakhtin at oracle.com Wed Dec 16 12:05:03 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 16 Dec 2015 04:05:03 -0800 (PST) Subject: RFR: 8145408: "com/sun/jdi/BreakpointWithFullGC.sh: Required output "Full GC" not found" Message-ID: <474da0df-f578-4572-839d-935ca560773c@default> Hi, Could you, please, review this small test-only fix: CR: https://bugs.openjdk.java.net/browse/JDK-8145408 "com/sun/jdi/BreakpointWithFullGC.sh: Required output "Full GC" not found" Webrev: http://cr.openjdk.java.net/~akulyakh/8145408/test/com/sun/jdi/BreakpointWithFullGC.sh.udiff.html The test, among other things, verifies that an indication of a Full GC event is present in the output. Recently, such an indication has been changed from similar to: [Full GC (System.gc()) 2663K->2663K(31744K), 0.0034321 secs] to similar to: [3.326s][info ][gc] GC(10) Pause Full (System.gc()) 11M->3M(12M) (3.312s, 3.326s) 14.405ms We are changing the matcher correspondingly, also making it more precise. Best regards, Alexander From jaroslav.bachorik at oracle.com Wed Dec 16 12:45:16 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 16 Dec 2015 13:45:16 +0100 Subject: RFR: 8145408: "com/sun/jdi/BreakpointWithFullGC.sh: Required output "Full GC" not found" In-Reply-To: <474da0df-f578-4572-839d-935ca560773c@default> References: <474da0df-f578-4572-839d-935ca560773c@default> Message-ID: <56715CDC.9040400@oracle.com> On 16.12.2015 13:05, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review this small test-only fix: > > CR: https://bugs.openjdk.java.net/browse/JDK-8145408 "com/sun/jdi/BreakpointWithFullGC.sh: Required output "Full GC" not found" > Webrev: http://cr.openjdk.java.net/~akulyakh/8145408/test/com/sun/jdi/BreakpointWithFullGC.sh.udiff.html > > The test, among other things, verifies that an indication of a Full GC event is present in the output. > > Recently, such an indication has been changed from similar to: > [Full GC (System.gc()) 2663K->2663K(31744K), 0.0034321 secs] > > to similar to: > [3.326s][info ][gc] GC(10) Pause Full (System.gc()) 11M->3M(12M) (3.312s, 3.326s) 14.405ms > > We are changing the matcher correspondingly, also making it more precise. The change looks good and fixes the problem with the changed logging output. For future, it would be also good to convert the test to Java only, along with other JDI shell tests. Cheers, -JB- > > Best regards, > Alexander > From alexander.kulyakhtin at oracle.com Wed Dec 16 13:11:04 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 16 Dec 2015 05:11:04 -0800 (PST) Subject: RFR: 8145408: "com/sun/jdi/BreakpointWithFullGC.sh: Required output "Full GC" not found" Message-ID: <11e31c33-3f78-4804-8f10-dd64df159a1a@default> Jaroslav, Thank you very much for the review. We are going to submit an enhancement to convert the existing jdi shell tests from scripts to java. As this shell test, along with several others, depends on a common shell script, all the depending tests will need to be modified in the course of such conversion. Best regards, Alexander ----- Original Message ----- From: jaroslav.bachorik at oracle.com To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net Cc: staffan.larsen at oracle.com Sent: Wednesday, December 16, 2015 3:45:18 PM GMT +03:00 Iraq Subject: Re: RFR: 8145408: "com/sun/jdi/BreakpointWithFullGC.sh: Required output "Full GC" not found" On 16.12.2015 13:05, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review this small test-only fix: > > CR: https://bugs.openjdk.java.net/browse/JDK-8145408 "com/sun/jdi/BreakpointWithFullGC.sh: Required output "Full GC" not found" > Webrev: http://cr.openjdk.java.net/~akulyakh/8145408/test/com/sun/jdi/BreakpointWithFullGC.sh.udiff.html > > The test, among other things, verifies that an indication of a Full GC event is present in the output. > > Recently, such an indication has been changed from similar to: > [Full GC (System.gc()) 2663K->2663K(31744K), 0.0034321 secs] > > to similar to: > [3.326s][info ][gc] GC(10) Pause Full (System.gc()) 11M->3M(12M) (3.312s, 3.326s) 14.405ms > > We are changing the matcher correspondingly, also making it more precise. The change looks good and fixes the problem with the changed logging output. For future, it would be also good to convert the test to Java only, along with other JDI shell tests. Cheers, -JB- > > Best regards, > Alexander > From jaroslav.bachorik at oracle.com Wed Dec 16 14:36:29 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 16 Dec 2015 15:36:29 +0100 Subject: RFR 8145417: JInfoSanityTest failed with Error attaching to remote server: java.rmi.ConnectException: Connection refused Message-ID: <567176ED.5050208@oracle.com> Please, review the following simple test change Issue : https://bugs.openjdk.java.net/browse/JDK-8145417 Webrev: http://cr.openjdk.java.net/~jbachorik/8145417/webrev.00 The affected tests check for 'Unknown host' in stderr. In some situations this line may not appear, although an alternative error indicating unavailability of the target host is thrown, and it is necessary to make the error matching more robust (eg. checking also for 'Connection refused to host:' message). Thanks, -JB- From daniel.daugherty at oracle.com Wed Dec 16 14:59:02 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 16 Dec 2015 07:59:02 -0700 Subject: RFR: 8145408: "com/sun/jdi/BreakpointWithFullGC.sh: Required output "Full GC" not found" In-Reply-To: <474da0df-f578-4572-839d-935ca560773c@default> References: <474da0df-f578-4572-839d-935ca560773c@default> Message-ID: <56717C36.2070202@oracle.com> You might want to include a comment like: # Prior to JDK9-BNN, the pattern was 'Full GC' where NN is the promoted build where the format changed. This will help anyone backporting test fixes to older releases. Dan On 12/16/15 5:05 AM, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review this small test-only fix: > > CR: https://bugs.openjdk.java.net/browse/JDK-8145408 "com/sun/jdi/BreakpointWithFullGC.sh: Required output "Full GC" not found" > Webrev: http://cr.openjdk.java.net/~akulyakh/8145408/test/com/sun/jdi/BreakpointWithFullGC.sh.udiff.html > > The test, among other things, verifies that an indication of a Full GC event is present in the output. > > Recently, such an indication has been changed from similar to: > [Full GC (System.gc()) 2663K->2663K(31744K), 0.0034321 secs] > > to similar to: > [3.326s][info ][gc] GC(10) Pause Full (System.gc()) 11M->3M(12M) (3.312s, 3.326s) 14.405ms > > We are changing the matcher correspondingly, also making it more precise. > > Best regards, > Alexander From jaroslav.bachorik at oracle.com Wed Dec 16 15:07:20 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 16 Dec 2015 16:07:20 +0100 Subject: RFR: JDK-8058865 JMX Test Refactoring In-Reply-To: <567059AA.90504@oracle.com> References: <567059AA.90504@oracle.com> Message-ID: <56717E28.6080707@oracle.com> Hi, On 15.12.2015 19:19, olivier.lagneau at oracle.com wrote: > Hi, > > Please review the following changes for task "JDK-8058865 : JMX Test > Refactoring" > > Issue: https://bugs.openjdk.java.net/browse/JDK-8058865 > Webrev: http://cr.openjdk.java.net/~olagneau/8058865/webrev.06/ > > Issue Description: > " The majority of the JMX related tests are in JTreg. There is a small > bunch of functional tests > which are written for DTonga and executed separately for promoted builds. > They are a mix of functional, stress and integration tests. > They should be ported over the JVM testbase or a stresstest harness." > > An analysis of the various tests in the JMX Tonga test suite has been > done first. > The outcome has been a list of functional tests that were relevant for a > port to > Jtreg environment (tests uncovered by current jdk unit tests). > > Some of the tests (MonitorThread tests) have shown to be unstable under > stressed > running context like can be happening with nightly test runs. They will > have to > be redesigned trying to eliminate the intermittent failure under > stressed context, > and thus are not part of this port. > > The list of ported tests is the following, all under > jdk/test/javax/management: > - MBeanServer/ExceptionTest.java > - mxbean/MXBeanExceptionHandlingTest.java > - mxbean/MXBeanInteropTest1.java > - mxbean/MXBeanInteropTest2.java > - mxbean/MXBeanLoadingTest1.java > - mxbean/MXBeanNotifTest.java > - mxbean/MXBeanWeirdParamTest.java > - query/SupportedQueryTypesTest.java > - security/AuthorizationTest.java > - security/SecurityTest.java > > This makes it an additional set of ~50 tests, using some utility > classes, config > and security files, making a total of 46 new files. > > This is a refactoring of test for jtreg running environment, not a redesign. > The tests have been modified to be able to run in this environment. > Some of them (MXBeanWeirdParamTest, > AuthorizationTest.java,SecurityTest.java) > need to be run in a distributed context. They run on a single machine with > 2 separate processes: a parent one (running the "mbean" server part) which > runs a subprocess process playing the role of the client. > > An internal review has been done first before this open review. That is the > reason for this review number of the webrev (webrev.06). > > Tests have been checked on jprt with both product and fastdebug builds, and > also checked running under stressed conditions. The total run time is > between > 5 and 10 minutes. > > Thanks for any feedback, Thumbs up from me! -JB- > > Olivier Lagneau > > From staffan.larsen at oracle.com Wed Dec 16 15:11:56 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 16 Dec 2015 16:11:56 +0100 Subject: RFR: 8145408: "com/sun/jdi/BreakpointWithFullGC.sh: Required output "Full GC" not found" In-Reply-To: <474da0df-f578-4572-839d-935ca560773c@default> References: <474da0df-f578-4572-839d-935ca560773c@default> Message-ID: <71AEC626-AECE-449F-B3CD-05A98736D6CB@oracle.com> Looks good! Thanks, /Staffan > On 16 dec. 2015, at 13:05, Alexander Kulyakhtin wrote: > > Hi, > > Could you, please, review this small test-only fix: > > CR: https://bugs.openjdk.java.net/browse/JDK-8145408 "com/sun/jdi/BreakpointWithFullGC.sh: Required output "Full GC" not found" > Webrev: http://cr.openjdk.java.net/~akulyakh/8145408/test/com/sun/jdi/BreakpointWithFullGC.sh.udiff.html > > The test, among other things, verifies that an indication of a Full GC event is present in the output. > > Recently, such an indication has been changed from similar to: > [Full GC (System.gc()) 2663K->2663K(31744K), 0.0034321 secs] > > to similar to: > [3.326s][info ][gc] GC(10) Pause Full (System.gc()) 11M->3M(12M) (3.312s, 3.326s) 14.405ms > > We are changing the matcher correspondingly, also making it more precise. > > Best regards, > Alexander From alexander.kulyakhtin at oracle.com Wed Dec 16 16:11:05 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 16 Dec 2015 08:11:05 -0800 (PST) Subject: RFR: 8145408: "com/sun/jdi/BreakpointWithFullGC.sh: Required output "Full GC" not found" Message-ID: <0af0d61f-30be-41c8-93d5-88d26df77318@default> Daniel, Thank you very much for the review. I'm going to add the comment as you have suggested. Best regards, Alexander ----- Original Message ----- From: daniel.daugherty at oracle.com To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net Sent: Wednesday, December 16, 2015 5:58:03 PM GMT +03:00 Iraq Subject: Re: RFR: 8145408: "com/sun/jdi/BreakpointWithFullGC.sh: Required output "Full GC" not found" You might want to include a comment like: # Prior to JDK9-BNN, the pattern was 'Full GC' where NN is the promoted build where the format changed. This will help anyone backporting test fixes to older releases. Dan On 12/16/15 5:05 AM, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review this small test-only fix: > > CR: https://bugs.openjdk.java.net/browse/JDK-8145408 "com/sun/jdi/BreakpointWithFullGC.sh: Required output "Full GC" not found" > Webrev: http://cr.openjdk.java.net/~akulyakh/8145408/test/com/sun/jdi/BreakpointWithFullGC.sh.udiff.html > > The test, among other things, verifies that an indication of a Full GC event is present in the output. > > Recently, such an indication has been changed from similar to: > [Full GC (System.gc()) 2663K->2663K(31744K), 0.0034321 secs] > > to similar to: > [3.326s][info ][gc] GC(10) Pause Full (System.gc()) 11M->3M(12M) (3.312s, 3.326s) 14.405ms > > We are changing the matcher correspondingly, also making it more precise. > > Best regards, > Alexander From kubota.yuji at gmail.com Wed Dec 16 17:05:05 2015 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Thu, 17 Dec 2015 02:05:05 +0900 Subject: Potential infinite waiting at JMXConnection#createConnection Message-ID: Hi all, If Shanliang cannot review, someone could review it? I reported this issue first at the below. http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-April/002152.html http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-May/017241.html Hope this patch helps to community. Thanks, Yuji 2015-12-10 22:40 GMT+09:00 KUBOTA Yuji : > Hi Shanliang and all, > > Sorry my reply is too late. But, finally, I reproduced this issue by > following test program! :) > Could you please review test program and my patch ? > > The test program includes some files, but I do not have an account of > openjdk, so I push it on icedtea server as below. > > http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/file/e31044f0804f > > The test program starts a simple sleep server program (JMXSSLServer) > on external jdb process with a breakpoint at > sun.security.ssl.ServerHandshaker.clientHello set. It then starts a > client process (JMXSSLCient) which tries to connect the sleep/jdb > process. > ServerHandshaker.clientHello responds to the client hello message and > sends SSL record back. By setting breakpont in that function, we can > emulate this issue in which client keeps waiting SSL record from > server. > Now, JMXConnectorFactory.connect() ignores > sun.rmi.transport.tcp.responseTimeout, so wait the response (SSL > record) from server INFINITELY. Once my patch (jdk9.patch) was added, > then the client will return 0 when the connection timeout happen by > sun.rmi.transport.tcp.responseTimeout. > And test program returns the client's return code. > > You can reproduce infinite waiting by the below. > * hg clone http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/ > * cd fixLoopAtJMXConnectorFactory/testProgram > * set JAVA_HOME > * mvn package > * setting debugcontrol.properties if you need. > * *NOTE* This test program will stop for "debugcontroltest.stop_time" ms. > * ${JAVA_HOME}/bin/java -cp .:target/debugcontrol-1.0-SNAPSHOT.jar > debugcontrol.DebugController > > * The result by JDK without my patch. > The client throws java.net.ConnectException after sending quit to jdb. > ------ > [INFO] Server process args > args[0] /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-3.b17.fc23.x86_64/bin/jdb > : > : > cli-out: [INFO] Service URL: service:jmx:rmi:///jndi/rmi://localhost:9876/jmxrmi > ser-err: Set deferred breakpoint sun.security.ssl.ServerHandshaker.clientHello > ser-out: > ser-err: Breakpoint hit: "thread=RMI TCP Connection(2)-127.0.0.1", > sun.security.ssl.ServerHandshaker.clientHello(), line=339 bci=0 > ser-out: > [INFO] sending quit to jdb > ser-err: RMI TCP Connection(2)-127.0.0.1[1] > cli-err: java.rmi.ConnectException: Connection refused to host: > 127.0.0.1; nested exception is: > cli-err: java.net.ConnectException: Connection refused > cli-err: at > sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619) > cli-err: at > sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216) > cli-err: at > sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202) > cli-err: at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:130) > cli-err: at > javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown > Source) > cli-err: at > javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2432) > cli-err: at > javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:308) > cli-err: at > javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270) > cli-err: at > debugcontrol.client.JMXSSLClient.execute(JMXSSLClient.java:51) > cli-err: at debugcontrol.client.JMXSSLClient.main(JMXSSLClient.java:34) > cli-err: Caused by: java.net.ConnectException: Connection refused > cli-err: at java.net.PlainSocketImpl.socketConnect(Native Method) > cli-err: at > java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) > cli-err: at > java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) > cli-err: at > java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) > cli-err: at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > cli-err: at java.net.Socket.connect(Socket.java:589) > cli-err: at > sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668) > cli-err: at sun.security.ssl.SSLSocketImpl.(SSLSocketImpl.java:427) > cli-err: at > sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:88) > cli-err: at > javax.rmi.ssl.SslRMIClientSocketFactory.createSocket(SslRMIClientSocketFactory.java:121) > cli-err: at > sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613) > cli-err: ... 9 more > [INFO] Thu Dec 10 16:16:50 JST 2015 Client done. Result code: 2 > [INFO] Client took 114462 msec. > > * By JDK 9 with my patch. > The client got java.net.SocketTimeoutException after the connection > timeout happen, then return 0. > ------ > [INFO] Server process args > args[0] /workspace/jdk9-netdev-patch/build/linux-x86_64-normal-server-release/jdk/bin/jdb > args[1] -classpath > args[2] target/classes > args[3] -J-Duser.language=en > args[4] -Dcom.sun.management.jmxremote.port=9876 > args[5] -Dcom.sun.management.jmxremote.password.file=jmxremote.password > args[6] -Djavax.net.ssl.keyStore=jmx-test-cert.pkcs12 > args[7] -Djavax.net.ssl.keyStoreType=pkcs12 > args[8] -Djavax.net.ssl.keyStorePassword=changeit > args[9] debugcontrol.server.JMXSSLServer > ser-out: Initializing jdb ... > ser-err: > Deferring breakpoint sun.security.ssl.ServerHandshaker.clientHello. > ser-out: It will be set after the class is loaded. > ser-err: > run debugcontrol.server.JMXSSLServer > ser-err: Set uncaught java.lang.Throwable > ser-out: Set deferred uncaught java.lang.Throwable > ser-err: > > ser-out: VM Started: [INFO] Server launched then sleep... > [INFO] Client process args: > args[0] /workspace/jdk9-netdev-patch/build/linux-x86_64-normal-server-release/jdk/bin/java > args[1] -classpath > args[2] target/classes > args[3] -Duser.language=en > args[4] -Djavax.net.ssl.trustStore=jmx-test-cert.pkcs12 > args[5] -Djavax.net.ssl.trustStoreType=pkcs12 > args[6] -Djavax.net.ssl.trustStorePassword=changeit > args[7] -Dsun.rmi.transport.tcp.responseTimeout=1000 > args[8] -Dsun.rmi.transport.tcp.handshakeTimeout=1000 > args[9] debugcontrol.client.JMXSSLClient > args[10] localhost > args[11] 9876 > cli-out: [INFO] Service URL: service:jmx:rmi:///jndi/rmi://localhost:9876/jmxrmi > ser-err: Set deferred breakpoint sun.security.ssl.ServerHandshaker.clientHello > ser-out: > ser-err: Breakpoint hit: "thread=RMI TCP Connection(2)-127.0.0.1", > sun.security.ssl.ServerHandshaker.clientHello(), line=356 bci=0 > ser-out: > cli-out: [INFO] Conglaturation. We got a timeout. > [INFO] Thu Dec 10 15:54:39 JST 2015 Client done. Result code: 0 > > > * My patch (no change from the reported) > * http://icedtea.classpath.org/people/ykubota/fixLoopAtJMXConnectorFactory/file/e31044f0804f/jdk9.patch > ------ > diff --git a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java > b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java > --- a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java > +++ b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java > @@ -224,6 +224,22 @@ > out.writeByte(TransportConstants.SingleOpProtocol); > } else { > out.writeByte(TransportConstants.StreamProtocol); > + > + int usableSoTimeout = 0; > + try { > + /* > + * If socket factory had set a non-zero timeout on its > + * own, then restore it instead of using the property- > + * configured value. > + */ > + usableSoTimeout = sock.getSoTimeout(); > + if (usableSoTimeout == 0) { > + usableSoTimeout = responseTimeout; > + } > + sock.setSoTimeout(usableSoTimeout); > + } catch (Exception e) { > + // if we fail to set this, ignore and proceed anyway > + } > out.flush(); > > /* > @@ -231,9 +247,7 @@ > * connection handshake; this also serves to guard against > * non-JRMP servers that do not respond (see 4322806). > */ > - int originalSoTimeout = 0; > try { > - originalSoTimeout = sock.getSoTimeout(); > sock.setSoTimeout(handshakeTimeout); > } catch (Exception e) { > // if we fail to set this, ignore and proceed anyway > @@ -281,14 +295,7 @@ > * that a remote method call is permitted to execute. > */ > try { > - /* > - * If socket factory had set a non-zero timeout on its > - * own, then restore it instead of using the property- > - * configured value. > - */ > - sock.setSoTimeout((originalSoTimeout != 0 ? > - originalSoTimeout : > - responseTimeout)); > + sock.setSoTimeout(usableSoTimeout); > } catch (Exception e) { > // if we fail to set this, ignore and proceed anyway > } > > Thanks, > Yuji From kim.barrett at oracle.com Wed Dec 16 17:07:11 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 16 Dec 2015 12:07:11 -0500 Subject: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration In-Reply-To: <56702DDF.9060407@oracle.com> References: <566E962D.8010107@oracle.com> <566ED7F8.4090204@oracle.com> <566EE0AF.9010905@oracle.com> <566FEA83.6060105@oracle.com> <15686d26-99f4-449b-b5a8-f342632b2922@default> <56702DDF.9060407@oracle.com> Message-ID: <748D61D7-8CFC-42B3-959B-31D75A926133@oracle.com> On Dec 15, 2015, at 10:12 AM, Marcus Larsson wrote: > > I think it's worth another round. :) > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.04/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.03-04/ Looks good. I like the reorganization around the ConfigurationLock class. From david.holmes at oracle.com Wed Dec 16 20:52:27 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Dec 2015 06:52:27 +1000 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <5670775A.4060806@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> Message-ID: <5671CF0B.20003@oracle.com> Hi Rachel, On 16/12/2015 6:26 AM, Rachel Protacio wrote: > Hi, > > Thanks for the comments, David. > > I had messed up my uploading before and had not actually updated the > open html. So for real this time, the most recent webrev is at > http://cr.openjdk.java.net/~rprotacio/8141211.01/ Of note: > - each incident of ttyLocker that involved separate logging lines for > the same message have been consolidated to one line > - each incident of ttyLocker that involved separate print statements to > one logging line has been changed to write to a buffer first, then print > the entire line at once to the log stream I think I may be missing something here, sorry. Taking src/share/vm/interpreter/bytecodeInterpreter.cpp as an example, three print_cr statements have been replaced with one log_info statement - but there are no newlines in-line in that one log_info statement. I was assuming that a single call to something like log_info would be 'atomic" and that we would manually place the \n as required in the output string. This won't show up well in email due to line wrapping but going from this: Exception (0x0000000101c69b18) thrown in interpreter method <{method} {0x00007f55b63dbc18} 'loadClass' '(Ljava/lang/String;Z)Ljava/lang/Class;' in 'java/lang/Cl> at bci 70 for thread 0x00007f56d0019800 to this: Exception (0x0000000101c69b18) thrown in interpreter method <{method} {0x00007f55b63dbc18} 'loadClass' '(Ljava/lang/String;Z)Ljava/lang/Class;' in 'java/lang/Cl> at bci 70 for thread 0x00007f56d0019800 will not be anywhere as near as clear in the logs. Thanks, David > Retested with JPRT, and the buffer-to-logstream schema in particular > works fine. > > Replies inline. > > On 12/13/2015 11:08 PM, David Holmes wrote: >> Hi Rachel, >> >> On 12/12/2015 7:38 AM, Rachel Protacio wrote: >>> Hello! An update and updated webrev. >>> >>> I've rewritten the two portions of code that had used ttyLockers to >>> print in one function-call, since there is no locker equivalent in UL, >>> plus the fact that it will be easier for users to look for one message's >>> contents without the decorators interrupting the lines. (And I >>> especially tested that the fix prints the whole line correctly.) >> >> Sorry I'm still seeing ttyLocker removal and use of multiple logging >> statements in: >> >> src/share/vm/interpreter/bytecodeInterpreter.cpp >> src/share/vm/interpreter/interpreterRuntime.cpp >> src/share/vm/opto/runtime.cpp >> >> which "two portions of code" did you change? > I apologize for that! I messed up with uploading the changeset before. > All fixed now in each of those files. >> >> I also note that src/share/vm/runtime/thread.cpp was not using >> ttyLocker but does have multi-part trace output. > True. Since a locker was unnecessary in the first place, I think it > makes sense to allow this (and other logging, both in UL and the > existing tty frameworks) to be printed in multiple steps. What do you > think? >> >>> As mentioned in the other thread, I will file a separate RFE to >>> deprecate this and other product flags being converted to logging. >>> >>> Since my last iteration was on hold/not reviewed yet, I've simply >>> updated it. http://cr.openjdk.java.net/~rprotacio/8141211.01 >> >> src/share/vm/c1/c1_Runtime1.cpp >> >> Nit in original code: >> >> 556 " for thread " INTPTR_FORMAT "", >> >> the "" before the comma seems superfluous. > Thanks for pointing that out! > Rachel >> >> Thanks, >> David >> >>> Thanks, >>> Rachel >>> >>> On 12/9/2015 1:12 PM, Rachel Protacio wrote: >>>> Hi, >>>> >>>> (Sorry if this sent twice. Thunderbird is acting up.) >>>> >>>> Thanks for the review. Replies inline. >>>> Updated webrev: http://cr.openjdk.java.net/~rprotacio/8141211.01/ >>>> >>>> On 12/8/2015 10:53 PM, David Holmes wrote: >>>>> Hi Rachel, >>>>> >>>>> On 9/12/2015 1:42 AM, Rachel Protacio wrote: >>>>>> Hello, >>>>>> >>>>>> Please review my conversion of -XX:+TraceExceptions to >>>>>> -Xlog:exceptions=info. The existing (product) flag is aliased to the >>>>>> logging flag at the info level. >>>>> >>>>> Q: how does use of ttyLocker map into UL? I see an awful lot of >>>>> multi-line logging blocks that are going to be completely messed up >>>>> without locking! >>>> I assumed that UL worked as-is for these instances, but I will check >>>> in with Marcus. >>>>> >>>>> src/share/vm/opto/runtime.cpp >>>>> >>>>> 1239 ResourceMark rm; >>>>> >>>>> What requires the introduction of the ResourceMark? >>>> A ResourceMark is necessary before using LogHandle output streams. >>>>> >>>>> --- >>>>> >>>>> src/share/vm/runtime/thread.cpp >>>>> >>>>> 2084 if (log_is_enabled(Info, exceptions)) { >>>>> 2085 ResourceMark rm; >>>>> >>>>> An extra leading space has crept in at +2085 >>>>> >>>>> 2087 logstream->print("Async. exception installed at runtime >>>>> exit (" INTPTR_FORMAT ")", p2i(this)); >>>>> 2088 if (has_last_Java_frame()) { >>>>> 2089 frame f = last_frame(); >>>>> 2090 logstream->print(" (pc: " INTPTR_FORMAT " sp: " >>>>> INTPTR_FORMAT " )", p2i(f.pc()), p2i(f.sp())); >>>>> 2091 } >>>>> >>>>> Indention of these lines is wrong at #2088 and #2089 - need an >>>>> additional space. >>>> Thanks for catching these! >>>>> >>>>> 2092 logstream->print_cr(" of type: %s", >>>>> InstanceKlass::cast(_pending_async_exception->klass())->external_name()); >>>>> >>>>> >>>>> >>>>> Why did the InstanceKlass::cast need to be introduced ?? >>>> That was a vestige from code before a new changeset at the same line, >>>> i.e. my merging the repo didn't catch this. I've gotten rid of the >>>> cast. >>>>> >>>>> --- >>>>> >>>>> test/runtime/CommandLine/TraceExceptionsTest.java >>>>> >>>>> You improved the readability of the source code by breaking the >>>>> @summary over two lines, but IIRC jtreg will write the summary into >>>>> the test log with all the additional spaces you added, as the summary >>>>> extends until the next tag. >>>> Ok, I didn't realize that! I've undone that change. >>>>> >>>>> --- >>>>> >>>>> test/runtime/logging/ExceptionsTest.java >>>>> >>>>> Can you avoid the code duplication please. >>>>> >>>>> Also perhaps you could/should also check there are no logging >>>>> statements present when logging is supposed to be disabled. I'm >>>>> guessing the other logging tests haven't considered this. ?? >>>> Good points. I've added a check. >>>>> >>>>>> If you have any questions on the alias table (in the arguments.cpp >>>>>> and >>>>>> .hpp files), Max will chime in as he is the one who implemented that >>>>>> portion. >>>>> >>>>> Okay some general questions. >>>>> >>>>> First I would expect that aliased logging options are also marked >>>>> deprecated so that we can eventually make them obsolete and remove >>>>> them. >>>> I'm not sure about this one. Coleen? Max? >>>>> >>>>> Secondly, arguably if someone specifies -XX:-TraceExceptions it >>>>> should disable exception logging - which may have been turned on by >>>>> -Xlog:all. >>>>> >>>>> Which leads to: how does the position of -XX:+/-TraceExceptions >>>>> interact with the position of -Xlog:xxx on the command-line (or the >>>>> other argument introducing mechanisms) ? >>>> Very true. I've added an entry in the alias table to that effect. >>>>> >>>>> src/share/vm/runtime/arguments.cpp >>>>> >>>>> 2743 if(lookup_logging_aliases(option->optionString, >>>>> aliased_logging_option)){ >>>>> >>>>> Need space after "if", and before { >>>> Done. >>>> >>>> Thanks, >>>> Rachel >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8141211/ >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141211 >>>>>> >>>>>> Testing: jtreg, JPRT, jck vm tests, refworkload performance tests, >>>>>> rbt >>>>>> quick & non-colo tests >>>>>> >>>>>> Thank you! >>>>>> Rachel >>>> >>> > From john.r.rose at oracle.com Wed Dec 16 21:01:19 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 16 Dec 2015 13:01:19 -0800 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <5670775A.4060806@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> Message-ID: <5387B10E-1AEF-428A-9096-E05E81A8071E@oracle.com> On Dec 15, 2015, at 12:26 PM, Rachel Protacio wrote: > > - each incident of ttyLocker that involved separate logging lines for the same message have been consolidated to one line > - each incident of ttyLocker that involved separate print statements to one logging line has been changed to write to a buffer first, then print the entire line at once to the log stream This is a strong argument for putting such functionality into the UL framework, instead of giving developers the unfortunate choice of either (a) doing it right with a bunch of random logic (Rachel's choice here) or (b) sweeping it under the carpet by breaking up a multi-part message into several log messages. We need to admit this is the Achilles Heel of logging as normally conceived (especially for very long multi-part messages like disassembler output, backtraces, or compilation logs), and just fix it in the UL frameowrk. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From rachel.protacio at oracle.com Wed Dec 16 21:33:54 2015 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 16 Dec 2015 16:33:54 -0500 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <5671CF0B.20003@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> <5671CF0B.20003@oracle.com> Message-ID: <5671D8C2.4040801@oracle.com> Hi, On 12/16/2015 3:52 PM, David Holmes wrote: > Hi Rachel, > > On 16/12/2015 6:26 AM, Rachel Protacio wrote: >> Hi, >> >> Thanks for the comments, David. >> >> I had messed up my uploading before and had not actually updated the >> open html. So for real this time, the most recent webrev is at >> http://cr.openjdk.java.net/~rprotacio/8141211.01/ Of note: >> - each incident of ttyLocker that involved separate logging lines for >> the same message have been consolidated to one line >> - each incident of ttyLocker that involved separate print statements to >> one logging line has been changed to write to a buffer first, then print >> the entire line at once to the log stream > > I think I may be missing something here, sorry. Taking > src/share/vm/interpreter/bytecodeInterpreter.cpp as an example, three > print_cr statements have been replaced with one log_info statement - > but there are no newlines in-line in that one log_info statement. I > was assuming that a single call to something like log_info would be > 'atomic" and that we would manually place the \n as required in the > output string. > > This won't show up well in email due to line wrapping but going from > this: > > Exception sun.launcher.resources.launcher_en_US> (0x0000000101c69b18) > thrown in interpreter method <{method} {0x00007f55b63dbc18} > 'loadClass' '(Ljava/lang/String;Z)Ljava/lang/Class;' in 'java/lang/Cl> > at bci 70 for thread 0x00007f56d0019800 > > to this: > > Exception sun.launcher.resources.launcher_en_US> (0x0000000101c69b18) thrown in > interpreter method <{method} {0x00007f55b63dbc18} 'loadClass' > '(Ljava/lang/String;Z)Ljava/lang/Class;' in 'java/lang/Cl> at bci 70 > for thread 0x00007f56d0019800 > > will not be anywhere as near as clear in the logs. Yes, I changed that intentionally. The choices as I saw them were: (a) multiple print_cr() calls, which could lead to unwanted interweaving and which breaks up the logging message with decorators at the beginning of every line, e.g. [0.225s][info ][exceptions] Exception (0x00000006d5f5ae28) [0.225s][info ][exceptions] thrown in interpreter method <{method} {0x00007fe231a04198} 'findClass' '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC> [0.225s][info ][exceptions] at bci 44 for thread 0x00007fe330019000 (b) adding newlines in the middle of the message, which would look like [0.225s][info ][exceptions] Exception (0x00000006d5f5ae28) thrown in interpreter method <{method} {0x00007fe231a04198} 'findClass' '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC> at bci 44 for thread 0x00007fe330019000 and could easily end up wrapping mid-logging anyway depending on the length of the exception message (c) turning it all into one wrapped line that would be relatively easier to programmatically parse since the decorators would be at the beginning of the line, i.e. [0.225s][info ][exceptions] Exception (0x00000006d5f5ae28) thrown in interpreter method <{method} {0x00007fe231a04198} 'findClass' '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC>at bci 44 for thread 0x00007fe330019000 which is also the most compact option. So I opted for (c). But if I should stick to the original approach, i.e. (b), I can see it could be easier to visually parse. Do you think that would be preferable? Thanks! Rachel > > Thanks, > David > >> Retested with JPRT, and the buffer-to-logstream schema in particular >> works fine. >> >> Replies inline. >> >> On 12/13/2015 11:08 PM, David Holmes wrote: >>> Hi Rachel, >>> >>> On 12/12/2015 7:38 AM, Rachel Protacio wrote: >>>> Hello! An update and updated webrev. >>>> >>>> I've rewritten the two portions of code that had used ttyLockers to >>>> print in one function-call, since there is no locker equivalent in UL, >>>> plus the fact that it will be easier for users to look for one >>>> message's >>>> contents without the decorators interrupting the lines. (And I >>>> especially tested that the fix prints the whole line correctly.) >>> >>> Sorry I'm still seeing ttyLocker removal and use of multiple logging >>> statements in: >>> >>> src/share/vm/interpreter/bytecodeInterpreter.cpp >>> src/share/vm/interpreter/interpreterRuntime.cpp >>> src/share/vm/opto/runtime.cpp >>> >>> which "two portions of code" did you change? >> I apologize for that! I messed up with uploading the changeset before. >> All fixed now in each of those files. >>> >>> I also note that src/share/vm/runtime/thread.cpp was not using >>> ttyLocker but does have multi-part trace output. >> True. Since a locker was unnecessary in the first place, I think it >> makes sense to allow this (and other logging, both in UL and the >> existing tty frameworks) to be printed in multiple steps. What do you >> think? >>> >>>> As mentioned in the other thread, I will file a separate RFE to >>>> deprecate this and other product flags being converted to logging. >>>> >>>> Since my last iteration was on hold/not reviewed yet, I've simply >>>> updated it. http://cr.openjdk.java.net/~rprotacio/8141211.01 >>> >>> src/share/vm/c1/c1_Runtime1.cpp >>> >>> Nit in original code: >>> >>> 556 " for thread " INTPTR_FORMAT "", >>> >>> the "" before the comma seems superfluous. >> Thanks for pointing that out! >> Rachel >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Rachel >>>> >>>> On 12/9/2015 1:12 PM, Rachel Protacio wrote: >>>>> Hi, >>>>> >>>>> (Sorry if this sent twice. Thunderbird is acting up.) >>>>> >>>>> Thanks for the review. Replies inline. >>>>> Updated webrev: http://cr.openjdk.java.net/~rprotacio/8141211.01/ >>>>> >>>>> On 12/8/2015 10:53 PM, David Holmes wrote: >>>>>> Hi Rachel, >>>>>> >>>>>> On 9/12/2015 1:42 AM, Rachel Protacio wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review my conversion of -XX:+TraceExceptions to >>>>>>> -Xlog:exceptions=info. The existing (product) flag is aliased to >>>>>>> the >>>>>>> logging flag at the info level. >>>>>> >>>>>> Q: how does use of ttyLocker map into UL? I see an awful lot of >>>>>> multi-line logging blocks that are going to be completely messed up >>>>>> without locking! >>>>> I assumed that UL worked as-is for these instances, but I will check >>>>> in with Marcus. >>>>>> >>>>>> src/share/vm/opto/runtime.cpp >>>>>> >>>>>> 1239 ResourceMark rm; >>>>>> >>>>>> What requires the introduction of the ResourceMark? >>>>> A ResourceMark is necessary before using LogHandle output streams. >>>>>> >>>>>> --- >>>>>> >>>>>> src/share/vm/runtime/thread.cpp >>>>>> >>>>>> 2084 if (log_is_enabled(Info, exceptions)) { >>>>>> 2085 ResourceMark rm; >>>>>> >>>>>> An extra leading space has crept in at +2085 >>>>>> >>>>>> 2087 logstream->print("Async. exception installed at runtime >>>>>> exit (" INTPTR_FORMAT ")", p2i(this)); >>>>>> 2088 if (has_last_Java_frame()) { >>>>>> 2089 frame f = last_frame(); >>>>>> 2090 logstream->print(" (pc: " INTPTR_FORMAT " sp: " >>>>>> INTPTR_FORMAT " )", p2i(f.pc()), p2i(f.sp())); >>>>>> 2091 } >>>>>> >>>>>> Indention of these lines is wrong at #2088 and #2089 - need an >>>>>> additional space. >>>>> Thanks for catching these! >>>>>> >>>>>> 2092 logstream->print_cr(" of type: %s", >>>>>> InstanceKlass::cast(_pending_async_exception->klass())->external_name()); >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Why did the InstanceKlass::cast need to be introduced ?? >>>>> That was a vestige from code before a new changeset at the same line, >>>>> i.e. my merging the repo didn't catch this. I've gotten rid of the >>>>> cast. >>>>>> >>>>>> --- >>>>>> >>>>>> test/runtime/CommandLine/TraceExceptionsTest.java >>>>>> >>>>>> You improved the readability of the source code by breaking the >>>>>> @summary over two lines, but IIRC jtreg will write the summary into >>>>>> the test log with all the additional spaces you added, as the >>>>>> summary >>>>>> extends until the next tag. >>>>> Ok, I didn't realize that! I've undone that change. >>>>>> >>>>>> --- >>>>>> >>>>>> test/runtime/logging/ExceptionsTest.java >>>>>> >>>>>> Can you avoid the code duplication please. >>>>>> >>>>>> Also perhaps you could/should also check there are no logging >>>>>> statements present when logging is supposed to be disabled. I'm >>>>>> guessing the other logging tests haven't considered this. ?? >>>>> Good points. I've added a check. >>>>>> >>>>>>> If you have any questions on the alias table (in the arguments.cpp >>>>>>> and >>>>>>> .hpp files), Max will chime in as he is the one who implemented >>>>>>> that >>>>>>> portion. >>>>>> >>>>>> Okay some general questions. >>>>>> >>>>>> First I would expect that aliased logging options are also marked >>>>>> deprecated so that we can eventually make them obsolete and remove >>>>>> them. >>>>> I'm not sure about this one. Coleen? Max? >>>>>> >>>>>> Secondly, arguably if someone specifies -XX:-TraceExceptions it >>>>>> should disable exception logging - which may have been turned on by >>>>>> -Xlog:all. >>>>>> >>>>>> Which leads to: how does the position of -XX:+/-TraceExceptions >>>>>> interact with the position of -Xlog:xxx on the command-line (or the >>>>>> other argument introducing mechanisms) ? >>>>> Very true. I've added an entry in the alias table to that effect. >>>>>> >>>>>> src/share/vm/runtime/arguments.cpp >>>>>> >>>>>> 2743 if(lookup_logging_aliases(option->optionString, >>>>>> aliased_logging_option)){ >>>>>> >>>>>> Need space after "if", and before { >>>>> Done. >>>>> >>>>> Thanks, >>>>> Rachel >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8141211/ >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141211 >>>>>>> >>>>>>> Testing: jtreg, JPRT, jck vm tests, refworkload performance tests, >>>>>>> rbt >>>>>>> quick & non-colo tests >>>>>>> >>>>>>> Thank you! >>>>>>> Rachel >>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Wed Dec 16 21:43:27 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 16 Dec 2015 16:43:27 -0500 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <5387B10E-1AEF-428A-9096-E05E81A8071E@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> <5387B10E-1AEF-428A-9096-E05E81A8071E@oracle.com> Message-ID: <5671DAFF.7060508@oracle.com> On 12/16/15 4:01 PM, John Rose wrote: > On Dec 15, 2015, at 12:26 PM, Rachel Protacio wrote: >> - each incident of ttyLocker that involved separate logging lines for the same message have been consolidated to one line >> - each incident of ttyLocker that involved separate print statements to one logging line has been changed to write to a buffer first, then print the entire line at once to the log stream > This is a strong argument for putting such functionality into the UL framework, > instead of giving developers the unfortunate choice of either (a) doing it right > with a bunch of random logic (Rachel's choice here) or (b) sweeping it under > the carpet by breaking up a multi-part message into several log messages. > > We need to admit this is the Achilles Heel of logging as normally conceived > (especially for very long multi-part messages like disassembler output, > backtraces, or compilation logs), and just fix it in the UL frameowrk. Yes, I agree. We should file a high priority RFE against UL for this if one isn't filed already. The runtime only uses ttyLocker (as far as I found) for TraceExceptions but the compiler uses it more often to aggregate messages. The lack of a locking mechanism seems to be one of the factors blocking the compiler group adoption of this feature. And will block more complex runtime logging conversions. So what do people vote that we do? Should we log the messages separately until this is fixed? I agreed with making these logs one line because even though they wrap, they weren't that long. It would be nice to be able to do the conversion work to UL concurrently while finding problems in the framework, and not be stuck. Thanks, Coleen > > ? John From david.holmes at oracle.com Wed Dec 16 23:39:29 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Dec 2015 09:39:29 +1000 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <5671D8C2.4040801@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> <5671CF0B.20003@oracle.com> <5671D8C2.4040801@oracle.com> Message-ID: <5671F631.8000903@oracle.com> Hi Rachel, On 17/12/2015 7:33 AM, Rachel Protacio wrote: > Hi, > > On 12/16/2015 3:52 PM, David Holmes wrote: >> Hi Rachel, >> >> On 16/12/2015 6:26 AM, Rachel Protacio wrote: >>> Hi, >>> >>> Thanks for the comments, David. >>> >>> I had messed up my uploading before and had not actually updated the >>> open html. So for real this time, the most recent webrev is at >>> http://cr.openjdk.java.net/~rprotacio/8141211.01/ Of note: >>> - each incident of ttyLocker that involved separate logging lines for >>> the same message have been consolidated to one line >>> - each incident of ttyLocker that involved separate print statements to >>> one logging line has been changed to write to a buffer first, then print >>> the entire line at once to the log stream >> >> I think I may be missing something here, sorry. Taking >> src/share/vm/interpreter/bytecodeInterpreter.cpp as an example, three >> print_cr statements have been replaced with one log_info statement - >> but there are no newlines in-line in that one log_info statement. I >> was assuming that a single call to something like log_info would be >> 'atomic" and that we would manually place the \n as required in the >> output string. >> >> This won't show up well in email due to line wrapping but going from >> this: >> >> Exception > sun.launcher.resources.launcher_en_US> (0x0000000101c69b18) >> thrown in interpreter method <{method} {0x00007f55b63dbc18} >> 'loadClass' '(Ljava/lang/String;Z)Ljava/lang/Class;' in 'java/lang/Cl> >> at bci 70 for thread 0x00007f56d0019800 >> >> to this: >> >> Exception > sun.launcher.resources.launcher_en_US> (0x0000000101c69b18) thrown in >> interpreter method <{method} {0x00007f55b63dbc18} 'loadClass' >> '(Ljava/lang/String;Z)Ljava/lang/Class;' in 'java/lang/Cl> at bci 70 >> for thread 0x00007f56d0019800 >> >> will not be anywhere as near as clear in the logs. > Yes, I changed that intentionally. The choices as I saw them were: > (a) multiple print_cr() calls, which could lead to unwanted interweaving > and which breaks up the logging message with decorators at the beginning > of every line, e.g. > > [0.225s][info ][exceptions] Exception 'java/lang/ClassNotFoundException': NoClassFound> (0x00000006d5f5ae28) > [0.225s][info ][exceptions] thrown in interpreter method <{method} > {0x00007fe231a04198} 'findClass' > '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC> > [0.225s][info ][exceptions] at bci 44 for thread 0x00007fe330019000 > > (b) adding newlines in the middle of the message, which would look like > > [0.225s][info ][exceptions] Exception 'java/lang/ClassNotFoundException': NoClassFound> (0x00000006d5f5ae28) > thrown in interpreter method <{method} {0x00007fe231a04198} > 'findClass' '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC> > at bci 44 for thread 0x00007fe330019000 > > and could easily end up wrapping mid-logging anyway depending on the > length of the exception message > (c) turning it all into one wrapped line that would be relatively easier > to programmatically parse since the decorators would be at the beginning > of the line, i.e. > > [0.225s][info ][exceptions] Exception 'java/lang/ClassNotFoundException': NoClassFound> > (0x00000006d5f5ae28) thrown in interpreter method <{method} > {0x00007fe231a04198} 'findClass' > '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC>at bci 44 > for thread 0x00007fe330019000 > > which is also the most compact option. > > So I opted for (c). But if I should stick to the original approach, i.e. > (b), I can see it could be easier to visually parse. Do you think that > would be preferable? I definitely vote for (b) - I think a goal of the conversion effort should be that if you disable the UL decorators then the output before and after the conversion should be the same. Decorators can be useful but also clutter. But I'm also worried that the UL framework might not atomically process a line with embedded newlines. Though in that case the fix needs to be in the UL framework. Thanks, David > Thanks! > Rachel > >> >> Thanks, >> David >> >>> Retested with JPRT, and the buffer-to-logstream schema in particular >>> works fine. >>> >>> Replies inline. >>> >>> On 12/13/2015 11:08 PM, David Holmes wrote: >>>> Hi Rachel, >>>> >>>> On 12/12/2015 7:38 AM, Rachel Protacio wrote: >>>>> Hello! An update and updated webrev. >>>>> >>>>> I've rewritten the two portions of code that had used ttyLockers to >>>>> print in one function-call, since there is no locker equivalent in UL, >>>>> plus the fact that it will be easier for users to look for one >>>>> message's >>>>> contents without the decorators interrupting the lines. (And I >>>>> especially tested that the fix prints the whole line correctly.) >>>> >>>> Sorry I'm still seeing ttyLocker removal and use of multiple logging >>>> statements in: >>>> >>>> src/share/vm/interpreter/bytecodeInterpreter.cpp >>>> src/share/vm/interpreter/interpreterRuntime.cpp >>>> src/share/vm/opto/runtime.cpp >>>> >>>> which "two portions of code" did you change? >>> I apologize for that! I messed up with uploading the changeset before. >>> All fixed now in each of those files. >>>> >>>> I also note that src/share/vm/runtime/thread.cpp was not using >>>> ttyLocker but does have multi-part trace output. >>> True. Since a locker was unnecessary in the first place, I think it >>> makes sense to allow this (and other logging, both in UL and the >>> existing tty frameworks) to be printed in multiple steps. What do you >>> think? >>>> >>>>> As mentioned in the other thread, I will file a separate RFE to >>>>> deprecate this and other product flags being converted to logging. >>>>> >>>>> Since my last iteration was on hold/not reviewed yet, I've simply >>>>> updated it. http://cr.openjdk.java.net/~rprotacio/8141211.01 >>>> >>>> src/share/vm/c1/c1_Runtime1.cpp >>>> >>>> Nit in original code: >>>> >>>> 556 " for thread " INTPTR_FORMAT "", >>>> >>>> the "" before the comma seems superfluous. >>> Thanks for pointing that out! >>> Rachel >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Rachel >>>>> >>>>> On 12/9/2015 1:12 PM, Rachel Protacio wrote: >>>>>> Hi, >>>>>> >>>>>> (Sorry if this sent twice. Thunderbird is acting up.) >>>>>> >>>>>> Thanks for the review. Replies inline. >>>>>> Updated webrev: http://cr.openjdk.java.net/~rprotacio/8141211.01/ >>>>>> >>>>>> On 12/8/2015 10:53 PM, David Holmes wrote: >>>>>>> Hi Rachel, >>>>>>> >>>>>>> On 9/12/2015 1:42 AM, Rachel Protacio wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review my conversion of -XX:+TraceExceptions to >>>>>>>> -Xlog:exceptions=info. The existing (product) flag is aliased to >>>>>>>> the >>>>>>>> logging flag at the info level. >>>>>>> >>>>>>> Q: how does use of ttyLocker map into UL? I see an awful lot of >>>>>>> multi-line logging blocks that are going to be completely messed up >>>>>>> without locking! >>>>>> I assumed that UL worked as-is for these instances, but I will check >>>>>> in with Marcus. >>>>>>> >>>>>>> src/share/vm/opto/runtime.cpp >>>>>>> >>>>>>> 1239 ResourceMark rm; >>>>>>> >>>>>>> What requires the introduction of the ResourceMark? >>>>>> A ResourceMark is necessary before using LogHandle output streams. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> src/share/vm/runtime/thread.cpp >>>>>>> >>>>>>> 2084 if (log_is_enabled(Info, exceptions)) { >>>>>>> 2085 ResourceMark rm; >>>>>>> >>>>>>> An extra leading space has crept in at +2085 >>>>>>> >>>>>>> 2087 logstream->print("Async. exception installed at runtime >>>>>>> exit (" INTPTR_FORMAT ")", p2i(this)); >>>>>>> 2088 if (has_last_Java_frame()) { >>>>>>> 2089 frame f = last_frame(); >>>>>>> 2090 logstream->print(" (pc: " INTPTR_FORMAT " sp: " >>>>>>> INTPTR_FORMAT " )", p2i(f.pc()), p2i(f.sp())); >>>>>>> 2091 } >>>>>>> >>>>>>> Indention of these lines is wrong at #2088 and #2089 - need an >>>>>>> additional space. >>>>>> Thanks for catching these! >>>>>>> >>>>>>> 2092 logstream->print_cr(" of type: %s", >>>>>>> InstanceKlass::cast(_pending_async_exception->klass())->external_name()); >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Why did the InstanceKlass::cast need to be introduced ?? >>>>>> That was a vestige from code before a new changeset at the same line, >>>>>> i.e. my merging the repo didn't catch this. I've gotten rid of the >>>>>> cast. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> test/runtime/CommandLine/TraceExceptionsTest.java >>>>>>> >>>>>>> You improved the readability of the source code by breaking the >>>>>>> @summary over two lines, but IIRC jtreg will write the summary into >>>>>>> the test log with all the additional spaces you added, as the >>>>>>> summary >>>>>>> extends until the next tag. >>>>>> Ok, I didn't realize that! I've undone that change. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> test/runtime/logging/ExceptionsTest.java >>>>>>> >>>>>>> Can you avoid the code duplication please. >>>>>>> >>>>>>> Also perhaps you could/should also check there are no logging >>>>>>> statements present when logging is supposed to be disabled. I'm >>>>>>> guessing the other logging tests haven't considered this. ?? >>>>>> Good points. I've added a check. >>>>>>> >>>>>>>> If you have any questions on the alias table (in the arguments.cpp >>>>>>>> and >>>>>>>> .hpp files), Max will chime in as he is the one who implemented >>>>>>>> that >>>>>>>> portion. >>>>>>> >>>>>>> Okay some general questions. >>>>>>> >>>>>>> First I would expect that aliased logging options are also marked >>>>>>> deprecated so that we can eventually make them obsolete and remove >>>>>>> them. >>>>>> I'm not sure about this one. Coleen? Max? >>>>>>> >>>>>>> Secondly, arguably if someone specifies -XX:-TraceExceptions it >>>>>>> should disable exception logging - which may have been turned on by >>>>>>> -Xlog:all. >>>>>>> >>>>>>> Which leads to: how does the position of -XX:+/-TraceExceptions >>>>>>> interact with the position of -Xlog:xxx on the command-line (or the >>>>>>> other argument introducing mechanisms) ? >>>>>> Very true. I've added an entry in the alias table to that effect. >>>>>>> >>>>>>> src/share/vm/runtime/arguments.cpp >>>>>>> >>>>>>> 2743 if(lookup_logging_aliases(option->optionString, >>>>>>> aliased_logging_option)){ >>>>>>> >>>>>>> Need space after "if", and before { >>>>>> Done. >>>>>> >>>>>> Thanks, >>>>>> Rachel >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> >>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8141211/ >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141211 >>>>>>>> >>>>>>>> Testing: jtreg, JPRT, jck vm tests, refworkload performance tests, >>>>>>>> rbt >>>>>>>> quick & non-colo tests >>>>>>>> >>>>>>>> Thank you! >>>>>>>> Rachel >>>>>> >>>>> >>> > From david.holmes at oracle.com Thu Dec 17 05:34:09 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Dec 2015 15:34:09 +1000 Subject: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration In-Reply-To: <56702DDF.9060407@oracle.com> References: <566E962D.8010107@oracle.com> <566ED7F8.4090204@oracle.com> <566EE0AF.9010905@oracle.com> <566FEA83.6060105@oracle.com> <15686d26-99f4-449b-b5a8-f342632b2922@default> <56702DDF.9060407@oracle.com> Message-ID: <56724951.3090404@oracle.com> Looks good! Thanks, David On 16/12/2015 1:12 AM, Marcus Larsson wrote: > Hey Markus, > > On 2015-12-15 11:58, Markus Gronlund wrote: >> Hi Marcus, >> >> Looks good! >> >> One minor thing that you don't need to fix if you don't want to: >> >> I would use: >> >> class ConfigurationLock { >> ... >> >> debug_only(static bool current_thread_has_lock();) >> >> }; >> >> to declare the this function in the class, then I would move the >> definition outside of it (since it's sits inside ASSERT macros). >> >> #ifdef ASSERT >> bool ConfigurationLock::current_thread_has_lock() { >> return _locking_thread_id == os::current_thread_id(); >> } >> #endif >> >> >> I just find it easier to read the class declaration without the macros >> inside of the class declaration (and since this is debug code, there >> is no real use of defining inline). As I said, you don?t need to fix >> this and to post another webrev. > > I think it's worth another round. :) > > New webrev: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.04/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8145083/webrev.03-04/ > > Thanks, > Marcus > > >> >> Good work! >> >> /Markus >> >> >> >> -----Original Message----- >> From: Marcus Larsson >> Sent: den 15 december 2015 11:25 >> To: serviceability-dev at openjdk.java.net >> Cc: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR: 8145083: Use semaphore instead of mutex for >> synchronization of Unified Logging configuration >> >> Hi, >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.03/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.02-03/ >> >> ConfigurationLocker renamed to ConfigurationLock to avoid confusion >> with the MutexLocker family of classes. >> Semaphore and locking thread id moved into the ConfigurationLock; >> added a function to check if current thread has the lock when asserts >> are enabled. >> >> Regards, >> Marcus >> >> >> On 2015-12-14 16:30, Marcus Larsson wrote: >>> Hi again, >>> >>> Made some changes to the patch after feedback from Markus Gr?nlund. >>> The ConfigurationLocker and the semaphore have been moved out of the >>> LogConfiguration.hpp and into the .cpp instead. The lock is only used >>> internally by the LogConfiguration so this makes sense. It simplifies >>> the LogConfiguration interface and hides the details of the locking >>> under the hood. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.02/ >>> >>> Incremental: >>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01-02/ >>> >>> Thanks, >>> Marcus >>> >>> On 2015-12-14 15:53, Marcus Larsson wrote: >>>> Hi, >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01/ >>>> >>>> Incremental: >>>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00-01/ >>>> >>>> Changes: >>>> * Introduced the ConfigurationLocker class for automatic wait/signal >>>> in constructor/destructor just like a MutexLocker. >>>> * Added an assert to verify that the "lock" is held by the current >>>> thread when calling configure_output. >>>> * Made the config-string functions in LogOutput protected and >>>> LogConfiguration a friend of LogOutput to prevent incorrect usage of >>>> these functions. These functions should typically only be used inside >>>> configure_output, which now ensures that the lock is held. >>>> >>>> Thanks, >>>> Marcus >>>> >>>> >>>> On 2015-12-14 11:13, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> Please review the following patch to use a semaphore instead of a >>>>> mutex for the synchronization of log configuration. Using a mutex >>>>> requires some parts of the VM to be initialized, whereas the >>>>> semaphores can be used right from the start. This simplifies the >>>>> code and allows very early log configuration without special cases >>>>> for early configuration vs reconfiguration after VM init. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00/ >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8145083 >>>>> >>>>> Thanks, >>>>> Marcus > From david.holmes at oracle.com Thu Dec 17 05:45:13 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Dec 2015 15:45:13 +1000 Subject: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ... In-Reply-To: <56700531.8060701@oracle.com> References: <566ECDA6.1030404@oracle.com> <566FB3BB.4050709@oracle.com> <567000F9.2070603@oracle.com> <56700279.4000408@oracle.com> <56700531.8060701@oracle.com> Message-ID: <56724BE9.5060304@oracle.com> On 15/12/2015 10:18 PM, Ivan Gerasimov wrote: > >> >> while(true) would convey that much more clearly - and perhaps obviate >> the need for pr_ex. >> > > Yes, I can surely transform the code > > - while (pr_ex != curr_id) { > + if (pr_ex != curr_id) { > + while (true} { > > The intention was to save a line :-) > > I'll use while (true), if it improves readability. It does :) And I don't you need pr_ex then as you can just compare OrderAccess::load_acquire(&process_exiting) with the current thread id - right? Thanks, David > Sincerely yours, > Ivan From ivan.gerasimov at oracle.com Thu Dec 17 08:23:18 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 17 Dec 2015 11:23:18 +0300 Subject: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ... In-Reply-To: <56724BE9.5060304@oracle.com> References: <566ECDA6.1030404@oracle.com> <566FB3BB.4050709@oracle.com> <567000F9.2070603@oracle.com> <56700279.4000408@oracle.com> <56700531.8060701@oracle.com> <56724BE9.5060304@oracle.com> Message-ID: <567270F6.7030206@oracle.com> On 17.12.2015 8:45, David Holmes wrote: > On 15/12/2015 10:18 PM, Ivan Gerasimov wrote: >> >>> >>> while(true) would convey that much more clearly - and perhaps obviate >>> the need for pr_ex. >>> >> >> Yes, I can surely transform the code >> >> - while (pr_ex != curr_id) { >> + if (pr_ex != curr_id) { >> + while (true} { >> >> The intention was to save a line :-) >> >> I'll use while (true), if it improves readability. > > It does :) And I don't you need pr_ex then as you can just compare > OrderAccess::load_acquire(&process_exiting) with the current thread id > - right? > We will suspend the current thread if two conditions are satisfied: process_exiting != 0 and process_exiting != current thread id. But, yes, pr_ex isn't really needed, as we can use process_exiting directly. Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/8145127/01/webrev/ Sincerely yours, Ivan From bengt.rutisson at oracle.com Thu Dec 17 08:41:41 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 17 Dec 2015 09:41:41 +0100 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <5671DAFF.7060508@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> <5387B10E-1AEF-428A-9096-E05E81A8071E@oracle.com> <5671DAFF.7060508@oracle.com> Message-ID: <56727545.4030004@oracle.com> On 2015-12-16 22:43, Coleen Phillimore wrote: > > > On 12/16/15 4:01 PM, John Rose wrote: >> On Dec 15, 2015, at 12:26 PM, Rachel Protacio >> wrote: >>> - each incident of ttyLocker that involved separate logging lines >>> for the same message have been consolidated to one line >>> - each incident of ttyLocker that involved separate print statements >>> to one logging line has been changed to write to a buffer first, >>> then print the entire line at once to the log stream >> This is a strong argument for putting such functionality into the UL >> framework, >> instead of giving developers the unfortunate choice of either (a) >> doing it right >> with a bunch of random logic (Rachel's choice here) or (b) sweeping >> it under >> the carpet by breaking up a multi-part message into several log >> messages. >> >> We need to admit this is the Achilles Heel of logging as normally >> conceived >> (especially for very long multi-part messages like disassembler output, >> backtraces, or compilation logs), and just fix it in the UL frameowrk. > > Yes, I agree. We should file a high priority RFE against UL for this > if one isn't filed already. The runtime only uses ttyLocker (as far > as I found) for TraceExceptions but the compiler uses it more often to > aggregate messages. The lack of a locking mechanism seems to be one > of the factors blocking the compiler group adoption of this feature. > And will block more complex runtime logging conversions. > > So what do people vote that we do? Should we log the messages > separately until this is fixed? I agreed with making these logs one > line because even though they wrap, they weren't that long. It would > be nice to be able to do the conversion work to UL concurrently while > finding problems in the framework, and not be stuck. From my point of view it would be very unfortunate to require all logging to take an extra lock. If the multiline support can be implemented in the UL framework without any extra cost for "normal" logging I would be fine with it. But if it would slow down the normal logging, which I assume would be the case if we require an extra lock, then I would prefer to push the responsibility up to the users of the UL framework to synchronize properly. Bengt > > Thanks, > Coleen >> >> ? John > From dmitry.samersoff at oracle.com Thu Dec 17 09:17:58 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 17 Dec 2015 12:17:58 +0300 Subject: [PATCH resend2] Skip the null pointer check before calling realloc In-Reply-To: <6dca8affef8a4566dfaa.1450212201@localhost.localdomain> References: <6dca8affef8a4566dfaa.1450212201@localhost.localdomain> Message-ID: <56727DC6.9070309@oracle.com> Alex, I'll sponsor the push, but please: 1. fix realloc issue as it suggested by Dan and me. 2. prepare a webrev (I'll put it under my ojdk account to /sponsorship/alexhenrie) -Dmitry On 2015-12-15 23:43, Alex Henrie wrote: > # HG changeset patch > # User Alex Henrie > # Date 1447827030 25200 > # Tue Nov 17 23:10:30 2015 -0700 > # Node ID 6dca8affef8a4566dfaa36faeb7a14fc4086843a > # Parent dc90094c0d66b3df2944da215d93542507c31e60 > Skip the null pointer check before calling realloc. > > "If ptr is a null pointer, realloc() shall be equivalent to malloc() for > the specified size." > http://pubs.opengroup.org/onlinepubs/9699919799/functions/realloc.html > > Also, sizeof(char*) is more correct here than sizeof(char**), although > in practice it doesn't make a difference. > > diff --git a/src/java.instrument/share/native/libinstrument/InvocationAdapter.c b/src/java.instrument/share/native/libinstrument/InvocationAdapter.c > --- a/src/java.instrument/share/native/libinstrument/InvocationAdapter.c > +++ b/src/java.instrument/share/native/libinstrument/InvocationAdapter.c > @@ -519,21 +519,17 @@ splitPathList(const char* str, int* path > int count = 0; > char** segments = NULL; > char* c = (char*) str; > while (*c != '\0') { > while (*c == ' ') c++; /* skip leading spaces */ > if (*c == '\0') { > break; > } > - if (segments == NULL) { > - segments = (char**)malloc( sizeof(char**) ); > - } else { > - segments = (char**)realloc( segments, (count+1)*sizeof(char**) ); > - } > + segments = (char**)realloc( segments, (count+1)*sizeof(char*) ); > jplis_assert(segments != (char**)NULL); > segments[count++] = c; > c = strchr(c, ' '); > if (c == NULL) { > break; > } > *c = '\0'; > c++; > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From marcus.larsson at oracle.com Thu Dec 17 10:31:16 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 17 Dec 2015 11:31:16 +0100 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <56727545.4030004@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> <5387B10E-1AEF-428A-9096-E05E81A8071E@oracle.com> <5671DAFF.7060508@oracle.com> <56727545.4030004@oracle.com> Message-ID: <56728EF4.7050704@oracle.com> Hi, On 2015-12-17 09:41, Bengt Rutisson wrote: > > > On 2015-12-16 22:43, Coleen Phillimore wrote: >> >> >> On 12/16/15 4:01 PM, John Rose wrote: >>> On Dec 15, 2015, at 12:26 PM, Rachel Protacio >>> wrote: >>>> - each incident of ttyLocker that involved separate logging lines >>>> for the same message have been consolidated to one line >>>> - each incident of ttyLocker that involved separate print >>>> statements to one logging line has been changed to write to a >>>> buffer first, then print the entire line at once to the log stream >>> This is a strong argument for putting such functionality into the UL >>> framework, >>> instead of giving developers the unfortunate choice of either (a) >>> doing it right >>> with a bunch of random logic (Rachel's choice here) or (b) sweeping >>> it under >>> the carpet by breaking up a multi-part message into several log >>> messages. >>> >>> We need to admit this is the Achilles Heel of logging as normally >>> conceived >>> (especially for very long multi-part messages like disassembler output, >>> backtraces, or compilation logs), and just fix it in the UL frameowrk. >> >> Yes, I agree. We should file a high priority RFE against UL for this >> if one isn't filed already. The runtime only uses ttyLocker (as far >> as I found) for TraceExceptions but the compiler uses it more often >> to aggregate messages. The lack of a locking mechanism seems to be >> one of the factors blocking the compiler group adoption of this >> feature. And will block more complex runtime logging conversions. >> >> So what do people vote that we do? Should we log the messages >> separately until this is fixed? I agreed with making these logs one >> line because even though they wrap, they weren't that long. It would >> be nice to be able to do the conversion work to UL concurrently while >> finding problems in the framework, and not be stuck. > > From my point of view it would be very unfortunate to require all > logging to take an extra lock. If the multiline support can be > implemented in the UL framework without any extra cost for "normal" > logging I would be fine with it. But if it would slow down the normal > logging, which I assume would be the case if we require an extra lock, > then I would prefer to push the responsibility up to the users of the > UL framework to synchronize properly. Support for multi line logging was a stretch goal of the UL project that was never implemented. I think it might be a good feature to have, given that there is a lot of logging requiring such functionality. Regardless, having this discussion is good, because I think we need to work out the details of how it should work. For example, should each line in a multi-line message be decorated? Do we write anything special to signify that these lines are tied together? The current implementation relies on the OS to do proper synchronization of the streams for the printf calls, which should guarantee that each line will be written atomically. Introducing a lock will be necessary for multi-line logging, but perhaps it won't be too bad if we use light weight locks very fine grained around the printfs. If we measure an increased cost for this, it should probably be weighed against the benefit for the use cases requiring it. Regards, Marcus > > Bengt > >> >> Thanks, >> Coleen >>> >>> ? John >> > From marcus.larsson at oracle.com Thu Dec 17 10:42:12 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 17 Dec 2015 11:42:12 +0100 Subject: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration In-Reply-To: <748D61D7-8CFC-42B3-959B-31D75A926133@oracle.com> References: <566E962D.8010107@oracle.com> <566ED7F8.4090204@oracle.com> <566EE0AF.9010905@oracle.com> <566FEA83.6060105@oracle.com> <15686d26-99f4-449b-b5a8-f342632b2922@default> <56702DDF.9060407@oracle.com> <748D61D7-8CFC-42B3-959B-31D75A926133@oracle.com> Message-ID: <56729184.20704@oracle.com> Thanks for reviewing, Kim! On 2015-12-16 18:07, Kim Barrett wrote: > On Dec 15, 2015, at 10:12 AM, Marcus Larsson wrote: >> I think it's worth another round. :) >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.04/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.03-04/ > Looks good. > > I like the reorganization around the ConfigurationLock class. > > From marcus.larsson at oracle.com Thu Dec 17 10:42:46 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 17 Dec 2015 11:42:46 +0100 Subject: RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration In-Reply-To: <56724951.3090404@oracle.com> References: <566E962D.8010107@oracle.com> <566ED7F8.4090204@oracle.com> <566EE0AF.9010905@oracle.com> <566FEA83.6060105@oracle.com> <15686d26-99f4-449b-b5a8-f342632b2922@default> <56702DDF.9060407@oracle.com> <56724951.3090404@oracle.com> Message-ID: <567291A6.9070801@oracle.com> Thanks for reviewing, David! On 2015-12-17 06:34, David Holmes wrote: > Looks good! > > Thanks, > David > > On 16/12/2015 1:12 AM, Marcus Larsson wrote: >> Hey Markus, >> >> On 2015-12-15 11:58, Markus Gronlund wrote: >>> Hi Marcus, >>> >>> Looks good! >>> >>> One minor thing that you don't need to fix if you don't want to: >>> >>> I would use: >>> >>> class ConfigurationLock { >>> ... >>> >>> debug_only(static bool current_thread_has_lock();) >>> >>> }; >>> >>> to declare the this function in the class, then I would move the >>> definition outside of it (since it's sits inside ASSERT macros). >>> >>> #ifdef ASSERT >>> bool ConfigurationLock::current_thread_has_lock() { >>> return _locking_thread_id == os::current_thread_id(); >>> } >>> #endif >>> >>> >>> I just find it easier to read the class declaration without the macros >>> inside of the class declaration (and since this is debug code, there >>> is no real use of defining inline). As I said, you don?t need to fix >>> this and to post another webrev. >> >> I think it's worth another round. :) >> >> New webrev: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.04/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.03-04/ >> >> Thanks, >> Marcus >> >> >>> >>> Good work! >>> >>> /Markus >>> >>> >>> >>> -----Original Message----- >>> From: Marcus Larsson >>> Sent: den 15 december 2015 11:25 >>> To: serviceability-dev at openjdk.java.net >>> Cc: hotspot-runtime-dev at openjdk.java.net >>> Subject: Re: RFR: 8145083: Use semaphore instead of mutex for >>> synchronization of Unified Logging configuration >>> >>> Hi, >>> >>> New webrev: >>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.03/ >>> >>> Incremental: >>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.02-03/ >>> >>> ConfigurationLocker renamed to ConfigurationLock to avoid confusion >>> with the MutexLocker family of classes. >>> Semaphore and locking thread id moved into the ConfigurationLock; >>> added a function to check if current thread has the lock when asserts >>> are enabled. >>> >>> Regards, >>> Marcus >>> >>> >>> On 2015-12-14 16:30, Marcus Larsson wrote: >>>> Hi again, >>>> >>>> Made some changes to the patch after feedback from Markus Gr?nlund. >>>> The ConfigurationLocker and the semaphore have been moved out of the >>>> LogConfiguration.hpp and into the .cpp instead. The lock is only used >>>> internally by the LogConfiguration so this makes sense. It simplifies >>>> the LogConfiguration interface and hides the details of the locking >>>> under the hood. >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.02/ >>>> >>>> Incremental: >>>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01-02/ >>>> >>>> Thanks, >>>> Marcus >>>> >>>> On 2015-12-14 15:53, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01/ >>>>> >>>>> Incremental: >>>>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00-01/ >>>>> >>>>> Changes: >>>>> * Introduced the ConfigurationLocker class for automatic wait/signal >>>>> in constructor/destructor just like a MutexLocker. >>>>> * Added an assert to verify that the "lock" is held by the current >>>>> thread when calling configure_output. >>>>> * Made the config-string functions in LogOutput protected and >>>>> LogConfiguration a friend of LogOutput to prevent incorrect usage of >>>>> these functions. These functions should typically only be used inside >>>>> configure_output, which now ensures that the lock is held. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>> >>>>> On 2015-12-14 11:13, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the following patch to use a semaphore instead of a >>>>>> mutex for the synchronization of log configuration. Using a mutex >>>>>> requires some parts of the VM to be initialized, whereas the >>>>>> semaphores can be used right from the start. This simplifies the >>>>>> code and allows very early log configuration without special cases >>>>>> for early configuration vs reconfiguration after VM init. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00/ >>>>>> >>>>>> Issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8145083 >>>>>> >>>>>> Thanks, >>>>>> Marcus >> From thomas.stuefe at gmail.com Thu Dec 17 19:39:31 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 17 Dec 2015 20:39:31 +0100 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <56728EF4.7050704@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> <5387B10E-1AEF-428A-9096-E05E81A8071E@oracle.com> <5671DAFF.7060508@oracle.com> <56727545.4030004@oracle.com> <56728EF4.7050704@oracle.com> Message-ID: Hi all, we at SAP have years ago added a logging system to our hotspot port which is in many ways similar to UL but solves the multiline-problem differently. (Side note: we are currently discussing whether to abandon our logging system in favour of UL, just because merging down- and upstream would be easier if we use the same logging system) In our system, we assemble the multiline content in memory and then print it in one go. Only during the printing part we lock (and only on platforms where we cannot be sure that one write call would not be atomic). The advantage is that locking is not responsibility of the caller. Basically, we have a Message class, which serves as message buffer to grow on demand (dynamically allocates C heap), with some care taken to balance number or (re)allocation calls and memory usage. The caller itself is responsible for adding newlines. Basically, it looks like this: Message mymsg = new Message; mymgs->print("hallo1\nhallo2\nhallo3"); tracer->print(mymsg); <- here, tracer will lock, write, unlock When we print it, we precede the multiline message with the decorators in the first line and indent the rest of the lines to the same position: [time][pid][tid] hallo1 hallo2 hallo3 This approach has served us quite well. We decided against locking done by the caller because users to minimize the danger of deadlocks. Kind Regards, Thomas On Thu, Dec 17, 2015 at 11:31 AM, Marcus Larsson wrote: > Hi, > > > On 2015-12-17 09:41, Bengt Rutisson wrote: > >> >> >> On 2015-12-16 22:43, Coleen Phillimore wrote: >> >>> >>> >>> On 12/16/15 4:01 PM, John Rose wrote: >>> >>>> On Dec 15, 2015, at 12:26 PM, Rachel Protacio < >>>> rachel.protacio at oracle.com> wrote: >>>> >>>>> - each incident of ttyLocker that involved separate logging lines for >>>>> the same message have been consolidated to one line >>>>> - each incident of ttyLocker that involved separate print statements >>>>> to one logging line has been changed to write to a buffer first, then print >>>>> the entire line at once to the log stream >>>>> >>>> This is a strong argument for putting such functionality into the UL >>>> framework, >>>> instead of giving developers the unfortunate choice of either (a) doing >>>> it right >>>> with a bunch of random logic (Rachel's choice here) or (b) sweeping it >>>> under >>>> the carpet by breaking up a multi-part message into several log >>>> messages. >>>> >>>> We need to admit this is the Achilles Heel of logging as normally >>>> conceived >>>> (especially for very long multi-part messages like disassembler output, >>>> backtraces, or compilation logs), and just fix it in the UL frameowrk. >>>> >>> >>> Yes, I agree. We should file a high priority RFE against UL for this if >>> one isn't filed already. The runtime only uses ttyLocker (as far as I >>> found) for TraceExceptions but the compiler uses it more often to aggregate >>> messages. The lack of a locking mechanism seems to be one of the factors >>> blocking the compiler group adoption of this feature. And will block more >>> complex runtime logging conversions. >>> >>> So what do people vote that we do? Should we log the messages >>> separately until this is fixed? I agreed with making these logs one line >>> because even though they wrap, they weren't that long. It would be nice to >>> be able to do the conversion work to UL concurrently while finding problems >>> in the framework, and not be stuck. >>> >> >> From my point of view it would be very unfortunate to require all logging >> to take an extra lock. If the multiline support can be implemented in the >> UL framework without any extra cost for "normal" logging I would be fine >> with it. But if it would slow down the normal logging, which I assume would >> be the case if we require an extra lock, then I would prefer to push the >> responsibility up to the users of the UL framework to synchronize properly. >> > > Support for multi line logging was a stretch goal of the UL project that > was never implemented. I think it might be a good feature to have, given > that there is a lot of logging requiring such functionality. Regardless, > having this discussion is good, because I think we need to work out the > details of how it should work. For example, should each line in a > multi-line message be decorated? Do we write anything special to signify > that these lines are tied together? > > The current implementation relies on the OS to do proper synchronization > of the streams for the printf calls, which should guarantee that each line > will be written atomically. Introducing a lock will be necessary for > multi-line logging, but perhaps it won't be too bad if we use light weight > locks very fine grained around the printfs. If we measure an increased cost > for this, it should probably be weighed against the benefit for the use > cases requiring it. > > Regards, > Marcus > > >> Bengt >> >> >>> Thanks, >>> Coleen >>> >>>> >>>> ? John >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexhenrie24 at gmail.com Thu Dec 17 21:04:30 2015 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Thu, 17 Dec 2015 14:04:30 -0700 Subject: [PATCH resend2] Skip the null pointer check before calling realloc In-Reply-To: <56727DC6.9070309@oracle.com> References: <6dca8affef8a4566dfaa.1450212201@localhost.localdomain> <56727DC6.9070309@oracle.com> Message-ID: 2015-12-17 2:17 GMT-07:00 Dmitry Samersoff : > I'll sponsor the push, but please: > > 1. fix realloc issue as it suggested by Dan and me. > > 2. prepare a webrev (I'll put it under my ojdk account to > /sponsorship/alexhenrie) Here you go. -Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: webrev.zip Type: application/zip Size: 81336 bytes Desc: not available URL: From john.r.rose at oracle.com Fri Dec 18 04:13:24 2015 From: john.r.rose at oracle.com (John Rose) Date: Thu, 17 Dec 2015 20:13:24 -0800 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> <5387B10E-1AEF-428A-9096-E05E81A8071E@oracle.com> <5671DAFF.7060508@oracle.com> <56727545.4030004@oracle.com> <56728EF4.7050704@oracle.com> Message-ID: On Dec 17, 2015, at 11:39 AM, Thomas St?fe wrote: > > When we print it, we precede the multiline message with the decorators in the first line and indent the rest of the lines to the same position: > > [time][pid][tid] hallo1 > hallo2 > hallo3 > > This approach has served us quite well. We decided against locking done by the caller because users to minimize the danger of deadlocks. I agree that buffering is a better approach than locking. In the old logging system, large amounts of logging are produced by the compiler threads, and is buffered separately per thread. Smaller amounts are dumped into a common "tty" stream, which is available only to one thread at a time. The effect of the ttyLocker is to ensure unbroken multi-line output. It doesn't intrinsically need to block other writers. Buffering is a great way to keep integrity without blocking. This could be introduced into the new UL framework like this: LogHandle(logging) log0; if (log0.is_debug()) { LogBuffer log(log0); int result = compute_debug_result(); log.debug("result = %d", result).trace(" tracing info"); obj->print_on(log.debug_stream()); } Or just: { LogBuffer(logging) log; if (log.is_debug()) { int result = compute_debug_result(); log.debug("result = %d", result).trace(" tracing info"); obj->print_on(log.debug_stream()); } } The "log" is a separate object from "log0" which has the same API, and buffers all output before flushing to the underlying "log0". (The RAII destructor flushes. Maybe it also has explicit flush.) Note that "log" has true object state, whereas "log0" is just a bundle of static methods. Perhaps LogBuffer could be economically used inside the Log methods themselves; currently they do buffering equivalent to what LogBuffer does, but using random logic (see uses of constant LogBufferSize). Basically, wherever a "printf" format is used with Log API points, there is already a hidden buffer (it resizes at most once, since there is just one printf call). Optional parameters to LogBuffer would control behavior related to (possibly) splitting very large outputs (like PrintAssembly), or buffering to files (using the rotating archive mechanism). This would provide a road to replacing the existing LogCompilation implementation, which has thread-local logs buffered to temp files. I.e., a long-lived, thread-local, file-backed LogBuffer would allow a compiler thread to produce gigabytes of output, all properly sequenced, with no interruptions and no blocking of other logs. Having a separate layer "LogBuffer" for keeping lines together will not penalize users of the underlying line-at-time facility. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Dec 18 04:51:32 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Dec 2015 14:51:32 +1000 Subject: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ... In-Reply-To: <567270F6.7030206@oracle.com> References: <566ECDA6.1030404@oracle.com> <566FB3BB.4050709@oracle.com> <567000F9.2070603@oracle.com> <56700279.4000408@oracle.com> <56700531.8060701@oracle.com> <56724BE9.5060304@oracle.com> <567270F6.7030206@oracle.com> Message-ID: <567390D4.10307@oracle.com> On 17/12/2015 6:23 PM, Ivan Gerasimov wrote: > > > On 17.12.2015 8:45, David Holmes wrote: >> On 15/12/2015 10:18 PM, Ivan Gerasimov wrote: >>> >>>> >>>> while(true) would convey that much more clearly - and perhaps obviate >>>> the need for pr_ex. >>>> >>> >>> Yes, I can surely transform the code >>> >>> - while (pr_ex != curr_id) { >>> + if (pr_ex != curr_id) { >>> + while (true} { >>> >>> The intention was to save a line :-) >>> >>> I'll use while (true), if it improves readability. >> >> It does :) And I don't you need pr_ex then as you can just compare >> OrderAccess::load_acquire(&process_exiting) with the current thread id >> - right? >> > > We will suspend the current thread if two conditions are satisfied: > process_exiting != 0 and process_exiting != current thread id. > But, yes, pr_ex isn't really needed, as we can use process_exiting > directly. > > Here's the updated webrev: > http://cr.openjdk.java.net/~igerasim/8145127/01/webrev/ I still see pr_ex ?? David > > Sincerely yours, > Ivan > From david.holmes at oracle.com Fri Dec 18 05:44:43 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Dec 2015 15:44:43 +1000 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <56727545.4030004@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> <5387B10E-1AEF-428A-9096-E05E81A8071E@oracle.com> <5671DAFF.7060508@oracle.com> <56727545.4030004@oracle.com> Message-ID: <56739D4B.5030405@oracle.com> On 17/12/2015 6:41 PM, Bengt Rutisson wrote: > On 2015-12-16 22:43, Coleen Phillimore wrote: >> On 12/16/15 4:01 PM, John Rose wrote: >>> On Dec 15, 2015, at 12:26 PM, Rachel Protacio >>> wrote: >>>> - each incident of ttyLocker that involved separate logging lines >>>> for the same message have been consolidated to one line >>>> - each incident of ttyLocker that involved separate print statements >>>> to one logging line has been changed to write to a buffer first, >>>> then print the entire line at once to the log stream >>> This is a strong argument for putting such functionality into the UL >>> framework, >>> instead of giving developers the unfortunate choice of either (a) >>> doing it right >>> with a bunch of random logic (Rachel's choice here) or (b) sweeping >>> it under >>> the carpet by breaking up a multi-part message into several log >>> messages. >>> >>> We need to admit this is the Achilles Heel of logging as normally >>> conceived >>> (especially for very long multi-part messages like disassembler output, >>> backtraces, or compilation logs), and just fix it in the UL frameowrk. >> >> Yes, I agree. We should file a high priority RFE against UL for this >> if one isn't filed already. The runtime only uses ttyLocker (as far >> as I found) for TraceExceptions but the compiler uses it more often to >> aggregate messages. The lack of a locking mechanism seems to be one >> of the factors blocking the compiler group adoption of this feature. >> And will block more complex runtime logging conversions. >> >> So what do people vote that we do? Should we log the messages >> separately until this is fixed? I agreed with making these logs one >> line because even though they wrap, they weren't that long. It would >> be nice to be able to do the conversion work to UL concurrently while >> finding problems in the framework, and not be stuck. > > From my point of view it would be very unfortunate to require all > logging to take an extra lock. If the multiline support can be > implemented in the UL framework without any extra cost for "normal" > logging I would be fine with it. But if it would slow down the normal > logging, which I assume would be the case if we require an extra lock, > then I would prefer to push the responsibility up to the users of the UL > framework to synchronize properly. How would users of the framework synchronize access to a shared resource where some of the users of the resource are not party to the synchronization process? AFAICS the synchronization has to be at the resource-level. David ----- > Bengt > >> >> Thanks, >> Coleen >>> >>> ? John >> > From kubota.yuji at gmail.com Fri Dec 18 06:27:35 2015 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Fri, 18 Dec 2015 15:27:35 +0900 Subject: Unexpected ArithmeticException at sun.jvm.hotspot.utilities.CompactHashTable Message-ID: Hi all, I caught an unexpected java.lang.ArithmeticException by CLHSDB through jhsdb as below. ----- ./jhsdb clhsdb --pid 16809 Attaching to process 16809, please wait... hsdb> class java/lang/ArithmeticException java/lang/ArithmeticException @0x0000000100011958 hsdb> class java class not found: java hsdb> class java/lang Error: java.lang.ArithmeticException: / by zero ----- I think that CLHSDB returns "class not found: java/lang". But ArithmetricException is returned instead. CLHSDB tries to search the given class name from the regular symbol table and the shared symbol table. And called the probe function of the shared symbol table does not support a case of the empty bucket such as below expression > long index = hash % bucketCount(); then, throws ArithmetricException. The stack trace of this java.lang.ArithmeticException is here. ------ java.lang.ArithmeticException: / by zero at sun.jvm.hotspot.utilities.CompactHashTable.probe(CompactHashTable.java:89) at sun.jvm.hotspot.memory.SymbolTable.probe(SymbolTable.java:97) at sun.jvm.hotspot.memory.SymbolTable.probe(SymbolTable.java:75) at sun.jvm.hotspot.memory.SystemDictionary.find(SystemDictionary.java:149) at sun.jvm.hotspot.utilities.SystemDictionaryHelper.findInstanceKlass(SystemDictionaryHelper.java:107) at jdk.nashorn.internal.scripts.Script$Recompilation$2402$7541A$sa.main$jclass(sa.js:247) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:625) at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:511) at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393) at jdk.nashorn.api.scripting.ScriptObjectMirror.callMember(ScriptObjectMirror.java:199) at jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(NashornScriptEngine.java:383) at jdk.nashorn.api.scripting.NashornScriptEngine.invokeFunction(NashornScriptEngine.java:190) at sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.call(JSJavaScriptEngine.java:78) at sun.jvm.hotspot.CommandProcessor$52.doit(CommandProcessor.java:1755) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1951) at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1921) at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1801) at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) at sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:134) at sun.jvm.hotspot.SALauncher.main(SALauncher.java:334) ------ I have created a patch from jdk9/dev/hotspot (changeset: 9625:de592ea5f7ba) as below, and checked to return "class not found java/lang" correctly. Please review it. diff --git a/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java b/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java --- a/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java +++ b/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java @@ -86,6 +86,10 @@ Address baseAddress = baseAddressField.getValue(addr); Address bucket = bucketsField.getValue(addr); Address bucketEnd = bucket; + + if (bucketCount() == 0) { + return null; + } long index = hash % bucketCount(); int bucketInfo = (int)bucket.getCIntegerAt(index * uintSize, uintSize, true); int bucketOffset = bucketOffset(bucketInfo); Thanks, Yuji From thomas.stuefe at gmail.com Fri Dec 18 08:12:12 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 18 Dec 2015 09:12:12 +0100 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> <5387B10E-1AEF-428A-9096-E05E81A8071E@oracle.com> <5671DAFF.7060508@oracle.com> <56727545.4030004@oracle.com> <56728EF4.7050704@oracle.com> Message-ID: On Thu, Dec 17, 2015 at 8:39 PM, Thomas St?fe wrote: > Hi all, > > we at SAP have years ago added a logging system to our hotspot port which > is in many ways similar to UL but solves the multiline-problem differently. > > (Side note: we are currently discussing whether to abandon our logging > system in favour of UL, just because merging down- and upstream would be > easier if we use the same logging system) > > In our system, we assemble the multiline content in memory and then print > it in one go. Only during the printing part we lock (and only on platforms > where we cannot be sure that one write call would not be atomic). The > advantage is that locking is not responsibility of the caller. > > Basically, we have a Message class, which serves as message buffer to grow > on demand (dynamically allocates C heap), with some care taken to balance > number or (re)allocation calls and memory usage. The caller itself is > responsible for adding newlines. > > Basically, it looks like this: > > Message mymsg = new Message; > mymgs->print("hallo1\nhallo2\nhallo3"); > tracer->print(mymsg); <- here, tracer will lock, write, unlock > > When we print it, we precede the multiline message with the decorators in > the first line and indent the rest of the lines to the same position: > > [time][pid][tid] hallo1 > hallo2 > hallo3 > > This approach has served us quite well. We decided against locking done by > the caller because users to minimize the danger of deadlocks. > > Kind Regards, Thomas > > Just wanted to add that one big advantage of buffering compared to locking is that you do not influence timing as much. With locking, you now introduce synchronization where before was none, which even if it does not deadlock may change timing just enough to make the error you are analyzing disappear. Granted, logging causes File IO which also changes timing, but who says you are always writing to files. If timing is really important, you could log into shared memory or similar. But once locking is introduced in the log system, it is difficult to get rid of again. ..Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Fri Dec 18 08:27:14 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 18 Dec 2015 09:27:14 +0100 Subject: [bump] Re: RFR 8145417: JInfoSanityTest failed with Error attaching to remote server: java.rmi.ConnectException: Connection refused In-Reply-To: <567176ED.5050208@oracle.com> References: <567176ED.5050208@oracle.com> Message-ID: <5673C362.4010108@oracle.com> On 16.12.2015 15:36, Jaroslav Bachorik wrote: > Please, review the following simple test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8145417 > Webrev: http://cr.openjdk.java.net/~jbachorik/8145417/webrev.00 > > The affected tests check for 'Unknown host' in stderr. In some > situations this line may not appear, although an alternative error > indicating unavailability of the target host is thrown, and it is > necessary to make the error matching more robust (eg. checking also for > 'Connection refused to host:' message). > > Thanks, > > -JB- From thomas.stuefe at gmail.com Fri Dec 18 08:35:30 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 18 Dec 2015 09:35:30 +0100 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> <5387B10E-1AEF-428A-9096-E05E81A8071E@oracle.com> <5671DAFF.7060508@oracle.com> <56727545.4030004@oracle.com> <56728EF4.7050704@oracle.com> Message-ID: Hi John, On Fri, Dec 18, 2015 at 5:13 AM, John Rose wrote: > On Dec 17, 2015, at 11:39 AM, Thomas St?fe > wrote: > > > When we print it, we precede the multiline message with the decorators in > the first line and indent the rest of the lines to the same position: > > [time][pid][tid] hallo1 > hallo2 > hallo3 > > This approach has served us quite well. We decided against locking done by > the caller because users to minimize the danger of deadlocks. > > > I agree that buffering is a better approach than locking. > In the old logging system, large amounts of logging are > produced by the compiler threads, and is buffered separately > per thread. Smaller amounts are dumped into a common "tty" > stream, which is available only to one thread at a time. > > The effect of the ttyLocker is to ensure unbroken multi-line output. > It doesn't intrinsically need to block other writers. > > Buffering is a great way to keep integrity without blocking. > This could be introduced into the new UL framework like this: > > LogHandle(logging) log0; > if (log0.is_debug()) { > LogBuffer log(log0); > int result = compute_debug_result(); > log.debug("result = %d", result).trace(" tracing info"); > obj->print_on(log.debug_stream()); > } > > Or just: > { LogBuffer(logging) log; > if (log.is_debug()) { > int result = compute_debug_result(); > log.debug("result = %d", result).trace(" tracing info"); > obj->print_on(log.debug_stream()); > } } > > The "log" is a separate object from "log0" which has the same API, > and buffers all output before flushing to the underlying "log0". > (The RAII destructor flushes. Maybe it also has explicit flush.) > > Note that "log" has true object state, whereas "log0" is just a > bundle of static methods. > > This is almost exactly what we did. Note that this approach is subtly different to ttyLocker in that is only affects your own logging calls. If the code section in which you assemble the LogBuffer were larger and interspersed with other logging calls to other tags (e.g. in functions you call), those other logging calls would go on unmolested. I find this actually better. Perhaps LogBuffer could be economically used inside the Log methods > themselves; currently they do buffering equivalent to what LogBuffer > does, but using random logic (see uses of constant LogBufferSize). > Basically, wherever a "printf" format is used with Log API points, > there is already a hidden buffer (it resizes at most once, since > there is just one printf call). > > Optional parameters to LogBuffer would control behavior related > to (possibly) splitting very large outputs (like PrintAssembly), > or buffering to files (using the rotating archive mechanism). > > This would provide a road to replacing the existing LogCompilation > implementation, which has thread-local logs buffered to temp files. > > I.e., a long-lived, thread-local, file-backed LogBuffer would allow > a compiler thread to produce gigabytes of output, all properly > sequenced, with no interruptions and no blocking of other logs. > > Having a separate layer "LogBuffer" for keeping lines together > will not penalize users of the underlying line-at-time facility. > > ? John > Note that you also could hide the buffer management completely in UL and just expose a database-like commit semantic, coupled with a thread-local buffer. Like this: log.start_multiline_message(); log.. log.. log.. log.commit_multiline_message(); All log calls between start_multiline_message() and commit_multiline_message() would not go to the normal destination but to a temporary buffer which is anchored in native thread local storage (not necessarily Thread::current() as that may or may not exist). In commit_multiline_message(), this buffer then is flushed to the real destination. Advantage: - You keep the normal logging calls as much as possible - this is very similar to the already existing ttyLocker semantic Disadvantage: - As said earlier, this affects all logging calls inbetween start_multiline_message() and commit_multiline_message(), not just yours Neither advantage nor disadvantage: you keep the TLS-anchored buffer around. This is nice because next time you log you save an allocation call, but needs to be managed to not be a memory drain. For instance, in commit_multiline_message() the buffer should be cut back to certain maximum size. I am unsure which approach I find better - the one where the caller creates an explicit buffer or the one where the logging system manages the buffer. Any would be fine for us. Kind Regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Fri Dec 18 08:43:14 2015 From: john.r.rose at oracle.com (John Rose) Date: Fri, 18 Dec 2015 00:43:14 -0800 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> <5387B10E-1AEF-428A-9096-E05E81A8071E@oracle.com> <5671DAFF.7060508@oracle.com> <56727545.4030004@oracle.com> <56728EF4.7050704@oracle.com> Message-ID: <8ACC184C-4641-4E12-AB46-C00FF51B69EE@oracle.com> On Dec 18, 2015, at 12:35 AM, Thomas St?fe wrote: > > Neither advantage nor disadvantage: you keep the TLS-anchored buffer around. This is nice because next time you log you save an allocation call, but needs to be managed to not be a memory drain. For instance, in commit_multiline_message() the buffer should be cut back to certain maximum size. > > I am unsure which approach I find better - the one where the caller creates an explicit buffer or the one where the logging system manages the buffer. Any would be fine for us. The approaches can be combined: Require the user to link the transaction together explicitly (in my example) but allow the transaction object (LogBuffer) to reuse a stashed thread-local buffer. Actually, for HotSpot, it's likely that a thread-local ResourceArea would often be the best fit, since blocks in those are cheap to allocate and free. I view the implicit addressing of the transaction buffer (in your code) as a special disadvantage, because it forces all log calls to check foir a thread-local condition (running transaction). That's probably what you meant by forcing everybody to pay the cost for the feature. The UL code is a veritable hive of templatery. A few more templates will give us a static distinction between log channels that are stateless and those which buffer, with little or no apparent difference to the user. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Fri Dec 18 09:14:47 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 18 Dec 2015 10:14:47 +0100 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <56739D4B.5030405@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> <5387B10E-1AEF-428A-9096-E05E81A8071E@oracle.com> <5671DAFF.7060508@oracle.com> <56727545.4030004@oracle.com> <56739D4B.5030405@oracle.com> Message-ID: <5673CE87.2040008@oracle.com> On 2015-12-18 06:44, David Holmes wrote: > On 17/12/2015 6:41 PM, Bengt Rutisson wrote: >> On 2015-12-16 22:43, Coleen Phillimore wrote: >>> On 12/16/15 4:01 PM, John Rose wrote: >>>> On Dec 15, 2015, at 12:26 PM, Rachel Protacio >>>> wrote: >>>>> - each incident of ttyLocker that involved separate logging lines >>>>> for the same message have been consolidated to one line >>>>> - each incident of ttyLocker that involved separate print statements >>>>> to one logging line has been changed to write to a buffer first, >>>>> then print the entire line at once to the log stream >>>> This is a strong argument for putting such functionality into the UL >>>> framework, >>>> instead of giving developers the unfortunate choice of either (a) >>>> doing it right >>>> with a bunch of random logic (Rachel's choice here) or (b) sweeping >>>> it under >>>> the carpet by breaking up a multi-part message into several log >>>> messages. >>>> >>>> We need to admit this is the Achilles Heel of logging as normally >>>> conceived >>>> (especially for very long multi-part messages like disassembler >>>> output, >>>> backtraces, or compilation logs), and just fix it in the UL frameowrk. >>> >>> Yes, I agree. We should file a high priority RFE against UL for this >>> if one isn't filed already. The runtime only uses ttyLocker (as far >>> as I found) for TraceExceptions but the compiler uses it more often to >>> aggregate messages. The lack of a locking mechanism seems to be one >>> of the factors blocking the compiler group adoption of this feature. >>> And will block more complex runtime logging conversions. >>> >>> So what do people vote that we do? Should we log the messages >>> separately until this is fixed? I agreed with making these logs one >>> line because even though they wrap, they weren't that long. It would >>> be nice to be able to do the conversion work to UL concurrently while >>> finding problems in the framework, and not be stuck. >> >> From my point of view it would be very unfortunate to require all >> logging to take an extra lock. If the multiline support can be >> implemented in the UL framework without any extra cost for "normal" >> logging I would be fine with it. But if it would slow down the normal >> logging, which I assume would be the case if we require an extra lock, >> then I would prefer to push the responsibility up to the users of the UL >> framework to synchronize properly. > > How would users of the framework synchronize access to a shared > resource where some of the users of the resource are not party to the > synchronization process? AFAICS the synchronization has to be at the > resource-level. I think it depends on what problem we are trying to solve. In most cases I have seen so far it would be fine for two different activities to log their output interleaved. If for example the compiler would log something during a GC I wouldn't see that as a serious problem. It is easy for a reader of the log file (human or machine) to sort out the logging since logging is never interleaved on the same line. And there is also the possibility for a user to pipe the logging to different files based on their tags. The problem I thought this email thread was about was when the same type of logging is done from multiple threads. Having multiple threads log multiple lines of similar data at the same time will be very hard to sort out after-the-fact in the log file. But since it is the same subsystem that does the logging that subsystem could introduce its own synchronization. It would of course not be synchronized with all other users of the UL framework, but I don't think that is such a big problem. Having said that, I am not against introducing multi-line logging support in the UL framework. I just would like to make sure that it does not come with a too high cost for all the use cases where the synchronization is not a problem. Using a buffered logger, as is being discussed now, would probably be a good solution since it wouldn't introduce a cost for the other logging. Bengt > > David > ----- > >> Bengt >> >>> >>> Thanks, >>> Coleen >>>> >>>> ? John >>> >> From serguei.spitsyn at oracle.com Fri Dec 18 10:23:29 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 18 Dec 2015 02:23:29 -0800 Subject: [bump] Re: RFR 8145417: JInfoSanityTest failed with Error attaching to remote server: java.rmi.ConnectException: Connection refused In-Reply-To: <5673C362.4010108@oracle.com> References: <567176ED.5050208@oracle.com> <5673C362.4010108@oracle.com> Message-ID: <5673DEA1.3050508@oracle.com> Looks good. Thanks, Serguei On 12/18/15 00:27, Jaroslav Bachorik wrote: > On 16.12.2015 15:36, Jaroslav Bachorik wrote: >> Please, review the following simple test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8145417 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8145417/webrev.00 >> >> The affected tests check for 'Unknown host' in stderr. In some >> situations this line may not appear, although an alternative error >> indicating unavailability of the target host is thrown, and it is >> necessary to make the error matching more robust (eg. checking also for >> 'Connection refused to host:' message). >> >> Thanks, >> >> -JB- > From marcus.larsson at oracle.com Fri Dec 18 13:01:22 2015 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 18 Dec 2015 14:01:22 +0100 Subject: [PING] Re: RFR: 8145294: TestLogRotation.java triggers a race in the UL framework In-Reply-To: <567124DA.204@oracle.com> References: <567124DA.204@oracle.com> Message-ID: <567403A2.5020108@oracle.com> On 2015-12-16 09:46, Marcus Larsson wrote: > Hi, > > Please review the following patch to fix a race in file rotations with > UL. > > Summary: > freopen and fwrite are not safe to use concurrently and hence the VM > might crash if a thread tries to write during a rotation. Writing and > rotating needs to be properly synchronized, but using a Mutex is > problematic here because the synchronization must be usable already at > argument parse time. The patch replaces the previously used mutexes > with semaphores (like with the LogConfiguration_lock case). > LogFileOutputs are now rotatable at any time and the LogOutput > interface has been simplified to reflect this. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8145294/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8145294 > > Testing: > TestLogRotation in RBT and locally > > Thanks, > Marcus From david.holmes at oracle.com Fri Dec 18 13:06:47 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Dec 2015 23:06:47 +1000 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <5673CE87.2040008@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> <5387B10E-1AEF-428A-9096-E05E81A8071E@oracle.com> <5671DAFF.7060508@oracle.com> <56727545.4030004@oracle.com> <56739D4B.5030405@oracle.com> <5673CE87.2040008@oracle.com> Message-ID: <567404E7.2030205@oracle.com> On 18/12/2015 7:14 PM, Bengt Rutisson wrote: > > > On 2015-12-18 06:44, David Holmes wrote: >> On 17/12/2015 6:41 PM, Bengt Rutisson wrote: >>> On 2015-12-16 22:43, Coleen Phillimore wrote: >>>> On 12/16/15 4:01 PM, John Rose wrote: >>>>> On Dec 15, 2015, at 12:26 PM, Rachel Protacio >>>>> wrote: >>>>>> - each incident of ttyLocker that involved separate logging lines >>>>>> for the same message have been consolidated to one line >>>>>> - each incident of ttyLocker that involved separate print statements >>>>>> to one logging line has been changed to write to a buffer first, >>>>>> then print the entire line at once to the log stream >>>>> This is a strong argument for putting such functionality into the UL >>>>> framework, >>>>> instead of giving developers the unfortunate choice of either (a) >>>>> doing it right >>>>> with a bunch of random logic (Rachel's choice here) or (b) sweeping >>>>> it under >>>>> the carpet by breaking up a multi-part message into several log >>>>> messages. >>>>> >>>>> We need to admit this is the Achilles Heel of logging as normally >>>>> conceived >>>>> (especially for very long multi-part messages like disassembler >>>>> output, >>>>> backtraces, or compilation logs), and just fix it in the UL frameowrk. >>>> >>>> Yes, I agree. We should file a high priority RFE against UL for this >>>> if one isn't filed already. The runtime only uses ttyLocker (as far >>>> as I found) for TraceExceptions but the compiler uses it more often to >>>> aggregate messages. The lack of a locking mechanism seems to be one >>>> of the factors blocking the compiler group adoption of this feature. >>>> And will block more complex runtime logging conversions. >>>> >>>> So what do people vote that we do? Should we log the messages >>>> separately until this is fixed? I agreed with making these logs one >>>> line because even though they wrap, they weren't that long. It would >>>> be nice to be able to do the conversion work to UL concurrently while >>>> finding problems in the framework, and not be stuck. >>> >>> From my point of view it would be very unfortunate to require all >>> logging to take an extra lock. If the multiline support can be >>> implemented in the UL framework without any extra cost for "normal" >>> logging I would be fine with it. But if it would slow down the normal >>> logging, which I assume would be the case if we require an extra lock, >>> then I would prefer to push the responsibility up to the users of the UL >>> framework to synchronize properly. >> >> How would users of the framework synchronize access to a shared >> resource where some of the users of the resource are not party to the >> synchronization process? AFAICS the synchronization has to be at the >> resource-level. > > I think it depends on what problem we are trying to solve. In most cases > I have seen so far it would be fine for two different activities to log > their output interleaved. If for example the compiler would log > something during a GC I wouldn't see that as a serious problem. It is I don't really agree but I see where you are coming from. > easy for a reader of the log file (human or machine) to sort out the > logging since logging is never interleaved on the same line. And there Actually ... we have seen Trace output "corrupted" somehow where lines are combined. This happened with some CDS-related tests earlier this year with TraceClassLoading - we had to relax the pattern so the corrupted lines would be accepted. Never did get to the bottom of it. Cheers, David > is also the possibility for a user to pipe the logging to different > files based on their tags. > > The problem I thought this email thread was about was when the same type > of logging is done from multiple threads. Having multiple threads log > multiple lines of similar data at the same time will be very hard to > sort out after-the-fact in the log file. But since it is the same > subsystem that does the logging that subsystem could introduce its own > synchronization. It would of course not be synchronized with all other > users of the UL framework, but I don't think that is such a big problem. > > Having said that, I am not against introducing multi-line logging > support in the UL framework. I just would like to make sure that it does > not come with a too high cost for all the use cases where the > synchronization is not a problem. > > Using a buffered logger, as is being discussed now, would probably be a > good solution since it wouldn't introduce a cost for the other logging. > > Bengt > > > >> >> David >> ----- >> >>> Bengt >>> >>>> >>>> Thanks, >>>> Coleen >>>>> >>>>> ? John >>>> >>> > From dmitry.samersoff at oracle.com Fri Dec 18 13:11:03 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 18 Dec 2015 16:11:03 +0300 Subject: [PATCH resend2] Skip the null pointer check before calling realloc In-Reply-To: References: <6dca8affef8a4566dfaa.1450212201@localhost.localdomain> <56727DC6.9070309@oracle.com> Message-ID: <567405E7.2060804@oracle.com> Alex, Unfortunately, webrev.zip attachment is removed from the e-mail. Could you put it somewhere and send me a link? Sorry for inconvenience. -Dmitry On 2015-12-18 00:04, Alex Henrie wrote: > An attachment in the email has been found to contain executable code and has been removed. > > File removed : webrev.zip, zip,html,list,c,c,,html,html,html,html,html,html,html,html,patch,html,html,patch,js > > ---------------------------------------------------------------------- > 2015-12-17 2:17 GMT-07:00 Dmitry Samersoff : >> I'll sponsor the push, but please: >> >> 1. fix realloc issue as it suggested by Dan and me. >> >> 2. prepare a webrev (I'll put it under my ojdk account to >> /sponsorship/alexhenrie) > > Here you go. > > -Alex > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Fri Dec 18 13:29:38 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 18 Dec 2015 14:29:38 +0100 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <567404E7.2030205@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> <5387B10E-1AEF-428A-9096-E05E81A8071E@oracle.com> <5671DAFF.7060508@oracle.com> <56727545.4030004@oracle.com> <56739D4B.5030405@oracle.com> <5673CE87.2040008@oracle.com> <567404E7.2030205@oracle.com> Message-ID: > On 18 dec. 2015, at 14:06, David Holmes wrote: > > On 18/12/2015 7:14 PM, Bengt Rutisson wrote: >> >> >> On 2015-12-18 06:44, David Holmes wrote: >>> On 17/12/2015 6:41 PM, Bengt Rutisson wrote: >>>> On 2015-12-16 22:43, Coleen Phillimore wrote: >>>>> On 12/16/15 4:01 PM, John Rose wrote: >>>>>> On Dec 15, 2015, at 12:26 PM, Rachel Protacio >>>>>> wrote: >>>>>>> - each incident of ttyLocker that involved separate logging lines >>>>>>> for the same message have been consolidated to one line >>>>>>> - each incident of ttyLocker that involved separate print statements >>>>>>> to one logging line has been changed to write to a buffer first, >>>>>>> then print the entire line at once to the log stream >>>>>> This is a strong argument for putting such functionality into the UL >>>>>> framework, >>>>>> instead of giving developers the unfortunate choice of either (a) >>>>>> doing it right >>>>>> with a bunch of random logic (Rachel's choice here) or (b) sweeping >>>>>> it under >>>>>> the carpet by breaking up a multi-part message into several log >>>>>> messages. >>>>>> >>>>>> We need to admit this is the Achilles Heel of logging as normally >>>>>> conceived >>>>>> (especially for very long multi-part messages like disassembler >>>>>> output, >>>>>> backtraces, or compilation logs), and just fix it in the UL frameowrk. >>>>> >>>>> Yes, I agree. We should file a high priority RFE against UL for this >>>>> if one isn't filed already. The runtime only uses ttyLocker (as far >>>>> as I found) for TraceExceptions but the compiler uses it more often to >>>>> aggregate messages. The lack of a locking mechanism seems to be one >>>>> of the factors blocking the compiler group adoption of this feature. >>>>> And will block more complex runtime logging conversions. >>>>> >>>>> So what do people vote that we do? Should we log the messages >>>>> separately until this is fixed? I agreed with making these logs one >>>>> line because even though they wrap, they weren't that long. It would >>>>> be nice to be able to do the conversion work to UL concurrently while >>>>> finding problems in the framework, and not be stuck. >>>> >>>> From my point of view it would be very unfortunate to require all >>>> logging to take an extra lock. If the multiline support can be >>>> implemented in the UL framework without any extra cost for "normal" >>>> logging I would be fine with it. But if it would slow down the normal >>>> logging, which I assume would be the case if we require an extra lock, >>>> then I would prefer to push the responsibility up to the users of the UL >>>> framework to synchronize properly. >>> >>> How would users of the framework synchronize access to a shared >>> resource where some of the users of the resource are not party to the >>> synchronization process? AFAICS the synchronization has to be at the >>> resource-level. >> >> I think it depends on what problem we are trying to solve. In most cases >> I have seen so far it would be fine for two different activities to log >> their output interleaved. If for example the compiler would log >> something during a GC I wouldn't see that as a serious problem. It is > > I don't really agree but I see where you are coming from. > >> easy for a reader of the log file (human or machine) to sort out the >> logging since logging is never interleaved on the same line. And there > > Actually ... we have seen Trace output "corrupted" somehow where lines are combined. This happened with some CDS-related tests earlier this year with TraceClassLoading - we had to relax the pattern so the corrupted lines would be accepted. Never did get to the bottom of it. Have you seen this happen with UL as well? > > Cheers, > David > >> is also the possibility for a user to pipe the logging to different >> files based on their tags. >> >> The problem I thought this email thread was about was when the same type >> of logging is done from multiple threads. Having multiple threads log >> multiple lines of similar data at the same time will be very hard to >> sort out after-the-fact in the log file. But since it is the same >> subsystem that does the logging that subsystem could introduce its own >> synchronization. It would of course not be synchronized with all other >> users of the UL framework, but I don't think that is such a big problem. >> >> Having said that, I am not against introducing multi-line logging >> support in the UL framework. I just would like to make sure that it does >> not come with a too high cost for all the use cases where the >> synchronization is not a problem. >> >> Using a buffered logger, as is being discussed now, would probably be a >> good solution since it wouldn't introduce a cost for the other logging. >> >> Bengt >> >> >> >>> >>> David >>> ----- >>> >>>> Bengt >>>> >>>>> >>>>> Thanks, >>>>> Coleen >>>>>> >>>>>> ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Fri Dec 18 13:32:54 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 18 Dec 2015 14:32:54 +0100 Subject: [PING] RFR: 8145294: TestLogRotation.java triggers a race in the UL framework In-Reply-To: <567403A2.5020108@oracle.com> References: <567124DA.204@oracle.com> <567403A2.5020108@oracle.com> Message-ID: <0760133E-7C8F-4937-974E-C625FC5AE462@oracle.com> Looks good! Thanks, /Staffan > On 18 dec. 2015, at 14:01, Marcus Larsson wrote: > > > > On 2015-12-16 09:46, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to fix a race in file rotations with UL. >> >> Summary: >> freopen and fwrite are not safe to use concurrently and hence the VM might crash if a thread tries to write during a rotation. Writing and rotating needs to be properly synchronized, but using a Mutex is problematic here because the synchronization must be usable already at argument parse time. The patch replaces the previously used mutexes with semaphores (like with the LogConfiguration_lock case). LogFileOutputs are now rotatable at any time and the LogOutput interface has been simplified to reflect this. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8145294/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8145294 >> >> Testing: >> TestLogRotation in RBT and locally >> >> Thanks, >> Marcus > From mikael.gerdin at oracle.com Fri Dec 18 13:47:04 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 18 Dec 2015 14:47:04 +0100 Subject: [PATCH resend2] Skip the null pointer check before calling realloc In-Reply-To: <567405E7.2060804@oracle.com> References: <6dca8affef8a4566dfaa.1450212201@localhost.localdomain> <56727DC6.9070309@oracle.com> <567405E7.2060804@oracle.com> Message-ID: <56740E58.2080408@oracle.com> Dmitry, On 2015-12-18 14:11, Dmitry Samersoff wrote: > Alex, > > Unfortunately, webrev.zip attachment is removed from the e-mail. > > Could you put it somewhere and send me a link? http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-December/018519.html I got the attachment just fine, maybe there is something specific to your setup which disallows you from receiving it? /Mikael > > Sorry for inconvenience. > > -Dmitry > > > On 2015-12-18 00:04, Alex Henrie wrote: >> An attachment in the email has been found to contain executable code and has been removed. >> >> File removed : webrev.zip, zip,html,list,c,c,,html,html,html,html,html,html,html,html,patch,html,html,patch,js >> >> ---------------------------------------------------------------------- >> 2015-12-17 2:17 GMT-07:00 Dmitry Samersoff : >>> I'll sponsor the push, but please: >>> >>> 1. fix realloc issue as it suggested by Dan and me. >>> >>> 2. prepare a webrev (I'll put it under my ojdk account to >>> /sponsorship/alexhenrie) >> >> Here you go. >> >> -Alex >> > > From dmitry.samersoff at oracle.com Fri Dec 18 13:50:17 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 18 Dec 2015 16:50:17 +0300 Subject: [PATCH resend2] Skip the null pointer check before calling realloc In-Reply-To: <56740E58.2080408@oracle.com> References: <6dca8affef8a4566dfaa.1450212201@localhost.localdomain> <56727DC6.9070309@oracle.com> <567405E7.2060804@oracle.com> <56740E58.2080408@oracle.com> Message-ID: <56740F19.1060705@oracle.com> Mikael, Nothing besides standard Oracle setup but thank you for the pointer. I was able to get webrev from your link and continue with it later today. -Dmitry On 2015-12-18 16:47, Mikael Gerdin wrote: > Dmitry, > > On 2015-12-18 14:11, Dmitry Samersoff wrote: >> Alex, >> >> Unfortunately, webrev.zip attachment is removed from the e-mail. >> >> Could you put it somewhere and send me a link? > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-December/018519.html > > e pointer > I got the attachment just fine, maybe there is something specific to > your setup which disallows you from receiving it? > > /Mikael > > >> >> Sorry for inconvenience. >> >> -Dmitry >> >> >> On 2015-12-18 00:04, Alex Henrie wrote: >>> An attachment in the email has been found to contain executable code >>> and has been removed. >>> >>> File removed : webrev.zip, >>> zip,html,list,c,c,,html,html,html,html,html,html,html,html,patch,html,html,patch,js >>> >>> >>> ---------------------------------------------------------------------- >>> 2015-12-17 2:17 GMT-07:00 Dmitry Samersoff >>> : >>>> I'll sponsor the push, but please: >>>> >>>> 1. fix realloc issue as it suggested by Dan and me. >>>> >>>> 2. prepare a webrev (I'll put it under my ojdk account to >>>> /sponsorship/alexhenrie) >>> >>> Here you go. >>> >>> -Alex >>> >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yasuenag at gmail.com Fri Dec 18 15:50:30 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 19 Dec 2015 00:50:30 +0900 Subject: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing Message-ID: <56742B46.9050106@gmail.com> Hi all, I encountered JVM crash when I passed -XX:+EnableTracing. I checked core image, it crashed in EventBooleanFlagChanged::writeEvent() which is called by Arguments::apply_ergo() because thread had not been initialized. (JVM seems to log changing GC algorithm to G1.) writeEvent() uses ResourceMark. Default constructor of ResourceMark uses ResourceArea in current thread. So ResourceMark in writeEvent() should pass valid ResourceArea. I think this issue is in traceEventClasses.xsl . However, my environment (GCC 5.3.1 on Fedora23) cannot build it because -Werror=maybe-uninitialized was occurred. So I also fixed them together. I've uploaded webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8145788/webrev.00/ I'm jdk9 committer, however I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa From ivan.gerasimov at oracle.com Sat Dec 19 12:28:36 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 19 Dec 2015 15:28:36 +0300 Subject: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ... In-Reply-To: <567390D4.10307@oracle.com> References: <566ECDA6.1030404@oracle.com> <566FB3BB.4050709@oracle.com> <567000F9.2070603@oracle.com> <56700279.4000408@oracle.com> <56700531.8060701@oracle.com> <56724BE9.5060304@oracle.com> <567270F6.7030206@oracle.com> <567390D4.10307@oracle.com> Message-ID: <56754D74.80802@oracle.com> >> We will suspend the current thread if two conditions are satisfied: >> process_exiting != 0 and process_exiting != current thread id. >> But, yes, pr_ex isn't really needed, as we can use process_exiting >> directly. >> >> Here's the updated webrev: >> http://cr.openjdk.java.net/~igerasim/8145127/01/webrev/ > > I still see pr_ex ?? > Oops. Forgot to 'hg qrefresh' before generating the webrev. The webrev has just been updated in place. Sincerely yours, Ivan From amy.lu at oracle.com Mon Dec 21 04:53:00 2015 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 21 Dec 2015 12:53:00 +0800 Subject: JDK 9 RFR of JDK-8145869: Mark test JMXStartStopTest.java and TestJstatdServer.java as intermittently failing Message-ID: <567785AC.1010808@oracle.com> sun/management/jmxremote/startstop/JMXStartStopTest.java sun/tools/jstatd/TestJstatdServer.java Above tests are known to fail intermittently, this patch is to mark the test accordingly with keyword 'intermittent'. bug: https://bugs.openjdk.java.net/browse/JDK-8145869 webrev: http://cr.openjdk.java.net/~amlu/8145869/webrev.00/ Thanks, Amy --- old/test/sun/management/jmxremote/startstop/JMXStartStopTest.java 2015-12-21 12:41:00.000000000 +0800 +++ new/test/sun/management/jmxremote/startstop/JMXStartStopTest.java 2015-12-21 12:41:00.000000000 +0800 @@ -58,7 +58,7 @@ * @run main/othervm/timeout=600 -XX:+UsePerfData JMXStartStopTest * @summary Makes sure that enabling/disabling the management agent through JCMD * achieves the desired results - * @key randomness + * @key randomness intermittent */ public class JMXStartStopTest { private static final String TEST_APP_NAME = "TestApp"; --- old/test/sun/tools/jstatd/TestJstatdServer.java 2015-12-21 12:41:01.000000000 +0800 +++ new/test/sun/tools/jstatd/TestJstatdServer.java 2015-12-21 12:41:01.000000000 +0800 @@ -24,6 +24,7 @@ /* * @test * @bug 4990825 + * @key intermittent * @library /lib/testlibrary * @modules java.management * @build jdk.testlibrary.* JstatdTest JstatGCUtilParser -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Mon Dec 21 08:38:49 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 21 Dec 2015 09:38:49 +0100 Subject: JDK 9 RFR of JDK-8145869: Mark test JMXStartStopTest.java and TestJstatdServer.java as intermittently failing In-Reply-To: <567785AC.1010808@oracle.com> References: <567785AC.1010808@oracle.com> Message-ID: <5677BA99.1020507@oracle.com> Looks good! -JB- On 21.12.2015 05:53, Amy Lu wrote: > sun/management/jmxremote/startstop/JMXStartStopTest.java > sun/tools/jstatd/TestJstatdServer.java > > Above tests are known to fail intermittently, this patch is to mark the > test accordingly with keyword 'intermittent'. > > bug: https://bugs.openjdk.java.net/browse/JDK-8145869 > webrev: http://cr.openjdk.java.net/~amlu/8145869/webrev.00/ > > Thanks, > Amy > > --- old/test/sun/management/jmxremote/startstop/JMXStartStopTest.java 2015-12-21 12:41:00.000000000 +0800 > +++ new/test/sun/management/jmxremote/startstop/JMXStartStopTest.java 2015-12-21 12:41:00.000000000 +0800 > @@ -58,7 +58,7 @@ > * @run main/othervm/timeout=600 -XX:+UsePerfData JMXStartStopTest > * @summary Makes sure that enabling/disabling the management agent through JCMD > * achieves the desired results > - * @key randomness > + * @key randomness intermittent > */ > public class JMXStartStopTest { > private static final String TEST_APP_NAME = "TestApp"; > --- old/test/sun/tools/jstatd/TestJstatdServer.java 2015-12-21 12:41:01.000000000 +0800 > +++ new/test/sun/tools/jstatd/TestJstatdServer.java 2015-12-21 12:41:01.000000000 +0800 > @@ -24,6 +24,7 @@ > /* > * @test > * @bug 4990825 > + * @key intermittent > * @library /lib/testlibrary > * @modules java.management > * @build jdk.testlibrary.* JstatdTest JstatGCUtilParser > > From harsha.wardhana.b at oracle.com Mon Dec 21 13:37:56 2015 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 21 Dec 2015 19:07:56 +0530 Subject: RFR : JDK-6744127 - NullPointerException at com.sun.tools.jdi.EventRequestManagerImpl.request In-Reply-To: <566FC8CC.8030109@oracle.com> References: <566E70A1.10701@oracle.com> <566FC8CC.8030109@oracle.com> Message-ID: <567800B4.9010202@oracle.com> Hi All, Please find below the updated webrev incorporating review comments. Issue : https://bugs.openjdk.java.net/browse/JDK-6744127 webrev : http://cr.openjdk.java.net/~jbachorik/sponsorship/6744127/webrev.01/ Hello Serguei, I will send fix for tonga test case in a separate review request. Regards Harsha On Tuesday 15 December 2015 01:31 PM, serguei.spitsyn at oracle.com wrote: > Hi Harsha, > > The fix looks good in general. > > If I understand correctly, any invoke of the requestList().add(), > requestList().remove() > or requestList().clear() will be implicitly synchronized on the list > object. > There only place left where we still need an explicit synchronized > statement > is the iteration over the list in the body of the method: > EventRequest request(int eventCmd, int requestId); > > I have some minor comments, though. > > The comment at the line 936 needs a dot at the end. > A space is needed after the keywords "synchronized", "while" and > "if" (lines: 943, 945 and 947). > The space is not needed at the line 946 after the cast. > > Also, I'd use the for-loop instead of while-loop like this: > for (EventRequestImpl er: rl) { > if (er.id == requestId) { > return er; > } > } > > But I leave it up to to you if you like to keep your variant. > > What tests did you run to make sure the fix does not brake anything? > I'd recommend to run the JTreg com/sun/jdi tests and the co-located > nsk.jdi.testlist tests. > If you already done so, could you, please, share the results? > > > Thank you for fixing this bug! > Serguei > > > > On 12/13/15 23:32, Harsha Wardhana B wrote: >> Hi All, >> >> Please review the fix for bug, >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-6744127 >> Webrev : >> http://cr.openjdk.java.net/~jbachorik/sponsorship/6744127/webrev.00 >> >> The fix synchronizes access to requestList of EventRequestManagerImpl. >> >> Thanks >> Harsha >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Mon Dec 21 15:58:11 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 21 Dec 2015 07:58:11 -0800 Subject: JDK 9 RFR of JDK-8145869: Mark test JMXStartStopTest.java and TestJstatdServer.java as intermittently failing In-Reply-To: <567785AC.1010808@oracle.com> References: <567785AC.1010808@oracle.com> Message-ID: <56782193.5000400@oracle.com> Looks fine Amy; thanks, -Joe On 12/20/2015 8:53 PM, Amy Lu wrote: > sun/management/jmxremote/startstop/JMXStartStopTest.java > sun/tools/jstatd/TestJstatdServer.java > > Above tests are known to fail intermittently, this patch is to mark > the test accordingly with keyword 'intermittent'. > > bug: https://bugs.openjdk.java.net/browse/JDK-8145869 > webrev: http://cr.openjdk.java.net/~amlu/8145869/webrev.00/ > > Thanks, > Amy > > --- old/test/sun/management/jmxremote/startstop/JMXStartStopTest.java > 2015-12-21 12:41:00.000000000 +0800 > +++ new/test/sun/management/jmxremote/startstop/JMXStartStopTest.java > 2015-12-21 12:41:00.000000000 +0800 > @@ -58,7 +58,7 @@ > * @run main/othervm/timeout=600 -XX:+UsePerfData JMXStartStopTest > * @summary Makes sure that enabling/disabling the management agent > through JCMD > * achieves the desired results > - * @key randomness > + * @key randomness intermittent > */ > public class JMXStartStopTest { > private static final String TEST_APP_NAME = "TestApp"; > --- old/test/sun/tools/jstatd/TestJstatdServer.java 2015-12-21 > 12:41:01.000000000 +0800 > +++ new/test/sun/tools/jstatd/TestJstatdServer.java 2015-12-21 > 12:41:01.000000000 +0800 > @@ -24,6 +24,7 @@ > /* > * @test > * @bug 4990825 > + * @key intermittent > * @library /lib/testlibrary > * @modules java.management > * @build jdk.testlibrary.* JstatdTest JstatGCUtilParser > > From rachel.protacio at oracle.com Mon Dec 21 19:36:59 2015 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 21 Dec 2015 14:36:59 -0500 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> <5387B10E-1AEF-428A-9096-E05E81A8071E@oracle.com> <5671DAFF.7060508@oracle.com> <56727545.4030004@oracle.com> <56739D4B.5030405@oracle.com> <5673CE87.2040008@oracle.com> <567404E7.2030205@oracle.com> Message-ID: <567854DB.7090901@oracle.com> Hello, everyone! I've filed an RFE for this issue. https://bugs.openjdk.java.net/browse/JDK-8145934 It'll probably be easier to continue the discussion there. Thanks, Rachel On 12/18/2015 8:29 AM, Staffan Larsen wrote: > >> On 18 dec. 2015, at 14:06, David Holmes > > wrote: >> >> On 18/12/2015 7:14 PM, Bengt Rutisson wrote: >>> >>> >>> On 2015-12-18 06:44, David Holmes wrote: >>>> On 17/12/2015 6:41 PM, Bengt Rutisson wrote: >>>>> On 2015-12-16 22:43, Coleen Phillimore wrote: >>>>>> On 12/16/15 4:01 PM, John Rose wrote: >>>>>>> On Dec 15, 2015, at 12:26 PM, Rachel Protacio >>>>>>> > >>>>>>> wrote: >>>>>>>> - each incident of ttyLocker that involved separate logging lines >>>>>>>> for the same message have been consolidated to one line >>>>>>>> - each incident of ttyLocker that involved separate print >>>>>>>> statements >>>>>>>> to one logging line has been changed to write to a buffer first, >>>>>>>> then print the entire line at once to the log stream >>>>>>> This is a strong argument for putting such functionality into the UL >>>>>>> framework, >>>>>>> instead of giving developers the unfortunate choice of either (a) >>>>>>> doing it right >>>>>>> with a bunch of random logic (Rachel's choice here) or (b) sweeping >>>>>>> it under >>>>>>> the carpet by breaking up a multi-part message into several log >>>>>>> messages. >>>>>>> >>>>>>> We need to admit this is the Achilles Heel of logging as normally >>>>>>> conceived >>>>>>> (especially for very long multi-part messages like disassembler >>>>>>> output, >>>>>>> backtraces, or compilation logs), and just fix it in the UL >>>>>>> frameowrk. >>>>>> >>>>>> Yes, I agree. We should file a high priority RFE against UL for this >>>>>> if one isn't filed already. The runtime only uses ttyLocker (as far >>>>>> as I found) for TraceExceptions but the compiler uses it more >>>>>> often to >>>>>> aggregate messages. The lack of a locking mechanism seems to be one >>>>>> of the factors blocking the compiler group adoption of this feature. >>>>>> And will block more complex runtime logging conversions. >>>>>> >>>>>> So what do people vote that we do? Should we log the messages >>>>>> separately until this is fixed? I agreed with making these logs one >>>>>> line because even though they wrap, they weren't that long. It would >>>>>> be nice to be able to do the conversion work to UL concurrently while >>>>>> finding problems in the framework, and not be stuck. >>>>> >>>>> From my point of view it would be very unfortunate to require all >>>>> logging to take an extra lock. If the multiline support can be >>>>> implemented in the UL framework without any extra cost for "normal" >>>>> logging I would be fine with it. But if it would slow down the normal >>>>> logging, which I assume would be the case if we require an extra lock, >>>>> then I would prefer to push the responsibility up to the users of >>>>> the UL >>>>> framework to synchronize properly. >>>> >>>> How would users of the framework synchronize access to a shared >>>> resource where some of the users of the resource are not party to the >>>> synchronization process? AFAICS the synchronization has to be at the >>>> resource-level. >>> >>> I think it depends on what problem we are trying to solve. In most cases >>> I have seen so far it would be fine for two different activities to log >>> their output interleaved. If for example the compiler would log >>> something during a GC I wouldn't see that as a serious problem. It is >> >> I don't really agree but I see where you are coming from. >> >>> easy for a reader of the log file (human or machine) to sort out the >>> logging since logging is never interleaved on the same line. And there >> >> Actually ... we have seen Trace output "corrupted" somehow where >> lines are combined. This happened with some CDS-related tests earlier >> this year with TraceClassLoading - we had to relax the pattern so the >> corrupted lines would be accepted. Never did get to the bottom of it. > > Have you seen this happen with UL as well? > >> >> Cheers, >> David >> >>> is also the possibility for a user to pipe the logging to different >>> files based on their tags. >>> >>> The problem I thought this email thread was about was when the same type >>> of logging is done from multiple threads. Having multiple threads log >>> multiple lines of similar data at the same time will be very hard to >>> sort out after-the-fact in the log file. But since it is the same >>> subsystem that does the logging that subsystem could introduce its own >>> synchronization. It would of course not be synchronized with all other >>> users of the UL framework, but I don't think that is such a big problem. >>> >>> Having said that, I am not against introducing multi-line logging >>> support in the UL framework. I just would like to make sure that it does >>> not come with a too high cost for all the use cases where the >>> synchronization is not a problem. >>> >>> Using a buffered logger, as is being discussed now, would probably be a >>> good solution since it wouldn't introduce a cost for the other logging. >>> >>> Bengt >>> >>> >>> >>>> >>>> David >>>> ----- >>>> >>>>> Bengt >>>>> >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>>> >>>>>>> ? John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Dec 21 20:01:24 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 21 Dec 2015 12:01:24 -0800 Subject: RFR : JDK-6744127 - NullPointerException at com.sun.tools.jdi.EventRequestManagerImpl.request In-Reply-To: <567800B4.9010202@oracle.com> References: <566E70A1.10701@oracle.com> <566FC8CC.8030109@oracle.com> <567800B4.9010202@oracle.com> Message-ID: <56785A94.2010702@oracle.com> Hi Harsha, The fix is good, thumbs up. Thank you for the extra work around the test failure! Thanks, Serguei On 12/21/15 05:37, Harsha Wardhana B wrote: > Hi All, > > Please find below the updated webrev incorporating review comments. > > Issue : https://bugs.openjdk.java.net/browse/JDK-6744127 > webrev : > http://cr.openjdk.java.net/~jbachorik/sponsorship/6744127/webrev.01/ > > Hello Serguei, > > I will send fix for tonga test case in a separate review request. > > Regards > Harsha > > On Tuesday 15 December 2015 01:31 PM, serguei.spitsyn at oracle.com wrote: >> Hi Harsha, >> >> The fix looks good in general. >> >> If I understand correctly, any invoke of the requestList().add(), >> requestList().remove() >> or requestList().clear() will be implicitly synchronized on the list >> object. >> There only place left where we still need an explicit synchronized >> statement >> is the iteration over the list in the body of the method: >> EventRequest request(int eventCmd, int requestId); >> >> I have some minor comments, though. >> >> The comment at the line 936 needs a dot at the end. >> A space is needed after the keywords "synchronized", "while" and >> "if" (lines: 943, 945 and 947). >> The space is not needed at the line 946 after the cast. >> >> Also, I'd use the for-loop instead of while-loop like this: >> for (EventRequestImpl er: rl) { >> if (er.id == requestId) { >> return er; >> } >> } >> >> But I leave it up to to you if you like to keep your variant. >> >> What tests did you run to make sure the fix does not brake anything? >> I'd recommend to run the JTreg com/sun/jdi tests and the >> co-located nsk.jdi.testlist tests. >> If you already done so, could you, please, share the results? >> >> >> Thank you for fixing this bug! >> Serguei >> >> >> >> On 12/13/15 23:32, Harsha Wardhana B wrote: >>> Hi All, >>> >>> Please review the fix for bug, >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-6744127 >>> Webrev : >>> http://cr.openjdk.java.net/~jbachorik/sponsorship/6744127/webrev.00 >>> >>> The fix synchronizes access to requestList of EventRequestManagerImpl. >>> >>> Thanks >>> Harsha >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rachel.protacio at oracle.com Mon Dec 21 21:46:02 2015 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 21 Dec 2015 16:46:02 -0500 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <5671F631.8000903@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> <5671CF0B.20003@oracle.com> <5671D8C2.4040801@oracle.com> <5671F631.8000903@oracle.com> Message-ID: <5678731A.7050206@oracle.com> Hi, Please take a look at my updated changeset! Webrev: http://cr.openjdk.java.net/~rprotacio/8141211.02/ I've fixed the multi-line statements as requested, i.e. put newlines in them to replicate the original format. Since the UL framework atomically writes complete messages, these single string messages do not need the discussed lockers to prevent interleaving. So it's ready to be checked in as-is (once reviewed, of course). I've opened a separate RFE for lockers, which will be necessary for other logging https://bugs.openjdk.java.net/browse/JDK-8145934 Thank you, Rachel On 12/16/2015 6:39 PM, David Holmes wrote: > Hi Rachel, > > On 17/12/2015 7:33 AM, Rachel Protacio wrote: >> Hi, >> >> On 12/16/2015 3:52 PM, David Holmes wrote: >>> Hi Rachel, >>> >>> On 16/12/2015 6:26 AM, Rachel Protacio wrote: >>>> Hi, >>>> >>>> Thanks for the comments, David. >>>> >>>> I had messed up my uploading before and had not actually updated the >>>> open html. So for real this time, the most recent webrev is at >>>> http://cr.openjdk.java.net/~rprotacio/8141211.01/ Of note: >>>> - each incident of ttyLocker that involved separate logging lines for >>>> the same message have been consolidated to one line >>>> - each incident of ttyLocker that involved separate print >>>> statements to >>>> one logging line has been changed to write to a buffer first, then >>>> print >>>> the entire line at once to the log stream >>> >>> I think I may be missing something here, sorry. Taking >>> src/share/vm/interpreter/bytecodeInterpreter.cpp as an example, three >>> print_cr statements have been replaced with one log_info statement - >>> but there are no newlines in-line in that one log_info statement. I >>> was assuming that a single call to something like log_info would be >>> 'atomic" and that we would manually place the \n as required in the >>> output string. >>> >>> This won't show up well in email due to line wrapping but going from >>> this: >>> >>> Exception >> sun.launcher.resources.launcher_en_US> (0x0000000101c69b18) >>> thrown in interpreter method <{method} {0x00007f55b63dbc18} >>> 'loadClass' '(Ljava/lang/String;Z)Ljava/lang/Class;' in 'java/lang/Cl> >>> at bci 70 for thread 0x00007f56d0019800 >>> >>> to this: >>> >>> Exception >> sun.launcher.resources.launcher_en_US> (0x0000000101c69b18) thrown in >>> interpreter method <{method} {0x00007f55b63dbc18} 'loadClass' >>> '(Ljava/lang/String;Z)Ljava/lang/Class;' in 'java/lang/Cl> at bci 70 >>> for thread 0x00007f56d0019800 >>> >>> will not be anywhere as near as clear in the logs. >> Yes, I changed that intentionally. The choices as I saw them were: >> (a) multiple print_cr() calls, which could lead to unwanted interweaving >> and which breaks up the logging message with decorators at the beginning >> of every line, e.g. >> >> [0.225s][info ][exceptions] Exception > 'java/lang/ClassNotFoundException': NoClassFound> >> (0x00000006d5f5ae28) >> [0.225s][info ][exceptions] thrown in interpreter method <{method} >> {0x00007fe231a04198} 'findClass' >> '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC> >> [0.225s][info ][exceptions] at bci 44 for thread >> 0x00007fe330019000 >> >> (b) adding newlines in the middle of the message, which would look like >> >> [0.225s][info ][exceptions] Exception > 'java/lang/ClassNotFoundException': NoClassFound> >> (0x00000006d5f5ae28) >> thrown in interpreter method <{method} {0x00007fe231a04198} >> 'findClass' '(Ljava/lang/String;)Ljava/lang/Class;' in >> 'java/net/URLC> >> at bci 44 for thread 0x00007fe330019000 >> >> and could easily end up wrapping mid-logging anyway depending on the >> length of the exception message >> (c) turning it all into one wrapped line that would be relatively easier >> to programmatically parse since the decorators would be at the beginning >> of the line, i.e. >> >> [0.225s][info ][exceptions] Exception > 'java/lang/ClassNotFoundException': NoClassFound> >> (0x00000006d5f5ae28) thrown in interpreter method <{method} >> {0x00007fe231a04198} 'findClass' >> '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC>at bci 44 >> for thread 0x00007fe330019000 >> >> which is also the most compact option. >> >> So I opted for (c). But if I should stick to the original approach, i.e. >> (b), I can see it could be easier to visually parse. Do you think that >> would be preferable? > > I definitely vote for (b) - I think a goal of the conversion effort > should be that if you disable the UL decorators then the output before > and after the conversion should be the same. Decorators can be useful > but also clutter. > > But I'm also worried that the UL framework might not atomically > process a line with embedded newlines. Though in that case the fix > needs to be in the UL framework. > > Thanks, > David > >> Thanks! >> Rachel >> >>> >>> Thanks, >>> David >>> >>>> Retested with JPRT, and the buffer-to-logstream schema in particular >>>> works fine. >>>> >>>> Replies inline. >>>> >>>> On 12/13/2015 11:08 PM, David Holmes wrote: >>>>> Hi Rachel, >>>>> >>>>> On 12/12/2015 7:38 AM, Rachel Protacio wrote: >>>>>> Hello! An update and updated webrev. >>>>>> >>>>>> I've rewritten the two portions of code that had used ttyLockers to >>>>>> print in one function-call, since there is no locker equivalent >>>>>> in UL, >>>>>> plus the fact that it will be easier for users to look for one >>>>>> message's >>>>>> contents without the decorators interrupting the lines. (And I >>>>>> especially tested that the fix prints the whole line correctly.) >>>>> >>>>> Sorry I'm still seeing ttyLocker removal and use of multiple logging >>>>> statements in: >>>>> >>>>> src/share/vm/interpreter/bytecodeInterpreter.cpp >>>>> src/share/vm/interpreter/interpreterRuntime.cpp >>>>> src/share/vm/opto/runtime.cpp >>>>> >>>>> which "two portions of code" did you change? >>>> I apologize for that! I messed up with uploading the changeset before. >>>> All fixed now in each of those files. >>>>> >>>>> I also note that src/share/vm/runtime/thread.cpp was not using >>>>> ttyLocker but does have multi-part trace output. >>>> True. Since a locker was unnecessary in the first place, I think it >>>> makes sense to allow this (and other logging, both in UL and the >>>> existing tty frameworks) to be printed in multiple steps. What do you >>>> think? >>>>> >>>>>> As mentioned in the other thread, I will file a separate RFE to >>>>>> deprecate this and other product flags being converted to logging. >>>>>> >>>>>> Since my last iteration was on hold/not reviewed yet, I've simply >>>>>> updated it. http://cr.openjdk.java.net/~rprotacio/8141211.01 >>>>> >>>>> src/share/vm/c1/c1_Runtime1.cpp >>>>> >>>>> Nit in original code: >>>>> >>>>> 556 " for thread " INTPTR_FORMAT "", >>>>> >>>>> the "" before the comma seems superfluous. >>>> Thanks for pointing that out! >>>> Rachel >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> Rachel >>>>>> >>>>>> On 12/9/2015 1:12 PM, Rachel Protacio wrote: >>>>>>> Hi, >>>>>>> >>>>>>> (Sorry if this sent twice. Thunderbird is acting up.) >>>>>>> >>>>>>> Thanks for the review. Replies inline. >>>>>>> Updated webrev: http://cr.openjdk.java.net/~rprotacio/8141211.01/ >>>>>>> >>>>>>> On 12/8/2015 10:53 PM, David Holmes wrote: >>>>>>>> Hi Rachel, >>>>>>>> >>>>>>>> On 9/12/2015 1:42 AM, Rachel Protacio wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review my conversion of -XX:+TraceExceptions to >>>>>>>>> -Xlog:exceptions=info. The existing (product) flag is aliased to >>>>>>>>> the >>>>>>>>> logging flag at the info level. >>>>>>>> >>>>>>>> Q: how does use of ttyLocker map into UL? I see an awful lot of >>>>>>>> multi-line logging blocks that are going to be completely >>>>>>>> messed up >>>>>>>> without locking! >>>>>>> I assumed that UL worked as-is for these instances, but I will >>>>>>> check >>>>>>> in with Marcus. >>>>>>>> >>>>>>>> src/share/vm/opto/runtime.cpp >>>>>>>> >>>>>>>> 1239 ResourceMark rm; >>>>>>>> >>>>>>>> What requires the introduction of the ResourceMark? >>>>>>> A ResourceMark is necessary before using LogHandle output streams. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>> >>>>>>>> 2084 if (log_is_enabled(Info, exceptions)) { >>>>>>>> 2085 ResourceMark rm; >>>>>>>> >>>>>>>> An extra leading space has crept in at +2085 >>>>>>>> >>>>>>>> 2087 logstream->print("Async. exception installed at >>>>>>>> runtime >>>>>>>> exit (" INTPTR_FORMAT ")", p2i(this)); >>>>>>>> 2088 if (has_last_Java_frame()) { >>>>>>>> 2089 frame f = last_frame(); >>>>>>>> 2090 logstream->print(" (pc: " INTPTR_FORMAT " sp: " >>>>>>>> INTPTR_FORMAT " )", p2i(f.pc()), p2i(f.sp())); >>>>>>>> 2091 } >>>>>>>> >>>>>>>> Indention of these lines is wrong at #2088 and #2089 - need an >>>>>>>> additional space. >>>>>>> Thanks for catching these! >>>>>>>> >>>>>>>> 2092 logstream->print_cr(" of type: %s", >>>>>>>> InstanceKlass::cast(_pending_async_exception->klass())->external_name()); >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Why did the InstanceKlass::cast need to be introduced ?? >>>>>>> That was a vestige from code before a new changeset at the same >>>>>>> line, >>>>>>> i.e. my merging the repo didn't catch this. I've gotten rid of the >>>>>>> cast. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> test/runtime/CommandLine/TraceExceptionsTest.java >>>>>>>> >>>>>>>> You improved the readability of the source code by breaking the >>>>>>>> @summary over two lines, but IIRC jtreg will write the summary >>>>>>>> into >>>>>>>> the test log with all the additional spaces you added, as the >>>>>>>> summary >>>>>>>> extends until the next tag. >>>>>>> Ok, I didn't realize that! I've undone that change. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> test/runtime/logging/ExceptionsTest.java >>>>>>>> >>>>>>>> Can you avoid the code duplication please. >>>>>>>> >>>>>>>> Also perhaps you could/should also check there are no logging >>>>>>>> statements present when logging is supposed to be disabled. I'm >>>>>>>> guessing the other logging tests haven't considered this. ?? >>>>>>> Good points. I've added a check. >>>>>>>> >>>>>>>>> If you have any questions on the alias table (in the >>>>>>>>> arguments.cpp >>>>>>>>> and >>>>>>>>> .hpp files), Max will chime in as he is the one who implemented >>>>>>>>> that >>>>>>>>> portion. >>>>>>>> >>>>>>>> Okay some general questions. >>>>>>>> >>>>>>>> First I would expect that aliased logging options are also marked >>>>>>>> deprecated so that we can eventually make them obsolete and remove >>>>>>>> them. >>>>>>> I'm not sure about this one. Coleen? Max? >>>>>>>> >>>>>>>> Secondly, arguably if someone specifies -XX:-TraceExceptions it >>>>>>>> should disable exception logging - which may have been turned >>>>>>>> on by >>>>>>>> -Xlog:all. >>>>>>>> >>>>>>>> Which leads to: how does the position of -XX:+/-TraceExceptions >>>>>>>> interact with the position of -Xlog:xxx on the command-line (or >>>>>>>> the >>>>>>>> other argument introducing mechanisms) ? >>>>>>> Very true. I've added an entry in the alias table to that effect. >>>>>>>> >>>>>>>> src/share/vm/runtime/arguments.cpp >>>>>>>> >>>>>>>> 2743 if(lookup_logging_aliases(option->optionString, >>>>>>>> aliased_logging_option)){ >>>>>>>> >>>>>>>> Need space after "if", and before { >>>>>>> Done. >>>>>>> >>>>>>> Thanks, >>>>>>> Rachel >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> >>>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8141211/ >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141211 >>>>>>>>> >>>>>>>>> Testing: jtreg, JPRT, jck vm tests, refworkload performance >>>>>>>>> tests, >>>>>>>>> rbt >>>>>>>>> quick & non-colo tests >>>>>>>>> >>>>>>>>> Thank you! >>>>>>>>> Rachel >>>>>>> >>>>>> >>>> >> From dmitry.samersoff at oracle.com Mon Dec 21 21:50:27 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 22 Dec 2015 00:50:27 +0300 Subject: RFR(L): JDK-8067194 Restructure hotspot/agent/src to conform the modular source layout Message-ID: <56787423.6020809@oracle.com> Everybody, Please, review the changes: http://cr.openjdk.java.net/~dsamersoff/JDK-8067194/webrevs.02/ The problem: Serviceability agent source should follow source layout convention for modular jdk. The solution: Move SA sources under src/jdk.hotspot.agent Move native code under jdk.hotspot.agent/{OS}/native/libsaproc Problems left: * I'll file a CR for each of problem and fix it later. 1. Custom gif copy routine left unchanged. 2. The name of SA under windows left unchanged it's sawindbg.dll 3. doc, scripts, test directories moved to a new location as is. It's content about to be evaluated. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From harsha.wardhana.b at oracle.com Tue Dec 22 04:06:13 2015 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 22 Dec 2015 09:36:13 +0530 Subject: RFR : JDK-6744127 - NullPointerException at com.sun.tools.jdi.EventRequestManagerImpl.request In-Reply-To: <56785A94.2010702@oracle.com> References: <566E70A1.10701@oracle.com> <566FC8CC.8030109@oracle.com> <567800B4.9010202@oracle.com> <56785A94.2010702@oracle.com> Message-ID: <5678CC35.601@oracle.com> Hi Serguei, Many thanks for reviewing the code. Regards Harsha On Tuesday 22 December 2015 01:31 AM, serguei.spitsyn at oracle.com wrote: > Hi Harsha, > > > The fix is good, thumbs up. > Thank you for the extra work around the test failure! > > Thanks, > Serguei > > > > On 12/21/15 05:37, Harsha Wardhana B wrote: >> Hi All, >> >> Please find below the updated webrev incorporating review comments. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-6744127 >> webrev : >> http://cr.openjdk.java.net/~jbachorik/sponsorship/6744127/webrev.01/ >> >> Hello Serguei, >> >> I will send fix for tonga test case in a separate review request. >> >> Regards >> Harsha >> >> On Tuesday 15 December 2015 01:31 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Harsha, >>> >>> The fix looks good in general. >>> >>> If I understand correctly, any invoke of the requestList().add(), >>> requestList().remove() >>> or requestList().clear() will be implicitly synchronized on the list >>> object. >>> There only place left where we still need an explicit synchronized >>> statement >>> is the iteration over the list in the body of the method: >>> EventRequest request(int eventCmd, int requestId); >>> >>> I have some minor comments, though. >>> >>> The comment at the line 936 needs a dot at the end. >>> A space is needed after the keywords "synchronized", "while" and >>> "if" (lines: 943, 945 and 947). >>> The space is not needed at the line 946 after the cast. >>> >>> Also, I'd use the for-loop instead of while-loop like this: >>> for (EventRequestImpl er: rl) { >>> if (er.id == requestId) { >>> return er; >>> } >>> } >>> >>> But I leave it up to to you if you like to keep your variant. >>> >>> What tests did you run to make sure the fix does not brake anything? >>> I'd recommend to run the JTreg com/sun/jdi tests and the >>> co-located nsk.jdi.testlist tests. >>> If you already done so, could you, please, share the results? >>> >>> >>> Thank you for fixing this bug! >>> Serguei >>> >>> >>> >>> On 12/13/15 23:32, Harsha Wardhana B wrote: >>>> Hi All, >>>> >>>> Please review the fix for bug, >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-6744127 >>>> Webrev : >>>> http://cr.openjdk.java.net/~jbachorik/sponsorship/6744127/webrev.00 >>>> >>>> The fix synchronizes access to requestList of EventRequestManagerImpl. >>>> >>>> Thanks >>>> Harsha >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Tue Dec 22 07:46:07 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 Dec 2015 08:46:07 +0100 Subject: RFR(L): JDK-8067194 Restructure hotspot/agent/src to conform the modular source layout In-Reply-To: <56787423.6020809@oracle.com> References: <56787423.6020809@oracle.com> Message-ID: <5678FFBF.1000002@oracle.com> Hello Dmitry, Nice to see this happen! make/lib/Lib-jdk.hotspot.agent.gmk: Missing a "/libsaproc" here: SA_SRC += $(SA_TOPDIR)/share/native $(SA_TOPDIR)/$(OPENJDK_TARGET_OS)/native/libsaproc Otherwise it looks good. /Erik On 2015-12-21 22:50, Dmitry Samersoff wrote: > Everybody, > > Please, review the changes: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8067194/webrevs.02/ > > The problem: > > Serviceability agent source should follow source layout > convention for modular jdk. > > The solution: > > Move SA sources under src/jdk.hotspot.agent > > Move native code under jdk.hotspot.agent/{OS}/native/libsaproc > > Problems left: > * I'll file a CR for each of problem and fix it later. > > 1. Custom gif copy routine left unchanged. > > 2. The name of SA under windows left unchanged it's sawindbg.dll > > 3. doc, scripts, test directories moved to a new location > as is. It's content about to be evaluated. > > -Dmitry > From magnus.ihse.bursie at oracle.com Tue Dec 22 09:49:15 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 22 Dec 2015 10:49:15 +0100 Subject: RFR(L): JDK-8067194 Restructure hotspot/agent/src to conform the modular source layout In-Reply-To: <5678FFBF.1000002@oracle.com> References: <56787423.6020809@oracle.com> <5678FFBF.1000002@oracle.com> Message-ID: <56791C9B.108@oracle.com> On 2015-12-22 08:46, Erik Joelsson wrote: > Hello Dmitry, > > Nice to see this happen! > > make/lib/Lib-jdk.hotspot.agent.gmk: > Missing a "/libsaproc" here: > SA_SRC += $(SA_TOPDIR)/share/native > $(SA_TOPDIR)/$(OPENJDK_TARGET_OS)/native/libsaproc > > Otherwise it looks good. Looks good to me too. /Magnus > > /Erik > > On 2015-12-21 22:50, Dmitry Samersoff wrote: >> Everybody, >> >> Please, review the changes: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8067194/webrevs.02/ >> >> The problem: >> >> Serviceability agent source should follow source layout >> convention for modular jdk. >> >> The solution: >> >> Move SA sources under src/jdk.hotspot.agent >> >> Move native code under jdk.hotspot.agent/{OS}/native/libsaproc >> >> Problems left: >> * I'll file a CR for each of problem and fix it later. >> >> 1. Custom gif copy routine left unchanged. >> >> 2. The name of SA under windows left unchanged it's sawindbg.dll >> >> 3. doc, scripts, test directories moved to a new location >> as is. It's content about to be evaluated. >> >> -Dmitry >> > From david.holmes at oracle.com Tue Dec 22 12:19:46 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Dec 2015 22:19:46 +1000 Subject: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing In-Reply-To: <56742B46.9050106@gmail.com> References: <56742B46.9050106@gmail.com> Message-ID: <56793FE2.5090106@oracle.com> On 19/12/2015 1:50 AM, Yasumasa Suenaga wrote: > Hi all, > > I encountered JVM crash when I passed -XX:+EnableTracing. > > I checked core image, it crashed in EventBooleanFlagChanged::writeEvent() > which is called by Arguments::apply_ergo() because thread had not been > initialized. (JVM seems to log changing GC algorithm to G1.) This seems like a logic error to me - something is trying to happen too early during VM initialization. We need to look at exactly what we are trying to do here, not just work around the crash. David ----- > writeEvent() uses ResourceMark. Default constructor of ResourceMark uses > ResourceArea in current thread. So ResourceMark in writeEvent() should > pass valid ResourceArea. > > I think this issue is in traceEventClasses.xsl . > However, my environment (GCC 5.3.1 on Fedora23) cannot build it because > -Werror=maybe-uninitialized was occurred. > So I also fixed them together. > > I've uploaded webrev. Could you review it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8145788/webrev.00/ > > I'm jdk9 committer, however I cannot access JPRT. > So I need a sponsor. > > > Thanks, > > Yasumasa > From jaroslav.bachorik at oracle.com Tue Dec 22 15:40:05 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 22 Dec 2015 16:40:05 +0100 Subject: RFR(L): JDK-8067194 Restructure hotspot/agent/src to conform the modular source layout In-Reply-To: <56787423.6020809@oracle.com> References: <56787423.6020809@oracle.com> Message-ID: <56796ED5.8070705@oracle.com> Hi, looks good, modulo the problems you are mentioning (docs will need update to refer to correct locations; the same might be true for the textual output from scripts). I believe the tests are still passing. Supposing the remaining problems are covered by CR you can consider this reviewed. Regards, -JB- On 21.12.2015 22:50, Dmitry Samersoff wrote: > Everybody, > > Please, review the changes: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8067194/webrevs.02/ > > The problem: > > Serviceability agent source should follow source layout > convention for modular jdk. > > The solution: > > Move SA sources under src/jdk.hotspot.agent > > Move native code under jdk.hotspot.agent/{OS}/native/libsaproc > > Problems left: > * I'll file a CR for each of problem and fix it later. > > 1. Custom gif copy routine left unchanged. > > 2. The name of SA under windows left unchanged it's sawindbg.dll > > 3. doc, scripts, test directories moved to a new location > as is. It's content about to be evaluated. > > -Dmitry > From jaroslav.bachorik at oracle.com Tue Dec 22 16:50:17 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 22 Dec 2015 17:50:17 +0100 Subject: RFR 8145982: JMXInterfaceBindingTest is failing intermittently Message-ID: <56797F49.5060107@oracle.com> Please, review this trivial test change Issue : https://bugs.openjdk.java.net/browse/JDK-8145982 Webrev: http://cr.openjdk.java.net/~jbachorik/8145982/webrev.00 The test calls System.exit(0) in case when it is not applicable (due to HW configuration). This call is forbidden by the test harness and the test fails. The solution is to replace it with 'return'. Thanks! -JB- From olivier.lagneau at oracle.com Tue Dec 22 17:25:36 2015 From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com) Date: Tue, 22 Dec 2015 18:25:36 +0100 Subject: jmx-dev RFR 8145982: JMXInterfaceBindingTest is failing intermittently In-Reply-To: <56797F49.5060107@oracle.com> References: <56797F49.5060107@oracle.com> Message-ID: <56798790.8080602@oracle.com> Hi Jaroslav, Looks good. Not a reviewer however. Olivier. On 22/12/2015 17:50, Jaroslav Bachorik wrote: > Please, review this trivial test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8145982 > Webrev: http://cr.openjdk.java.net/~jbachorik/8145982/webrev.00 > > The test calls System.exit(0) in case when it is not applicable (due > to HW configuration). This call is forbidden by the test harness and > the test fails. The solution is to replace it with 'return'. > > Thanks! > > -JB- -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Tue Dec 22 17:34:07 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Dec 2015 17:34:07 +0000 Subject: jmx-dev RFR 8145982: JMXInterfaceBindingTest is failing intermittently In-Reply-To: <56798790.8080602@oracle.com> References: <56797F49.5060107@oracle.com> <56798790.8080602@oracle.com> Message-ID: <84CB7512-79B8-47FB-AD9B-A9D792D34627@oracle.com> On 22 Dec 2015, at 17:25, olivier.lagneau at oracle.com wrote: > Hi Jaroslav, > > Looks good. Not a reviewer however. +1 -Chris. > Olivier. > > On 22/12/2015 17:50, Jaroslav Bachorik wrote: >> Please, review this trivial test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8145982 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8145982/webrev.00 >> >> The test calls System.exit(0) in case when it is not applicable (due to HW configuration). This call is forbidden by the test harness and the test fails. The solution is to replace it with 'return'. >> >> Thanks! >> >> -JB- > From yasuenag at gmail.com Wed Dec 23 01:49:01 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 23 Dec 2015 10:49:01 +0900 Subject: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing In-Reply-To: <56793FE2.5090106@oracle.com> References: <56742B46.9050106@gmail.com> <56793FE2.5090106@oracle.com> Message-ID: <5679FD8D.2090201@gmail.com> Hi David, I've added callstack when JVM crashed: https://bugs.openjdk.java.net/browse/JDK-8145788?focusedCommentId=13880225&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13880225 This crash occurrs in Arguments::apply_ergo() in Threads::create_vm(). apply_ergo() calls before JavaThread initialization. I think that TraceEvent can avoid crash with two approach: 1. Initialize JavaThread before calling apply_ergo() in create_vm(). 2. Avoid crash at TraceEvent when it is called before JavaThread initialization. Thanks, Yasumasa On 2015/12/22 21:19, David Holmes wrote: > On 19/12/2015 1:50 AM, Yasumasa Suenaga wrote: >> Hi all, >> >> I encountered JVM crash when I passed -XX:+EnableTracing. >> >> I checked core image, it crashed in EventBooleanFlagChanged::writeEvent() >> which is called by Arguments::apply_ergo() because thread had not been >> initialized. (JVM seems to log changing GC algorithm to G1.) > > This seems like a logic error to me - something is trying to happen too > early during VM initialization. We need to look at exactly what we are > trying to do here, not just work around the crash. > > David > ----- > >> writeEvent() uses ResourceMark. Default constructor of ResourceMark uses >> ResourceArea in current thread. So ResourceMark in writeEvent() should >> pass valid ResourceArea. >> >> I think this issue is in traceEventClasses.xsl . >> However, my environment (GCC 5.3.1 on Fedora23) cannot build it because >> -Werror=maybe-uninitialized was occurred. >> So I also fixed them together. >> >> I've uploaded webrev. Could you review it? >> http://cr.openjdk.java.net/~ysuenaga/JDK-8145788/webrev.00/ >> >> I'm jdk9 committer, however I cannot access JPRT. >> So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa >> From david.holmes at oracle.com Wed Dec 23 04:20:49 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Dec 2015 14:20:49 +1000 Subject: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing In-Reply-To: <5679FD8D.2090201@gmail.com> References: <56742B46.9050106@gmail.com> <56793FE2.5090106@oracle.com> <5679FD8D.2090201@gmail.com> Message-ID: <567A2121.1060504@oracle.com> Hi Yasumasa, On 23/12/2015 11:49 AM, Yasumasa Suenaga wrote: > Hi David, > > I've added callstack when JVM crashed: > https://bugs.openjdk.java.net/browse/JDK-8145788?focusedCommentId=13880225&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13880225 Thanks for that. > This crash occurrs in Arguments::apply_ergo() in Threads::create_vm(). > apply_ergo() calls before JavaThread initialization. > > I think that TraceEvent can avoid crash with two approach: > > 1. Initialize JavaThread before calling apply_ergo() in create_vm(). That is not likely to be an option - it would likely be far too disruptive to the initialization sequence. > 2. Avoid crash at TraceEvent when it is called before JavaThread initialization. Or don't call it at all. We will have to wait for the tracing experts to have a good look at this. We end up in code that is not expecting to be run before more of the VM is initialized, so we have to look at what else may be being assumed and then decide whether to handle the situation or avoid it. Thanks, David > > Thanks, > > Yasumasa > > > On 2015/12/22 21:19, David Holmes wrote: >> On 19/12/2015 1:50 AM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I encountered JVM crash when I passed -XX:+EnableTracing. >>> >>> I checked core image, it crashed in EventBooleanFlagChanged::writeEvent() >>> which is called by Arguments::apply_ergo() because thread had not been >>> initialized. (JVM seems to log changing GC algorithm to G1.) >> >> This seems like a logic error to me - something is trying to happen too >> early during VM initialization. We need to look at exactly what we are >> trying to do here, not just work around the crash. >> >> David >> ----- >> >>> writeEvent() uses ResourceMark. Default constructor of ResourceMark uses >>> ResourceArea in current thread. So ResourceMark in writeEvent() should >>> pass valid ResourceArea. >>> >>> I think this issue is in traceEventClasses.xsl . >>> However, my environment (GCC 5.3.1 on Fedora23) cannot build it because >>> -Werror=maybe-uninitialized was occurred. >>> So I also fixed them together. >>> >>> I've uploaded webrev. Could you review it? >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8145788/webrev.00/ >>> >>> I'm jdk9 committer, however I cannot access JPRT. >>> So I need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> From david.holmes at oracle.com Wed Dec 23 04:26:55 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Dec 2015 14:26:55 +1000 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <5678731A.7050206@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> <5671CF0B.20003@oracle.com> <5671D8C2.4040801@oracle.com> <5671F631.8000903@oracle.com> <5678731A.7050206@oracle.com> Message-ID: <567A228F.8080704@oracle.com> Thanks Rachel - looks good. David On 22/12/2015 7:46 AM, Rachel Protacio wrote: > Hi, > > Please take a look at my updated changeset! Webrev: > http://cr.openjdk.java.net/~rprotacio/8141211.02/ > > I've fixed the multi-line statements as requested, i.e. put newlines in > them to replicate the original format. > > Since the UL framework atomically writes complete messages, these single > string messages do not need the discussed lockers to prevent > interleaving. So it's ready to be checked in as-is (once reviewed, of > course). I've opened a separate RFE for lockers, which will be necessary > for other logging https://bugs.openjdk.java.net/browse/JDK-8145934 > > Thank you, > Rachel > > On 12/16/2015 6:39 PM, David Holmes wrote: >> Hi Rachel, >> >> On 17/12/2015 7:33 AM, Rachel Protacio wrote: >>> Hi, >>> >>> On 12/16/2015 3:52 PM, David Holmes wrote: >>>> Hi Rachel, >>>> >>>> On 16/12/2015 6:26 AM, Rachel Protacio wrote: >>>>> Hi, >>>>> >>>>> Thanks for the comments, David. >>>>> >>>>> I had messed up my uploading before and had not actually updated the >>>>> open html. So for real this time, the most recent webrev is at >>>>> http://cr.openjdk.java.net/~rprotacio/8141211.01/ Of note: >>>>> - each incident of ttyLocker that involved separate logging lines for >>>>> the same message have been consolidated to one line >>>>> - each incident of ttyLocker that involved separate print >>>>> statements to >>>>> one logging line has been changed to write to a buffer first, then >>>>> print >>>>> the entire line at once to the log stream >>>> >>>> I think I may be missing something here, sorry. Taking >>>> src/share/vm/interpreter/bytecodeInterpreter.cpp as an example, three >>>> print_cr statements have been replaced with one log_info statement - >>>> but there are no newlines in-line in that one log_info statement. I >>>> was assuming that a single call to something like log_info would be >>>> 'atomic" and that we would manually place the \n as required in the >>>> output string. >>>> >>>> This won't show up well in email due to line wrapping but going from >>>> this: >>>> >>>> Exception >>> sun.launcher.resources.launcher_en_US> (0x0000000101c69b18) >>>> thrown in interpreter method <{method} {0x00007f55b63dbc18} >>>> 'loadClass' '(Ljava/lang/String;Z)Ljava/lang/Class;' in 'java/lang/Cl> >>>> at bci 70 for thread 0x00007f56d0019800 >>>> >>>> to this: >>>> >>>> Exception >>> sun.launcher.resources.launcher_en_US> (0x0000000101c69b18) thrown in >>>> interpreter method <{method} {0x00007f55b63dbc18} 'loadClass' >>>> '(Ljava/lang/String;Z)Ljava/lang/Class;' in 'java/lang/Cl> at bci 70 >>>> for thread 0x00007f56d0019800 >>>> >>>> will not be anywhere as near as clear in the logs. >>> Yes, I changed that intentionally. The choices as I saw them were: >>> (a) multiple print_cr() calls, which could lead to unwanted interweaving >>> and which breaks up the logging message with decorators at the beginning >>> of every line, e.g. >>> >>> [0.225s][info ][exceptions] Exception >> 'java/lang/ClassNotFoundException': NoClassFound> >>> (0x00000006d5f5ae28) >>> [0.225s][info ][exceptions] thrown in interpreter method <{method} >>> {0x00007fe231a04198} 'findClass' >>> '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC> >>> [0.225s][info ][exceptions] at bci 44 for thread >>> 0x00007fe330019000 >>> >>> (b) adding newlines in the middle of the message, which would look like >>> >>> [0.225s][info ][exceptions] Exception >> 'java/lang/ClassNotFoundException': NoClassFound> >>> (0x00000006d5f5ae28) >>> thrown in interpreter method <{method} {0x00007fe231a04198} >>> 'findClass' '(Ljava/lang/String;)Ljava/lang/Class;' in >>> 'java/net/URLC> >>> at bci 44 for thread 0x00007fe330019000 >>> >>> and could easily end up wrapping mid-logging anyway depending on the >>> length of the exception message >>> (c) turning it all into one wrapped line that would be relatively easier >>> to programmatically parse since the decorators would be at the beginning >>> of the line, i.e. >>> >>> [0.225s][info ][exceptions] Exception >> 'java/lang/ClassNotFoundException': NoClassFound> >>> (0x00000006d5f5ae28) thrown in interpreter method <{method} >>> {0x00007fe231a04198} 'findClass' >>> '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC>at bci 44 >>> for thread 0x00007fe330019000 >>> >>> which is also the most compact option. >>> >>> So I opted for (c). But if I should stick to the original approach, i.e. >>> (b), I can see it could be easier to visually parse. Do you think that >>> would be preferable? >> >> I definitely vote for (b) - I think a goal of the conversion effort >> should be that if you disable the UL decorators then the output before >> and after the conversion should be the same. Decorators can be useful >> but also clutter. >> >> But I'm also worried that the UL framework might not atomically >> process a line with embedded newlines. Though in that case the fix >> needs to be in the UL framework. >> >> Thanks, >> David >> >>> Thanks! >>> Rachel >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Retested with JPRT, and the buffer-to-logstream schema in particular >>>>> works fine. >>>>> >>>>> Replies inline. >>>>> >>>>> On 12/13/2015 11:08 PM, David Holmes wrote: >>>>>> Hi Rachel, >>>>>> >>>>>> On 12/12/2015 7:38 AM, Rachel Protacio wrote: >>>>>>> Hello! An update and updated webrev. >>>>>>> >>>>>>> I've rewritten the two portions of code that had used ttyLockers to >>>>>>> print in one function-call, since there is no locker equivalent >>>>>>> in UL, >>>>>>> plus the fact that it will be easier for users to look for one >>>>>>> message's >>>>>>> contents without the decorators interrupting the lines. (And I >>>>>>> especially tested that the fix prints the whole line correctly.) >>>>>> >>>>>> Sorry I'm still seeing ttyLocker removal and use of multiple logging >>>>>> statements in: >>>>>> >>>>>> src/share/vm/interpreter/bytecodeInterpreter.cpp >>>>>> src/share/vm/interpreter/interpreterRuntime.cpp >>>>>> src/share/vm/opto/runtime.cpp >>>>>> >>>>>> which "two portions of code" did you change? >>>>> I apologize for that! I messed up with uploading the changeset before. >>>>> All fixed now in each of those files. >>>>>> >>>>>> I also note that src/share/vm/runtime/thread.cpp was not using >>>>>> ttyLocker but does have multi-part trace output. >>>>> True. Since a locker was unnecessary in the first place, I think it >>>>> makes sense to allow this (and other logging, both in UL and the >>>>> existing tty frameworks) to be printed in multiple steps. What do you >>>>> think? >>>>>> >>>>>>> As mentioned in the other thread, I will file a separate RFE to >>>>>>> deprecate this and other product flags being converted to logging. >>>>>>> >>>>>>> Since my last iteration was on hold/not reviewed yet, I've simply >>>>>>> updated it. http://cr.openjdk.java.net/~rprotacio/8141211.01 >>>>>> >>>>>> src/share/vm/c1/c1_Runtime1.cpp >>>>>> >>>>>> Nit in original code: >>>>>> >>>>>> 556 " for thread " INTPTR_FORMAT "", >>>>>> >>>>>> the "" before the comma seems superfluous. >>>>> Thanks for pointing that out! >>>>> Rachel >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> Rachel >>>>>>> >>>>>>> On 12/9/2015 1:12 PM, Rachel Protacio wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> (Sorry if this sent twice. Thunderbird is acting up.) >>>>>>>> >>>>>>>> Thanks for the review. Replies inline. >>>>>>>> Updated webrev: http://cr.openjdk.java.net/~rprotacio/8141211.01/ >>>>>>>> >>>>>>>> On 12/8/2015 10:53 PM, David Holmes wrote: >>>>>>>>> Hi Rachel, >>>>>>>>> >>>>>>>>> On 9/12/2015 1:42 AM, Rachel Protacio wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review my conversion of -XX:+TraceExceptions to >>>>>>>>>> -Xlog:exceptions=info. The existing (product) flag is aliased to >>>>>>>>>> the >>>>>>>>>> logging flag at the info level. >>>>>>>>> >>>>>>>>> Q: how does use of ttyLocker map into UL? I see an awful lot of >>>>>>>>> multi-line logging blocks that are going to be completely >>>>>>>>> messed up >>>>>>>>> without locking! >>>>>>>> I assumed that UL worked as-is for these instances, but I will >>>>>>>> check >>>>>>>> in with Marcus. >>>>>>>>> >>>>>>>>> src/share/vm/opto/runtime.cpp >>>>>>>>> >>>>>>>>> 1239 ResourceMark rm; >>>>>>>>> >>>>>>>>> What requires the introduction of the ResourceMark? >>>>>>>> A ResourceMark is necessary before using LogHandle output streams. >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>> >>>>>>>>> 2084 if (log_is_enabled(Info, exceptions)) { >>>>>>>>> 2085 ResourceMark rm; >>>>>>>>> >>>>>>>>> An extra leading space has crept in at +2085 >>>>>>>>> >>>>>>>>> 2087 logstream->print("Async. exception installed at >>>>>>>>> runtime >>>>>>>>> exit (" INTPTR_FORMAT ")", p2i(this)); >>>>>>>>> 2088 if (has_last_Java_frame()) { >>>>>>>>> 2089 frame f = last_frame(); >>>>>>>>> 2090 logstream->print(" (pc: " INTPTR_FORMAT " sp: " >>>>>>>>> INTPTR_FORMAT " )", p2i(f.pc()), p2i(f.sp())); >>>>>>>>> 2091 } >>>>>>>>> >>>>>>>>> Indention of these lines is wrong at #2088 and #2089 - need an >>>>>>>>> additional space. >>>>>>>> Thanks for catching these! >>>>>>>>> >>>>>>>>> 2092 logstream->print_cr(" of type: %s", >>>>>>>>> InstanceKlass::cast(_pending_async_exception->klass())->external_name()); >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Why did the InstanceKlass::cast need to be introduced ?? >>>>>>>> That was a vestige from code before a new changeset at the same >>>>>>>> line, >>>>>>>> i.e. my merging the repo didn't catch this. I've gotten rid of the >>>>>>>> cast. >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> test/runtime/CommandLine/TraceExceptionsTest.java >>>>>>>>> >>>>>>>>> You improved the readability of the source code by breaking the >>>>>>>>> @summary over two lines, but IIRC jtreg will write the summary >>>>>>>>> into >>>>>>>>> the test log with all the additional spaces you added, as the >>>>>>>>> summary >>>>>>>>> extends until the next tag. >>>>>>>> Ok, I didn't realize that! I've undone that change. >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> test/runtime/logging/ExceptionsTest.java >>>>>>>>> >>>>>>>>> Can you avoid the code duplication please. >>>>>>>>> >>>>>>>>> Also perhaps you could/should also check there are no logging >>>>>>>>> statements present when logging is supposed to be disabled. I'm >>>>>>>>> guessing the other logging tests haven't considered this. ?? >>>>>>>> Good points. I've added a check. >>>>>>>>> >>>>>>>>>> If you have any questions on the alias table (in the >>>>>>>>>> arguments.cpp >>>>>>>>>> and >>>>>>>>>> .hpp files), Max will chime in as he is the one who implemented >>>>>>>>>> that >>>>>>>>>> portion. >>>>>>>>> >>>>>>>>> Okay some general questions. >>>>>>>>> >>>>>>>>> First I would expect that aliased logging options are also marked >>>>>>>>> deprecated so that we can eventually make them obsolete and remove >>>>>>>>> them. >>>>>>>> I'm not sure about this one. Coleen? Max? >>>>>>>>> >>>>>>>>> Secondly, arguably if someone specifies -XX:-TraceExceptions it >>>>>>>>> should disable exception logging - which may have been turned >>>>>>>>> on by >>>>>>>>> -Xlog:all. >>>>>>>>> >>>>>>>>> Which leads to: how does the position of -XX:+/-TraceExceptions >>>>>>>>> interact with the position of -Xlog:xxx on the command-line (or >>>>>>>>> the >>>>>>>>> other argument introducing mechanisms) ? >>>>>>>> Very true. I've added an entry in the alias table to that effect. >>>>>>>>> >>>>>>>>> src/share/vm/runtime/arguments.cpp >>>>>>>>> >>>>>>>>> 2743 if(lookup_logging_aliases(option->optionString, >>>>>>>>> aliased_logging_option)){ >>>>>>>>> >>>>>>>>> Need space after "if", and before { >>>>>>>> Done. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Rachel >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> >>>>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8141211/ >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141211 >>>>>>>>>> >>>>>>>>>> Testing: jtreg, JPRT, jck vm tests, refworkload performance >>>>>>>>>> tests, >>>>>>>>>> rbt >>>>>>>>>> quick & non-colo tests >>>>>>>>>> >>>>>>>>>> Thank you! >>>>>>>>>> Rachel >>>>>>>> >>>>>>> >>>>> >>> > From david.holmes at oracle.com Wed Dec 23 04:41:32 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Dec 2015 14:41:32 +1000 Subject: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ... In-Reply-To: <56754D74.80802@oracle.com> References: <566ECDA6.1030404@oracle.com> <566FB3BB.4050709@oracle.com> <567000F9.2070603@oracle.com> <56700279.4000408@oracle.com> <56700531.8060701@oracle.com> <56724BE9.5060304@oracle.com> <567270F6.7030206@oracle.com> <567390D4.10307@oracle.com> <56754D74.80802@oracle.com> Message-ID: <567A25FC.7080109@oracle.com> Looks okay. Second review needed though. Thanks, David On 19/12/2015 10:28 PM, Ivan Gerasimov wrote: > > >>> We will suspend the current thread if two conditions are satisfied: >>> process_exiting != 0 and process_exiting != current thread id. >>> But, yes, pr_ex isn't really needed, as we can use process_exiting >>> directly. >>> >>> Here's the updated webrev: >>> http://cr.openjdk.java.net/~igerasim/8145127/01/webrev/ >> >> I still see pr_ex ?? >> > > Oops. > Forgot to 'hg qrefresh' before generating the webrev. > The webrev has just been updated in place. > > Sincerely yours, > Ivan > From jaroslav.bachorik at oracle.com Wed Dec 23 10:26:07 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 23 Dec 2015 11:26:07 +0100 Subject: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses Message-ID: <567A76BF.5090305@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 The test fails for IPv6 addresses since the RMI expects an IPv6 address to be properly wrapped in '[]'. In addition to that the logic for selecting IP addresses to bind is flawed - it does not check for IP addresses of multiple adapters but for multiple IP addresses assigned to 'localhost'. In combination with IPv4 & IPv6 this will cause the test to attempt binding to IPv4 and IPv6 address of the same adapter simultaneously and the test will fail. The fix adds the requested wrapping for IPv6 addresses and adjusts the IP selection logic to iterate over distinct adapters first and prevent IPv4 and IPv6 address of the same adapter being treated as two addresses (for the purposes of the test). Thanks, -JB- From ivan.gerasimov at oracle.com Wed Dec 23 12:20:20 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 23 Dec 2015 15:20:20 +0300 Subject: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ... In-Reply-To: <567A25FC.7080109@oracle.com> References: <566ECDA6.1030404@oracle.com> <566FB3BB.4050709@oracle.com> <567000F9.2070603@oracle.com> <56700279.4000408@oracle.com> <56700531.8060701@oracle.com> <56724BE9.5060304@oracle.com> <567270F6.7030206@oracle.com> <567390D4.10307@oracle.com> <56754D74.80802@oracle.com> <567A25FC.7080109@oracle.com> Message-ID: <567A9183.1000900@oracle.com> Thank you David for review! Sincerely yours, Ivan On 23.12.2015 7:41, David Holmes wrote: > Looks okay. > > Second review needed though. > > Thanks, > David > > On 19/12/2015 10:28 PM, Ivan Gerasimov wrote: >> >> >>>> We will suspend the current thread if two conditions are satisfied: >>>> process_exiting != 0 and process_exiting != current thread id. >>>> But, yes, pr_ex isn't really needed, as we can use process_exiting >>>> directly. >>>> >>>> Here's the updated webrev: >>>> http://cr.openjdk.java.net/~igerasim/8145127/01/webrev/ >>> >>> I still see pr_ex ?? >>> >> >> Oops. >> Forgot to 'hg qrefresh' before generating the webrev. >> The webrev has just been updated in place. >> >> Sincerely yours, >> Ivan >> > From dmitry.samersoff at oracle.com Wed Dec 23 12:28:34 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 23 Dec 2015 15:28:34 +0300 Subject: JDK-8067194: FYI, SA sources moved to jdk.hotspot.agent Message-ID: <567A9372.2070506@oracle.com> Everybody, FYI, I just pushed JDK-8067194 that move SA sources to modules-ready location: from hotspot/agent to hotspot/src/jdk.hotspot.agent Please, make sure you WS is updated correctly and if you have fixes that touch SA code in a queue, please re-merge it. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yasuenag at gmail.com Wed Dec 23 14:25:43 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 23 Dec 2015 23:25:43 +0900 Subject: RFR: JDK-8145788: JVM crashes with -XX:+EnableTracing In-Reply-To: <567A2121.1060504@oracle.com> References: <56742B46.9050106@gmail.com> <56793FE2.5090106@oracle.com> <5679FD8D.2090201@gmail.com> <567A2121.1060504@oracle.com> Message-ID: <567AAEE7.1060806@gmail.com> Hi David, >> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). > > That is not likely to be an option - it would likely be far too > disruptive to the initialization sequence. Agree. Thus I choose 2. > We will have to wait for the tracing experts to have a good look at > this. I'm waiting that the tracing experts join this discussion. Thanks, Yasumasa On 2015/12/23 13:20, David Holmes wrote: > Hi Yasumasa, > > On 23/12/2015 11:49 AM, Yasumasa Suenaga wrote: >> Hi David, >> >> I've added callstack when JVM crashed: >> https://bugs.openjdk.java.net/browse/JDK-8145788?focusedCommentId=13880225&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13880225 > > Thanks for that. > >> This crash occurrs in Arguments::apply_ergo() in Threads::create_vm(). >> apply_ergo() calls before JavaThread initialization. >> >> I think that TraceEvent can avoid crash with two approach: >> >> 1. Initialize JavaThread before calling apply_ergo() in create_vm(). > > That is not likely to be an option - it would likely be far too > disruptive to the initialization sequence. > >> 2. Avoid crash at TraceEvent when it is called before JavaThread initialization. > > Or don't call it at all. > > We will have to wait for the tracing experts to have a good look at > this. We end up in code that is not expecting to be run before more of > the VM is initialized, so we have to look at what else may be being > assumed and then decide whether to handle the situation or avoid it. > > Thanks, > David > >> >> Thanks, >> >> Yasumasa >> >> >> On 2015/12/22 21:19, David Holmes wrote: >>> On 19/12/2015 1:50 AM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> I encountered JVM crash when I passed -XX:+EnableTracing. >>>> >>>> I checked core image, it crashed in EventBooleanFlagChanged::writeEvent() >>>> which is called by Arguments::apply_ergo() because thread had not been >>>> initialized. (JVM seems to log changing GC algorithm to G1.) >>> >>> This seems like a logic error to me - something is trying to happen too >>> early during VM initialization. We need to look at exactly what we are >>> trying to do here, not just work around the crash. >>> >>> David >>> ----- >>> >>>> writeEvent() uses ResourceMark. Default constructor of ResourceMark uses >>>> ResourceArea in current thread. So ResourceMark in writeEvent() should >>>> pass valid ResourceArea. >>>> >>>> I think this issue is in traceEventClasses.xsl . >>>> However, my environment (GCC 5.3.1 on Fedora23) cannot build it because >>>> -Werror=maybe-uninitialized was occurred. >>>> So I also fixed them together. >>>> >>>> I've uploaded webrev. Could you review it? >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8145788/webrev.00/ >>>> >>>> I'm jdk9 committer, however I cannot access JPRT. >>>> So I need a sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> From rachel.protacio at oracle.com Wed Dec 23 16:08:16 2015 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 23 Dec 2015 11:08:16 -0500 Subject: RFR: 8141211: Convert TraceExceptions to Unified Logging In-Reply-To: <567A228F.8080704@oracle.com> References: <5666FA60.7060702@oracle.com> <5667A5B5.6080701@oracle.com> <56686F22.4080104@oracle.com> <566B425B.5000002@oracle.com> <566E40D3.5060305@oracle.com> <5670775A.4060806@oracle.com> <5671CF0B.20003@oracle.com> <5671D8C2.4040801@oracle.com> <5671F631.8000903@oracle.com> <5678731A.7050206@oracle.com> <567A228F.8080704@oracle.com> Message-ID: <567AC6F0.5030803@oracle.com> Thank you, David! Rachel On 12/22/2015 11:26 PM, David Holmes wrote: > Thanks Rachel - looks good. > > David > > On 22/12/2015 7:46 AM, Rachel Protacio wrote: >> Hi, >> >> Please take a look at my updated changeset! Webrev: >> http://cr.openjdk.java.net/~rprotacio/8141211.02/ >> >> I've fixed the multi-line statements as requested, i.e. put newlines in >> them to replicate the original format. >> >> Since the UL framework atomically writes complete messages, these single >> string messages do not need the discussed lockers to prevent >> interleaving. So it's ready to be checked in as-is (once reviewed, of >> course). I've opened a separate RFE for lockers, which will be necessary >> for other logging https://bugs.openjdk.java.net/browse/JDK-8145934 >> >> Thank you, >> Rachel >> >> On 12/16/2015 6:39 PM, David Holmes wrote: >>> Hi Rachel, >>> >>> On 17/12/2015 7:33 AM, Rachel Protacio wrote: >>>> Hi, >>>> >>>> On 12/16/2015 3:52 PM, David Holmes wrote: >>>>> Hi Rachel, >>>>> >>>>> On 16/12/2015 6:26 AM, Rachel Protacio wrote: >>>>>> Hi, >>>>>> >>>>>> Thanks for the comments, David. >>>>>> >>>>>> I had messed up my uploading before and had not actually updated the >>>>>> open html. So for real this time, the most recent webrev is at >>>>>> http://cr.openjdk.java.net/~rprotacio/8141211.01/ Of note: >>>>>> - each incident of ttyLocker that involved separate logging lines >>>>>> for >>>>>> the same message have been consolidated to one line >>>>>> - each incident of ttyLocker that involved separate print >>>>>> statements to >>>>>> one logging line has been changed to write to a buffer first, then >>>>>> print >>>>>> the entire line at once to the log stream >>>>> >>>>> I think I may be missing something here, sorry. Taking >>>>> src/share/vm/interpreter/bytecodeInterpreter.cpp as an example, three >>>>> print_cr statements have been replaced with one log_info statement - >>>>> but there are no newlines in-line in that one log_info statement. I >>>>> was assuming that a single call to something like log_info would be >>>>> 'atomic" and that we would manually place the \n as required in the >>>>> output string. >>>>> >>>>> This won't show up well in email due to line wrapping but going from >>>>> this: >>>>> >>>>> Exception >>>> sun.launcher.resources.launcher_en_US> (0x0000000101c69b18) >>>>> thrown in interpreter method <{method} {0x00007f55b63dbc18} >>>>> 'loadClass' '(Ljava/lang/String;Z)Ljava/lang/Class;' in >>>>> 'java/lang/Cl> >>>>> at bci 70 for thread 0x00007f56d0019800 >>>>> >>>>> to this: >>>>> >>>>> Exception >>>> sun.launcher.resources.launcher_en_US> (0x0000000101c69b18) thrown in >>>>> interpreter method <{method} {0x00007f55b63dbc18} 'loadClass' >>>>> '(Ljava/lang/String;Z)Ljava/lang/Class;' in 'java/lang/Cl> at bci 70 >>>>> for thread 0x00007f56d0019800 >>>>> >>>>> will not be anywhere as near as clear in the logs. >>>> Yes, I changed that intentionally. The choices as I saw them were: >>>> (a) multiple print_cr() calls, which could lead to unwanted >>>> interweaving >>>> and which breaks up the logging message with decorators at the >>>> beginning >>>> of every line, e.g. >>>> >>>> [0.225s][info ][exceptions] Exception >>> 'java/lang/ClassNotFoundException': NoClassFound> >>>> (0x00000006d5f5ae28) >>>> [0.225s][info ][exceptions] thrown in interpreter method >>>> <{method} >>>> {0x00007fe231a04198} 'findClass' >>>> '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC> >>>> [0.225s][info ][exceptions] at bci 44 for thread >>>> 0x00007fe330019000 >>>> >>>> (b) adding newlines in the middle of the message, which would look >>>> like >>>> >>>> [0.225s][info ][exceptions] Exception >>> 'java/lang/ClassNotFoundException': NoClassFound> >>>> (0x00000006d5f5ae28) >>>> thrown in interpreter method <{method} {0x00007fe231a04198} >>>> 'findClass' '(Ljava/lang/String;)Ljava/lang/Class;' in >>>> 'java/net/URLC> >>>> at bci 44 for thread 0x00007fe330019000 >>>> >>>> and could easily end up wrapping mid-logging anyway depending on the >>>> length of the exception message >>>> (c) turning it all into one wrapped line that would be relatively >>>> easier >>>> to programmatically parse since the decorators would be at the >>>> beginning >>>> of the line, i.e. >>>> >>>> [0.225s][info ][exceptions] Exception >>> 'java/lang/ClassNotFoundException': NoClassFound> >>>> (0x00000006d5f5ae28) thrown in interpreter method <{method} >>>> {0x00007fe231a04198} 'findClass' >>>> '(Ljava/lang/String;)Ljava/lang/Class;' in 'java/net/URLC>at >>>> bci 44 >>>> for thread 0x00007fe330019000 >>>> >>>> which is also the most compact option. >>>> >>>> So I opted for (c). But if I should stick to the original approach, >>>> i.e. >>>> (b), I can see it could be easier to visually parse. Do you think that >>>> would be preferable? >>> >>> I definitely vote for (b) - I think a goal of the conversion effort >>> should be that if you disable the UL decorators then the output before >>> and after the conversion should be the same. Decorators can be useful >>> but also clutter. >>> >>> But I'm also worried that the UL framework might not atomically >>> process a line with embedded newlines. Though in that case the fix >>> needs to be in the UL framework. >>> >>> Thanks, >>> David >>> >>>> Thanks! >>>> Rachel >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Retested with JPRT, and the buffer-to-logstream schema in particular >>>>>> works fine. >>>>>> >>>>>> Replies inline. >>>>>> >>>>>> On 12/13/2015 11:08 PM, David Holmes wrote: >>>>>>> Hi Rachel, >>>>>>> >>>>>>> On 12/12/2015 7:38 AM, Rachel Protacio wrote: >>>>>>>> Hello! An update and updated webrev. >>>>>>>> >>>>>>>> I've rewritten the two portions of code that had used >>>>>>>> ttyLockers to >>>>>>>> print in one function-call, since there is no locker equivalent >>>>>>>> in UL, >>>>>>>> plus the fact that it will be easier for users to look for one >>>>>>>> message's >>>>>>>> contents without the decorators interrupting the lines. (And I >>>>>>>> especially tested that the fix prints the whole line correctly.) >>>>>>> >>>>>>> Sorry I'm still seeing ttyLocker removal and use of multiple >>>>>>> logging >>>>>>> statements in: >>>>>>> >>>>>>> src/share/vm/interpreter/bytecodeInterpreter.cpp >>>>>>> src/share/vm/interpreter/interpreterRuntime.cpp >>>>>>> src/share/vm/opto/runtime.cpp >>>>>>> >>>>>>> which "two portions of code" did you change? >>>>>> I apologize for that! I messed up with uploading the changeset >>>>>> before. >>>>>> All fixed now in each of those files. >>>>>>> >>>>>>> I also note that src/share/vm/runtime/thread.cpp was not using >>>>>>> ttyLocker but does have multi-part trace output. >>>>>> True. Since a locker was unnecessary in the first place, I think it >>>>>> makes sense to allow this (and other logging, both in UL and the >>>>>> existing tty frameworks) to be printed in multiple steps. What do >>>>>> you >>>>>> think? >>>>>>> >>>>>>>> As mentioned in the other thread, I will file a separate RFE to >>>>>>>> deprecate this and other product flags being converted to logging. >>>>>>>> >>>>>>>> Since my last iteration was on hold/not reviewed yet, I've simply >>>>>>>> updated it. http://cr.openjdk.java.net/~rprotacio/8141211.01 >>>>>>> >>>>>>> src/share/vm/c1/c1_Runtime1.cpp >>>>>>> >>>>>>> Nit in original code: >>>>>>> >>>>>>> 556 " for thread " INTPTR_FORMAT "", >>>>>>> >>>>>>> the "" before the comma seems superfluous. >>>>>> Thanks for pointing that out! >>>>>> Rachel >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Thanks, >>>>>>>> Rachel >>>>>>>> >>>>>>>> On 12/9/2015 1:12 PM, Rachel Protacio wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> (Sorry if this sent twice. Thunderbird is acting up.) >>>>>>>>> >>>>>>>>> Thanks for the review. Replies inline. >>>>>>>>> Updated webrev: http://cr.openjdk.java.net/~rprotacio/8141211.01/ >>>>>>>>> >>>>>>>>> On 12/8/2015 10:53 PM, David Holmes wrote: >>>>>>>>>> Hi Rachel, >>>>>>>>>> >>>>>>>>>> On 9/12/2015 1:42 AM, Rachel Protacio wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Please review my conversion of -XX:+TraceExceptions to >>>>>>>>>>> -Xlog:exceptions=info. The existing (product) flag is >>>>>>>>>>> aliased to >>>>>>>>>>> the >>>>>>>>>>> logging flag at the info level. >>>>>>>>>> >>>>>>>>>> Q: how does use of ttyLocker map into UL? I see an awful lot of >>>>>>>>>> multi-line logging blocks that are going to be completely >>>>>>>>>> messed up >>>>>>>>>> without locking! >>>>>>>>> I assumed that UL worked as-is for these instances, but I will >>>>>>>>> check >>>>>>>>> in with Marcus. >>>>>>>>>> >>>>>>>>>> src/share/vm/opto/runtime.cpp >>>>>>>>>> >>>>>>>>>> 1239 ResourceMark rm; >>>>>>>>>> >>>>>>>>>> What requires the introduction of the ResourceMark? >>>>>>>>> A ResourceMark is necessary before using LogHandle output >>>>>>>>> streams. >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>> >>>>>>>>>> 2084 if (log_is_enabled(Info, exceptions)) { >>>>>>>>>> 2085 ResourceMark rm; >>>>>>>>>> >>>>>>>>>> An extra leading space has crept in at +2085 >>>>>>>>>> >>>>>>>>>> 2087 logstream->print("Async. exception installed at >>>>>>>>>> runtime >>>>>>>>>> exit (" INTPTR_FORMAT ")", p2i(this)); >>>>>>>>>> 2088 if (has_last_Java_frame()) { >>>>>>>>>> 2089 frame f = last_frame(); >>>>>>>>>> 2090 logstream->print(" (pc: " INTPTR_FORMAT " sp: " >>>>>>>>>> INTPTR_FORMAT " )", p2i(f.pc()), p2i(f.sp())); >>>>>>>>>> 2091 } >>>>>>>>>> >>>>>>>>>> Indention of these lines is wrong at #2088 and #2089 - need an >>>>>>>>>> additional space. >>>>>>>>> Thanks for catching these! >>>>>>>>>> >>>>>>>>>> 2092 logstream->print_cr(" of type: %s", >>>>>>>>>> InstanceKlass::cast(_pending_async_exception->klass())->external_name()); >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Why did the InstanceKlass::cast need to be introduced ?? >>>>>>>>> That was a vestige from code before a new changeset at the same >>>>>>>>> line, >>>>>>>>> i.e. my merging the repo didn't catch this. I've gotten rid of >>>>>>>>> the >>>>>>>>> cast. >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> test/runtime/CommandLine/TraceExceptionsTest.java >>>>>>>>>> >>>>>>>>>> You improved the readability of the source code by breaking the >>>>>>>>>> @summary over two lines, but IIRC jtreg will write the summary >>>>>>>>>> into >>>>>>>>>> the test log with all the additional spaces you added, as the >>>>>>>>>> summary >>>>>>>>>> extends until the next tag. >>>>>>>>> Ok, I didn't realize that! I've undone that change. >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> test/runtime/logging/ExceptionsTest.java >>>>>>>>>> >>>>>>>>>> Can you avoid the code duplication please. >>>>>>>>>> >>>>>>>>>> Also perhaps you could/should also check there are no logging >>>>>>>>>> statements present when logging is supposed to be disabled. I'm >>>>>>>>>> guessing the other logging tests haven't considered this. ?? >>>>>>>>> Good points. I've added a check. >>>>>>>>>> >>>>>>>>>>> If you have any questions on the alias table (in the >>>>>>>>>>> arguments.cpp >>>>>>>>>>> and >>>>>>>>>>> .hpp files), Max will chime in as he is the one who implemented >>>>>>>>>>> that >>>>>>>>>>> portion. >>>>>>>>>> >>>>>>>>>> Okay some general questions. >>>>>>>>>> >>>>>>>>>> First I would expect that aliased logging options are also >>>>>>>>>> marked >>>>>>>>>> deprecated so that we can eventually make them obsolete and >>>>>>>>>> remove >>>>>>>>>> them. >>>>>>>>> I'm not sure about this one. Coleen? Max? >>>>>>>>>> >>>>>>>>>> Secondly, arguably if someone specifies -XX:-TraceExceptions it >>>>>>>>>> should disable exception logging - which may have been turned >>>>>>>>>> on by >>>>>>>>>> -Xlog:all. >>>>>>>>>> >>>>>>>>>> Which leads to: how does the position of -XX:+/-TraceExceptions >>>>>>>>>> interact with the position of -Xlog:xxx on the command-line (or >>>>>>>>>> the >>>>>>>>>> other argument introducing mechanisms) ? >>>>>>>>> Very true. I've added an entry in the alias table to that effect. >>>>>>>>>> >>>>>>>>>> src/share/vm/runtime/arguments.cpp >>>>>>>>>> >>>>>>>>>> 2743 if(lookup_logging_aliases(option->optionString, >>>>>>>>>> aliased_logging_option)){ >>>>>>>>>> >>>>>>>>>> Need space after "if", and before { >>>>>>>>> Done. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Rachel >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8141211/ >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8141211 >>>>>>>>>>> >>>>>>>>>>> Testing: jtreg, JPRT, jck vm tests, refworkload performance >>>>>>>>>>> tests, >>>>>>>>>>> rbt >>>>>>>>>>> quick & non-colo tests >>>>>>>>>>> >>>>>>>>>>> Thank you! >>>>>>>>>>> Rachel >>>>>>>>> >>>>>>>> >>>>>> >>>> >> From andreas.eriksson at oracle.com Mon Dec 28 14:02:30 2015 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Mon, 28 Dec 2015 15:02:30 +0100 Subject: RFR (M): 8129419: heapDumper.cpp: assert(length_in_bytes > 0) failed: nothing to copy In-Reply-To: <566F0BCB.3000407@oracle.com> References: <566EE268.1010803@oracle.com> <566EFCC7.6010106@oracle.com> <566F0BCB.3000407@oracle.com> Message-ID: <568140F6.40805@oracle.com> Hi, Here is the webrev for type changes. Top-repo: http://cr.openjdk.java.net/~aeriksso/8129419/webrev.01/jdk9-hs-rt/ Hotspot: http://cr.openjdk.java.net/~aeriksso/8129419/webrev.01/hotspot/ The windows_x64 native write function uses a length of type uint, not size_t. I added an ifdef for that case and handled it, but better suggestions are welcome. Also found and fixed another problem in the hprof parser when skipping over bytes. I've not included the tests, they have OOM issues on several JPRT hosts, and until I've figured out a way to fix that I wont be pushing them. Thanks, Andreas On 2015-12-14 19:34, Andreas Eriksson wrote: > Hi Dmitry, thanks for looking at this. > > > On 2015-12-14 18:30, Dmitry Samersoff wrote: >> Andreas, >> >> Nice cleanup. >> >> Some generic comments below. >> >> 1. It would be excellent if you can split webrev into two parts, one >> part with types cleanup and other part with array truncation related >> changes or ever push these changes separately as it address different >> problems. >> >> Type cleanup could be reviewed quickly, but review of array truncation >> requires some time. >> >> (We already have two different CRs: JDK-8129419 for type cleanup and >> JDK-8144732 for array truncation) > > Yes, that's a good point. > >> >> >> 2. >> it might be better to use size_t and jlong (or julong) across all file >> and get rid of all other types with a few exclusion. > > I'll see what I can do, and we can look at it closer once I've split > the type changes into a separate webrev. > >> 3. >> Each assert costs some time in nightly testing, so we probably don't >> need as much asserts. > > Alright. > >> >> 4. write_internal: >> >> There are couple of cases where ::write writes less bytes than >> requested and doesn't return -1. >> So we should check if ::write returns a value less that len and if it >> happens deal with errno - either repeat entire write >> attempt(EINTR/EAGAIN) or abort writing. > > Actually, I meant to ask about that, but forgot: > I tried using os::write, which handles EINTR/EAGAIN if necessary > (depending on platform), but Solaris has an assert that fails: > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/5a42c1dde332/src/os/solaris/vm/os_solaris.cpp#l5692 > > It checks that os::write is called by a JavaThread that is in_native, > which we are not, since we are in the VM_thread doing a safepoint_op. > Does anyone know if that assert is really needed? It's only done for > Solaris. > >> >> 5. we should handle zero-length array in calculate_array_max_length - >> it's a legitimate case > > Not sure what you mean here, I believe it does handle zero-length arrays. > It should just fall through without taking any of the if-clauses. > (Or do you mean that I should add a return immediately at the top if > length is zero?) > >> 6. max_juint is less than SegmentedHeapDumpThreshold so non-segmented >> heapdump can't contain huge array and it's better to check for segmented >> dump before any other checks. > > Correct me if I'm wrong here, but SegmentedHeapDumpThreshold could in > theory be set so that we have a non-segmented heap dump while still > having huge arrays. > Not sure if this is worth taking into account, since it most likely > would lead to other problems as well, and the flag is develop only, so > it can't happen in product builds. > What do you think would be best to do here? > > - Andreas > >> >> -Dmitry >> >> >> On 2015-12-14 18:38, Andreas Eriksson wrote: >>> Hi, >>> >>> Please review this fix for dumping of long arrays, and general cleanup >>> of types in heapDumper.cpp. >>> >>> Problem: >>> At several places in heapDumper.cpp overflows could happen when dumping >>> long arrays. >>> Also the hprof format uses an u4 as a record length field, but arrays >>> can be longer than that (counted in bytes). >>> >>> Fix: >>> Many types that were previously signed are changed to equivalent >>> unsigned types and/or to a larger type to prevent overflow. >>> The bulk of the change though is the addition of >>> calculate_array_max_length, which for a given array returns the number >>> of elements we can dump. That length is then used to truncate arrays >>> that are too long. >>> Whenever an array is truncated a warning is printed: >>> Java HotSpot(TM) 64-Bit Server VM warning: cannot dump array of type >>> object[] with length 1,073,741,823; truncating to length 536,870,908 >>> >>> Much of the rest of the change is moving functions needed by >>> calculate_array_max_length to the DumpWriter or DumperSupport class so >>> that they can be accessed. >>> >>> Added a test that relies on the hprof parser, which also had a >>> couple of >>> overflow problems (top repo changes). >>> I've also run this change against a couple of other tests, but they are >>> problematic in JPRT because they are using large heaps and lots of >>> disk. >>> >>> Bug: >>> 8129419: heapDumper.cpp: assert(length_in_bytes > 0) failed: nothing to >>> copy >>> https://bugs.openjdk.java.net/browse/JDK-8129419 >>> >>> Also fixed in this change is the problems seen in these two bugs: >>> 8133317: Integer overflow in heapDumper.cpp leads to corrupt HPROF >>> dumps >>> https://bugs.openjdk.java.net/browse/JDK-8133317 >>> >>> 8144732: VM_HeapDumper hits assert with bad dump_len >>> https://bugs.openjdk.java.net/browse/JDK-8144732 >>> >>> Webrev: >>> Top repo: >>> http://cr.openjdk.java.net/~aeriksso/8129419/webrev.00/jdk9-hs-rt/ >>> Hotspot: >>> http://cr.openjdk.java.net/~aeriksso/8129419/webrev.00/hotspot/ >>> >>> Regards, >>> Andreas >> > From sharath.ballal at oracle.com Mon Dec 28 17:01:40 2015 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 28 Dec 2015 09:01:40 -0800 (PST) Subject: Review of JDK-6659240 - Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory Message-ID: <2072ed8f-585c-4c1c-b036-c97775636db1@default> Hi, Kindly review the changes for bug https://bugs.openjdk.java.net/browse/JDK-6659240 Webrev: http://cr.openjdk.java.net/~jbachorik/sponsorship/6659240/webrev.00/ CCC request for the same is being raised in parallel. -Sharath Ballal -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Tue Dec 29 20:27:52 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 29 Dec 2015 23:27:52 +0300 Subject: RFR (M): 8129419: heapDumper.cpp: assert(length_in_bytes > 0) failed: nothing to copy In-Reply-To: <568140F6.40805@oracle.com> References: <566EE268.1010803@oracle.com> <566EFCC7.6010106@oracle.com> <566F0BCB.3000407@oracle.com> <568140F6.40805@oracle.com> Message-ID: <5682ECC8.2040309@oracle.com> Andreas, Great work. All but write_internal looks good for me (see below). HprofReader.java: Nit - length -= skipped; should be after if skipped == 0 heapDumper.cpp:480 1. For windows you can do : assert(len < (size_t)UINT_MAX, ... ); ::write( ..., (uint) (len & UINT_MAX)); 2. You should check for n < len and if it is true, deal with errno. n = 0 is legitimate case, so assert is not necessary. -Dmitry On 2015-12-28 17:02, Andreas Eriksson wrote: > Hi, > > Here is the webrev for type changes. > Top-repo: > http://cr.openjdk.java.net/~aeriksso/8129419/webrev.01/jdk9-hs-rt/ > Hotspot: http://cr.openjdk.java.net/~aeriksso/8129419/webrev.01/hotspot/ > > The windows_x64 native write function uses a length of type uint, not > size_t. I added an ifdef for that case and handled it, but better > suggestions are welcome. > > Also found and fixed another problem in the hprof parser when skipping > over bytes. > > I've not included the tests, they have OOM issues on several JPRT hosts, > and until I've figured out a way to fix that I wont be pushing them. > > Thanks, > Andreas > > On 2015-12-14 19:34, Andreas Eriksson wrote: >> Hi Dmitry, thanks for looking at this. >> >> >> On 2015-12-14 18:30, Dmitry Samersoff wrote: >>> Andreas, >>> >>> Nice cleanup. >>> >>> Some generic comments below. >>> >>> 1. It would be excellent if you can split webrev into two parts, one >>> part with types cleanup and other part with array truncation related >>> changes or ever push these changes separately as it address different >>> problems. >>> >>> Type cleanup could be reviewed quickly, but review of array truncation >>> requires some time. >>> >>> (We already have two different CRs: JDK-8129419 for type cleanup and >>> JDK-8144732 for array truncation) >> >> Yes, that's a good point. >> >>> >>> >>> 2. >>> it might be better to use size_t and jlong (or julong) across all file >>> and get rid of all other types with a few exclusion. >> >> I'll see what I can do, and we can look at it closer once I've split >> the type changes into a separate webrev. >> >>> 3. >>> Each assert costs some time in nightly testing, so we probably don't >>> need as much asserts. >> >> Alright. >> >>> >>> 4. write_internal: >>> >>> There are couple of cases where ::write writes less bytes than >>> requested and doesn't return -1. >>> So we should check if ::write returns a value less that len and if it >>> happens deal with errno - either repeat entire write >>> attempt(EINTR/EAGAIN) or abort writing. >> >> Actually, I meant to ask about that, but forgot: >> I tried using os::write, which handles EINTR/EAGAIN if necessary >> (depending on platform), but Solaris has an assert that fails: >> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/5a42c1dde332/src/os/solaris/vm/os_solaris.cpp#l5692 >> >> It checks that os::write is called by a JavaThread that is in_native, >> which we are not, since we are in the VM_thread doing a safepoint_op. >> Does anyone know if that assert is really needed? It's only done for >> Solaris. >> >>> >>> 5. we should handle zero-length array in calculate_array_max_length - >>> it's a legitimate case >> >> Not sure what you mean here, I believe it does handle zero-length arrays. >> It should just fall through without taking any of the if-clauses. >> (Or do you mean that I should add a return immediately at the top if >> length is zero?) >> >>> 6. max_juint is less than SegmentedHeapDumpThreshold so non-segmented >>> heapdump can't contain huge array and it's better to check for segmented >>> dump before any other checks. >> >> Correct me if I'm wrong here, but SegmentedHeapDumpThreshold could in >> theory be set so that we have a non-segmented heap dump while still >> having huge arrays. >> Not sure if this is worth taking into account, since it most likely >> would lead to other problems as well, and the flag is develop only, so >> it can't happen in product builds. >> What do you think would be best to do here? >> >> - Andreas >> >>> >>> -Dmitry >>> >>> >>> On 2015-12-14 18:38, Andreas Eriksson wrote: >>>> Hi, >>>> >>>> Please review this fix for dumping of long arrays, and general cleanup >>>> of types in heapDumper.cpp. >>>> >>>> Problem: >>>> At several places in heapDumper.cpp overflows could happen when dumping >>>> long arrays. >>>> Also the hprof format uses an u4 as a record length field, but arrays >>>> can be longer than that (counted in bytes). >>>> >>>> Fix: >>>> Many types that were previously signed are changed to equivalent >>>> unsigned types and/or to a larger type to prevent overflow. >>>> The bulk of the change though is the addition of >>>> calculate_array_max_length, which for a given array returns the number >>>> of elements we can dump. That length is then used to truncate arrays >>>> that are too long. >>>> Whenever an array is truncated a warning is printed: >>>> Java HotSpot(TM) 64-Bit Server VM warning: cannot dump array of type >>>> object[] with length 1,073,741,823; truncating to length 536,870,908 >>>> >>>> Much of the rest of the change is moving functions needed by >>>> calculate_array_max_length to the DumpWriter or DumperSupport class so >>>> that they can be accessed. >>>> >>>> Added a test that relies on the hprof parser, which also had a >>>> couple of >>>> overflow problems (top repo changes). >>>> I've also run this change against a couple of other tests, but they are >>>> problematic in JPRT because they are using large heaps and lots of >>>> disk. >>>> >>>> Bug: >>>> 8129419: heapDumper.cpp: assert(length_in_bytes > 0) failed: nothing to >>>> copy >>>> https://bugs.openjdk.java.net/browse/JDK-8129419 >>>> >>>> Also fixed in this change is the problems seen in these two bugs: >>>> 8133317: Integer overflow in heapDumper.cpp leads to corrupt HPROF >>>> dumps >>>> https://bugs.openjdk.java.net/browse/JDK-8133317 >>>> >>>> 8144732: VM_HeapDumper hits assert with bad dump_len >>>> https://bugs.openjdk.java.net/browse/JDK-8144732 >>>> >>>> Webrev: >>>> Top repo: >>>> http://cr.openjdk.java.net/~aeriksso/8129419/webrev.00/jdk9-hs-rt/ >>>> Hotspot: >>>> http://cr.openjdk.java.net/~aeriksso/8129419/webrev.00/hotspot/ >>>> >>>> Regards, >>>> Andreas >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Wed Dec 30 09:06:21 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 30 Dec 2015 10:06:21 +0100 Subject: Review of JDK-6659240 - Exceptions thrown by MXBeans wrongly documented in j.l.m.ManagementFactory In-Reply-To: <2072ed8f-585c-4c1c-b036-c97775636db1@default> References: <2072ed8f-585c-4c1c-b036-c97775636db1@default> Message-ID: <56839E8D.3010706@oracle.com> On 28.12.2015 18:01, Sharath Ballal wrote: > Hi, > > Kindly review the changes for bug > https://bugs.openjdk.java.net/browse/JDK-6659240 > > Webrev: http://cr.openjdk.java.net/~jbachorik/sponsorship/6659240/webrev.00/ Looks good! -JB- > > CCC request for the same is being raised in parallel. > > -Sharath Ballal >