From shanliang.jiang at oracle.com Mon Jan 5 17:47:29 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 05 Jan 2015 18:47:29 +0100 Subject: jmx-dev RFR 6720349: NotificationBufferDeadlockTest.java throw exception: java.lang.Exception: TEST FAILED: Deadlock detected Message-ID: <54AACE31.80402@oracle.com> Hi, Please review this fix: bug: https://bugs.openjdk.java.net/browse/JDK-8068418 webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068418/00/ This must be a timing issue in the test, the test called: t.join(5000L); to wait a thread's dying, I reproduced the bug by insert at line 202: try { Thread.sleep(5100); } catch (Exception ee) {} to delay the t's dying. The fix is to replace: t.join(5000L); by: t.join(); and replace: Object.wait(timeout); by CountDownLatch.countDown(); The test harness timeout will be used as the max waiting timeout. Shanliang From david.holmes at oracle.com Tue Jan 6 02:46:20 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 06 Jan 2015 12:46:20 +1000 Subject: jmx-dev RFR 6720349: NotificationBufferDeadlockTest.java throw exception: java.lang.Exception: TEST FAILED: Deadlock detected In-Reply-To: <54AACE31.80402@oracle.com> References: <54AACE31.80402@oracle.com> Message-ID: <54AB4C7C.10208@oracle.com> Hi Shanliang, On 6/01/2015 3:47 AM, shanliang wrote: > Hi, > > Please review this fix: > > bug: https://bugs.openjdk.java.net/browse/JDK-8068418 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068418/00/ > > This must be a timing issue in the test, the test called: > t.join(5000L); to wait a thread's dying, I reproduced the bug by > insert at line 202: > try { > Thread.sleep(5100); > } catch (Exception ee) {} > to delay the t's dying. > > The fix is to replace: > t.join(5000L); > by: > t.join(); > > and replace: > Object.wait(timeout); > by > CountDownLatch.countDown(); Okay - you could have just done wait() but the switch to CountDownLatch is somewhat cleaner. > The test harness timeout will be used as the max waiting timeout. So the test will now never report that it thinks it has hit a deadlock, it will just timeout. But you added some extra printout so okay I guess - but I suggest adding a comment at the top (where @run etc are) saying that if test times out then deadlock is suspected. Minor nit: System.out.println("DeadlockTest-addNotificationListener waiting the XXX thread to die. should say "waiting for the XXX thread ..." Thanks, David > Shanliang From shanliang.jiang at oracle.com Tue Jan 6 11:03:38 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 06 Jan 2015 12:03:38 +0100 Subject: jmx-dev RFR 6720349: NotificationBufferDeadlockTest.java throw exception: java.lang.Exception: TEST FAILED: Deadlock detected In-Reply-To: <54AB4C7C.10208@oracle.com> References: <54AACE31.80402@oracle.com> <54AB4C7C.10208@oracle.com> Message-ID: <54ABC10A.6090707@oracle.com> David, Here is the new version, I have added the comments as you suggested, and I replaced the variable "sources" with a synchronized list. http://cr.openjdk.java.net/~sjiang/JDK-8068418/01/ Thanks for the review. Shanliang David Holmes wrote: > Hi Shanliang, > > On 6/01/2015 3:47 AM, shanliang wrote: >> Hi, >> >> Please review this fix: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8068418 >> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068418/00/ >> >> This must be a timing issue in the test, the test called: >> t.join(5000L); to wait a thread's dying, I reproduced the bug by >> insert at line 202: >> try { >> Thread.sleep(5100); >> } catch (Exception ee) {} >> to delay the t's dying. >> >> The fix is to replace: >> t.join(5000L); >> by: >> t.join(); >> >> and replace: >> Object.wait(timeout); >> by >> CountDownLatch.countDown(); > > Okay - you could have just done wait() but the switch to > CountDownLatch is somewhat cleaner. > >> The test harness timeout will be used as the max waiting timeout. > > So the test will now never report that it thinks it has hit a > deadlock, it will just timeout. But you added some extra printout so > okay I guess - but I suggest adding a comment at the top (where @run > etc are) saying that if test times out then deadlock is suspected. > > Minor nit: > > System.out.println("DeadlockTest-addNotificationListener waiting the > XXX thread to die. > > should say "waiting for the XXX thread ..." > > Thanks, > David > >> Shanliang From david.holmes at oracle.com Tue Jan 6 12:08:40 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 06 Jan 2015 22:08:40 +1000 Subject: jmx-dev RFR 6720349: NotificationBufferDeadlockTest.java throw exception: java.lang.Exception: TEST FAILED: Deadlock detected In-Reply-To: <54ABC10A.6090707@oracle.com> References: <54AACE31.80402@oracle.com> <54AB4C7C.10208@oracle.com> <54ABC10A.6090707@oracle.com> Message-ID: <54ABD048.1040903@oracle.com> On 6/01/2015 9:03 PM, shanliang wrote: > David, > > Here is the new version, I have added the comments as you suggested, and > I replaced the variable "sources" with a synchronized list. Why did you do that ?? Vector is synchronized so it was fine for the job. David > http://cr.openjdk.java.net/~sjiang/JDK-8068418/01/ > > Thanks for the review. > Shanliang > > David Holmes wrote: >> Hi Shanliang, >> >> On 6/01/2015 3:47 AM, shanliang wrote: >>> Hi, >>> >>> Please review this fix: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8068418 >>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068418/00/ >>> >>> This must be a timing issue in the test, the test called: >>> t.join(5000L); to wait a thread's dying, I reproduced the bug by >>> insert at line 202: >>> try { >>> Thread.sleep(5100); >>> } catch (Exception ee) {} >>> to delay the t's dying. >>> >>> The fix is to replace: >>> t.join(5000L); >>> by: >>> t.join(); >>> >>> and replace: >>> Object.wait(timeout); >>> by >>> CountDownLatch.countDown(); >> >> Okay - you could have just done wait() but the switch to >> CountDownLatch is somewhat cleaner. >> >>> The test harness timeout will be used as the max waiting timeout. >> >> So the test will now never report that it thinks it has hit a >> deadlock, it will just timeout. But you added some extra printout so >> okay I guess - but I suggest adding a comment at the top (where @run >> etc are) saying that if test times out then deadlock is suspected. >> >> Minor nit: >> >> System.out.println("DeadlockTest-addNotificationListener waiting the >> XXX thread to die. >> >> should say "waiting for the XXX thread ..." >> >> Thanks, >> David >> >>> Shanliang > From shanliang.jiang at oracle.com Tue Jan 6 12:56:05 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 06 Jan 2015 13:56:05 +0100 Subject: jmx-dev RFR 6720349: NotificationBufferDeadlockTest.java throw exception: java.lang.Exception: TEST FAILED: Deadlock detected In-Reply-To: <54ABD048.1040903@oracle.com> References: <54AACE31.80402@oracle.com> <54AB4C7C.10208@oracle.com> <54ABC10A.6090707@oracle.com> <54ABD048.1040903@oracle.com> Message-ID: <54ABDB65.2070109@oracle.com> David Holmes wrote: > On 6/01/2015 9:03 PM, shanliang wrote: >> David, >> >> Here is the new version, I have added the comments as you suggested, and >> I replaced the variable "sources" with a synchronized list. > > Why did you do that ?? Vector is synchronized so it was fine for the job. You are right! I have changed back to Vector: http://cr.openjdk.java.net/~sjiang/JDK-8068418/02/ I forgot Vetor is synchronized, so long time not use it. Thanks, Shanliang > > David > >> http://cr.openjdk.java.net/~sjiang/JDK-8068418/01/ >> >> Thanks for the review. >> Shanliang >> >> David Holmes wrote: >>> Hi Shanliang, >>> >>> On 6/01/2015 3:47 AM, shanliang wrote: >>>> Hi, >>>> >>>> Please review this fix: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8068418 >>>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068418/00/ >>>> >>>> This must be a timing issue in the test, the test called: >>>> t.join(5000L); to wait a thread's dying, I reproduced the bug by >>>> insert at line 202: >>>> try { >>>> Thread.sleep(5100); >>>> } catch (Exception ee) {} >>>> to delay the t's dying. >>>> >>>> The fix is to replace: >>>> t.join(5000L); >>>> by: >>>> t.join(); >>>> >>>> and replace: >>>> Object.wait(timeout); >>>> by >>>> CountDownLatch.countDown(); >>> >>> Okay - you could have just done wait() but the switch to >>> CountDownLatch is somewhat cleaner. >>> >>>> The test harness timeout will be used as the max waiting timeout. >>> >>> So the test will now never report that it thinks it has hit a >>> deadlock, it will just timeout. But you added some extra printout so >>> okay I guess - but I suggest adding a comment at the top (where @run >>> etc are) saying that if test times out then deadlock is suspected. >>> >>> Minor nit: >>> >>> System.out.println("DeadlockTest-addNotificationListener waiting the >>> XXX thread to die. >>> >>> should say "waiting for the XXX thread ..." >>> >>> Thanks, >>> David >>> >>>> Shanliang >> From david.holmes at oracle.com Wed Jan 7 01:20:18 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 07 Jan 2015 11:20:18 +1000 Subject: jmx-dev RFR 6720349: NotificationBufferDeadlockTest.java throw exception: java.lang.Exception: TEST FAILED: Deadlock detected In-Reply-To: <54ABDB65.2070109@oracle.com> References: <54AACE31.80402@oracle.com> <54AB4C7C.10208@oracle.com> <54ABC10A.6090707@oracle.com> <54ABD048.1040903@oracle.com> <54ABDB65.2070109@oracle.com> Message-ID: <54AC89D2.4060507@oracle.com> On 6/01/2015 10:56 PM, shanliang wrote: > David Holmes wrote: >> On 6/01/2015 9:03 PM, shanliang wrote: >>> David, >>> >>> Here is the new version, I have added the comments as you suggested, and >>> I replaced the variable "sources" with a synchronized list. >> >> Why did you do that ?? Vector is synchronized so it was fine for the job. > You are right! I have changed back to Vector: > http://cr.openjdk.java.net/~sjiang/JDK-8068418/02/ > > I forgot Vetor is synchronized, so long time not use it. :) Thanks - seems okay to me. David > Thanks, > Shanliang >> >> David >> >>> http://cr.openjdk.java.net/~sjiang/JDK-8068418/01/ >>> >>> Thanks for the review. >>> Shanliang >>> >>> David Holmes wrote: >>>> Hi Shanliang, >>>> >>>> On 6/01/2015 3:47 AM, shanliang wrote: >>>>> Hi, >>>>> >>>>> Please review this fix: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8068418 >>>>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068418/00/ >>>>> >>>>> This must be a timing issue in the test, the test called: >>>>> t.join(5000L); to wait a thread's dying, I reproduced the bug by >>>>> insert at line 202: >>>>> try { >>>>> Thread.sleep(5100); >>>>> } catch (Exception ee) {} >>>>> to delay the t's dying. >>>>> >>>>> The fix is to replace: >>>>> t.join(5000L); >>>>> by: >>>>> t.join(); >>>>> >>>>> and replace: >>>>> Object.wait(timeout); >>>>> by >>>>> CountDownLatch.countDown(); >>>> >>>> Okay - you could have just done wait() but the switch to >>>> CountDownLatch is somewhat cleaner. >>>> >>>>> The test harness timeout will be used as the max waiting timeout. >>>> >>>> So the test will now never report that it thinks it has hit a >>>> deadlock, it will just timeout. But you added some extra printout so >>>> okay I guess - but I suggest adding a comment at the top (where @run >>>> etc are) saying that if test times out then deadlock is suspected. >>>> >>>> Minor nit: >>>> >>>> System.out.println("DeadlockTest-addNotificationListener waiting the >>>> XXX thread to die. >>>> >>>> should say "waiting for the XXX thread ..." >>>> >>>> Thanks, >>>> David >>>> >>>>> Shanliang >>> > From shanliang.jiang at oracle.com Thu Jan 8 13:59:59 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 08 Jan 2015 14:59:59 +0100 Subject: jmx-dev RFR 8068591: javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java should be quarantined Message-ID: <54AE8D5F.5070409@oracle.com> Hi, Please review this simple fix: bug: https://bugs.openjdk.java.net/browse/JDK-8068591 webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068591/00/ Thanks, Shanliang From shanliang.jiang at oracle.com Tue Jan 13 09:28:31 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 13 Jan 2015 10:28:31 +0100 Subject: jmx-dev RFR: 8068774 CounterMonitorDeadlockTest.java timed out Message-ID: <54B4E53F.3020302@oracle.com> Hi Please review this test bug fix Bug: https://bugs.openjdk.java.net/browse/JDK-8068774 Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068774/00/ The problem must be here: 98 monitorProxy.start(); 99 100 final int initGetCount = observedProxy.getGetCount(); The test calls initGetCount after starting the monitor, but the test case 1 is: "Remove monitored MBean within monitored getAttribute" that means if the monitor calls getAttribute before the test calls observedProxy.getGetCount(), then no more getAttribute will happen and the return of observedProxy.getGetCount() will not be changed any more. This is why the test is timeout. I reproduced the bug by inserting at line 99: Thread.sleep(1000); Thanks, Shanliang From jaroslav.bachorik at oracle.com Tue Jan 13 11:21:24 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 13 Jan 2015 12:21:24 +0100 Subject: jmx-dev RFR: 8068774 CounterMonitorDeadlockTest.java timed out In-Reply-To: <54B4E53F.3020302@oracle.com> References: <54B4E53F.3020302@oracle.com> Message-ID: <54B4FFB4.9050303@oracle.com> Looks good! Just don't forget to add "noreg-self" label to the issue. -JB- On 13.1.2015 10:28, shanliang wrote: > Hi > > Please review this test bug fix > > Bug: https://bugs.openjdk.java.net/browse/JDK-8068774 > Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068774/00/ > > > The problem must be here: > 98 monitorProxy.start(); > 99 > 100 final int initGetCount = observedProxy.getGetCount(); > > The test calls initGetCount after starting the monitor, but the test > case 1 is: > "Remove monitored MBean within monitored getAttribute" > > that means if the monitor calls getAttribute before the test calls > observedProxy.getGetCount(), then no more getAttribute will happen and > the return of observedProxy.getGetCount() will not be changed any more. > This is why the test is timeout. > > I reproduced the bug by inserting at line 99: > Thread.sleep(1000); > > Thanks, > Shanliang From daniel.fuchs at oracle.com Tue Jan 13 11:30:41 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 13 Jan 2015 12:30:41 +0100 Subject: jmx-dev RFR: 8068774 CounterMonitorDeadlockTest.java timed out In-Reply-To: <54B4E53F.3020302@oracle.com> References: <54B4E53F.3020302@oracle.com> Message-ID: <54B501E1.2010702@oracle.com> On 13/01/15 10:28, shanliang wrote: > Hi > > Please review this test bug fix > > Bug: https://bugs.openjdk.java.net/browse/JDK-8068774 > Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068774/00/ Looks good Shanliang! best regards, -- daniel > > > The problem must be here: > 98 monitorProxy.start(); > 99 > 100 final int initGetCount = observedProxy.getGetCount(); > > The test calls initGetCount after starting the monitor, but the test > case 1 is: > "Remove monitored MBean within monitored getAttribute" > > that means if the monitor calls getAttribute before the test calls > observedProxy.getGetCount(), then no more getAttribute will happen and > the return of observedProxy.getGetCount() will not be changed any more. > This is why the test is timeout. > > I reproduced the bug by inserting at line 99: > Thread.sleep(1000); > > Thanks, > Shanliang From stevenschlansker at gmail.com Fri Jan 16 19:33:44 2015 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Fri, 16 Jan 2015 11:33:44 -0800 Subject: jmx-dev Include JMXMP protocol in Java 9 by default? Message-ID: Hi jmx-dev, hopefully this is the right mailing list for this :) JMX is a great technology for adding management capabilities to your Java apps. We use it extensively to monitor and control our running applications. However, the default RMI connector doesn?t play nicely with a lot of new networking technologies. Anything from firewalls to NAT to running inside of a Linux (or Docker) container makes RMI?s requirement of opening a random port extremely onerous. It is possible to get the default RMI connector to use fixed ports, but it?s not easy at all. Luckily, there?s the JMXMP connector! It?s nicer in almost every way - uses a single port, you can specify a fixed port to listen on in the connector server URI, etc. The only downside is that you need jmxremote_optional.jar included on your classpath. This is even more inconvenient once you realize that you have to do the same to every installation of jconsole and visualvm for every developer that wants to connect to a JMXMP enabled service. There?s a number of articles pointing this out on the internet at large, but seemingly most Java devs still don?t know about it - presumably because it?s not installed by default. Is there any possibility of promoting the JMXMP connector out of jmxremote_optional into the base JDK, perhaps in time for Java 9? Thanks for considering, Steven From shanliang.jiang at oracle.com Tue Jan 27 17:43:06 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 27 Jan 2015 18:43:06 +0100 Subject: jmx-dev RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans Message-ID: <54C7CE2A.1090700@oracle.com> Hi, Please review: bug: https://bugs.openjdk.java.net/browse/JDK-8065213 webrev: http://cr.openjdk.java.net/~sjiang/JDK-8065213/00/ The class PlatformMBeanProvider.java is added to allow different modules to inform ManagementFactory of their Plaform MBeans. In this version we use the ServiceLoader to load these Plaform MBeans, later we will replace the ServiceProvider by jigsaw mechanisms. there are 2 providers in this version: DefaultPlatformMBeanProvider: for all MBeans in the java.lang.management.* (java.management module) com/sun/management/internal/PlatformMBeanProviderImpl: for the MBeans in com.sun.management.* com.sun.management.* (jdk.management module) Thanks, Shanliang From mandy.chung at oracle.com Wed Jan 28 06:46:51 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 27 Jan 2015 22:46:51 -0800 Subject: jmx-dev RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54C7CE2A.1090700@oracle.com> References: <54C7CE2A.1090700@oracle.com> Message-ID: <54C885DB.50304@oracle.com> On 1/27/2015 9:43 AM, shanliang wrote: > Hi, > > Please review: > > bug: https://bugs.openjdk.java.net/browse/JDK-8065213 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8065213/00/ > > The class PlatformMBeanProvider.java is added to allow different > modules to inform ManagementFactory of their Plaform MBeans. In this > version we use the ServiceLoader to load these Plaform MBeans, later > we will replace the ServiceProvider by jigsaw mechanisms. > Thanks for taking on this one. This is the first step toward separating com.sun.management API from java.management module as Java SE module must only export Java SE API per the principles described in JEP 200. This patch separates the standard java.lang.management and JDK-specific MBeans to be provided by two different providers. The next task is to separate the com.sun.management API and its implementation from java.management into a different module (e.g. jdk.management). This will enable java.lang.management to work with and without jdk.management (JDK-specific MBeans) when the module system moves further along. > there are 2 providers in this version: > DefaultPlatformMBeanProvider: for all MBeans in the > java.lang.management.* (java.management module) > com/sun/management/internal/PlatformMBeanProviderImpl: for the > MBeans in com.sun.management.* com.sun.management.* (jdk.management > module) This looks right. The patch looks okay and the ManagementFactory change using service providers is quite clean. Review comments: ManagementFactory.java line 760: would be helpful to add some comments describing that the implementation of this method. You can use MemoryManagerMXBean and GarageCollectorMXBean as the example. Comments for the addProxyNames line 867: it would be more readable if you break this into two statements. List providers = AccessController.doPrivileged(...); providers.stream() .forEachOrdered(...); line 875-886: worths formatting line 885 - instead of creating a HashMap and put entry in the forEach call. You could have do: .collect(toMap(PlatformComponent::getObjectNamePattern, Function.identity()) You could also have the getMap() be called to initialize the componentMap static field (i.e. initialize it in the static initializer rather than lazily so the providers must be loaded anyway. Can you add comments for the PlatformMBeanFinder methods? com/sun/management/internal/PlatformMBeanProviderImpl.java line 43: does this mxbeanList have to be created lazily? Would it be better to make it a final field and create it at the constructor? line 58-59, 66-67, 111-112, 118-119: nit formatting java/lang/management/DefaultPlatformMBeanProvider.java line 42: should this mxbeanList be a final field? you can replace java.lang.management.MemoryManagerMXBean.class with MemoryManagerMXBean.class as it's in the same package. Same apply to other java.lang.management classes. Some formatting nit like mentioned above. Thanks Mandy From daniel.fuchs at oracle.com Wed Jan 28 10:44:35 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 28 Jan 2015 11:44:35 +0100 Subject: jmx-dev RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54C7CE2A.1090700@oracle.com> References: <54C7CE2A.1090700@oracle.com> Message-ID: <54C8BD93.8090605@oracle.com> Hi Shanliang, This looks good. ManagementFactory.java: line 871: there's a stray debug trace that you probably forgot to remove: 871 System.out.println("\n\n===== jsl adding: "+provider); lines 877-885: I believe it would improved readability if the content of the forEachOrdered statement was factored out in a private static method. Something like: .forEachOrdered(provider -> addToComponentMap(componentMap, provider)) private static void addToComponentMap( Map> cmpMap, PlatformMBeanProvider provider) { provider.getPlatformComponentList().stream() .collect(toMap(p -> p.getObjectNamePattern(), p -> p, (p1, p2) -> { throw new InternalError(p1.getObjectNamePattern() + " has been used as key for " + p1 + ", it cannot be reused for " + p2); })) .values() .stream() // put all components into a map, "putIfAbsent" .forEach(p -> cmpMap.putIfAbsent(p.getObjectNamePattern(), p)); } PlatformMBeanProviderImpl.java: 105 * 3 OperatingSystemMXBean Not sure what '3' means here - I suggest to remove it. best regards, -- daniel On 27/01/15 18:43, shanliang wrote: > Hi, > > Please review: > > bug: https://bugs.openjdk.java.net/browse/JDK-8065213 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8065213/00/ > > The class PlatformMBeanProvider.java is added to allow different modules > to inform ManagementFactory of their Plaform MBeans. In this version we > use the ServiceLoader to load these Plaform MBeans, later we will > replace the ServiceProvider by jigsaw mechanisms. > > there are 2 providers in this version: > DefaultPlatformMBeanProvider: for all MBeans in the > java.lang.management.* (java.management module) > com/sun/management/internal/PlatformMBeanProviderImpl: for the > MBeans in com.sun.management.* com.sun.management.* (jdk.management module) > > Thanks, > Shanliang > > > From daniel.fuchs at oracle.com Thu Jan 29 11:07:26 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 29 Jan 2015 12:07:26 +0100 Subject: jmx-dev RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54C885DB.50304@oracle.com> References: <54C7CE2A.1090700@oracle.com> <54C885DB.50304@oracle.com> Message-ID: <54CA146E.5000307@oracle.com> On 28/01/15 07:46, Mandy Chung wrote: > com/sun/management/internal/PlatformMBeanProviderImpl.java > line 43: does this mxbeanList have to be created lazily? > Would it be better to make it a final field and create it at the > constructor? Hi Mandy, I was the one to suggest the lazy initialization. Given that the constructor is going to be invoked by the ServiceLoader, I thought it would be better to delay any heavy initialization until such time that the loaded service provider is actually used. best regards, -- daniel From mandy.chung at oracle.com Thu Jan 29 19:48:31 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 29 Jan 2015 11:48:31 -0800 Subject: jmx-dev RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54CA146E.5000307@oracle.com> References: <54C7CE2A.1090700@oracle.com> <54C885DB.50304@oracle.com> <54CA146E.5000307@oracle.com> Message-ID: <54CA8E8F.8030404@oracle.com> On 1/29/15 3:07 AM, Daniel Fuchs wrote: > On 28/01/15 07:46, Mandy Chung wrote: >> com/sun/management/internal/PlatformMBeanProviderImpl.java >> line 43: does this mxbeanList have to be created lazily? >> Would it be better to make it a final field and create it at the >> constructor? > > Hi Mandy, > > I was the one to suggest the lazy initialization. > Given that the constructor is going to be invoked by the > ServiceLoader, I thought it would be better to delay any > heavy initialization until such time that the loaded > service provider is actually used. > These providers will need to be loaded and the mxbeanList will be looked at except for the cases that we are sure that the MXBean only comes from the default provider. I see the cost of constructing mxbeanList involves loading several classes. If performance is an issue, perhaps the fast-path would be in ManagementFactory to defer loading providers and may be better to follow up the performance side in the second phase (that I expect more changes to sun/management classes) You may want to consider using limited doPrivileged (that can be done in the second phase). Mandy > best regards, > > -- daniel From shanliang.jiang at oracle.com Fri Jan 30 17:38:46 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 30 Jan 2015 18:38:46 +0100 Subject: jmx-dev RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54C885DB.50304@oracle.com> References: <54C7CE2A.1090700@oracle.com> <54C885DB.50304@oracle.com> Message-ID: <54CBC1A6.8090302@oracle.com> Hi, Thanks for all your comments, here is the new version: http://cr.openjdk.java.net/~sjiang/JDK-8065213/01/ Mandy Chung wrote: > ManagementFactory.java > line 760: would be helpful to add some comments describing > that the implementation of this method. You can use > MemoryManagerMXBean and GarageCollectorMXBean as the example. Done. > > Comments for the addProxyNames Changed the method name to getProxyNames and added the comments > > line 867: it would be more readable if you break this into > two statements. > List providers = > AccessController.doPrivileged(...); > providers.stream() > .forEachOrdered(...); Done > line 875-886: worths formatting > > line 885 - instead of creating a HashMap and put entry in the > forEach call. > You could have do: > .collect(toMap(PlatformComponent::getObjectNamePattern, > Function.identity()) Yes, as: .collect(toMap(PlatformComponent::getObjectNamePattern, Function.identity(), (p1, p2) -> p1)); > > You could also have the getMap() be called to initialize the > componentMap > static field (i.e. initialize it in the static initializer rather > than lazily > so the providers must be loaded anyway. componentMap is now initialized statically. > > Can you add comments for the PlatformMBeanFinder methods? Yes done > > com/sun/management/internal/PlatformMBeanProviderImpl.java > line 43: does this mxbeanList have to be created lazily? > Would it be better to make it a final field and create it at the > constructor? Done as final > line 58-59, 66-67, 111-112, 118-119: nit formatting > > java/lang/management/DefaultPlatformMBeanProvider.java > line 42: should this mxbeanList be a final field? Done > you can replace java.lang.management.MemoryManagerMXBean.class > with MemoryManagerMXBean.class as it's in the same package. > Same apply to other java.lang.management classes. Done >>> com/sun/management/internal/PlatformMBeanProviderImpl.java >>> line 43: does this mxbeanList have to be created lazily? >>> Would it be better to make it a final field and create it at the >>> constructor? > > These providers will need to be loaded and the mxbeanList will be > looked at except for the cases that we are sure that the MXBean only > comes from the default provider. I see the cost of constructing > mxbeanList involves loading several classes. If performance is an > issue, perhaps the fast-path would be in ManagementFactory to defer > loading providers and may be better to follow up the performance side > in the second phase (that I expect more changes to sun/management > classes) > > You may want to consider using limited doPrivileged (that can be done > in the second phase). OK, now they are final, I will add doPrivileged in next version. Daniel Fuchs wrote: > ManagementFactory.java: > > line 871: there's a stray debug trace that you probably > forgot to remove: > > 871 System.out.println("\n\n===== jsl adding: "+provider); :) > > > lines 877-885: > > I believe it would improved readability if the content of the > forEachOrdered statement was factored out in a private static > method. Something like: > > .forEachOrdered(provider -> addToComponentMap(componentMap, provider)) > > > private static void addToComponentMap( > Map> cmpMap, > PlatformMBeanProvider provider) { > provider.getPlatformComponentList().stream() > .collect(toMap(p -> p.getObjectNamePattern(), p -> p, > (p1, p2) -> { > throw new InternalError(p1.getObjectNamePattern() > + " has been used as key for " + p1 > + ", it cannot be reused for " + p2); > })) > .values() > .stream() // put all components into a map, "putIfAbsent" > .forEach(p -> > cmpMap.putIfAbsent(p.getObjectNamePattern(), p)); > } You must know that code was changed :) > > PlatformMBeanProviderImpl.java: > > 105 * 3 OperatingSystemMXBean > > Not sure what '3' means here - I suggest to remove it. OK Thanks, Shanliang From mandy.chung at oracle.com Sat Jan 31 01:19:07 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 30 Jan 2015 17:19:07 -0800 Subject: jmx-dev RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54CBC1A6.8090302@oracle.com> References: <54C7CE2A.1090700@oracle.com> <54C885DB.50304@oracle.com> <54CBC1A6.8090302@oracle.com> Message-ID: <54CC2D8B.5080507@oracle.com> On 1/30/2015 9:38 AM, shanliang wrote: > Thanks for all your comments, here is the new version: > http://cr.openjdk.java.net/~sjiang/JDK-8065213/01/ Thank you for the update. Looks fine to me. Minor comment: PlatformMBeanProviderImpl.java line 43: better to rename it as "list" or other name. same as in DefaultPlatformMBeanProvider.java line 54 No need to generate new webrev. Mandy