From kevin.walls at oracle.com Fri Sep 1 08:01:39 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 1 Sep 2017 09:01:39 +0100 Subject: RFR(S): 8186902: jcmd GC.run should not be blocked by DisableExplicitGC In-Reply-To: <21456d53-4ac0-1f3e-0ac9-fd8b6afe4c41@oracle.com> References: <326a22c3-4b44-791f-fced-9281ad86f31d@oracle.com> <5ef0939d-159c-c233-be7c-cca74f6073fb@oracle.com> <21456d53-4ac0-1f3e-0ac9-fd8b6afe4c41@oracle.com> Message-ID: <10f976ad-ad94-5585-6003-22057fb393e9@oracle.com> Thanks Serguei, and Mikael! On 30/08/2017 00:33, serguei.spitsyn at oracle.com wrote: > Hi Kevin, > > It looks good to me. > > Thanks, > Serguei > > > On 8/29/17 04:41, Kevin Walls wrote: >> Hi, >> >> This is a small review request for: >> >> 8186902: jcmd GC.run should not be blocked by DisableExplicitGC >> https://bugs.openjdk.java.net/browse/JDK-8186902 >> >> jcmd GC.run to invoke GC fails if -XX:+DisableExplicitGC is set: this >> seems like a mistake as it is obstructive for a live app that needs a >> GC, and was started with -XX:+DisableExplicitGC. >> >> hg diff pasted below, simply removes the DisableExplicitGC if and >> un-indents the existing call to collect(). >> >> Builds and manually tests OK, GC occurs in response to jcmd GC.run >> even if java was started with -XX:+DisableExplicitGC >> >> Previous email on this: >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021748.html >> >> Many thanks >> Kevin >> >> >> bash-4.2$ cd hotspot >> bash-4.2$ hg diff >> diff -r a20f0fa4c426 src/share/vm/services/diagnosticCommand.cpp >> --- a/src/share/vm/services/diagnosticCommand.cpp?????? Mon Aug 28 >> 23:46:22 2017 +0000 >> +++ b/src/share/vm/services/diagnosticCommand.cpp?????? Tue Aug 29 >> 02:55:56 2017 -0700 >> @@ -414,11 +414,7 @@ >> ?} >> >> ?void SystemGCDCmd::execute(DCmdSource source, TRAPS) { >> -? if (!DisableExplicitGC) { >> -??? Universe::heap()->collect(GCCause::_dcmd_gc_run); >> -? } else { >> -??? output()->print_cr("Explicit GC is disabled, no GC has been >> performed."); >> -? } >> +? Universe::heap()->collect(GCCause::_dcmd_gc_run); >> ?} >> >> ?void RunFinalizationDCmd::execute(DCmdSource source, TRAPS) { >> bash-4.2$ >> >> >> >> >> On 29/08/2017 10:14, Kevin Walls wrote: >>> >>> Hi Mikael, thanks yes, it could be a separate cmd GC.runForce... >>> However I was thinking if you can get as far as having your jcmd >>> executed, you really _do_ want to run that collection.? Whatever >>> behaviour you were protecting against when you chose the >>> command-line arguments, you would only ever want to override if you >>> run the jcmd to invoke GC... 8-) >>> >>> I'll convert this to a review request for removing that check, will >>> post that shortly.? This would be changing the behaviour, but I >>> don't think it contradicts anything we document, and we seem to have >>> added the check without documenting it. >>> >>> Thanks >>> Kevin >>> >>> >>> On 28/08/2017 16:01, Mikael Gerdin wrote: >>>> Hi Kevin, >>>> >>>> On 2017-08-22 16:38, Kevin Walls wrote: >>>>> Hi, >>>>> >>>>> jcmd GC.run to invoke GC fails if -XX:+DisableExplicitGC is set: >>>>> this seems like a mistake? >>>>> >>>>> This behaviour is obstructive for a live app that _needs_ a GC, >>>>> and was started with -XX:+DisableExplicitGC. >>>>> >>>>> DisableExplicitGC to protect from Java code calling System.gc >>>>> frequently makes sense, but if I can attach and run a dcmd, I >>>>> should have permission to inspect and maintain the JVM, including >>>>> invoking a GC. (This is as the user who owns the process and can >>>>> kill it off.) >>>>> >>>>> The behaviour (checking DisableExplicitGC in >>>>> SystemGCDCmd::execute) comes in with: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8004095 >>>>> 8004095: Add support for JMX interface to Diagnostic Framework and >>>>> Commands >>>>> >>>>> The JMX relation I suppose suggests we didn't want JMX to override >>>>> DisableExplicitGC by way of using a jcmd/DCmd. >>>>> >>>>> But also, we now have: >>>>> 8072913: [REDO] GCCause should distinguish jcmd GC.run from >>>>> System.gc() >>>>> Summary: GCCause which is caused by GC.run diagnostic command >>>>> should be different from System.gc() . >>>>> >>>>> ..at least the causes are distinct. >>>>> >>>>> I don't think we document this clearly.? Our comment in >>>>> globals.hpp is ""Ignore calls to System.gc()".? I don't think we >>>>> say anywhere that jcmd is subject to being disabled by the flag. >>>>> >>>>> Interested to hear any reason in favour of the current behaviour!? >>>>> If there's nothing, I'll log a bug and ask for review of the >>>>> change to remove it... >>>> >>>> There were some discussions earlier around this area and I came up >>>> with the idea of having a "force" option to the GC.run command to >>>> override DisableExplicitGC. >>>> The comments in globals.hpp are a notoriously bad spec for the >>>> flags since they are only ever present in debug builds of the JVM. >>>> >>>> Thanks >>>> /Mikael >>>> >>>>> >>>>> Thanks >>>>> Kevin >>>>> >>>>> >>>>> >>> >> > From serguei.spitsyn at oracle.com Sat Sep 2 08:30:10 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sat, 2 Sep 2017 01:30:10 -0700 Subject: RFR(S) 8177901: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface Message-ID: An HTML attachment was scrubbed... URL: From shafi.s.ahmad at oracle.com Mon Sep 4 10:11:00 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Mon, 4 Sep 2017 03:11:00 -0700 (PDT) Subject: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code Message-ID: <131072bd-7d03-4f79-8ca0-6c26f9bbe315@default> Hi, Please review the fix for 'JDK-8170299: Debugger does not stop inside the low memory notifications code' to jdk10. With the current implementation 'debugger does not stop inside the low memory *notifications* code' This is expected as the notification code is getting executed with the service thread, which is a hidden thread. jdk10-dev-new$ jdb -Xmx32m MemoryWarningSystem Initializing jdb ... > stop at MemoryWarningSystem$1:25 Deferring breakpoint MemoryWarningSystem$1:25. It will be set after the class is loaded. > run run MemoryWarningSystem Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > . . . > quit Breakpoint not hit. With the attached webrev, jdb stop at breakpoint inside notification code. jdk10-dev-new$ jdb -Xmx64m MemoryWarningSystem Initializing jdb ... > stop at MemoryWarningSystem$1:25 Deferring breakpoint MemoryWarningSystem$1:25. It will be set after the class is loaded. > run run MemoryWarningSystem Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > VM Started: Set deferred breakpoint MemoryWarningSystem$1:25 Breakpoint hit: "thread=Thread-0", MemoryWarningSystem$1.memoryUsageLow(), line=25 bci=0 25 System.out.println("Memory usage low!!!"); Thread-0[1] step > Memory usage low!!! Step completed: "thread=Thread-0", MemoryWarningSystem$1.memoryUsageLow(), line=26 bci=8 26 double percentageUsed = ((double) usedMemory) / maxMemory; Thread-0[1] where [1] MemoryWarningSystem$1.memoryUsageLow (MemoryWarningSystem.java:26) [2] MemoryWarningSystem$2.handleNotification (MemoryWarningSystem.java:48) [3] javax.management.NotificationBroadcasterSupport.handleNotification (NotificationBroadcasterSupport.java:284) [4] javax.management.NotificationBroadcasterSupport$SendNotifJob.run (NotificationBroadcasterSupport.java:361) [5] java.lang.Thread.run (Thread.java:844) Thread-0[1] step > Step completed: "thread=Thread-0", MemoryWarningSystem$1.memoryUsageLow(), line=27 bci=15 27 System.out.println("percentageUsed = " + percentageUsed); Thread-0[1] list 23 mws.addListener(new MemoryWarningSystem.Listener() { 24 public void memoryUsageLow(long usedMemory, long maxMemory) { 25 System.out.println("Memory usage low!!!"); 26 double percentageUsed = ((double) usedMemory) / maxMemory; 27 => System.out.println("percentageUsed = " + percentageUsed); 28 MemoryWarningSystem.setPercentageUsageThreshold(0.8); 29 } 30 }); 31 32 Collection numbers = new LinkedList(); Thread-0[1] In the change, the class 'MemoryImpl' is derived from class 'NotificationBroadcasterSupport' instead of class 'NotificationEmitterSupport' NotificationBroadcastSupport takes an Executor, MemoryImpl constructor call super() with an executor, a visible thread. The method hasListeners() is referenced inside MemoryImpl.java and defined in NotificationEmitterSupport. This method is not present in NotificationBroadcasterSupport so I added it to NotificationBroadcasterSupport. Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8170299 Webrev link: http://cr.openjdk.java.net/~shshahma/8170299/webrev.01/ Testing: jprt -testset core, vm tonga tests nsk.jvmti.testlist, nsk.jdi.testlist, nsk.jdwp.testlist and jtreg tests ./jdk/test/com/sun/jdi/ Please let me know if I missed to test some more test suit[s]. Thanks to Mandy and Poonam for helping me in fixing this. Regards, Shafi -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Tue Sep 5 04:38:20 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 5 Sep 2017 10:08:20 +0530 Subject: JEP review : JDK-8171311 - REST APIs for JMX Message-ID: Hi All, Please review the JEP for REST APIs for JMX : https://bugs.openjdk.java.net/browse/JDK-8171311 The JEP aims at providing RESTful web interfaces to MBeans. Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. Thanks -Harsha From david.holmes at oracle.com Tue Sep 5 04:43:57 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Sep 2017 14:43:57 +1000 Subject: RFR(S) 8177901: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: References: Message-ID: <1405f243-f3f8-613b-2d16-0b9016a782f7@oracle.com> Hi Serguei, This looks good to me. One not below. On 2/09/2017 6:30 PM, serguei.spitsyn at oracle.com wrote: > Please, review a fix for: > https://bugs.openjdk.java.net/browse/JDK-8177901 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177901-jdi-wrong_phase.1 src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c + // Release commandLoop vmDeathLock if necessary + void commandLoop_exitVmDeathLockOnError(void); + commandLoop_exitVmDeathLockOnError(); The declaration should be in the eventHelper.h header file. It looks really odd to declare the function then call it. Thanks, David ----- > > Summary: > > ? The approach to fix this is to introduce a new lock vmDeathLock in > eventHelper.c > ? and use it to sync the commandLoop with the JVMTI event callback > cbVMDeath > ? the same way as it was done for debugLoop_run. > ? (see the fix of: https://bugs.openjdk.java.net/browse/JDK-8134103) > > ? One potential issue with it is that the commandLoop() transitively > uses some helper > ? functions (e.g. from util.c) that use the macro EXIT_ERROR, and so, > can abort. > ? It seems, in such a case the vmDeathLock will remain locked, and so, > ? the cbVMDeath() will block on it causing a deadlock. > ? Note, that these helper functions can be also called from different > contexts/threads > ? (not from the commandLoop thread only). In such contexts the > commandLoop vmDeathLock > ? is not being entered, and so, should not be exited. > > ? To fix this potential issue, new function, > commandLoop_exitVmDeathLockOnError(), > ? is introduced, and it is called from the debugInit_exit(). > The commandLoop_exitVmDeathLockOnError() always checks if current thread is > ? the commandLoop thread and only in such a case unlocks the vmDeathLock. > > Testing: > ? Ran the nsk.jdi, nsk.jdwp and jtreg jdk_jdi for both release and > fastdebug builds. > ? All tests are passed. > > Thanks, > Serguei > From serguei.spitsyn at oracle.com Tue Sep 5 05:23:55 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 4 Sep 2017 22:23:55 -0700 Subject: RFR(S) 8177901: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: <1405f243-f3f8-613b-2d16-0b9016a782f7@oracle.com> References: <1405f243-f3f8-613b-2d16-0b9016a782f7@oracle.com> Message-ID: Hi David, On 9/4/17 21:43, David Holmes wrote: > Hi Serguei, > > This looks good to me. One not below. > > On 2/09/2017 6:30 PM, serguei.spitsyn at oracle.com wrote: >> Please, review a fix for: >> https://bugs.openjdk.java.net/browse/JDK-8177901 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177901-jdi-wrong_phase.1 >> > > src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c > > +???? // Release commandLoop vmDeathLock if necessary > +???? void commandLoop_exitVmDeathLockOnError(void); > +???? commandLoop_exitVmDeathLockOnError(); > > The declaration should be in the eventHelper.h header file. It looks > really odd to declare the function then call it. Ok, I'll move it to the header. Thank you a lot for he review! Serguei > > Thanks, > David > ----- > >> >> Summary: >> >> ?? The approach to fix this is to introduce a new lock vmDeathLock in >> eventHelper.c >> ?? and use it to sync the commandLoop with the JVMTI event callback >> cbVMDeath >> ?? the same way as it was done for debugLoop_run. >> ?? (see the fix of: https://bugs.openjdk.java.net/browse/JDK-8134103) >> >> ?? One potential issue with it is that the commandLoop() transitively >> uses some helper >> ?? functions (e.g. from util.c) that use the macro EXIT_ERROR, and >> so, can abort. >> ?? It seems, in such a case the vmDeathLock will remain locked, and so, >> ?? the cbVMDeath() will block on it causing a deadlock. >> ?? Note, that these helper functions can be also called from >> different contexts/threads >> ?? (not from the commandLoop thread only). In such contexts the >> commandLoop vmDeathLock >> ?? is not being entered, and so, should not be exited. >> >> ?? To fix this potential issue, new function, >> commandLoop_exitVmDeathLockOnError(), >> ?? is introduced, and it is called from the debugInit_exit(). >> The commandLoop_exitVmDeathLockOnError() always checks if current >> thread is >> ?? the commandLoop thread and only in such a case unlocks the >> vmDeathLock. >> >> Testing: >> ?? Ran the nsk.jdi, nsk.jdwp and jtreg jdk_jdi for both release and >> fastdebug builds. >> ?? All tests are passed. >> >> Thanks, >> Serguei >> From daniel.daugherty at oracle.com Tue Sep 5 16:14:50 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 5 Sep 2017 10:14:50 -0600 Subject: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code In-Reply-To: <131072bd-7d03-4f79-8ca0-6c26f9bbe315@default> References: <131072bd-7d03-4f79-8ca0-6c26f9bbe315@default> Message-ID: <563f375f-b814-4544-9f88-5e8b99610324@oracle.com> Seems like you should also run: nsk.monitoring.testlist Dan On 9/4/17 4:11 AM, Shafi Ahmad wrote: > > Hi, > > Please review the fix for ?JDK-8170299: Debugger does not stop inside > the low memory notifications code? to jdk10. > > With the current implementation ?debugger does not stop inside the low > memory *notifications* code? > > This is expected as the notification code is getting executed with the > service thread, which is a hidden thread. > > jdk10-dev-new$ jdb -Xmx32m MemoryWarningSystem > > Initializing jdb ... > > > stop at MemoryWarningSystem$1:25 > > Deferring breakpoint MemoryWarningSystem$1:25. > > It will be set after the class is loaded. > > > run > > run MemoryWarningSystem > > Set uncaught java.lang.Throwable > > Set deferred uncaught java.lang.Throwable > > > > > . . . > > > quit > > Breakpoint not hit. > > With the attached webrev, jdb stop ?at breakpoint inside notification > code. > > jdk10-dev-new$ jdb -Xmx64m MemoryWarningSystem > > Initializing jdb ... > > > stop at MemoryWarningSystem$1:25 > > Deferring breakpoint MemoryWarningSystem$1:25. > > It will be set after the class is loaded. > > > run > > run MemoryWarningSystem > > Set uncaught java.lang.Throwable > > Set deferred uncaught java.lang.Throwable > > > > > VM Started: Set deferred breakpoint MemoryWarningSystem$1:25 > > Breakpoint hit: "thread=Thread-0", > MemoryWarningSystem$1.memoryUsageLow(), line=25 bci=0 > > 25??????????? System.out.println("Memory usage low!!!"); > > Thread-0[1] step > > > Memory usage low!!! > > Step completed: "thread=Thread-0", > MemoryWarningSystem$1.memoryUsageLow(), line=26 bci=8 > > 26??????????? double percentageUsed = ((double) usedMemory) / maxMemory; > > Thread-0[1] where > > ? [1] MemoryWarningSystem$1.memoryUsageLow (MemoryWarningSystem.java:26) > > ? [2] MemoryWarningSystem$2.handleNotification > (MemoryWarningSystem.java:48) > > ? [3] > javax.management.NotificationBroadcasterSupport.handleNotification > (NotificationBroadcasterSupport.java:284) > > ? [4] javax.management.NotificationBroadcasterSupport$SendNotifJob.run > (NotificationBroadcasterSupport.java:361) > > ? [5] java.lang.Thread.run (Thread.java:844) > > Thread-0[1] step > > > > > Step completed: "thread=Thread-0", > MemoryWarningSystem$1.memoryUsageLow(), line=27 bci=15 > > 27 System.out.println("percentageUsed = " + percentageUsed); > > Thread-0[1] list > > 23??????? mws.addListener(new MemoryWarningSystem.Listener() { > > 24????????? public void memoryUsageLow(long usedMemory, long maxMemory) { > > 25??????????? System.out.println("Memory usage low!!!"); > > 26??????????? double percentageUsed = ((double) usedMemory) / maxMemory; > > 27 => System.out.println("percentageUsed = " + percentageUsed); > > 28 MemoryWarningSystem.setPercentageUsageThreshold(0.8); > > 29????????? } > > 30??????? }); > > 31 > > 32??????? Collection numbers = new LinkedList(); > > Thread-0[1] > > In the change, the class ?MemoryImpl? is derived from class > ?NotificationBroadcasterSupport? instead of class > ?NotificationEmitterSupport? > > NotificationBroadcastSupport takes an Executor, MemoryImpl constructor > ?call super() with an executor, ?a visible thread. > > The method hasListeners() is referenced ?inside MemoryImpl.java and > defined in ?NotificationEmitterSupport. > > This method is not present in ?NotificationBroadcasterSupport so I > added it to NotificationBroadcasterSupport. > > Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8170299 > > Webrev link: http://cr.openjdk.java.net/~shshahma/8170299/webrev.01/ > > > Testing: jprt -testset core, vm tonga tests nsk.jvmti.testlist, > nsk.jdi.testlist, nsk.jdwp.testlist and jtreg tests > ./jdk/test/com/sun/jdi/ > > Please let me know if I missed to test some more test suit[s]. > > Thanks to Mandy and Poonam for helping me in fixing this. > > Regards, > > Shafi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.gahlin at oracle.com Tue Sep 5 16:30:49 2017 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 5 Sep 2017 18:30:49 +0200 Subject: JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: Message-ID: <59AED139.4030102@oracle.com> Hi Harsha, Looping in jmx-dev. > byte[], short[], int[], float[], double[] Should long[] be included there as well? > The REST adapter will come with a simple and lightweight JSON parser. Is this an internal parser or will it be exposed as an API? If so, how does it relate to JEP 198: Light-Weight JSON API? http://openjdk.java.net/jeps/198 Will com.sun.net.httpserver.HttpServer be used to serve the requests? Thanks Erik > Hi All, > > Please review the JEP for REST APIs for JMX : > https://bugs.openjdk.java.net/browse/JDK-8171311 > > The JEP aims at providing RESTful web interfaces to MBeans. > > Access to MBeans registered in a MBeanServer running inside a JVM > requires a Java client. Language-agnostic access to MBeans will > require spawning a Java client which can be cumbersome. The proposed > JEP allows MBeans to be accessed in a language/platform-independent, > ubiquitous and seamless manner. > > Thanks > -Harsha > > From shafi.s.ahmad at oracle.com Tue Sep 5 16:44:42 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Tue, 5 Sep 2017 16:44:42 +0000 (UTC) Subject: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code In-Reply-To: <563f375f-b814-4544-9f88-5e8b99610324@oracle.com> References: <131072bd-7d03-4f79-8ca0-6c26f9bbe315@default> <563f375f-b814-4544-9f88-5e8b99610324@oracle.com> Message-ID: <2559A0F3F1C918EE.d7de5b4c-3657-452b-91b0-2166e78f5f46@mail.outlook.com> Thank you Daniel. I will run and update it with the result. Regards, Shafi On Tue, Sep 5, 2017 at 9:44 PM +0530, "Daniel D. Daugherty" wrote: Seems like you should also run: nsk.monitoring.testlist Dan On 9/4/17 4:11 AM, Shafi Ahmad wrote: Hi, ? Please review the fix for ?JDK-8170299: Debugger does not stop inside the low memory notifications code? to jdk10. ? With the current implementation ?debugger does not stop inside the low memory *notifications* code? This is expected as the notification code is getting executed with the service thread, which is a hidden thread. ? jdk10-dev-new$ jdb -Xmx32m MemoryWarningSystem Initializing jdb ... > stop at MemoryWarningSystem$1:25 Deferring breakpoint MemoryWarningSystem$1:25. It will be set after the class is loaded. > run run MemoryWarningSystem Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > . . . > quit ? Breakpoint not hit. ? With the attached webrev, jdb stop ?at breakpoint inside notification code. ? jdk10-dev-new$ jdb -Xmx64m MemoryWarningSystem Initializing jdb ... > stop at MemoryWarningSystem$1:25 Deferring breakpoint MemoryWarningSystem$1:25. It will be set after the class is loaded. > run run MemoryWarningSystem Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > VM Started: Set deferred breakpoint MemoryWarningSystem$1:25 ? Breakpoint hit: "thread=Thread-0", MemoryWarningSystem$1.memoryUsageLow(), line=25 bci=0 25??????????? System.out.println("Memory usage low!!!"); ? Thread-0[1] step > Memory usage low!!! ? Step completed: "thread=Thread-0", MemoryWarningSystem$1.memoryUsageLow(), line=26 bci=8 26??????????? double percentageUsed = ((double) usedMemory) / maxMemory; ? Thread-0[1] where ? [1] MemoryWarningSystem$1.memoryUsageLow (MemoryWarningSystem.java:26) ? [2] MemoryWarningSystem$2.handleNotification (MemoryWarningSystem.java:48) ? [3] javax.management.NotificationBroadcasterSupport.handleNotification (NotificationBroadcasterSupport.java:284) ? [4] javax.management.NotificationBroadcasterSupport$SendNotifJob.run (NotificationBroadcasterSupport.java:361) ? [5] java.lang.Thread.run (Thread.java:844) Thread-0[1] step > Step completed: "thread=Thread-0", MemoryWarningSystem$1.memoryUsageLow(), line=27 bci=15 27??????????? System.out.println("percentageUsed = " + percentageUsed); ? Thread-0[1] list 23??????? mws.addListener(new MemoryWarningSystem.Listener() { 24????????? public void memoryUsageLow(long usedMemory, long maxMemory) { 25??????????? System.out.println("Memory usage low!!!"); 26??????????? double percentageUsed = ((double) usedMemory) / maxMemory; 27 =>???????? System.out.println("percentageUsed = " + percentageUsed); 28??????????? MemoryWarningSystem.setPercentageUsageThreshold(0.8); 29????????? } 30??????? }); 31??? 32??????? Collection numbers = new LinkedList(); Thread-0[1] ? In the change, the class ?MemoryImpl? is derived from class ?NotificationBroadcasterSupport? instead of class ?NotificationEmitterSupport? NotificationBroadcastSupport takes an Executor, MemoryImpl constructor ?call super() with an executor, ?a visible thread. ? The method hasListeners() is referenced ?inside MemoryImpl.java and defined in ?NotificationEmitterSupport. This method is not present in ?NotificationBroadcasterSupport so I added it to NotificationBroadcasterSupport. ? Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8170299 Webrev link: http://cr.openjdk.java.net/~shshahma/8170299/webrev.01/ ? Testing: jprt -testset core, vm tonga tests nsk.jvmti.testlist, nsk.jdi.testlist, nsk.jdwp.testlist and jtreg tests ./jdk/test/com/sun/jdi/ ? Please let me know if I missed to test some more test suit[s]. ? Thanks to Mandy and Poonam for helping me in fixing this. ? Regards, Shafi -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Tue Sep 5 17:06:05 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 5 Sep 2017 11:06:05 -0600 Subject: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code In-Reply-To: <2559A0F3F1C918EE.d7de5b4c-3657-452b-91b0-2166e78f5f46@mail.outlook.com> References: <131072bd-7d03-4f79-8ca0-6c26f9bbe315@default> <563f375f-b814-4544-9f88-5e8b99610324@oracle.com> <2559A0F3F1C918EE.d7de5b4c-3657-452b-91b0-2166e78f5f46@mail.outlook.com> Message-ID: Sorry for the incomplete answer earlier. There are also relevant tests in: ??? jdk/test/java/lang/management ??? jdk/test/com/sun/management ??? jdk/test/sun/management ??? jdk/test/jdk/internal/agent ??? jdk/test/javax/management ??? jdk/test/com/sun/jmx You might want to just run the 'jdk_management' and 'jdk_jmx' test groups... that should also pick up any closed side tests... Dan On 9/5/17 10:44 AM, Shafi Ahmad wrote: > Thank you Daniel. I will run and update it with the result. > > Regards, > Shafi > > > > On Tue, Sep 5, 2017 at 9:44 PM +0530, "Daniel D. Daugherty" > > wrote: > > Seems like you should also run: nsk.monitoring.testlist > > Dan > > > On 9/4/17 4:11 AM, Shafi Ahmad wrote: >> >> Hi, >> >> Please review the fix for ?JDK-8170299: Debugger does not stop >> inside the low memory notifications code? to jdk10. >> >> With the current implementation ?debugger does not stop inside >> the low memory *notifications* code? >> >> This is expected as the notification code is getting executed >> with the service thread, which is a hidden thread. >> >> jdk10-dev-new$ jdb -Xmx32m MemoryWarningSystem >> >> Initializing jdb ... >> >> > stop at MemoryWarningSystem$1:25 >> >> Deferring breakpoint MemoryWarningSystem$1:25. >> >> It will be set after the class is loaded. >> >> > run >> >> run MemoryWarningSystem >> >> Set uncaught java.lang.Throwable >> >> Set deferred uncaught java.lang.Throwable >> >> > >> >> . . . >> >> > quit >> >> Breakpoint not hit. >> >> With the attached webrev, jdb stop ?at breakpoint inside >> notification code. >> >> jdk10-dev-new$ jdb -Xmx64m MemoryWarningSystem >> >> Initializing jdb ... >> >> > stop at MemoryWarningSystem$1:25 >> >> Deferring breakpoint MemoryWarningSystem$1:25. >> >> It will be set after the class is loaded. >> >> > run >> >> run MemoryWarningSystem >> >> Set uncaught java.lang.Throwable >> >> Set deferred uncaught java.lang.Throwable >> >> > >> >> VM Started: Set deferred breakpoint MemoryWarningSystem$1:25 >> >> Breakpoint hit: "thread=Thread-0", >> MemoryWarningSystem$1.memoryUsageLow(), line=25 bci=0 >> >> 25 System.out.println("Memory usage low!!!"); >> >> Thread-0[1] step >> >> > Memory usage low!!! >> >> Step completed: "thread=Thread-0", >> MemoryWarningSystem$1.memoryUsageLow(), line=26 bci=8 >> >> 26??????????? double percentageUsed = ((double) usedMemory) / >> maxMemory; >> >> Thread-0[1] where >> >> ? [1] MemoryWarningSystem$1.memoryUsageLow >> (MemoryWarningSystem.java:26) >> >> ? [2] MemoryWarningSystem$2.handleNotification >> (MemoryWarningSystem.java:48) >> >> ? [3] >> javax.management.NotificationBroadcasterSupport.handleNotification >> (NotificationBroadcasterSupport.java:284) >> >> ? [4] >> javax.management.NotificationBroadcasterSupport$SendNotifJob.run >> (NotificationBroadcasterSupport.java:361) >> >> ? [5] java.lang.Thread.run (Thread.java:844) >> >> Thread-0[1] step >> >> > >> >> Step completed: "thread=Thread-0", >> MemoryWarningSystem$1.memoryUsageLow(), line=27 bci=15 >> >> 27 System.out.println("percentageUsed = " + percentageUsed); >> >> Thread-0[1] list >> >> 23??????? mws.addListener(new MemoryWarningSystem.Listener() { >> >> 24????????? public void memoryUsageLow(long usedMemory, long >> maxMemory) { >> >> 25 System.out.println("Memory usage low!!!"); >> >> 26??????????? double percentageUsed = ((double) usedMemory) / >> maxMemory; >> >> 27 => System.out.println("percentageUsed = " + percentageUsed); >> >> 28 MemoryWarningSystem.setPercentageUsageThreshold(0.8); >> >> 29????????? } >> >> 30??????? }); >> >> 31 >> >> 32??????? Collection numbers = new LinkedList(); >> >> Thread-0[1] >> >> In the change, the class ?MemoryImpl? is derived from class >> ?NotificationBroadcasterSupport? instead of class >> ?NotificationEmitterSupport? >> >> NotificationBroadcastSupport takes an Executor, MemoryImpl >> constructor ?call super() with an executor, ?a visible thread. >> >> The method hasListeners() is referenced ?inside MemoryImpl.java >> and defined in ?NotificationEmitterSupport. >> >> This method is not present in ?NotificationBroadcasterSupport so >> I added it to NotificationBroadcasterSupport. >> >> Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8170299 >> >> Webrev link: >> http://cr.openjdk.java.net/~shshahma/8170299/webrev.01/ >> >> >> Testing: jprt -testset core, vm tonga tests nsk.jvmti.testlist, >> nsk.jdi.testlist, nsk.jdwp.testlist and jtreg tests >> ./jdk/test/com/sun/jdi/ >> >> Please let me know if I missed to test some more test suit[s]. >> >> Thanks to Mandy and Poonam for helping me in fixing this. >> >> Regards, >> >> Shafi >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Sep 5 18:01:44 2017 From: jcbeyler at google.com (JC Beyler) Date: Tue, 5 Sep 2017 11:01:44 -0700 Subject: NotifyFramePop and FramePop events In-Reply-To: References: Message-ID: Hi all, After looking at the code a bit more, I don't see a viable way of really either: - At notification disabling, remove all pop event requests - Enforcing that the current frame at depth is singled out, if you disable and then pop that frame, the event is destroyed with the frame so that a subsequent pop at that depth no longer fires Because of that, I'd recommend just changing the documentation to highlight this, it might look a bit like this: --- old/src/share/vm/prims/jvmti.xml 2017-09-05 10:51:05.850810934 -0700 +++ new/src/share/vm/prims/jvmti.xml 2017-09-05 10:51:05.710811367 -0700 @@ -2907,7 +2907,7 @@ Notify Frame Pop - When the frame that is currently at + When a frame currently at is popped from the stack, generate a event. See the event for details. @@ -2916,6 +2916,12 @@

The specified thread must either be the current thread or the thread must be suspended. +

+ Note: if the notification event is disabled and a frame at + is popped, no event is generated. + After re-enabling the notification event, the registered + is still active and will provoke an + event when a frame at is popped. jvmdi Would someone want to review this and tell me if I should create a webrev for it? Or tell me hell no ;-) Thanks! Jc On Thu, Aug 31, 2017 at 3:15 PM, JC Beyler wrote: > Hi all, > > I was asked to raise a question about NotifyFramePop and FramePop events > and I thought I would just ask it here: > > If we imagine we have a stack frame such as: > > call_depth0 > call_depth1 > call_depth2 > call_depth3 > > And at this third depth, we request a frame pop when leaving depth1 via > the NotifyFramePop call. We would of course assume that when leaving > call_depth1 we get a FramePop event. > > Now imagine that we disable the frame pop event notification in > call_depth2: > call_depth0 > call_depth1 > call_depth2 > SetEventNotificationMode > > (JVMTI_DISABLE, JVMTI_EVENT_FRAME_POP, NULL) > > If the stack now pops back to call_depth0, the frame pop system is not > checked, the FramePop for call_depth1 is not issued either. > > However, imagine now that later down the road, the stack trace has built > itself back up and we enabled the event: > call_depth0 > second_call_depth1 > second_call_depth2 > SetEventNotificationMode > > (JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, NULL) > > Then when leaving second_call_depth1, we seemingly will issue a frame pop > event. > > Here is the qualm: > - It seems counter intuitive and the documentation does not specify/warn > about this; it seems that if you disable the events you should perhaps > clear up the pop requests. > - At least the documentation for NotifyFramePop ( > https://docs.oracle.com/javase/7/docs/platform/jvmti/ > jvmti.html#NotifyFramePop) should be changed since it says: "When the > frame that is currently at depth is popped from the stack" to something > like "When the first frame at the depth is popped from the stack and the > event notification is enabled" > > Therefore the questions are: > > 1) Is this such a corner case, that we do not wish to try to fix the > documentation or the code? > 2) Is this a corner case we do not wish to handle, therefore put a fix in > the documentation to at least warn users of this > 3) Is this a bug that we'd like to fix? > > Thanks for your insight, > Jc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Wed Sep 6 03:39:00 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 6 Sep 2017 09:09:00 +0530 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <59AED139.4030102@oracle.com> References: <59AED139.4030102@oracle.com> Message-ID: <52f0a5e2-1ea1-2443-790f-0c0c4c07a000@oracle.com> Hi Erik, On Tuesday 05 September 2017 10:00 PM, Erik Gahlin wrote: > Hi Harsha, > > Looping in jmx-dev. > > > byte[], short[], int[], float[], double[] > > Should long[] be included there as well? Yes. Thanks. > > > The REST adapter will come with a simple and lightweight JSON parser. > > Is this an internal parser or will it be exposed as an API? It is an internal parser. > > If so, how does it relate to JEP 198: Light-Weight JSON API? > http://openjdk.java.net/jeps/198 It is written from scratch using JavaCC and is not related to above JEP. > > Will com.sun.net.httpserver.HttpServer be used to serve the requests? Yes. > > > Thanks > Erik > >> Hi All, >> >> Please review the JEP for REST APIs for JMX : >> https://bugs.openjdk.java.net/browse/JDK-8171311 >> >> The JEP aims at providing RESTful web interfaces to MBeans. >> >> Access to MBeans registered in a MBeanServer running inside a JVM >> requires a Java client. Language-agnostic access to MBeans will >> require spawning a Java client which can be cumbersome. The proposed >> JEP allows MBeans to be accessed in a language/platform-independent, >> ubiquitous and seamless manner. >> >> Thanks >> -Harsha >> >> > - Harsha From kirk.pepperdine at gmail.com Wed Sep 6 04:51:29 2017 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Wed, 6 Sep 2017 06:51:29 +0200 Subject: JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <59AED139.4030102@oracle.com> References: <59AED139.4030102@oracle.com> Message-ID: Hi, Have you run into this project? https://jolokia.org. Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. Kind regards, Kirk > On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: > > Hi Harsha, > > Looping in jmx-dev. > > > byte[], short[], int[], float[], double[] > > Should long[] be included there as well? > > > The REST adapter will come with a simple and lightweight JSON parser. > > Is this an internal parser or will it be exposed as an API? > > If so, how does it relate to JEP 198: Light-Weight JSON API? > http://openjdk.java.net/jeps/198 > > Will com.sun.net.httpserver.HttpServer be used to serve the requests? > > Thanks > Erik > >> Hi All, >> >> Please review the JEP for REST APIs for JMX : >> https://bugs.openjdk.java.net/browse/JDK-8171311 >> >> The JEP aims at providing RESTful web interfaces to MBeans. >> >> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. >> >> Thanks >> -Harsha >> >> > From harsha.wardhana.b at oracle.com Wed Sep 6 05:03:59 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 6 Sep 2017 10:33:59 +0530 Subject: JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: <59AED139.4030102@oracle.com> Message-ID: Hi Kirk, Yes. Jolokia was considered and is listed as an alternative in the JEP. * Jolokia can serve as a viable alternative but can be bulky. We are looking for simple and lightweight solution. -Harsha On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote: > Hi, > > Have you run into this project? https://jolokia.org. Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. > > Kind regards, > Kirk > >> On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: >> >> Hi Harsha, >> >> Looping in jmx-dev. >> >>> byte[], short[], int[], float[], double[] >> Should long[] be included there as well? >> >>> The REST adapter will come with a simple and lightweight JSON parser. >> Is this an internal parser or will it be exposed as an API? >> >> If so, how does it relate to JEP 198: Light-Weight JSON API? >> http://openjdk.java.net/jeps/198 >> >> Will com.sun.net.httpserver.HttpServer be used to serve the requests? >> >> Thanks >> Erik >> >>> Hi All, >>> >>> Please review the JEP for REST APIs for JMX : >>> https://bugs.openjdk.java.net/browse/JDK-8171311 >>> >>> The JEP aims at providing RESTful web interfaces to MBeans. >>> >>> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. >>> >>> Thanks >>> -Harsha >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Wed Sep 6 05:08:54 2017 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Wed, 6 Sep 2017 07:08:54 +0200 Subject: JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: <59AED139.4030102@oracle.com> Message-ID: Hi Harsha, I wouldn?t consider Jolokia to be an alternative because as I suggested, it?s not a complete JMXConnector implementation and as such cannot be used with standard JMX clients such as the MBean viewer in JMC or VisualVM. In my opinion, it would be super if the product of the JEP could work as a drop-in replacement for the RMI-JMXConnctor that all standard JMX tooling currently uses. Kind regards, Kirk > On Sep 6, 2017, at 7:03 AM, Harsha Wardhana B wrote: > > Hi Kirk, > > Yes. Jolokia was considered and is listed as an alternative in the JEP. > > Jolokia can serve as a viable alternative but can be bulky. We are looking for simple and lightweight solution. > > -Harsha > > On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote: >> Hi, >> >> Have you run into this project? https://jolokia.org . Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. >> >> Kind regards, >> Kirk >> >>> On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: >>> >>> Hi Harsha, >>> >>> Looping in jmx-dev. >>> >>>> byte[], short[], int[], float[], double[] >>> Should long[] be included there as well? >>> >>>> The REST adapter will come with a simple and lightweight JSON parser. >>> Is this an internal parser or will it be exposed as an API? >>> >>> If so, how does it relate to JEP 198: Light-Weight JSON API? >>> http://openjdk.java.net/jeps/198 >>> >>> Will com.sun.net.httpserver.HttpServer be used to serve the requests? >>> >>> Thanks >>> Erik >>> >>>> Hi All, >>>> >>>> Please review the JEP for REST APIs for JMX : >>>> https://bugs.openjdk.java.net/browse/JDK-8171311 >>>> >>>> The JEP aims at providing RESTful web interfaces to MBeans. >>>> >>>> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. >>>> >>>> Thanks >>>> -Harsha >>>> >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Sep 6 06:05:16 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 5 Sep 2017 23:05:16 -0700 Subject: NotifyFramePop and FramePop events In-Reply-To: References: Message-ID: <81ca65ea-feea-2378-83a3-948f9df36893@oracle.com> An HTML attachment was scrubbed... URL: From martin at skarsaune.net Wed Sep 6 06:38:26 2017 From: martin at skarsaune.net (Martin Skarsaune) Date: Wed, 06 Sep 2017 06:38:26 +0000 Subject: Misleading output from jcmd JFR.check Message-ID: Hi If I run *JFR.check* in build 9+181 , the response indicates that I can invoke *VM.unlock_commercial_features*. This command is not available in the given VM. The output should not refer to this command i VM where it is not available. Cheers Martin Skarsaune Example: Martins-MacBook-Pro-2:Downloads marska$ java -version java version "9" Java(TM) SE Runtime Environment (build 9+181) Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) Martins-MacBook-Pro-2:Downloads marska$ /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/jcmd 11700 JFR.check 11700: Java Flight Recorder not enabled. Use VM.unlock_commercial_features to enable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Wed Sep 6 06:46:55 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 6 Sep 2017 12:16:55 +0530 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: <59AED139.4030102@oracle.com> Message-ID: Hi Martin, In my opinion, the interfaces exposed by current JEP are lot closer to REST style than the interfaces exposed by Jolokia. For instance, HTTP GET by default should be used to read resources, but it is made part of URL in Jolokia interfaces. /read/// I would wait on opinions from more people before considering changing the current interfaces. Thanks -Harsha On Wednesday 06 September 2017 11:40 AM, Martin Skarsaune wrote: > Hello > > Would one at least consider adopting the same URL paths and payloads > as Jolokia? This could make life a lot easier for third party tools > that connect to it. > > Best Regards > > Martin Skarsaune > > ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B > >: > > Hi Kirk, > > Yes. Jolokia was considered and is listed as an alternative in the > JEP. > > * Jolokia can serve as a viable alternative but can be bulky. We > are looking for simple and lightweight solution. > > > -Harsha > > On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote: >> Hi, >> >> Have you run into this project?https://jolokia.org. Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. >> >> Kind regards, >> Kirk >> >>> On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: >>> >>> Hi Harsha, >>> >>> Looping in jmx-dev. >>> >>>> byte[], short[], int[], float[], double[] >>> Should long[] be included there as well? >>> >>>> The REST adapter will come with a simple and lightweight JSON parser. >>> Is this an internal parser or will it be exposed as an API? >>> >>> If so, how does it relate to JEP 198: Light-Weight JSON API? >>> http://openjdk.java.net/jeps/198 >>> >>> Will com.sun.net.httpserver.HttpServer be used to serve the requests? >>> >>> Thanks >>> Erik >>> >>>> Hi All, >>>> >>>> Please review the JEP for REST APIs for JMX : >>>> https://bugs.openjdk.java.net/browse/JDK-8171311 >>>> >>>> The JEP aims at providing RESTful web interfaces to MBeans. >>>> >>>> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. >>>> >>>> Thanks >>>> -Harsha >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Sep 6 06:52:52 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Sep 2017 16:52:52 +1000 Subject: Misleading output from jcmd JFR.check In-Reply-To: References: Message-ID: <21055cd1-18ae-e643-dad3-2a084ed2b301@oracle.com> Hi Martin, On 6/09/2017 4:38 PM, Martin Skarsaune wrote: > Hi > > If I run *JFR.check* in build 9+181 , the response indicates that I can > invoke *VM.unlock_commercial_features*. > This command is not available in the given VM. > > The output should not refer to this command i VM where it is not available. > > Cheers > > Martin Skarsaune > > > Example: > > Martins-MacBook-Pro-2:Downloads marska$ java -version > > java version "9" > > Java(TM) SE Runtime Environment (build 9+181) > > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) > > Martins-MacBook-Pro-2:Downloads marska$ > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/jcmd 11700 > JFR.check > > 11700: What JVM is process 11700? What does "jcmd 11700 help" show? Thanks, David ----- > Java Flight Recorder not enabled. > > > Use VM.unlock_commercial_features to enable. > > From martin at skarsaune.net Wed Sep 6 07:00:11 2017 From: martin at skarsaune.net (Martin Skarsaune) Date: Wed, 06 Sep 2017 07:00:11 +0000 Subject: Misleading output from jcmd JFR.check In-Reply-To: <21055cd1-18ae-e643-dad3-2a084ed2b301@oracle.com> References: <21055cd1-18ae-e643-dad3-2a084ed2b301@oracle.com> Message-ID: Hi David Details below. Cheers Martin Martins-MacBook-Pro-2:Downloads marska$ /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/*jcmd 11700 VM.command_line* 11700: VM Arguments: java_command: hawtio-app-1.5.3.jar java_class_path (initial): hawtio-app-1.5.3.jar Launcher Type: SUN_STANDARD Martins-MacBook-Pro-2:Downloads marska$ /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/*jcmd 11700 help* 11700: The following commands are available: JFR.configure JFR.stop JFR.start JFR.dump JFR.check VM.log VM.native_memory ManagementAgent.status ManagementAgent.stop ManagementAgent.start_local ManagementAgent.start Compiler.directives_clear Compiler.directives_remove Compiler.directives_add Compiler.directives_print VM.print_touched_methods Compiler.codecache Compiler.codelist Compiler.queue VM.classloader_stats Thread.print JVMTI.data_dump JVMTI.agent_load VM.stringtable VM.symboltable VM.class_hierarchy GC.class_stats GC.class_histogram GC.heap_dump GC.finalizer_info GC.heap_info GC.run_finalization GC.run VM.info VM.uptime VM.dynlibs VM.set_flag VM.flags VM.system_properties VM.command_line VM.version help For more information about a specific command use 'help '. Martins-MacBook-Pro-2:Downloads marska$ ons. 6. sep. 2017 kl. 08:53 skrev David Holmes : > Hi Martin, > > On 6/09/2017 4:38 PM, Martin Skarsaune wrote: > > Hi > > > > If I run *JFR.check* in build 9+181 , the response indicates that I can > > invoke *VM.unlock_commercial_features*. > > This command is not available in the given VM. > > > > The output should not refer to this command i VM where it is not > available. > > > > Cheers > > > > Martin Skarsaune > > > > > > Example: > > > > Martins-MacBook-Pro-2:Downloads marska$ java -version > > > > java version "9" > > > > Java(TM) SE Runtime Environment (build 9+181) > > > > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) > > > > Martins-MacBook-Pro-2:Downloads marska$ > > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/jcmd 11700 > > JFR.check > > > > 11700: > > What JVM is process 11700? What does "jcmd 11700 help" show? > > Thanks, > David > ----- > > > Java Flight Recorder not enabled. > > > > > > Use VM.unlock_commercial_features to enable. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Sep 6 07:10:17 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Sep 2017 17:10:17 +1000 Subject: Misleading output from jcmd JFR.check In-Reply-To: References: <21055cd1-18ae-e643-dad3-2a084ed2b301@oracle.com> Message-ID: <1177eb76-2aa1-bbc9-da89-7bb8a8501c93@oracle.com> Hi Martin, On 6/09/2017 5:00 PM, Martin Skarsaune wrote: > Hi David > > Details below. What does "java -version" show for that JVM please. Thanks, David > Cheers > > Martin > > Martins-MacBook-Pro-2:Downloads marska$ > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/*jcmd > 11700 VM.command_line* > > 11700: > > VM Arguments: > > java_command: hawtio-app-1.5.3.jar > > java_class_path (initial): hawtio-app-1.5.3.jar > > Launcher Type: SUN_STANDARD > > Martins-MacBook-Pro-2:Downloads marska$ > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/*jcmd > 11700 help* > > 11700: > > The following commands are available: > > JFR.configure > > JFR.stop > > JFR.start > > JFR.dump > > JFR.check > > VM.log > > VM.native_memory > > ManagementAgent.status > > ManagementAgent.stop > > ManagementAgent.start_local > > ManagementAgent.start > > Compiler.directives_clear > > Compiler.directives_remove > > Compiler.directives_add > > Compiler.directives_print > > VM.print_touched_methods > > Compiler.codecache > > Compiler.codelist > > Compiler.queue > > VM.classloader_stats > > Thread.print > > JVMTI.data_dump > > JVMTI.agent_load > > VM.stringtable > > VM.symboltable > > VM.class_hierarchy > > GC.class_stats > > GC.class_histogram > > GC.heap_dump > > GC.finalizer_info > > GC.heap_info > > GC.run_finalization > > GC.run > > VM.info > > VM.uptime > > VM.dynlibs > > VM.set_flag > > VM.flags > > VM.system_properties > > VM.command_line > > VM.version > > help > > > For more information about a specific command use 'help '. > > Martins-MacBook-Pro-2:Downloads marska$ > > > ons. 6. sep. 2017 kl. 08:53 skrev David Holmes >: > > Hi Martin, > > On 6/09/2017 4:38 PM, Martin Skarsaune wrote: > > Hi > > > > If I run *JFR.check* in build 9+181 , the response indicates that > I can > > invoke *VM.unlock_commercial_features*. > > This command is not available in the given VM. > > > > The output should not refer to this command i VM where it is not > available. > > > > Cheers > > > > Martin Skarsaune > > > > > > Example: > > > > Martins-MacBook-Pro-2:Downloads marska$ java -version > > > > java version "9" > > > > Java(TM) SE Runtime Environment (build 9+181) > > > > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) > > > > Martins-MacBook-Pro-2:Downloads marska$ > > > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/jcmd 11700 > > JFR.check > > > > 11700: > > What JVM is process 11700? What does "jcmd 11700 help" show? > > Thanks, > David > ----- > > > Java Flight Recorder not enabled. > > > > > > Use VM.unlock_commercial_features to enable. > > > > > From martin at skarsaune.net Wed Sep 6 07:13:29 2017 From: martin at skarsaune.net (Martin Skarsaune) Date: Wed, 06 Sep 2017 07:13:29 +0000 Subject: Misleading output from jcmd JFR.check In-Reply-To: <1177eb76-2aa1-bbc9-da89-7bb8a8501c93@oracle.com> References: <21055cd1-18ae-e643-dad3-2a084ed2b301@oracle.com> <1177eb76-2aa1-bbc9-da89-7bb8a8501c93@oracle.com> Message-ID: Martins-MacBook-Pro-2:Downloads marska$ java -version java version "9" Java(TM) SE Runtime Environment (build 9+181) Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) Also included in the first message ;-) ons. 6. sep. 2017 kl. 09:10 skrev David Holmes : > Hi Martin, > > On 6/09/2017 5:00 PM, Martin Skarsaune wrote: > > Hi David > > > > Details below. > > What does "java -version" show for that JVM please. > > Thanks, > David > > > Cheers > > > > Martin > > > > Martins-MacBook-Pro-2:Downloads marska$ > > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/*jcmd > > 11700 VM.command_line* > > > > 11700: > > > > VM Arguments: > > > > java_command: hawtio-app-1.5.3.jar > > > > java_class_path (initial): hawtio-app-1.5.3.jar > > > > Launcher Type: SUN_STANDARD > > > > Martins-MacBook-Pro-2:Downloads marska$ > > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/*jcmd > > 11700 help* > > > > 11700: > > > > The following commands are available: > > > > JFR.configure > > > > JFR.stop > > > > JFR.start > > > > JFR.dump > > > > JFR.check > > > > VM.log > > > > VM.native_memory > > > > ManagementAgent.status > > > > ManagementAgent.stop > > > > ManagementAgent.start_local > > > > ManagementAgent.start > > > > Compiler.directives_clear > > > > Compiler.directives_remove > > > > Compiler.directives_add > > > > Compiler.directives_print > > > > VM.print_touched_methods > > > > Compiler.codecache > > > > Compiler.codelist > > > > Compiler.queue > > > > VM.classloader_stats > > > > Thread.print > > > > JVMTI.data_dump > > > > JVMTI.agent_load > > > > VM.stringtable > > > > VM.symboltable > > > > VM.class_hierarchy > > > > GC.class_stats > > > > GC.class_histogram > > > > GC.heap_dump > > > > GC.finalizer_info > > > > GC.heap_info > > > > GC.run_finalization > > > > GC.run > > > > VM.info > > > > VM.uptime > > > > VM.dynlibs > > > > VM.set_flag > > > > VM.flags > > > > VM.system_properties > > > > VM.command_line > > > > VM.version > > > > help > > > > > > For more information about a specific command use 'help '. > > > > Martins-MacBook-Pro-2:Downloads marska$ > > > > > > ons. 6. sep. 2017 kl. 08:53 skrev David Holmes > >: > > > > Hi Martin, > > > > On 6/09/2017 4:38 PM, Martin Skarsaune wrote: > > > Hi > > > > > > If I run *JFR.check* in build 9+181 , the response indicates that > > I can > > > invoke *VM.unlock_commercial_features*. > > > This command is not available in the given VM. > > > > > > The output should not refer to this command i VM where it is not > > available. > > > > > > Cheers > > > > > > Martin Skarsaune > > > > > > > > > Example: > > > > > > Martins-MacBook-Pro-2:Downloads marska$ java -version > > > > > > java version "9" > > > > > > Java(TM) SE Runtime Environment (build 9+181) > > > > > > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) > > > > > > Martins-MacBook-Pro-2:Downloads marska$ > > > > > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/jcmd > 11700 > > > JFR.check > > > > > > 11700: > > > > What JVM is process 11700? What does "jcmd 11700 help" show? > > > > Thanks, > > David > > ----- > > > > > Java Flight Recorder not enabled. > > > > > > > > > Use VM.unlock_commercial_features to enable. > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Sep 6 07:14:58 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Sep 2017 17:14:58 +1000 Subject: Misleading output from jcmd JFR.check In-Reply-To: References: <21055cd1-18ae-e643-dad3-2a084ed2b301@oracle.com> <1177eb76-2aa1-bbc9-da89-7bb8a8501c93@oracle.com> Message-ID: <1f8b64bc-e00b-fba8-7a69-27d162c19c47@oracle.com> On 6/09/2017 5:13 PM, Martin Skarsaune wrote: > Martins-MacBook-Pro-2:Downloads marska$ java -version > > java version "9" > > Java(TM) SE Runtime Environment (build 9+181) > > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) > > > Also included in the first message ;-) It wasn't clear that process 11700 was running the exact same JVM. Thanks, David > > ons. 6. sep. 2017 kl. 09:10 skrev David Holmes >: > > Hi Martin, > > On 6/09/2017 5:00 PM, Martin Skarsaune wrote: > > Hi David > > > > Details below. > > What does "java -version" show for that JVM please. > > Thanks, > David > > > Cheers > > > > Martin > > > > Martins-MacBook-Pro-2:Downloads marska$ > > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/*jcmd > > 11700 VM.command_line* > > > > 11700: > > > > VM Arguments: > > > > java_command: hawtio-app-1.5.3.jar > > > > java_class_path (initial): hawtio-app-1.5.3.jar > > > > Launcher Type: SUN_STANDARD > > > > Martins-MacBook-Pro-2:Downloads marska$ > > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/*jcmd > > 11700 help* > > > > 11700: > > > > The following commands are available: > > > > JFR.configure > > > > JFR.stop > > > > JFR.start > > > > JFR.dump > > > > JFR.check > > > > VM.log > > > > VM.native_memory > > > > ManagementAgent.status > > > > ManagementAgent.stop > > > > ManagementAgent.start_local > > > > ManagementAgent.start > > > > Compiler.directives_clear > > > > Compiler.directives_remove > > > > Compiler.directives_add > > > > Compiler.directives_print > > > > VM.print_touched_methods > > > > Compiler.codecache > > > > Compiler.codelist > > > > Compiler.queue > > > > VM.classloader_stats > > > > Thread.print > > > > JVMTI.data_dump > > > > JVMTI.agent_load > > > > VM.stringtable > > > > VM.symboltable > > > > VM.class_hierarchy > > > > GC.class_stats > > > > GC.class_histogram > > > > GC.heap_dump > > > > GC.finalizer_info > > > > GC.heap_info > > > > GC.run_finalization > > > > GC.run > > > > VM.info > > > > VM.uptime > > > > VM.dynlibs > > > > VM.set_flag > > > > VM.flags > > > > VM.system_properties > > > > VM.command_line > > > > VM.version > > > > help > > > > > > For more information about a specific command use 'help '. > > > > Martins-MacBook-Pro-2:Downloads marska$ > > > > > > ons. 6. sep. 2017 kl. 08:53 skrev David Holmes > > > >>: > > > >? ? ?Hi Martin, > > > >? ? ?On 6/09/2017 4:38 PM, Martin Skarsaune wrote: > >? ? ? > Hi > >? ? ? > > >? ? ? > If I run *JFR.check* in build 9+181 , the response > indicates that > >? ? ?I can > >? ? ? > invoke *VM.unlock_commercial_features*. > >? ? ? > This command is not available in the given VM. > >? ? ? > > >? ? ? > The output should not refer to this command i VM where it > is not > >? ? ?available. > >? ? ? > > >? ? ? > Cheers > >? ? ? > > >? ? ? > Martin Skarsaune > >? ? ? > > >? ? ? > > >? ? ? > Example: > >? ? ? > > >? ? ? > Martins-MacBook-Pro-2:Downloads marska$ java -version > >? ? ? > > >? ? ? > java version "9" > >? ? ? > > >? ? ? > Java(TM) SE Runtime Environment (build 9+181) > >? ? ? > > >? ? ? > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) > >? ? ? > > >? ? ? > Martins-MacBook-Pro-2:Downloads marska$ > >? ? ? > > > > ?/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/jcmd > 11700 > >? ? ? > JFR.check > >? ? ? > > >? ? ? > 11700: > > > >? ? ?What JVM is process 11700? What does "jcmd 11700 help" show? > > > >? ? ?Thanks, > >? ? ?David > >? ? ?----- > > > >? ? ? > Java Flight Recorder not enabled. > >? ? ? > > >? ? ? > > >? ? ? > Use VM.unlock_commercial_features to enable. > >? ? ? > > >? ? ? > > > > From david.holmes at oracle.com Wed Sep 6 07:36:07 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Sep 2017 17:36:07 +1000 Subject: Misleading output from jcmd JFR.check In-Reply-To: <1f8b64bc-e00b-fba8-7a69-27d162c19c47@oracle.com> References: <21055cd1-18ae-e643-dad3-2a084ed2b301@oracle.com> <1177eb76-2aa1-bbc9-da89-7bb8a8501c93@oracle.com> <1f8b64bc-e00b-fba8-7a69-27d162c19c47@oracle.com> Message-ID: Hi Martin, I think this is just a peculiarity of the Java 9 early access builds. Those builds don't include any commercial features - which includes the Dcmds to check or enable commercial features. However the JFR Dcmds are still listed as available, but of course inoperative as they are commercial features and need to be enabled. The help information isn't aware that early-access builds don't have commercial features so it helpfully tells you how you would normally enable JFR. This will soon be moot as Java 9 is released. Also note, as per the download page: http://jdk.java.net/9/ issues pertaining to the EA builds should be reported at https://community.oracle.com/community/java/java_desktop/java-se-early-access. Those builds are not part of the OpenJDK and so issues pertaining to them should not be raised on OpenJDK mailing lists. Thanks, David ----- On 6/09/2017 5:14 PM, David Holmes wrote: > On 6/09/2017 5:13 PM, Martin Skarsaune wrote: >> Martins-MacBook-Pro-2:Downloads marska$ java -version >> >> java version "9" >> >> Java(TM) SE Runtime Environment (build 9+181) >> >> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) >> >> >> Also included in the first message ;-) > > It wasn't clear that process 11700 was running the exact same JVM. > > Thanks, > David > >> >> ons. 6. sep. 2017 kl. 09:10 skrev David Holmes >> >: >> >> ??? Hi Martin, >> >> ??? On 6/09/2017 5:00 PM, Martin Skarsaune wrote: >> ???? > Hi David >> ???? > >> ???? > Details below. >> >> ??? What does "java -version" show for that JVM please. >> >> ??? Thanks, >> ??? David >> >> ???? > Cheers >> ???? > >> ???? > Martin >> ???? > >> ???? > Martins-MacBook-Pro-2:Downloads marska$ >> ???? > >> /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/*jcmd >> ???? > 11700 VM.command_line* >> ???? > >> ???? > 11700: >> ???? > >> ???? > VM Arguments: >> ???? > >> ???? > java_command: hawtio-app-1.5.3.jar >> ???? > >> ???? > java_class_path (initial): hawtio-app-1.5.3.jar >> ???? > >> ???? > Launcher Type: SUN_STANDARD >> ???? > >> ???? > Martins-MacBook-Pro-2:Downloads marska$ >> ???? > >> /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/*jcmd >> ???? > 11700 help* >> ???? > >> ???? > 11700: >> ???? > >> ???? > The following commands are available: >> ???? > >> ???? > JFR.configure >> ???? > >> ???? > JFR.stop >> ???? > >> ???? > JFR.start >> ???? > >> ???? > JFR.dump >> ???? > >> ???? > JFR.check >> ???? > >> ???? > VM.log >> ???? > >> ???? > VM.native_memory >> ???? > >> ???? > ManagementAgent.status >> ???? > >> ???? > ManagementAgent.stop >> ???? > >> ???? > ManagementAgent.start_local >> ???? > >> ???? > ManagementAgent.start >> ???? > >> ???? > Compiler.directives_clear >> ???? > >> ???? > Compiler.directives_remove >> ???? > >> ???? > Compiler.directives_add >> ???? > >> ???? > Compiler.directives_print >> ???? > >> ???? > VM.print_touched_methods >> ???? > >> ???? > Compiler.codecache >> ???? > >> ???? > Compiler.codelist >> ???? > >> ???? > Compiler.queue >> ???? > >> ???? > VM.classloader_stats >> ???? > >> ???? > Thread.print >> ???? > >> ???? > JVMTI.data_dump >> ???? > >> ???? > JVMTI.agent_load >> ???? > >> ???? > VM.stringtable >> ???? > >> ???? > VM.symboltable >> ???? > >> ???? > VM.class_hierarchy >> ???? > >> ???? > GC.class_stats >> ???? > >> ???? > GC.class_histogram >> ???? > >> ???? > GC.heap_dump >> ???? > >> ???? > GC.finalizer_info >> ???? > >> ???? > GC.heap_info >> ???? > >> ???? > GC.run_finalization >> ???? > >> ???? > GC.run >> ???? > >> ???? > VM.info >> ???? > >> ???? > VM.uptime >> ???? > >> ???? > VM.dynlibs >> ???? > >> ???? > VM.set_flag >> ???? > >> ???? > VM.flags >> ???? > >> ???? > VM.system_properties >> ???? > >> ???? > VM.command_line >> ???? > >> ???? > VM.version >> ???? > >> ???? > help >> ???? > >> ???? > >> ???? > For more information about a specific command use 'help >> '. >> ???? > >> ???? > Martins-MacBook-Pro-2:Downloads marska$ >> ???? > >> ???? > >> ???? > ons. 6. sep. 2017 kl. 08:53 skrev David Holmes >> ??? >> ???? > > >>: >> ???? > >> ???? >? ? ?Hi Martin, >> ???? > >> ???? >? ? ?On 6/09/2017 4:38 PM, Martin Skarsaune wrote: >> ???? >? ? ? > Hi >> ???? >? ? ? > >> ???? >? ? ? > If I run *JFR.check* in build 9+181 , the response >> ??? indicates that >> ???? >? ? ?I can >> ???? >? ? ? > invoke *VM.unlock_commercial_features*. >> ???? >? ? ? > This command is not available in the given VM. >> ???? >? ? ? > >> ???? >? ? ? > The output should not refer to this command i VM where it >> ??? is not >> ???? >? ? ?available. >> ???? >? ? ? > >> ???? >? ? ? > Cheers >> ???? >? ? ? > >> ???? >? ? ? > Martin Skarsaune >> ???? >? ? ? > >> ???? >? ? ? > >> ???? >? ? ? > Example: >> ???? >? ? ? > >> ???? >? ? ? > Martins-MacBook-Pro-2:Downloads marska$ java -version >> ???? >? ? ? > >> ???? >? ? ? > java version "9" >> ???? >? ? ? > >> ???? >? ? ? > Java(TM) SE Runtime Environment (build 9+181) >> ???? >? ? ? > >> ???? >? ? ? > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) >> ???? >? ? ? > >> ???? >? ? ? > Martins-MacBook-Pro-2:Downloads marska$ >> ???? >? ? ? > >> ???? > >> ?/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/jcmd >> ??? 11700 >> ???? >? ? ? > JFR.check >> ???? >? ? ? > >> ???? >? ? ? > 11700: >> ???? > >> ???? >? ? ?What JVM is process 11700? What does "jcmd 11700 help" show? >> ???? > >> ???? >? ? ?Thanks, >> ???? >? ? ?David >> ???? >? ? ?----- >> ???? > >> ???? >? ? ? > Java Flight Recorder not enabled. >> ???? >? ? ? > >> ???? >? ? ? > >> ???? >? ? ? > Use VM.unlock_commercial_features to enable. >> ???? >? ? ? > >> ???? >? ? ? > >> ???? > >> From martin at skarsaune.net Wed Sep 6 07:38:03 2017 From: martin at skarsaune.net (Martin Skarsaune) Date: Wed, 06 Sep 2017 07:38:03 +0000 Subject: Misleading output from jcmd JFR.check In-Reply-To: <1f8b64bc-e00b-fba8-7a69-27d162c19c47@oracle.com> References: <21055cd1-18ae-e643-dad3-2a084ed2b301@oracle.com> <1177eb76-2aa1-bbc9-da89-7bb8a8501c93@oracle.com> <1f8b64bc-e00b-fba8-7a69-27d162c19c47@oracle.com> Message-ID: Ah, good point. I think it should be pretty straightforward to reproduce. I don't think it makes much difference what java application runs, but if you want to run the exact same application, you can get it here : https://oss.sonatype.org/content/repositories/public/io/hawt/hawtio-app/1.5.3/hawtio-app-1.5.3.jar Martin ons. 6. sep. 2017 kl. 09:15 skrev David Holmes : > On 6/09/2017 5:13 PM, Martin Skarsaune wrote: > > Martins-MacBook-Pro-2:Downloads marska$ java -version > > > > java version "9" > > > > Java(TM) SE Runtime Environment (build 9+181) > > > > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) > > > > > > Also included in the first message ;-) > > It wasn't clear that process 11700 was running the exact same JVM. > > Thanks, > David > > > > > ons. 6. sep. 2017 kl. 09:10 skrev David Holmes > >: > > > > Hi Martin, > > > > On 6/09/2017 5:00 PM, Martin Skarsaune wrote: > > > Hi David > > > > > > Details below. > > > > What does "java -version" show for that JVM please. > > > > Thanks, > > David > > > > > Cheers > > > > > > Martin > > > > > > Martins-MacBook-Pro-2:Downloads marska$ > > > > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/*jcmd > > > 11700 VM.command_line* > > > > > > 11700: > > > > > > VM Arguments: > > > > > > java_command: hawtio-app-1.5.3.jar > > > > > > java_class_path (initial): hawtio-app-1.5.3.jar > > > > > > Launcher Type: SUN_STANDARD > > > > > > Martins-MacBook-Pro-2:Downloads marska$ > > > > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/*jcmd > > > 11700 help* > > > > > > 11700: > > > > > > The following commands are available: > > > > > > JFR.configure > > > > > > JFR.stop > > > > > > JFR.start > > > > > > JFR.dump > > > > > > JFR.check > > > > > > VM.log > > > > > > VM.native_memory > > > > > > ManagementAgent.status > > > > > > ManagementAgent.stop > > > > > > ManagementAgent.start_local > > > > > > ManagementAgent.start > > > > > > Compiler.directives_clear > > > > > > Compiler.directives_remove > > > > > > Compiler.directives_add > > > > > > Compiler.directives_print > > > > > > VM.print_touched_methods > > > > > > Compiler.codecache > > > > > > Compiler.codelist > > > > > > Compiler.queue > > > > > > VM.classloader_stats > > > > > > Thread.print > > > > > > JVMTI.data_dump > > > > > > JVMTI.agent_load > > > > > > VM.stringtable > > > > > > VM.symboltable > > > > > > VM.class_hierarchy > > > > > > GC.class_stats > > > > > > GC.class_histogram > > > > > > GC.heap_dump > > > > > > GC.finalizer_info > > > > > > GC.heap_info > > > > > > GC.run_finalization > > > > > > GC.run > > > > > > VM.info > > > > > > VM.uptime > > > > > > VM.dynlibs > > > > > > VM.set_flag > > > > > > VM.flags > > > > > > VM.system_properties > > > > > > VM.command_line > > > > > > VM.version > > > > > > help > > > > > > > > > For more information about a specific command use 'help > '. > > > > > > Martins-MacBook-Pro-2:Downloads marska$ > > > > > > > > > ons. 6. sep. 2017 kl. 08:53 skrev David Holmes > > > > > >>>: > > > > > > Hi Martin, > > > > > > On 6/09/2017 4:38 PM, Martin Skarsaune wrote: > > > > Hi > > > > > > > > If I run *JFR.check* in build 9+181 , the response > > indicates that > > > I can > > > > invoke *VM.unlock_commercial_features*. > > > > This command is not available in the given VM. > > > > > > > > The output should not refer to this command i VM where it > > is not > > > available. > > > > > > > > Cheers > > > > > > > > Martin Skarsaune > > > > > > > > > > > > Example: > > > > > > > > Martins-MacBook-Pro-2:Downloads marska$ java -version > > > > > > > > java version "9" > > > > > > > > Java(TM) SE Runtime Environment (build 9+181) > > > > > > > > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) > > > > > > > > Martins-MacBook-Pro-2:Downloads marska$ > > > > > > > > > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/jcmd > > 11700 > > > > JFR.check > > > > > > > > 11700: > > > > > > What JVM is process 11700? What does "jcmd 11700 help" show? > > > > > > Thanks, > > > David > > > ----- > > > > > > > Java Flight Recorder not enabled. > > > > > > > > > > > > Use VM.unlock_commercial_features to enable. > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at skarsaune.net Wed Sep 6 07:48:57 2017 From: martin at skarsaune.net (Martin Skarsaune) Date: Wed, 06 Sep 2017 07:48:57 +0000 Subject: Misleading output from jcmd JFR.check In-Reply-To: References: <21055cd1-18ae-e643-dad3-2a084ed2b301@oracle.com> <1177eb76-2aa1-bbc9-da89-7bb8a8501c93@oracle.com> <1f8b64bc-e00b-fba8-7a69-27d162c19c47@oracle.com> Message-ID: Ok, that makes sense. Have posted to early access community. Thanks again Martin ons. 6. sep. 2017 kl. 09:38 skrev Martin Skarsaune : > Ah, good point. > > I think it should be pretty straightforward to reproduce. I don't think it > makes much difference what java application runs, but if you want to run > the exact same application, you can get it here : > > > https://oss.sonatype.org/content/repositories/public/io/hawt/hawtio-app/1.5.3/hawtio-app-1.5.3.jar > > Martin > > ons. 6. sep. 2017 kl. 09:15 skrev David Holmes : > >> On 6/09/2017 5:13 PM, Martin Skarsaune wrote: >> > Martins-MacBook-Pro-2:Downloads marska$ java -version >> > >> > java version "9" >> > >> > Java(TM) SE Runtime Environment (build 9+181) >> > >> > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) >> > >> > >> > Also included in the first message ;-) >> >> It wasn't clear that process 11700 was running the exact same JVM. >> >> Thanks, >> David >> >> > >> > ons. 6. sep. 2017 kl. 09:10 skrev David Holmes > > >: >> > >> > Hi Martin, >> > >> > On 6/09/2017 5:00 PM, Martin Skarsaune wrote: >> > > Hi David >> > > >> > > Details below. >> > >> > What does "java -version" show for that JVM please. >> > >> > Thanks, >> > David >> > >> > > Cheers >> > > >> > > Martin >> > > >> > > Martins-MacBook-Pro-2:Downloads marska$ >> > > >> /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/*jcmd >> > > 11700 VM.command_line* >> > > >> > > 11700: >> > > >> > > VM Arguments: >> > > >> > > java_command: hawtio-app-1.5.3.jar >> > > >> > > java_class_path (initial): hawtio-app-1.5.3.jar >> > > >> > > Launcher Type: SUN_STANDARD >> > > >> > > Martins-MacBook-Pro-2:Downloads marska$ >> > > >> /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/*jcmd >> > > 11700 help* >> > > >> > > 11700: >> > > >> > > The following commands are available: >> > > >> > > JFR.configure >> > > >> > > JFR.stop >> > > >> > > JFR.start >> > > >> > > JFR.dump >> > > >> > > JFR.check >> > > >> > > VM.log >> > > >> > > VM.native_memory >> > > >> > > ManagementAgent.status >> > > >> > > ManagementAgent.stop >> > > >> > > ManagementAgent.start_local >> > > >> > > ManagementAgent.start >> > > >> > > Compiler.directives_clear >> > > >> > > Compiler.directives_remove >> > > >> > > Compiler.directives_add >> > > >> > > Compiler.directives_print >> > > >> > > VM.print_touched_methods >> > > >> > > Compiler.codecache >> > > >> > > Compiler.codelist >> > > >> > > Compiler.queue >> > > >> > > VM.classloader_stats >> > > >> > > Thread.print >> > > >> > > JVMTI.data_dump >> > > >> > > JVMTI.agent_load >> > > >> > > VM.stringtable >> > > >> > > VM.symboltable >> > > >> > > VM.class_hierarchy >> > > >> > > GC.class_stats >> > > >> > > GC.class_histogram >> > > >> > > GC.heap_dump >> > > >> > > GC.finalizer_info >> > > >> > > GC.heap_info >> > > >> > > GC.run_finalization >> > > >> > > GC.run >> > > >> > > VM.info >> > > >> > > VM.uptime >> > > >> > > VM.dynlibs >> > > >> > > VM.set_flag >> > > >> > > VM.flags >> > > >> > > VM.system_properties >> > > >> > > VM.command_line >> > > >> > > VM.version >> > > >> > > help >> > > >> > > >> > > For more information about a specific command use 'help >> '. >> > > >> > > Martins-MacBook-Pro-2:Downloads marska$ >> > > >> > > >> > > ons. 6. sep. 2017 kl. 08:53 skrev David Holmes >> > >> > > > >>>: >> > > >> > > Hi Martin, >> > > >> > > On 6/09/2017 4:38 PM, Martin Skarsaune wrote: >> > > > Hi >> > > > >> > > > If I run *JFR.check* in build 9+181 , the response >> > indicates that >> > > I can >> > > > invoke *VM.unlock_commercial_features*. >> > > > This command is not available in the given VM. >> > > > >> > > > The output should not refer to this command i VM where it >> > is not >> > > available. >> > > > >> > > > Cheers >> > > > >> > > > Martin Skarsaune >> > > > >> > > > >> > > > Example: >> > > > >> > > > Martins-MacBook-Pro-2:Downloads marska$ java -version >> > > > >> > > > java version "9" >> > > > >> > > > Java(TM) SE Runtime Environment (build 9+181) >> > > > >> > > > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed >> mode) >> > > > >> > > > Martins-MacBook-Pro-2:Downloads marska$ >> > > > >> > > >> > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/jcmd >> > 11700 >> > > > JFR.check >> > > > >> > > > 11700: >> > > >> > > What JVM is process 11700? What does "jcmd 11700 help" show? >> > > >> > > Thanks, >> > > David >> > > ----- >> > > >> > > > Java Flight Recorder not enabled. >> > > > >> > > > >> > > > Use VM.unlock_commercial_features to enable. >> > > > >> > > > >> > > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Sep 6 07:52:14 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Sep 2017 17:52:14 +1000 Subject: Misleading output from jcmd JFR.check In-Reply-To: References: <21055cd1-18ae-e643-dad3-2a084ed2b301@oracle.com> <1177eb76-2aa1-bbc9-da89-7bb8a8501c93@oracle.com> <1f8b64bc-e00b-fba8-7a69-27d162c19c47@oracle.com> Message-ID: <28296434-7d68-a45d-e266-f2364d71b373@oracle.com> On 6/09/2017 5:48 PM, Martin Skarsaune wrote: > Ok, that makes sense. > Have posted to early access community. Not really any need now :) Cheers, David > Thanks again > > Martin > > ons. 6. sep. 2017 kl. 09:38 skrev Martin Skarsaune >: > > Ah, good point. > > I think it should be pretty straightforward to reproduce. I don't > think it makes much difference what java application runs, but if > you want to run the exact same application, you can get it here : > > https://oss.sonatype.org/content/repositories/public/io/hawt/hawtio-app/1.5.3/hawtio-app-1.5.3.jar > > Martin > > ons. 6. sep. 2017 kl. 09:15 skrev David Holmes > >: > > On 6/09/2017 5:13 PM, Martin Skarsaune wrote: > > Martins-MacBook-Pro-2:Downloads marska$ java -version > > > > java version "9" > > > > Java(TM) SE Runtime Environment (build 9+181) > > > > Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) > > > > > > Also included in the first message ;-) > > It wasn't clear that process 11700 was running the exact same JVM. > > Thanks, > David > > > > > ons. 6. sep. 2017 kl. 09:10 skrev David Holmes > > > >>: > > > >? ? ?Hi Martin, > > > >? ? ?On 6/09/2017 5:00 PM, Martin Skarsaune wrote: > >? ? ? > Hi David > >? ? ? > > >? ? ? > Details below. > > > >? ? ?What does "java -version" show for that JVM please. > > > >? ? ?Thanks, > >? ? ?David > > > >? ? ? > Cheers > >? ? ? > > >? ? ? > Martin > >? ? ? > > >? ? ? > Martins-MacBook-Pro-2:Downloads marska$ > >? ? ? > > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/*jcmd > >? ? ? > 11700 VM.command_line* > >? ? ? > > >? ? ? > 11700: > >? ? ? > > >? ? ? > VM Arguments: > >? ? ? > > >? ? ? > java_command: hawtio-app-1.5.3.jar > >? ? ? > > >? ? ? > java_class_path (initial): hawtio-app-1.5.3.jar > >? ? ? > > >? ? ? > Launcher Type: SUN_STANDARD > >? ? ? > > >? ? ? > Martins-MacBook-Pro-2:Downloads marska$ > >? ? ? > > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/*jcmd > >? ? ? > 11700 help* > >? ? ? > > >? ? ? > 11700: > >? ? ? > > >? ? ? > The following commands are available: > >? ? ? > > >? ? ? > JFR.configure > >? ? ? > > >? ? ? > JFR.stop > >? ? ? > > >? ? ? > JFR.start > >? ? ? > > >? ? ? > JFR.dump > >? ? ? > > >? ? ? > JFR.check > >? ? ? > > >? ? ? > VM.log > >? ? ? > > >? ? ? > VM.native_memory > >? ? ? > > >? ? ? > ManagementAgent.status > >? ? ? > > >? ? ? > ManagementAgent.stop > >? ? ? > > >? ? ? > ManagementAgent.start_local > >? ? ? > > >? ? ? > ManagementAgent.start > >? ? ? > > >? ? ? > Compiler.directives_clear > >? ? ? > > >? ? ? > Compiler.directives_remove > >? ? ? > > >? ? ? > Compiler.directives_add > >? ? ? > > >? ? ? > Compiler.directives_print > >? ? ? > > >? ? ? > VM.print_touched_methods > >? ? ? > > >? ? ? > Compiler.codecache > >? ? ? > > >? ? ? > Compiler.codelist > >? ? ? > > >? ? ? > Compiler.queue > >? ? ? > > >? ? ? > VM.classloader_stats > >? ? ? > > >? ? ? > Thread.print > >? ? ? > > >? ? ? > JVMTI.data_dump > >? ? ? > > >? ? ? > JVMTI.agent_load > >? ? ? > > >? ? ? > VM.stringtable > >? ? ? > > >? ? ? > VM.symboltable > >? ? ? > > >? ? ? > VM.class_hierarchy > >? ? ? > > >? ? ? > GC.class_stats > >? ? ? > > >? ? ? > GC.class_histogram > >? ? ? > > >? ? ? > GC.heap_dump > >? ? ? > > >? ? ? > GC.finalizer_info > >? ? ? > > >? ? ? > GC.heap_info > >? ? ? > > >? ? ? > GC.run_finalization > >? ? ? > > >? ? ? > GC.run > >? ? ? > > >? ? ? > VM.info > >? ? ? > > >? ? ? > VM.uptime > >? ? ? > > >? ? ? > VM.dynlibs > >? ? ? > > >? ? ? > VM.set_flag > >? ? ? > > >? ? ? > VM.flags > >? ? ? > > >? ? ? > VM.system_properties > >? ? ? > > >? ? ? > VM.command_line > >? ? ? > > >? ? ? > VM.version > >? ? ? > > >? ? ? > help > >? ? ? > > >? ? ? > > >? ? ? > For more information about a specific command use > 'help '. > >? ? ? > > >? ? ? > Martins-MacBook-Pro-2:Downloads marska$ > >? ? ? > > >? ? ? > > >? ? ? > ons. 6. sep. 2017 kl. 08:53 skrev David Holmes > >? ? ? > > > >? ? ? > >>>: > >? ? ? > > >? ? ? >? ? ?Hi Martin, > >? ? ? > > >? ? ? >? ? ?On 6/09/2017 4:38 PM, Martin Skarsaune wrote: > >? ? ? >? ? ? > Hi > >? ? ? >? ? ? > > >? ? ? >? ? ? > If I run *JFR.check* in build 9+181 , the response > >? ? ?indicates that > >? ? ? >? ? ?I can > >? ? ? >? ? ? > invoke *VM.unlock_commercial_features*. > >? ? ? >? ? ? > This command is not available in the given VM. > >? ? ? >? ? ? > > >? ? ? >? ? ? > The output should not refer to this command i > VM where it > >? ? ?is not > >? ? ? >? ? ?available. > >? ? ? >? ? ? > > >? ? ? >? ? ? > Cheers > >? ? ? >? ? ? > > >? ? ? >? ? ? > Martin Skarsaune > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > Example: > >? ? ? >? ? ? > > >? ? ? >? ? ? > Martins-MacBook-Pro-2:Downloads marska$ java > -version > >? ? ? >? ? ? > > >? ? ? >? ? ? > java version "9" > >? ? ? >? ? ? > > >? ? ? >? ? ? > Java(TM) SE Runtime Environment (build 9+181) > >? ? ? >? ? ? > > >? ? ? >? ? ? > Java HotSpot(TM) 64-Bit Server VM (build 9+181, > mixed mode) > >? ? ? >? ? ? > > >? ? ? >? ? ? > Martins-MacBook-Pro-2:Downloads marska$ > >? ? ? >? ? ? > > >? ? ? > > > > ?/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/jcmd > >? ? ?11700 > >? ? ? >? ? ? > JFR.check > >? ? ? >? ? ? > > >? ? ? >? ? ? > 11700: > >? ? ? > > >? ? ? >? ? ?What JVM is process 11700? What does "jcmd 11700 > help" show? > >? ? ? > > >? ? ? >? ? ?Thanks, > >? ? ? >? ? ?David > >? ? ? >? ? ?----- > >? ? ? > > >? ? ? >? ? ? > Java Flight Recorder not enabled. > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? >? ? ? > Use VM.unlock_commercial_features to enable. > >? ? ? >? ? ? > > >? ? ? >? ? ? > > >? ? ? > > > > From jcbeyler at google.com Wed Sep 6 17:29:28 2017 From: jcbeyler at google.com (JC Beyler) Date: Wed, 6 Sep 2017 10:29:28 -0700 Subject: NotifyFramePop and FramePop events In-Reply-To: <81ca65ea-feea-2378-83a3-948f9df36893@oracle.com> References: <81ca65ea-feea-2378-83a3-948f9df36893@oracle.com> Message-ID: That is only cleared if the state is enabled for JVMTI_EVENT_FRAME_POP. If you disable it before, you'd skip that. When I go look at the jvmtiEventController and peruse, it seems that if you can have the case I am talking about if all the threads turn off the JVMTI_EVENT_FRAME_POP, then the state would be off as well and then we would not clear (or even check for that matter). Am I wrong? On Tue, Sep 5, 2017 at 11:05 PM, serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Hi JC, > > Thank you for verifying this! > > > > On 9/5/17 11:01, JC Beyler wrote: > > Hi all, > > After looking at the code a bit more, I don't see a viable way of really > either: > - At notification disabling, remove all pop event requests > - Enforcing that the current frame at depth is singled out, if you > disable and then pop that frame, the event is destroyed with the frame so > that a subsequent pop at that depth no longer fires > > Because of that, I'd recommend just changing the documentation to > highlight this, it might look a bit like this: > > --- old/src/share/vm/prims/jvmti.xml 2017-09-05 10:51:05.850810934 -0700 > +++ new/src/share/vm/prims/jvmti.xml 2017-09-05 10:51:05.710811367 -0700 > @@ -2907,7 +2907,7 @@ > > Notify Frame Pop > > - When the frame that is currently at > + When a frame currently at > is popped from the stack, generate a > event. See the > event for details. > @@ -2916,6 +2916,12 @@ >

> The specified thread must either be the current thread > or the thread must be suspended. > +

> + Note: if the notification event is disabled and a frame at > + is popped, no event is generated. > + After re-enabling the notification event, the registered > + is still active and will provoke an > + event when a frame at is popped. > > jvmdi > > > Would someone want to review this and tell me if I should create a webrev for it? Or tell me hell no ;-) > > > I'd say, "hell no" as it looks wrong to me. ;-) > Please, see a comment below. > > > Thanks! > > Jc > > > On Thu, Aug 31, 2017 at 3:15 PM, JC Beyler wrote: > >> Hi all, >> >> I was asked to raise a question about NotifyFramePop and FramePop events >> and I thought I would just ask it here: >> >> If we imagine we have a stack frame such as: >> >> call_depth0 >> call_depth1 >> call_depth2 >> call_depth3 >> >> And at this third depth, we request a frame pop when leaving depth1 via >> the NotifyFramePop call. We would of course assume that when leaving >> call_depth1 we get a FramePop event. >> >> Now imagine that we disable the frame pop event notification in >> call_depth2: >> call_depth0 >> call_depth1 >> call_depth2 >> SetEventNotificationMode >> >> (JVMTI_DISABLE, JVMTI_EVENT_FRAME_POP, NULL) >> >> If the stack now pops back to call_depth0, the frame pop system is not >> checked, the FramePop for call_depth1 is not issued either. >> >> However, imagine now that later down the road, the stack trace has built >> itself back up and we enabled the event: >> call_depth0 >> second_call_depth1 >> second_call_depth2 >> SetEventNotificationMode >> >> (JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, NULL) >> >> Then when leaving second_call_depth1, we seemingly will issue a frame pop >> event. >> > > No. > The NotifyFramePop request has been already cleaned at the first > call_depth0 pop. > Please, see the following line in the jvmtiExport.cpp: > JvmtiExport::post_method_exit(): > ets->clear_frame_pop(cur_frame_number); > > We have to make another NotifyFramePop request to get this one. > > Thanks, > Serguei > > > >> Here is the qualm: >> - It seems counter intuitive and the documentation does not >> specify/warn about this; it seems that if you disable the events you should >> perhaps clear up the pop requests. >> - At least the documentation for NotifyFramePop ( >> https://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti. >> html#NotifyFramePop) should be changed since it says: "When the frame >> that is currently at depth is popped from the stack" to something like >> "When the first frame at the depth is popped from the stack and the event >> notification is enabled" >> >> Therefore the questions are: >> >> 1) Is this such a corner case, that we do not wish to try to fix the >> documentation or the code? >> 2) Is this a corner case we do not wish to handle, therefore put a fix in >> the documentation to at least warn users of this >> 3) Is this a bug that we'd like to fix? >> >> Thanks for your insight, >> Jc >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at skarsaune.net Wed Sep 6 20:46:58 2017 From: martin at skarsaune.net (Martin Skarsaune) Date: Wed, 06 Sep 2017 20:46:58 +0000 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: <59AED139.4030102@oracle.com> Message-ID: How about POST payloads? Since they are so similar already, it would be a huge advantage if they could be made interchangeable. For instance I have done some work on hawt.io plugins. A typical scenario for a plugin is to set up one or more chained requests for read/write/exec on an MBean, and have a callback process the response. If the payloads were compatible, the road to support this new backend might not be too difficult. That would give this new initiative a real boost over traditional JMX connections. Otherwise one would have to impose an additional layer of complexity to bridge the difference. I suppose you know these tools very well already. There is by the way a presentation on JMX, Jolokia and hawt.io at JavaZone in a weeks time, and the recording is usually made available just a few hours later: https://2017.javazone.no/program/bbe08ad550174e16abd954733e018590 Best regards Martin ons. 6. sep. 2017 kl. 08:47 skrev Harsha Wardhana B < harsha.wardhana.b at oracle.com>: > Hi Martin, > > In my opinion, the interfaces exposed by current JEP are lot closer to > REST style than the interfaces exposed by Jolokia. > > For instance, HTTP GET by default should be used to read resources, but it > is made part of URL in Jolokia interfaces. > > /read/// > > > I would wait on opinions from more people before considering changing the > current interfaces. > > Thanks > > -Harsha > > > On Wednesday 06 September 2017 11:40 AM, Martin Skarsaune wrote: > > Hello > > Would one at least consider adopting the same URL paths and payloads as > Jolokia? This could make life a lot easier for third party tools that > connect to it. > > Best Regards > > Martin Skarsaune > > ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B < > harsha.wardhana.b at oracle.com>: > >> Hi Kirk, >> >> Yes. Jolokia was considered and is listed as an alternative in the JEP. >> >> >> - Jolokia can serve as a viable alternative but can be bulky. We are >> looking for simple and lightweight solution. >> >> >> -Harsha >> >> On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote: >> >> Hi, >> >> Have you run into this project? https://jolokia.org. Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. >> >> Kind regards, >> Kirk >> >> >> On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: >> >> Hi Harsha, >> >> Looping in jmx-dev. >> >> >> byte[], short[], int[], float[], double[] >> >> Should long[] be included there as well? >> >> >> The REST adapter will come with a simple and lightweight JSON parser. >> >> Is this an internal parser or will it be exposed as an API? >> >> If so, how does it relate to JEP 198: Light-Weight JSON API?http://openjdk.java.net/jeps/198 >> >> Will com.sun.net.httpserver.HttpServer be used to serve the requests? >> >> Thanks >> Erik >> >> >> Hi All, >> >> Please review the JEP for REST APIs for JMX : >> https://bugs.openjdk.java.net/browse/JDK-8171311 >> >> The JEP aims at providing RESTful web interfaces to MBeans. >> >> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. >> >> Thanks >> -Harsha >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Sep 6 22:07:15 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 6 Sep 2017 15:07:15 -0700 Subject: NotifyFramePop and FramePop events In-Reply-To: References: <81ca65ea-feea-2378-83a3-948f9df36893@oracle.com> Message-ID: <2b1b3390-81dd-58b0-872f-fbc98c64aeca@oracle.com> An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Sep 6 23:56:47 2017 From: jcbeyler at google.com (JC Beyler) Date: Wed, 6 Sep 2017 16:56:47 -0700 Subject: NotifyFramePop and FramePop events In-Reply-To: <2b1b3390-81dd-58b0-872f-fbc98c64aeca@oracle.com> References: <81ca65ea-feea-2378-83a3-948f9df36893@oracle.com> <2b1b3390-81dd-58b0-872f-fbc98c64aeca@oracle.com> Message-ID: Thanks Serguei! Just so I know, is your current thought that we should try to fix the implementation or change the documentation something like I did? Perhaps you don't know yet :) Jc On Wed, Sep 6, 2017 at 3:07 PM, serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > On 9/6/17 10:29, JC Beyler wrote: > > That is only cleared if the state is enabled for JVMTI_EVENT_FRAME_POP. If > you disable it before, you'd skip that. > > > Agreed. > It is a bug in implementation. > > > When I go look at the jvmtiEventController and peruse, it seems that if > you can have the case I am talking about if all the threads turn off the > JVMTI_EVENT_FRAME_POP, then the state would be off as well and then we > would not clear (or even check for that matter). > > Am I wrong? > > > You are right. > I have filed the bug: > https://bugs.openjdk.java.net/browse/JDK-8187289 > NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is > disabled > > > Thanks, > Serguei > > > > > On Tue, Sep 5, 2017 at 11:05 PM, serguei.spitsyn at oracle.com < > serguei.spitsyn at oracle.com> wrote: > >> Hi JC, >> >> Thank you for verifying this! >> >> >> >> On 9/5/17 11:01, JC Beyler wrote: >> >> Hi all, >> >> After looking at the code a bit more, I don't see a viable way of really >> either: >> - At notification disabling, remove all pop event requests >> - Enforcing that the current frame at depth is singled out, if you >> disable and then pop that frame, the event is destroyed with the frame so >> that a subsequent pop at that depth no longer fires >> >> Because of that, I'd recommend just changing the documentation to >> highlight this, it might look a bit like this: >> >> --- old/src/share/vm/prims/jvmti.xml 2017-09-05 10:51:05.850810934 -0700 >> +++ new/src/share/vm/prims/jvmti.xml 2017-09-05 10:51:05.710811367 -0700 >> @@ -2907,7 +2907,7 @@ >> >> Notify Frame Pop >> >> - When the frame that is currently at >> + When a frame currently at >> is popped from the stack, generate a >> event. See the >> event for details. >> @@ -2916,6 +2916,12 @@ >>

>> The specified thread must either be the current thread >> or the thread must be suspended. >> +

>> + Note: if the notification event is disabled and a frame at >> + is popped, no event is generated. >> + After re-enabling the notification event, the registered >> + is still active and will provoke an >> + event when a frame at is popped. >> >> jvmdi >> >> >> Would someone want to review this and tell me if I should create a webrev for it? Or tell me hell no ;-) >> >> >> I'd say, "hell no" as it looks wrong to me. ;-) >> Please, see a comment below. >> >> >> Thanks! >> >> Jc >> >> >> On Thu, Aug 31, 2017 at 3:15 PM, JC Beyler wrote: >> >>> Hi all, >>> >>> I was asked to raise a question about NotifyFramePop and FramePop events >>> and I thought I would just ask it here: >>> >>> If we imagine we have a stack frame such as: >>> >>> call_depth0 >>> call_depth1 >>> call_depth2 >>> call_depth3 >>> >>> And at this third depth, we request a frame pop when leaving depth1 via >>> the NotifyFramePop call. We would of course assume that when leaving >>> call_depth1 we get a FramePop event. >>> >>> Now imagine that we disable the frame pop event notification in >>> call_depth2: >>> call_depth0 >>> call_depth1 >>> call_depth2 >>> SetEventNotificationMode >>> >>> (JVMTI_DISABLE, JVMTI_EVENT_FRAME_POP, NULL) >>> >>> If the stack now pops back to call_depth0, the frame pop system is not >>> checked, the FramePop for call_depth1 is not issued either. >>> >>> However, imagine now that later down the road, the stack trace has built >>> itself back up and we enabled the event: >>> call_depth0 >>> second_call_depth1 >>> second_call_depth2 >>> SetEventNotificationMode >>> >>> (JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, NULL) >>> >>> Then when leaving second_call_depth1, we seemingly will issue a frame >>> pop event. >>> >> >> No. >> The NotifyFramePop request has been already cleaned at the first >> call_depth0 pop. >> Please, see the following line in the jvmtiExport.cpp: >> JvmtiExport::post_method_exit(): >> ets->clear_frame_pop(cur_frame_number); >> >> We have to make another NotifyFramePop request to get this one. >> >> Thanks, >> Serguei >> >> >> >>> Here is the qualm: >>> - It seems counter intuitive and the documentation does not >>> specify/warn about this; it seems that if you disable the events you should >>> perhaps clear up the pop requests. >>> - At least the documentation for NotifyFramePop ( >>> https://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti. >>> html#NotifyFramePop) should be changed since it says: "When the frame >>> that is currently at depth is popped from the stack" to something like >>> "When the first frame at the depth is popped from the stack and the event >>> notification is enabled" >>> >>> Therefore the questions are: >>> >>> 1) Is this such a corner case, that we do not wish to try to fix the >>> documentation or the code? >>> 2) Is this a corner case we do not wish to handle, therefore put a fix >>> in the documentation to at least warn users of this >>> 3) Is this a bug that we'd like to fix? >>> >>> Thanks for your insight, >>> Jc >>> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Sep 7 01:01:14 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 6 Sep 2017 18:01:14 -0700 Subject: NotifyFramePop and FramePop events In-Reply-To: References: <81ca65ea-feea-2378-83a3-948f9df36893@oracle.com> <2b1b3390-81dd-58b0-872f-fbc98c64aeca@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu Sep 7 01:42:11 2017 From: jcbeyler at google.com (JC Beyler) Date: Wed, 6 Sep 2017 18:42:11 -0700 Subject: NotifyFramePop and FramePop events In-Reply-To: References: <81ca65ea-feea-2378-83a3-948f9df36893@oracle.com> <2b1b3390-81dd-58b0-872f-fbc98c64aeca@oracle.com> Message-ID: Sounds good to me. Thanks for the quick turn around and figuring out what you would like to do. Let me know if I can do anything to help, Jc On Wed, Sep 6, 2017 at 6:01 PM, serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Fixing it in the spec is wrong. > The implementation needs to be fixed. > A straight-forward fix will most likely cause some performance degradation > in interpreter mode. > So, the fix is going to be more tricky. > > If you do not object, I'll assign this bug to my self. > Will see if there is a time to fix it in 10. > > Thanks, > Serguei > > > On 9/6/17 16:56, JC Beyler wrote: > > Thanks Serguei! > > Just so I know, is your current thought that we should try to fix the > implementation or change the documentation something like I did? > > Perhaps you don't know yet :) > Jc > > On Wed, Sep 6, 2017 at 3:07 PM, serguei.spitsyn at oracle.com < > serguei.spitsyn at oracle.com> wrote: > >> On 9/6/17 10:29, JC Beyler wrote: >> >> That is only cleared if the state is enabled for JVMTI_EVENT_FRAME_POP. >> If you disable it before, you'd skip that. >> >> >> Agreed. >> It is a bug in implementation. >> >> >> When I go look at the jvmtiEventController and peruse, it seems that if >> you can have the case I am talking about if all the threads turn off the >> JVMTI_EVENT_FRAME_POP, then the state would be off as well and then we >> would not clear (or even check for that matter). >> >> Am I wrong? >> >> >> You are right. >> I have filed the bug: >> https://bugs.openjdk.java.net/browse/JDK-8187289 >> NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is >> disabled >> >> >> Thanks, >> Serguei >> >> >> >> >> On Tue, Sep 5, 2017 at 11:05 PM, serguei.spitsyn at oracle.com < >> serguei.spitsyn at oracle.com> wrote: >> >>> Hi JC, >>> >>> Thank you for verifying this! >>> >>> >>> >>> On 9/5/17 11:01, JC Beyler wrote: >>> >>> Hi all, >>> >>> After looking at the code a bit more, I don't see a viable way of really >>> either: >>> - At notification disabling, remove all pop event requests >>> - Enforcing that the current frame at depth is singled out, if you >>> disable and then pop that frame, the event is destroyed with the frame so >>> that a subsequent pop at that depth no longer fires >>> >>> Because of that, I'd recommend just changing the documentation to >>> highlight this, it might look a bit like this: >>> >>> --- old/src/share/vm/prims/jvmti.xml 2017-09-05 10:51:05.850810934 -0700 >>> +++ new/src/share/vm/prims/jvmti.xml 2017-09-05 10:51:05.710811367 -0700 >>> @@ -2907,7 +2907,7 @@ >>> >>> Notify Frame Pop >>> >>> - When the frame that is currently at >>> + When a frame currently at >>> is popped from the stack, generate a >>> event. See the >>> event for details. >>> @@ -2916,6 +2916,12 @@ >>>

>>> The specified thread must either be the current thread >>> or the thread must be suspended. >>> +

>>> + Note: if the notification event is disabled and a frame at >>> + is popped, no event is generated. >>> + After re-enabling the notification event, the registered >>> + is still active and will provoke an >>> + event when a frame at is popped. >>> >>> jvmdi >>> >>> >>> Would someone want to review this and tell me if I should create a webrev for it? Or tell me hell no ;-) >>> >>> >>> I'd say, "hell no" as it looks wrong to me. ;-) >>> Please, see a comment below. >>> >>> >>> Thanks! >>> >>> Jc >>> >>> >>> On Thu, Aug 31, 2017 at 3:15 PM, JC Beyler wrote: >>> >>>> Hi all, >>>> >>>> I was asked to raise a question about NotifyFramePop and FramePop >>>> events and I thought I would just ask it here: >>>> >>>> If we imagine we have a stack frame such as: >>>> >>>> call_depth0 >>>> call_depth1 >>>> call_depth2 >>>> call_depth3 >>>> >>>> And at this third depth, we request a frame pop when leaving depth1 via >>>> the NotifyFramePop call. We would of course assume that when leaving >>>> call_depth1 we get a FramePop event. >>>> >>>> Now imagine that we disable the frame pop event notification in >>>> call_depth2: >>>> call_depth0 >>>> call_depth1 >>>> call_depth2 >>>> SetEventNotificationMode >>>> >>>> (JVMTI_DISABLE, JVMTI_EVENT_FRAME_POP, NULL) >>>> >>>> If the stack now pops back to call_depth0, the frame pop system is not >>>> checked, the FramePop for call_depth1 is not issued either. >>>> >>>> However, imagine now that later down the road, the stack trace has >>>> built itself back up and we enabled the event: >>>> call_depth0 >>>> second_call_depth1 >>>> second_call_depth2 >>>> SetEventNotificationMode >>>> >>>> (JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, NULL) >>>> >>>> Then when leaving second_call_depth1, we seemingly will issue a frame >>>> pop event. >>>> >>> >>> No. >>> The NotifyFramePop request has been already cleaned at the first >>> call_depth0 pop. >>> Please, see the following line in the jvmtiExport.cpp: >>> JvmtiExport::post_method_exit(): >>> ets->clear_frame_pop(cur_frame_number); >>> >>> We have to make another NotifyFramePop request to get this one. >>> >>> Thanks, >>> Serguei >>> >>> >>> >>>> Here is the qualm: >>>> - It seems counter intuitive and the documentation does not >>>> specify/warn about this; it seems that if you disable the events you should >>>> perhaps clear up the pop requests. >>>> - At least the documentation for NotifyFramePop ( >>>> https://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti. >>>> html#NotifyFramePop) should be changed since it says: "When the frame >>>> that is currently at depth is popped from the stack" to something like >>>> "When the first frame at the depth is popped from the stack and the event >>>> notification is enabled" >>>> >>>> Therefore the questions are: >>>> >>>> 1) Is this such a corner case, that we do not wish to try to fix the >>>> documentation or the code? >>>> 2) Is this a corner case we do not wish to handle, therefore put a fix >>>> in the documentation to at least warn users of this >>>> 3) Is this a bug that we'd like to fix? >>>> >>>> Thanks for your insight, >>>> Jc >>>> >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shafi.s.ahmad at oracle.com Thu Sep 7 06:13:24 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Wed, 6 Sep 2017 23:13:24 -0700 (PDT) Subject: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code In-Reply-To: References: <131072bd-7d03-4f79-8ca0-6c26f9bbe315@default> <563f375f-b814-4544-9f88-5e8b99610324@oracle.com> <2559A0F3F1C918EE.d7de5b4c-3657-452b-91b0-2166e78f5f46@mail.outlook.com> Message-ID: <62aceca9-6710-4a3c-9f87-0cc15d064842@default> Hi Daniel, ? Thank you for the input. ? With this change I am not seeing any addition failure for all the suggested test suits. ? TEST 346/346 346/346 nsk/monitoring/ThreadMXBean/GetThreadAllocatedBytes/stressTest_proxy_custom PASS HARNESS ENDED: Wed Sep 06 00:00:49 PDT 2017 ? TOTAL TESTS IN RUN: 346 TEST PASS: 346; 100% rate TEST FAIL: 0; 0% rate TEST UNDEFINED: 0; 0% rate TEST INCOMPLETE: 0; 0% rate TESTS NOT RUN: 0 ? TOTAL TEST IN TESTLIST: 359 ? Passed: com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh Passed: com/sun/management/CheckSomeMXBeanImplPackage.java Passed: com/sun/management/VMOptionOpenDataTest.java Test results: passed: 30 Report written to /scratch/shshahma/Java/jdk10-dev-new/JTreport/html/report.html Results written to /scratch/shshahma/Java/jdk10-dev-new/JTwork ? Passed: java/lang/management/ThreadMXBean/ThreadUserTime.java Test results: passed: 65 Report written to /scratch/shshahma/Java/jdk10-dev-new/JTreport/html/report.html Results written to /scratch/shshahma/Java/jdk10-dev-new/JTwork ? Passed: jdk/internal/agent/AgentCheckTest.java Passed: jdk/internal/agent/AgentCMETest.java Test results: passed: 2 Report written to /scratch/shshahma/Java/jdk10-dev-new/JTreport/html/report.html Results written to /scratch/shshahma/Java/jdk10-dev-new/JTwor ? Passed: sun/management/PlatformMBeanProviderConstructorCheck.java Test results: passed: 33 Report written to /scratch/shshahma/Java/jdk10-dev-new/JTreport/html/report.html Results written to /scratch/shshahma/Java/jdk10-dev-new/JTwork ? Passed: javax/management/timer/StartTest.java Test results: passed: 243; failed: 1 Report written to /scratch/shshahma/Java/jdk10-dev-new/JTreport/html/report.html Results written to /scratch/shshahma/Java/jdk10-dev-new/JTwork Error: Some tests failed or other problems occurred. ? I verified the above failure and without my change it failed too. ? jdk10-dev-new$ jtreg -v1 -jdk:./build/linux-x64/jdk/? jdk/test/javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java FAILED: javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java Test results: failed: 1 Report written to /scratch/shshahma/Java/jdk10-dev-new/JTreport/html/report.html Results written to /scratch/shshahma/Java/jdk10-dev-new/JTwork Error: Some tests failed or other problems occurred. jdk10-dev-new$ tail ./JTwork/javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.jtr ??????? -Dtest.timeout.factor=1.0 \\ ??????? -Dtest.modules=java.management \\ ??????? --add-modules java.management \\ ??????? -Djmx-registry.host=jmx-registry-host \\ ??????? -Djmx-registry.port=jmx-registry-port \\ ??????? com.sun.javatest.regtest.agent.MainWrapper /scratch/shshahma/Java/jdk10-dev-new/JTwork/javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.d/main.0.jta result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Specify port with system property: -Djmx-registry.port= ? test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Specify port with system property: -Djmx-registry.port= ? Regards, Shafi ? From: Daniel D. Daugherty Sent: Tuesday, September 05, 2017 10:36 PM To: Shafi Ahmad ; serviceability-dev at openjdk.java.net Subject: Re: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code ? Sorry for the incomplete answer earlier. There are also relevant tests in: ??? jdk/test/java/lang/management ??? jdk/test/com/sun/management ??? jdk/test/sun/management ??? jdk/test/jdk/internal/agent ??? jdk/test/javax/management ??? jdk/test/com/sun/jmx You might want to just run the 'jdk_management' and 'jdk_jmx' test groups... that should also pick up any closed side tests... Dan ??? On 9/5/17 10:44 AM, Shafi Ahmad wrote: Thank you Daniel. I will run and update it with the result. Regards, Shafi On Tue, Sep 5, 2017 at 9:44 PM +0530, "Daniel D. Daugherty" wrote: Seems like you should also run: nsk.monitoring.testlist Dan On 9/4/17 4:11 AM, Shafi Ahmad wrote: Hi, ? Please review the fix for ?JDK-8170299: Debugger does not stop inside the low memory notifications code? to jdk10. ? With the current implementation ?debugger does not stop inside the low memory *notifications* code? This is expected as the notification code is getting executed with the service thread, which is a hidden thread. ? jdk10-dev-new$ jdb -Xmx32m MemoryWarningSystem Initializing jdb ... > stop at MemoryWarningSystem$1:25 Deferring breakpoint MemoryWarningSystem$1:25. It will be set after the class is loaded. > run run MemoryWarningSystem Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > . . . > quit ? Breakpoint not hit. ? With the attached webrev, jdb stop ?at breakpoint inside notification code. ? jdk10-dev-new$ jdb -Xmx64m MemoryWarningSystem Initializing jdb ... > stop at MemoryWarningSystem$1:25 Deferring breakpoint MemoryWarningSystem$1:25. It will be set after the class is loaded. > run run MemoryWarningSystem Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > VM Started: Set deferred breakpoint MemoryWarningSystem$1:25 ? Breakpoint hit: "thread=Thread-0", MemoryWarningSystem$1.memoryUsageLow(), line=25 bci=0 25??????????? System.out.println("Memory usage low!!!"); ? Thread-0[1] step > Memory usage low!!! ? Step completed: "thread=Thread-0", MemoryWarningSystem$1.memoryUsageLow(), line=26 bci=8 26??????????? double percentageUsed = ((double) usedMemory) / maxMemory; ? Thread-0[1] where ? [1] MemoryWarningSystem$1.memoryUsageLow (MemoryWarningSystem.java:26) ? [2] MemoryWarningSystem$2.handleNotification (MemoryWarningSystem.java:48) ? [3] javax.management.NotificationBroadcasterSupport.handleNotification (NotificationBroadcasterSupport.java:284) ? [4] javax.management.NotificationBroadcasterSupport$SendNotifJob.run (NotificationBroadcasterSupport.java:361) ? [5] java.lang.Thread.run (Thread.java:844) Thread-0[1] step > Step completed: "thread=Thread-0", MemoryWarningSystem$1.memoryUsageLow(), line=27 bci=15 27??????????? System.out.println("percentageUsed = " + percentageUsed); ? Thread-0[1] list 23??????? mws.addListener(new MemoryWarningSystem.Listener() { 24????????? public void memoryUsageLow(long usedMemory, long maxMemory) { 25??????????? System.out.println("Memory usage low!!!"); 26??????????? double percentageUsed = ((double) usedMemory) / maxMemory; 27 =>???????? System.out.println("percentageUsed = " + percentageUsed); 28??????????? MemoryWarningSystem.setPercentageUsageThreshold(0.8); 29????????? } 30??????? }); 31??? 32??????? Collection numbers = new LinkedList(); Thread-0[1] ? In the change, the class ?MemoryImpl? is derived from class ?NotificationBroadcasterSupport? instead of class ?NotificationEmitterSupport? NotificationBroadcastSupport takes an Executor, MemoryImpl constructor ?call super() with an executor, ?a visible thread. ? The method hasListeners() is referenced ?inside MemoryImpl.java and defined in ?NotificationEmitterSupport. This method is not present in ?NotificationBroadcasterSupport so I added it to NotificationBroadcasterSupport. ? Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8170299 Webrev link: HYPERLINK "http://cr.openjdk.java.net/%7Eshshahma/8170299/webrev.01/"http://cr.openjdk.java.net/~shshahma/8170299/webrev.01/ ? Testing: jprt -testset core, vm tonga tests nsk.jvmti.testlist, nsk.jdi.testlist, nsk.jdwp.testlist and jtreg tests ./jdk/test/com/sun/jdi/ ? Please let me know if I missed to test some more test suit[s]. ? Thanks to Mandy and Poonam for helping me in fixing this. ? Regards, Shafi ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Sep 7 21:39:05 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 7 Sep 2017 14:39:05 -0700 Subject: RFR: SA: MacOS X: 8184042: several serviceability/sa tests timed out on MacOS X In-Reply-To: <7b5ba4a7-2463-d9e3-b0a4-76957c630719@oracle.com> References: <2121618c-2878-385e-72bb-d9dc6c25b65a@oracle.com> <7b5ba4a7-2463-d9e3-b0a4-76957c630719@oracle.com> Message-ID: <081d276d-4616-364c-2f9c-acda35b4eaf4@oracle.com> On 8/25/17 02:24, serguei.spitsyn at oracle.com wrote: > Hi Jini, > > > On 8/18/17 04:00, David Holmes wrote: >> Hi Jini, >> >> Just reading the bug report and your description below this seems >> like a major change to try and use a facility (mach exceptions) that >> no one seems to have any experience with! That isn't something to be >> rushed. > >> Even if PT_ATTACH has been deprecated restoring its use may be the >> quick way forward instead of trying to rush in something like this. > > This approach looks reasonable to me. I've just realized that my statement might sound incorrectly. I meant that the David's suggestion to restore the use of the deprecated PT_ATTACH looks reasonable. Sorry, if it caused any confusion. Thanks, Serguei > Otherwise, it would be nice to hear why it is not good. > How much would it break the fix of the JDK-8182299? > > Thanks, > Serguei > >> >> Just my 2c. >> >> Cheers, >> David >> >> On 18/08/2017 8:00 PM, Jini George wrote: >>> Hi all, >>> >>> Requesting reviews for: >>> https://bugs.openjdk.java.net/browse/JDK-8184042 >>> >>> Webrev: http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/ >>> >>> Problem gist: The deprecated ptrace() command, PT_ATTACH was changed >>> to PT_ATTACHEXC, which causes mach exceptions (and not UNIX signals) >>> to be delivered via mach messages.This caused SA to hang at >>> waitpid() waiting for a signal, which does not arrive. >>> >>> Solution in a nutshell: The solution is to make the required changes >>> to handle mach 'soft signal' exceptions in the form of mach messages >>> instead of signals, while attaching to and detaching from the target >>> process. The detailed steps are outlined in JBS. >>> >>> The changes appear huge due to the inclusion of pre-generated mach >>> exception handling files (mach_exc*). Since this is an integration >>> blocker, it would be great to get quick reviews on this. >>> >>> Thank you, >>> Jini. >>> >>> >>> >>> >>> >>> > From serguei.spitsyn at oracle.com Thu Sep 7 22:03:18 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 7 Sep 2017 15:03:18 -0700 Subject: RFR: SA: MacOS X: 8184042: several serviceability/sa tests timed out on MacOS X In-Reply-To: <081d276d-4616-364c-2f9c-acda35b4eaf4@oracle.com> References: <2121618c-2878-385e-72bb-d9dc6c25b65a@oracle.com> <7b5ba4a7-2463-d9e3-b0a4-76957c630719@oracle.com> <081d276d-4616-364c-2f9c-acda35b4eaf4@oracle.com> Message-ID: <17390914-efd5-7c39-f8cf-ea2e9e4f0f9a@oracle.com> On 9/7/17 14:39, serguei.spitsyn at oracle.com wrote: > On 8/25/17 02:24, serguei.spitsyn at oracle.com wrote: >> Hi Jini, >> >> >> On 8/18/17 04:00, David Holmes wrote: >>> Hi Jini, >>> >>> Just reading the bug report and your description below this seems >>> like a major change to try and use a facility (mach exceptions) that >>> no one seems to have any experience with! That isn't something to be >>> rushed. >> >>> Even if PT_ATTACH has been deprecated restoring its use may be the >>> quick way forward instead of trying to rush in something like this. >> >> This approach looks reasonable to me. > > I've just realized that my statement might sound incorrectly. > I meant that the David's suggestion to restore the use of the > deprecated PT_ATTACH looks reasonable. Forgot to send a link. Not sure, if an approach of replacing ptrace usage could be reasonable: ? http://uninformed.org/index.cgi?v=4&a=3&p=14 Thanks, Serguei > > Sorry, if it caused any confusion. > > Thanks, > Serguei > > >> Otherwise, it would be nice to hear why it is not good. >> How much would it break the fix of the JDK-8182299? >> >> Thanks, >> Serguei >> >>> >>> Just my 2c. >>> >>> Cheers, >>> David >>> >>> On 18/08/2017 8:00 PM, Jini George wrote: >>>> Hi all, >>>> >>>> Requesting reviews for: >>>> https://bugs.openjdk.java.net/browse/JDK-8184042 >>>> >>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/ >>>> >>>> Problem gist: The deprecated ptrace() command, PT_ATTACH was >>>> changed to PT_ATTACHEXC, which causes mach exceptions (and not UNIX >>>> signals) to be delivered via mach messages.This caused SA to hang >>>> at waitpid() waiting for a signal, which does not arrive. >>>> >>>> Solution in a nutshell: The solution is to make the required >>>> changes to handle mach 'soft signal' exceptions in the form of mach >>>> messages instead of signals, while attaching to and detaching from >>>> the target process. The detailed steps are outlined in JBS. >>>> >>>> The changes appear huge due to the inclusion of pre-generated mach >>>> exception handling files (mach_exc*). Since this is an integration >>>> blocker, it would be great to get quick reviews on this. >>>> >>>> Thank you, >>>> Jini. >>>> >>>> >>>> >>>> >>>> >>>> >> > From harsha.wardhana.b at oracle.com Fri Sep 8 03:58:50 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Fri, 8 Sep 2017 09:28:50 +0530 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: <59AED139.4030102@oracle.com> Message-ID: Hi Martin, I will take a second look at POST payloads. Thanks Harsha On Thursday 07 September 2017 02:16 AM, Martin Skarsaune wrote: > How about POST payloads? Since they are so similar already, it would > be a huge advantage if they could be made interchangeable. > > For instance I have done some work on hawt.io > plugins. A typical scenario for a plugin is to set up one or more > chained requests for read/write/exec on an MBean, and have a callback > process the response. If the payloads were compatible, the road to > support this new backend might not be too difficult. That would give > this new initiative a real boost over traditional JMX connections. > Otherwise one would have to impose an additional layer of complexity > to bridge the difference. > > I suppose you know these tools very well already. There is by the way > a presentation on JMX, Jolokia and hawt.io at > JavaZone in a weeks time, and the recording is usually made available > just a few hours later: > https://2017.javazone.no/program/bbe08ad550174e16abd954733e018590 > > Best regards > > Martin > > ons. 6. sep. 2017 kl. 08:47 skrev Harsha Wardhana B > >: > > Hi Martin, > > In my opinion, the interfaces exposed by current JEP are lot > closer to REST style than the interfaces exposed by Jolokia. > > For instance, HTTP GET by default should be used to read > resources, but it is made part of URL in Jolokia interfaces. > > /read/// > > > I would wait on opinions from more people before considering > changing the current interfaces. > > Thanks > > -Harsha > > > On Wednesday 06 September 2017 11:40 AM, Martin Skarsaune wrote: >> Hello >> >> Would one at least consider adopting the same URL paths and >> payloads as Jolokia? This could make life a lot easier for third >> party tools that connect to it. >> >> Best Regards >> >> Martin Skarsaune >> >> ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B >> >: >> >> Hi Kirk, >> >> Yes. Jolokia was considered and is listed as an alternative >> in the JEP. >> >> * Jolokia can serve as a viable alternative but can be >> bulky. We are looking for simple and lightweight solution. >> >> >> -Harsha >> >> On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote: >>> Hi, >>> >>> Have you run into this project?https://jolokia.org. Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. >>> >>> Kind regards, >>> Kirk >>> >>>> On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: >>>> >>>> Hi Harsha, >>>> >>>> Looping in jmx-dev. >>>> >>>>> byte[], short[], int[], float[], double[] >>>> Should long[] be included there as well? >>>> >>>>> The REST adapter will come with a simple and lightweight JSON parser. >>>> Is this an internal parser or will it be exposed as an API? >>>> >>>> If so, how does it relate to JEP 198: Light-Weight JSON API? >>>> http://openjdk.java.net/jeps/198 >>>> >>>> Will com.sun.net.httpserver.HttpServer be used to serve the requests? >>>> >>>> Thanks >>>> Erik >>>> >>>>> Hi All, >>>>> >>>>> Please review the JEP for REST APIs for JMX : >>>>> https://bugs.openjdk.java.net/browse/JDK-8171311 >>>>> >>>>> The JEP aims at providing RESTful web interfaces to MBeans. >>>>> >>>>> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. >>>>> >>>>> Thanks >>>>> -Harsha >>>>> >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Fri Sep 8 05:41:42 2017 From: jini.george at oracle.com (Jini George) Date: Fri, 8 Sep 2017 11:11:42 +0530 Subject: RFR: SA: MacOS X: 8184042: several serviceability/sa tests timed out on MacOS X In-Reply-To: <17390914-efd5-7c39-f8cf-ea2e9e4f0f9a@oracle.com> References: <2121618c-2878-385e-72bb-d9dc6c25b65a@oracle.com> <7b5ba4a7-2463-d9e3-b0a4-76957c630719@oracle.com> <081d276d-4616-364c-2f9c-acda35b4eaf4@oracle.com> <17390914-efd5-7c39-f8cf-ea2e9e4f0f9a@oracle.com> Message-ID: <344e3474-81db-aed2-1158-22162b62de0d@oracle.com> Hi Serguei, David, Thank you very much for the link and your responses. I agree that the restoration of PT_ATTACH would have been a good very-short term solution if it were an integration blocker. But given that the restoration would be more or less a hack since PT_ATTACH has been deprecated and replaced by PT_ATTACHEXC, and since we have time, I think the right solution is to move to PT_ATTACHEXC. Sooner or later, we would have to do the switch anyways. Here is a snippet from the man page of ptrace() from Mac OSX version 10.11.6. PT_ATTACH This call has been replaced with PT_ATTACHEXC. PT_ATTACHEXC This request allows a process to gain control of an otherwise unrelated process and begin tracing it. It does not need any cooperation from the to-be-traced process. In this case, pid specifies the process ID of the to-be-traced process, and the other two arguments are ignored. This request requires that the target process must have the same real UID as the tracing process, and that it must not be executing a setuid or setgid executable. (If the tracing process is running as root, these restrictions do not apply.) The tracing process will see the newly-traced process stop and may then control it as if it had been traced all along. Note that this call differs from the prior call ( PT_ATTACH) in that signals from the child are delivered to the parent as Mach exceptions (see EXC_SOFT_SIGNAL). Moreover other debuggers like gdb and lldb have switched to using PT_ATTACHEXC. As pointed out in the link also, ptrace() on Apple has always been bare-bones. We need to supplement it with acquiring port rights to an exception port and waiting on that port where we can receive the Mach exception messages. My modifications are along the above lines. Thank you, Jini. On 9/8/2017 3:33 AM, serguei.spitsyn at oracle.com wrote: > On 9/7/17 14:39, serguei.spitsyn at oracle.com wrote: >> On 8/25/17 02:24, serguei.spitsyn at oracle.com wrote: >>> Hi Jini, >>> >>> >>> On 8/18/17 04:00, David Holmes wrote: >>>> Hi Jini, >>>> >>>> Just reading the bug report and your description below this seems >>>> like a major change to try and use a facility (mach exceptions) >>>> that no one seems to have any experience with! That isn't something >>>> to be rushed. >>> >>>> Even if PT_ATTACH has been deprecated restoring its use may be the >>>> quick way forward instead of trying to rush in something like this. >>> >>> This approach looks reasonable to me. >> >> I've just realized that my statement might sound incorrectly. >> I meant that the David's suggestion to restore the use of the >> deprecated PT_ATTACH looks reasonable. > > Forgot to send a link. > Not sure, if an approach of replacing ptrace usage could be reasonable: > http://uninformed.org/index.cgi?v=4&a=3&p=14 > > > Thanks, > Serguei > > >> >> Sorry, if it caused any confusion. >> >> Thanks, >> Serguei >> >> >>> Otherwise, it would be nice to hear why it is not good. >>> How much would it break the fix of the JDK-8182299? >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Just my 2c. >>>> >>>> Cheers, >>>> David >>>> >>>> On 18/08/2017 8:00 PM, Jini George wrote: >>>>> Hi all, >>>>> >>>>> Requesting reviews for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8184042 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/ >>>>> >>>>> Problem gist: The deprecated ptrace() command, PT_ATTACH was >>>>> changed to PT_ATTACHEXC, which causes mach exceptions (and not >>>>> UNIX signals) to be delivered via mach messages.This caused SA to >>>>> hang at waitpid() waiting for a signal, which does not arrive. >>>>> >>>>> Solution in a nutshell: The solution is to make the required >>>>> changes to handle mach 'soft signal' exceptions in the form of >>>>> mach messages instead of signals, while attaching to and detaching >>>>> from the target process. The detailed steps are outlined in JBS. >>>>> >>>>> The changes appear huge due to the inclusion of pre-generated mach >>>>> exception handling files (mach_exc*). Since this is an integration >>>>> blocker, it would be great to get quick reviews on this. >>>>> >>>>> Thank you, >>>>> Jini. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >> > From shafi.s.ahmad at oracle.com Fri Sep 8 07:34:47 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Fri, 8 Sep 2017 00:34:47 -0700 (PDT) Subject: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code In-Reply-To: <62aceca9-6710-4a3c-9f87-0cc15d064842@default> References: <131072bd-7d03-4f79-8ca0-6c26f9bbe315@default> <563f375f-b814-4544-9f88-5e8b99610324@oracle.com> <2559A0F3F1C918EE.d7de5b4c-3657-452b-91b0-2166e78f5f46@mail.outlook.com> <62aceca9-6710-4a3c-9f87-0cc15d064842@default> Message-ID: Gentle reminder. ? Regards, Shafi ? ? From: Shafi Ahmad Sent: Thursday, September 07, 2017 11:43 AM To: Daniel Daugherty ; serviceability-dev at openjdk.java.net Subject: RE: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code ? Hi Daniel, ? Thank you for the input. ? With this change I am not seeing any addition failure for all the suggested test suits. ? TEST 346/346 346/346 nsk/monitoring/ThreadMXBean/GetThreadAllocatedBytes/stressTest_proxy_custom PASS HARNESS ENDED: Wed Sep 06 00:00:49 PDT 2017 ? TOTAL TESTS IN RUN: 346 TEST PASS: 346; 100% rate TEST FAIL: 0; 0% rate TEST UNDEFINED: 0; 0% rate TEST INCOMPLETE: 0; 0% rate TESTS NOT RUN: 0 ? TOTAL TEST IN TESTLIST: 359 ? Passed: com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh Passed: com/sun/management/CheckSomeMXBeanImplPackage.java Passed: com/sun/management/VMOptionOpenDataTest.java Test results: passed: 30 Report written to /scratch/shshahma/Java/jdk10-dev-new/JTreport/html/report.html Results written to /scratch/shshahma/Java/jdk10-dev-new/JTwork ? Passed: java/lang/management/ThreadMXBean/ThreadUserTime.java Test results: passed: 65 Report written to /scratch/shshahma/Java/jdk10-dev-new/JTreport/html/report.html Results written to /scratch/shshahma/Java/jdk10-dev-new/JTwork ? Passed: jdk/internal/agent/AgentCheckTest.java Passed: jdk/internal/agent/AgentCMETest.java Test results: passed: 2 Report written to /scratch/shshahma/Java/jdk10-dev-new/JTreport/html/report.html Results written to /scratch/shshahma/Java/jdk10-dev-new/JTwor ? Passed: sun/management/PlatformMBeanProviderConstructorCheck.java Test results: passed: 33 Report written to /scratch/shshahma/Java/jdk10-dev-new/JTreport/html/report.html Results written to /scratch/shshahma/Java/jdk10-dev-new/JTwork ? Passed: javax/management/timer/StartTest.java Test results: passed: 243; failed: 1 Report written to /scratch/shshahma/Java/jdk10-dev-new/JTreport/html/report.html Results written to /scratch/shshahma/Java/jdk10-dev-new/JTwork Error: Some tests failed or other problems occurred. ? I verified the above failure and without my change it failed too. ? jdk10-dev-new$ jtreg -v1 -jdk:./build/linux-x64/jdk/? jdk/test/javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java FAILED: javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java Test results: failed: 1 Report written to /scratch/shshahma/Java/jdk10-dev-new/JTreport/html/report.html Results written to /scratch/shshahma/Java/jdk10-dev-new/JTwork Error: Some tests failed or other problems occurred. jdk10-dev-new$ tail ./JTwork/javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.jtr ??????? -Dtest.timeout.factor=1.0 \\ ??????? -Dtest.modules=java.management \\ ??????? --add-modules java.management \\ ??????? -Djmx-registry.host=jmx-registry-host \\ ??????? -Djmx-registry.port=jmx-registry-port \\ ??????? com.sun.javatest.regtest.agent.MainWrapper /scratch/shshahma/Java/jdk10-dev-new/JTwork/javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.d/main.0.jta result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Specify port with system property: -Djmx-registry.port= ? test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Specify port with system property: -Djmx-registry.port= ? Regards, Shafi ? From: Daniel D. Daugherty Sent: Tuesday, September 05, 2017 10:36 PM To: Shafi Ahmad ; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: Re: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code ? Sorry for the incomplete answer earlier. There are also relevant tests in: ??? jdk/test/java/lang/management ??? jdk/test/com/sun/management ??? jdk/test/sun/management ??? jdk/test/jdk/internal/agent ??? jdk/test/javax/management ??? jdk/test/com/sun/jmx You might want to just run the 'jdk_management' and 'jdk_jmx' test groups... that should also pick up any closed side tests... Dan ??? On 9/5/17 10:44 AM, Shafi Ahmad wrote: Thank you Daniel. I will run and update it with the result. Regards, Shafi ? On Tue, Sep 5, 2017 at 9:44 PM +0530, "Daniel D. Daugherty" wrote: Seems like you should also run: nsk.monitoring.testlist Dan On 9/4/17 4:11 AM, Shafi Ahmad wrote: Hi, ? Please review the fix for ?JDK-8170299: Debugger does not stop inside the low memory notifications code? to jdk10. ? With the current implementation ?debugger does not stop inside the low memory *notifications* code? This is expected as the notification code is getting executed with the service thread, which is a hidden thread. ? jdk10-dev-new$ jdb -Xmx32m MemoryWarningSystem Initializing jdb ... > stop at MemoryWarningSystem$1:25 Deferring breakpoint MemoryWarningSystem$1:25. It will be set after the class is loaded. > run run MemoryWarningSystem Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > . . . > quit ? Breakpoint not hit. ? With the attached webrev, jdb stop ?at breakpoint inside notification code. ? jdk10-dev-new$ jdb -Xmx64m MemoryWarningSystem Initializing jdb ... > stop at MemoryWarningSystem$1:25 Deferring breakpoint MemoryWarningSystem$1:25. It will be set after the class is loaded. > run run MemoryWarningSystem Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > VM Started: Set deferred breakpoint MemoryWarningSystem$1:25 ? Breakpoint hit: "thread=Thread-0", MemoryWarningSystem$1.memoryUsageLow(), line=25 bci=0 25??????????? System.out.println("Memory usage low!!!"); ? Thread-0[1] step > Memory usage low!!! ? Step completed: "thread=Thread-0", MemoryWarningSystem$1.memoryUsageLow(), line=26 bci=8 26??????????? double percentageUsed = ((double) usedMemory) / maxMemory; ? Thread-0[1] where ? [1] MemoryWarningSystem$1.memoryUsageLow (MemoryWarningSystem.java:26) ? [2] MemoryWarningSystem$2.handleNotification (MemoryWarningSystem.java:48) ? [3] javax.management.NotificationBroadcasterSupport.handleNotification (NotificationBroadcasterSupport.java:284) ? [4] javax.management.NotificationBroadcasterSupport$SendNotifJob.run (NotificationBroadcasterSupport.java:361) ? [5] java.lang.Thread.run (Thread.java:844) Thread-0[1] step > Step completed: "thread=Thread-0", MemoryWarningSystem$1.memoryUsageLow(), line=27 bci=15 27??????????? System.out.println("percentageUsed = " + percentageUsed); ? Thread-0[1] list 23??????? mws.addListener(new MemoryWarningSystem.Listener() { 24????????? public void memoryUsageLow(long usedMemory, long maxMemory) { 25??????????? System.out.println("Memory usage low!!!"); 26??????????? double percentageUsed = ((double) usedMemory) / maxMemory; 27 =>???????? System.out.println("percentageUsed = " + percentageUsed); 28??????????? MemoryWarningSystem.setPercentageUsageThreshold(0.8); 29????????? } 30??????? }); 31??? 32??????? Collection numbers = new LinkedList(); Thread-0[1] ? In the change, the class ?MemoryImpl? is derived from class ?NotificationBroadcasterSupport? instead of class ?NotificationEmitterSupport? NotificationBroadcastSupport takes an Executor, MemoryImpl constructor ?call super() with an executor, ?a visible thread. ? The method hasListeners() is referenced ?inside MemoryImpl.java and defined in ?NotificationEmitterSupport. This method is not present in ?NotificationBroadcasterSupport so I added it to NotificationBroadcasterSupport. ? Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8170299 Webrev link: HYPERLINK "http://cr.openjdk.java.net/%7Eshshahma/8170299/webrev.01/"http://cr.openjdk.java.net/~shshahma/8170299/webrev.01/ ? Testing: jprt -testset core, vm tonga tests nsk.jvmti.testlist, nsk.jdi.testlist, nsk.jdwp.testlist and jtreg tests ./jdk/test/com/sun/jdi/ ? Please let me know if I missed to test some more test suit[s]. ? Thanks to Mandy and Poonam for helping me in fixing this. ? Regards, Shafi ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Sun Sep 10 13:22:13 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 10 Sep 2017 22:22:13 +0900 Subject: 4 issues for HSDB In-Reply-To: <189ee30e-d25e-3615-8ec4-b0d7d7c3f112@gmail.com> References: <189ee30e-d25e-3615-8ec4-b0d7d7c3f112@gmail.com> Message-ID: PING: Have you checked these issues? I want to know I can file them to JBS and can send webrev. Yasumasa On 2017/08/31 23:49, Yasumasa Suenaga wrote: > Hi all, > > I attached HSDB to jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider . However, I found 4 issues. > I propose patches for them, but they are not yet filed to JBS. I want to file and to send review request after this discussion. > > > 1. Java Stack cannot be shown. > > ? - Suggested fix > ??? http://cr.openjdk.java.net/~ysuenaga/hsdb-fix/conflict-type/ > > ? - How to reproduce > ??? Choose "main" thread and click "Show Java stack trace" icon on "Java Threads" toolbar. > > ? - Stack trace > ``` > Exception in thread "AWT-EventQueue-0" sun.jvm.hotspot.utilities.AssertionFailure: type check > ????at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) > ????at jdk.hotspot.agent/sun.jvm.hotspot.runtime.StackValue.getObject(StackValue.java:59) > ????at jdk.hotspot.agent/sun.jvm.hotspot.runtime.StackValueCollection.oopHandleAt(StackValueCollection.java:51) > ????at jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTMLForJavaStackTrace(HTMLGenerator.java:1931) > ????at jdk.hotspot.agent/sun.jvm.hotspot.ui.JavaStackTracePanel.setJavaThread(JavaStackTracePanel.java:78) > ????at jdk.hotspot.agent/sun.jvm.hotspot.HSDB.showJavaStackTrace(HSDB.java:1526) > ``` > > ? I guess it is caused by inlined method which is generated by JIT compiler. > ? StackValue has T_CONFLICT value. It might be able to skip. > ? I'm not sure about this. So I need comments. > > > 2. ArrayIndexOutOfBoundsException is occurred on Stack Memory window > > ? - Suggested fix > ??? http://cr.openjdk.java.net/~ysuenaga/hsdb-fix/indy/ > > ? - How to reproduce > ??? Choose "main" thread and click "Stack Memory" icon on "Java Threads" toolbar. > > ? - Stack trace > ``` > Error while performing oopsDo for frame sp: 0x00007f80db89e590, unextendedSP: 0x00007f80db89e598, fp: 0x00007f80db89e5e8, pc: 0x00007f80bb7abf00 > java.lang.ArrayIndexOutOfBoundsException: 384 57 > ????at jdk.hotspot.agent/sun.jvm.hotspot.utilities.GenericArray.getIntegerAt(GenericArray.java:82) > ????at jdk.hotspot.agent/sun.jvm.hotspot.utilities.U2Array.at(U2Array.java:59) > ????at jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.invokedynamicCPCacheIndex(ConstantPool.java:278) > ????at jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.invokedynamicCPCacheEntryAt(ConstantPool.java:283) > ????at jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.implNameAndTypeRefIndexAt(ConstantPool.java:292) > ????at jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.implGetSignatureRefAt(ConstantPool.java:264) > ????at jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.getSignatureRefAt(ConstantPool.java:256) > ????at jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.doMethod(GenerateOopMap.java:1731) > ????at jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.interp1(GenerateOopMap.java:1386) > ????at jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.interpBB(GenerateOopMap.java:803) > ????at jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.interpAll(GenerateOopMap.java:1109) > ????at jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.doInterpretation(GenerateOopMap.java:982) > ????at jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.computeMap(GenerateOopMap.java:2199) > ????at jdk.hotspot.agent/sun.jvm.hotspot.interpreter.OopMapForCacheEntry.computeMap(OopMapForCacheEntry.java:80) > ????at jdk.hotspot.agent/sun.jvm.hotspot.interpreter.OopMapCacheEntry.fill(OopMapCacheEntry.java:53) > ????at jdk.hotspot.agent/sun.jvm.hotspot.oops.Method.getMaskFor(Method.java:261) > ????at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.oopsInterpretedDo(Frame.java:588) > ????at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.oopsDo(Frame.java:440) > ????at jdk.hotspot.agent/sun.jvm.hotspot.HSDB$34.run(HSDB.java:1038) > ``` > ? It seems to relate to JDK-8175816. > ? I guess SA handles incorrect data for ConstantPool for indy. It should be handled like invokedynamic_cp_cache_index(). > > > 3. UnknownOopException is occurred on Stack Memory window > > ? - Suggested fix > ??? http://cr.openjdk.java.net/~ysuenaga/hsdb-fix/oopmap/ > > ? - How to reproduce > ??? Choose "output reader" thread and click "Stack Memory" icon on "Java Threads" toolbar. > > ? - Stack trace > ``` > Error while performing oopsDo for frame sp: 0x00007f80986cb630, unextendedSP: 0x00007f80986cb630, fp: null, pc: 0x00007f80c32edfeb > sun.jvm.hotspot.oops.UnknownOopException > ????at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.newOop(ObjectHeap.java:264) > ????at jdk.hotspot.agent/sun.jvm.hotspot.HSDB$34$1.addAnnotation(HSDB.java:1098) > ????at jdk.hotspot.agent/sun.jvm.hotspot.HSDB$34$1.visitAddress(HSDB.java:1045) > ????at jdk.hotspot.agent/sun.jvm.hotspot.compiler.ImmutableOopMapSet$MyVisitor.visitOopLocation(ImmutableOopMapSet.java:58) > ????at jdk.hotspot.agent/sun.jvm.hotspot.compiler.ImmutableOopMapSet.allDo(ImmutableOopMapSet.java:230) > ????at jdk.hotspot.agent/sun.jvm.hotspot.compiler.ImmutableOopMapSet.oopsDo(ImmutableOopMapSet.java:179) > ????at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.oopsCodeBlobDo(Frame.java:618) > ????at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.oopsDo(Frame.java:444) > ????at jdk.hotspot.agent/sun.jvm.hotspot.HSDB$34.run(HSDB.java:1038) > ????at jdk.hotspot.agent/sun.jvm.hotspot.utilities.WorkerThread$MainLoop.run(WorkerThread.java:70) > ????at java.base/java.lang.Thread.run(Thread.java:844) > ``` > > ? According to frame::oopmapreg_to_location(), Frame#oopMapRegToLocation() should be calculated with "VMRegImpl::stack_slot_size". Not address size. > ? I saw similar exception and call stack at reverse pointer calculation. > > > 4. [Unknown generation] is shown in Stack Memory for output reader thread > > ? - Suggested fix > ??? http://cr.openjdk.java.net/~ysuenaga/hsdb-fix/stackmemory-g1/ > > ? - How to reproduce > ??? Choose "output reader" thread and click "Stack Memory" icon on "Java Threads" toolbar. > > ? HSDB.java is not handles G1CollectedHeap. So it is not detect the generation of oop. > > > Thanks, > > Yasumasa From david.holmes at oracle.com Sun Sep 10 20:53:56 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Sep 2017 06:53:56 +1000 Subject: 4 issues for HSDB In-Reply-To: References: <189ee30e-d25e-3615-8ec4-b0d7d7c3f112@gmail.com> Message-ID: Hi Yasumasa, On 10/09/2017 11:22 PM, Yasumasa Suenaga wrote: > PING: Have you checked these issues? > > I want to know I can file them to JBS and can send webrev. I would suggest going ahead and doing that. Thanks, David > > Yasumasa > > > On 2017/08/31 23:49, Yasumasa Suenaga wrote: >> Hi all, >> >> I attached HSDB to >> jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider . However, I >> found 4 issues. >> I propose patches for them, but they are not yet filed to JBS. I want >> to file and to send review request after this discussion. >> >> >> 1. Java Stack cannot be shown. >> >> ?? - Suggested fix >> ???? http://cr.openjdk.java.net/~ysuenaga/hsdb-fix/conflict-type/ >> >> ?? - How to reproduce >> ???? Choose "main" thread and click "Show Java stack trace" icon on >> "Java Threads" toolbar. >> >> ?? - Stack trace >> ``` >> Exception in thread "AWT-EventQueue-0" >> sun.jvm.hotspot.utilities.AssertionFailure: type check >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.StackValue.getObject(StackValue.java:59) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.StackValueCollection.oopHandleAt(StackValueCollection.java:51) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTMLForJavaStackTrace(HTMLGenerator.java:1931) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.ui.JavaStackTracePanel.setJavaThread(JavaStackTracePanel.java:78) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.HSDB.showJavaStackTrace(HSDB.java:1526) >> ``` >> >> ?? I guess it is caused by inlined method which is generated by JIT >> compiler. >> ?? StackValue has T_CONFLICT value. It might be able to skip. >> ?? I'm not sure about this. So I need comments. >> >> >> 2. ArrayIndexOutOfBoundsException is occurred on Stack Memory window >> >> ?? - Suggested fix >> ???? http://cr.openjdk.java.net/~ysuenaga/hsdb-fix/indy/ >> >> ?? - How to reproduce >> ???? Choose "main" thread and click "Stack Memory" icon on "Java >> Threads" toolbar. >> >> ?? - Stack trace >> ``` >> Error while performing oopsDo for frame sp: 0x00007f80db89e590, >> unextendedSP: 0x00007f80db89e598, fp: 0x00007f80db89e5e8, pc: >> 0x00007f80bb7abf00 >> java.lang.ArrayIndexOutOfBoundsException: 384 57 >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.utilities.GenericArray.getIntegerAt(GenericArray.java:82) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.utilities.U2Array.at(U2Array.java:59) >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.invokedynamicCPCacheIndex(ConstantPool.java:278) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.invokedynamicCPCacheEntryAt(ConstantPool.java:283) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.implNameAndTypeRefIndexAt(ConstantPool.java:292) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.implGetSignatureRefAt(ConstantPool.java:264) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.getSignatureRefAt(ConstantPool.java:256) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.doMethod(GenerateOopMap.java:1731) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.interp1(GenerateOopMap.java:1386) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.interpBB(GenerateOopMap.java:803) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.interpAll(GenerateOopMap.java:1109) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.doInterpretation(GenerateOopMap.java:982) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.computeMap(GenerateOopMap.java:2199) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.interpreter.OopMapForCacheEntry.computeMap(OopMapForCacheEntry.java:80) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.interpreter.OopMapCacheEntry.fill(OopMapCacheEntry.java:53) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.Method.getMaskFor(Method.java:261) >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.oopsInterpretedDo(Frame.java:588) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.oopsDo(Frame.java:440) >> ?????at jdk.hotspot.agent/sun.jvm.hotspot.HSDB$34.run(HSDB.java:1038) >> ``` >> ?? It seems to relate to JDK-8175816. >> ?? I guess SA handles incorrect data for ConstantPool for indy. It >> should be handled like invokedynamic_cp_cache_index(). >> >> >> 3. UnknownOopException is occurred on Stack Memory window >> >> ?? - Suggested fix >> ???? http://cr.openjdk.java.net/~ysuenaga/hsdb-fix/oopmap/ >> >> ?? - How to reproduce >> ???? Choose "output reader" thread and click "Stack Memory" icon on >> "Java Threads" toolbar. >> >> ?? - Stack trace >> ``` >> Error while performing oopsDo for frame sp: 0x00007f80986cb630, >> unextendedSP: 0x00007f80986cb630, fp: null, pc: 0x00007f80c32edfeb >> sun.jvm.hotspot.oops.UnknownOopException >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.newOop(ObjectHeap.java:264) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.HSDB$34$1.addAnnotation(HSDB.java:1098) >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.HSDB$34$1.visitAddress(HSDB.java:1045) >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.compiler.ImmutableOopMapSet$MyVisitor.visitOopLocation(ImmutableOopMapSet.java:58) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.compiler.ImmutableOopMapSet.allDo(ImmutableOopMapSet.java:230) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.compiler.ImmutableOopMapSet.oopsDo(ImmutableOopMapSet.java:179) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.oopsCodeBlobDo(Frame.java:618) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.oopsDo(Frame.java:444) >> ?????at jdk.hotspot.agent/sun.jvm.hotspot.HSDB$34.run(HSDB.java:1038) >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.utilities.WorkerThread$MainLoop.run(WorkerThread.java:70) >> >> ?????at java.base/java.lang.Thread.run(Thread.java:844) >> ``` >> >> ?? According to frame::oopmapreg_to_location(), >> Frame#oopMapRegToLocation() should be calculated with >> "VMRegImpl::stack_slot_size". Not address size. >> ?? I saw similar exception and call stack at reverse pointer calculation. >> >> >> 4. [Unknown generation] is shown in Stack Memory for output reader thread >> >> ?? - Suggested fix >> ???? http://cr.openjdk.java.net/~ysuenaga/hsdb-fix/stackmemory-g1/ >> >> ?? - How to reproduce >> ???? Choose "output reader" thread and click "Stack Memory" icon on >> "Java Threads" toolbar. >> >> ?? HSDB.java is not handles G1CollectedHeap. So it is not detect the >> generation of oop. >> >> >> Thanks, >> >> Yasumasa From yasuenag at gmail.com Mon Sep 11 01:40:41 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 11 Sep 2017 10:40:41 +0900 Subject: 4 issues for HSDB In-Reply-To: References: <189ee30e-d25e-3615-8ec4-b0d7d7c3f112@gmail.com> Message-ID: Thanks David ! I filed them to JBS. >>> 1. Java Stack cannot be shown. https://bugs.openjdk.java.net/browse/JDK-8187401 >>> 2. ArrayIndexOutOfBoundsException is occurred on Stack Memory window This issue is already filed as JDK-8175816, and assigned. I uploaded suggested fix and link to this mail thread. >>> 3. UnknownOopException is occurred on Stack Memory window https://bugs.openjdk.java.net/browse/JDK-8187402 >>> 4. [Unknown generation] is shown in Stack Memory for output reader thread https://bugs.openjdk.java.net/browse/JDK-8187403 I will send review requests for 1. , 3. , 4. later. Yasumasa 2017-09-11 5:53 GMT+09:00 David Holmes : > Hi Yasumasa, > > On 10/09/2017 11:22 PM, Yasumasa Suenaga wrote: >> >> PING: Have you checked these issues? >> >> I want to know I can file them to JBS and can send webrev. > > > I would suggest going ahead and doing that. > > Thanks, > David > > >> >> Yasumasa >> >> >> On 2017/08/31 23:49, Yasumasa Suenaga wrote: >>> >>> Hi all, >>> >>> I attached HSDB to jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider >>> . However, I found 4 issues. >>> I propose patches for them, but they are not yet filed to JBS. I want to >>> file and to send review request after this discussion. >>> >>> >>> 1. Java Stack cannot be shown. >>> >>> - Suggested fix >>> http://cr.openjdk.java.net/~ysuenaga/hsdb-fix/conflict-type/ >>> >>> - How to reproduce >>> Choose "main" thread and click "Show Java stack trace" icon on "Java >>> Threads" toolbar. >>> >>> - Stack trace >>> ``` >>> Exception in thread "AWT-EventQueue-0" >>> sun.jvm.hotspot.utilities.AssertionFailure: type check >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.runtime.StackValue.getObject(StackValue.java:59) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.runtime.StackValueCollection.oopHandleAt(StackValueCollection.java:51) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTMLForJavaStackTrace(HTMLGenerator.java:1931) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.ui.JavaStackTracePanel.setJavaThread(JavaStackTracePanel.java:78) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.HSDB.showJavaStackTrace(HSDB.java:1526) >>> ``` >>> >>> I guess it is caused by inlined method which is generated by JIT >>> compiler. >>> StackValue has T_CONFLICT value. It might be able to skip. >>> I'm not sure about this. So I need comments. >>> >>> >>> 2. ArrayIndexOutOfBoundsException is occurred on Stack Memory window >>> >>> - Suggested fix >>> http://cr.openjdk.java.net/~ysuenaga/hsdb-fix/indy/ >>> >>> - How to reproduce >>> Choose "main" thread and click "Stack Memory" icon on "Java Threads" >>> toolbar. >>> >>> - Stack trace >>> ``` >>> Error while performing oopsDo for frame sp: 0x00007f80db89e590, >>> unextendedSP: 0x00007f80db89e598, fp: 0x00007f80db89e5e8, pc: >>> 0x00007f80bb7abf00 >>> java.lang.ArrayIndexOutOfBoundsException: 384 57 >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.utilities.GenericArray.getIntegerAt(GenericArray.java:82) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.utilities.U2Array.at(U2Array.java:59) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.invokedynamicCPCacheIndex(ConstantPool.java:278) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.invokedynamicCPCacheEntryAt(ConstantPool.java:283) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.implNameAndTypeRefIndexAt(ConstantPool.java:292) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.implGetSignatureRefAt(ConstantPool.java:264) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.getSignatureRefAt(ConstantPool.java:256) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.doMethod(GenerateOopMap.java:1731) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.interp1(GenerateOopMap.java:1386) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.interpBB(GenerateOopMap.java:803) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.interpAll(GenerateOopMap.java:1109) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.doInterpretation(GenerateOopMap.java:982) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.computeMap(GenerateOopMap.java:2199) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.interpreter.OopMapForCacheEntry.computeMap(OopMapForCacheEntry.java:80) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.interpreter.OopMapCacheEntry.fill(OopMapCacheEntry.java:53) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.oops.Method.getMaskFor(Method.java:261) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.oopsInterpretedDo(Frame.java:588) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.oopsDo(Frame.java:440) >>> at jdk.hotspot.agent/sun.jvm.hotspot.HSDB$34.run(HSDB.java:1038) >>> ``` >>> It seems to relate to JDK-8175816. >>> I guess SA handles incorrect data for ConstantPool for indy. It should >>> be handled like invokedynamic_cp_cache_index(). >>> >>> >>> 3. UnknownOopException is occurred on Stack Memory window >>> >>> - Suggested fix >>> http://cr.openjdk.java.net/~ysuenaga/hsdb-fix/oopmap/ >>> >>> - How to reproduce >>> Choose "output reader" thread and click "Stack Memory" icon on "Java >>> Threads" toolbar. >>> >>> - Stack trace >>> ``` >>> Error while performing oopsDo for frame sp: 0x00007f80986cb630, >>> unextendedSP: 0x00007f80986cb630, fp: null, pc: 0x00007f80c32edfeb >>> sun.jvm.hotspot.oops.UnknownOopException >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.newOop(ObjectHeap.java:264) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.HSDB$34$1.addAnnotation(HSDB.java:1098) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.HSDB$34$1.visitAddress(HSDB.java:1045) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.compiler.ImmutableOopMapSet$MyVisitor.visitOopLocation(ImmutableOopMapSet.java:58) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.compiler.ImmutableOopMapSet.allDo(ImmutableOopMapSet.java:230) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.compiler.ImmutableOopMapSet.oopsDo(ImmutableOopMapSet.java:179) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.oopsCodeBlobDo(Frame.java:618) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.oopsDo(Frame.java:444) >>> at jdk.hotspot.agent/sun.jvm.hotspot.HSDB$34.run(HSDB.java:1038) >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.utilities.WorkerThread$MainLoop.run(WorkerThread.java:70) >>> at java.base/java.lang.Thread.run(Thread.java:844) >>> ``` >>> >>> According to frame::oopmapreg_to_location(), >>> Frame#oopMapRegToLocation() should be calculated with >>> "VMRegImpl::stack_slot_size". Not address size. >>> I saw similar exception and call stack at reverse pointer calculation. >>> >>> >>> 4. [Unknown generation] is shown in Stack Memory for output reader thread >>> >>> - Suggested fix >>> http://cr.openjdk.java.net/~ysuenaga/hsdb-fix/stackmemory-g1/ >>> >>> - How to reproduce >>> Choose "output reader" thread and click "Stack Memory" icon on "Java >>> Threads" toolbar. >>> >>> HSDB.java is not handles G1CollectedHeap. So it is not detect the >>> generation of oop. >>> >>> >>> Thanks, >>> >>> Yasumasa From yasuenag at gmail.com Mon Sep 11 02:16:33 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 11 Sep 2017 11:16:33 +0900 Subject: RFR: 8187401: Java Stack cannot be shown on HSDB Message-ID: Hi all, This review request is a part of [1]. JBS: https://bugs.openjdk.java.net/browse/JDK-8187401 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html From yasuenag at gmail.com Mon Sep 11 02:17:40 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 11 Sep 2017 11:17:40 +0900 Subject: RFR: 8187402: UnknownOopException is occurred on Stack Memory window in HSDB Message-ID: Hi all, This review request is a part of [1]. JBS: https://bugs.openjdk.java.net/browse/JDK-8187402 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.00/ I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html From yasuenag at gmail.com Mon Sep 11 02:18:32 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 11 Sep 2017 11:18:32 +0900 Subject: RFR: 8187403: [Unknown generation] is shown in Stack Memory on HSDB Message-ID: Hi all, This review request is a part of [1]. JBS: https://bugs.openjdk.java.net/browse/JDK-8187403 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.00/ I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html From martin at skarsaune.net Wed Sep 6 06:10:04 2017 From: martin at skarsaune.net (Martin Skarsaune) Date: Wed, 06 Sep 2017 06:10:04 +0000 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: <59AED139.4030102@oracle.com> Message-ID: Hello Would one at least consider adopting the same URL paths and payloads as Jolokia? This could make life a lot easier for third party tools that connect to it. Best Regards Martin Skarsaune ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B < harsha.wardhana.b at oracle.com>: > Hi Kirk, > > Yes. Jolokia was considered and is listed as an alternative in the JEP. > > > - Jolokia can serve as a viable alternative but can be bulky. We are > looking for simple and lightweight solution. > > > -Harsha > > On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote: > > Hi, > > Have you run into this project? https://jolokia.org. Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. > > Kind regards, > Kirk > > > On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: > > Hi Harsha, > > Looping in jmx-dev. > > > byte[], short[], int[], float[], double[] > > > Should long[] be included there as well? > > > The REST adapter will come with a simple and lightweight JSON parser. > > > Is this an internal parser or will it be exposed as an API? > > If so, how does it relate to JEP 198: Light-Weight JSON API?http://openjdk.java.net/jeps/198 > > Will com.sun.net.httpserver.HttpServer be used to serve the requests? > > Thanks > Erik > > > Hi All, > > Please review the JEP for REST APIs for JMX : > https://bugs.openjdk.java.net/browse/JDK-8171311 > > The JEP aims at providing RESTful web interfaces to MBeans. > > Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. > > Thanks > -Harsha > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Mon Sep 11 03:34:55 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Sun, 10 Sep 2017 20:34:55 -0700 Subject: RFR(10)(M): 8179498: attach in linux should be relative to /proc/pid/root and namespace aware In-Reply-To: <6434ed9c-7ea0-fe2d-d185-eca74c06ea0b@oracle.com> References: <6434ed9c-7ea0-fe2d-d185-eca74c06ea0b@oracle.com> Message-ID: <27b7a7af-e95b-4b36-5808-be8607f1b30b@oracle.com> [re-sending - sent to wrong alias first time] Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8179498 http://cr.openjdk.java.net/~cjplummer/8179498/webrev.00/webrev_jdk/ The CR has the relevant details. Some previous discussions can be found here: http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/021237.html http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-May/021249.html http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021679.html Testing with docker has been limited to just making sure jcmd now works with the docker setup I was provided. I currently don't see how we can run our existing tests in a way that would test the docker support without doing some rewriting of the tests. I also ran all our hotspot tier1, 2, and 3 tests, along with jdk/test/tools and jdk/test/sun/tools tests to make sure existing functionality is not broken with these changes. thanks, Chris From jini.george at oracle.com Mon Sep 11 09:55:30 2017 From: jini.george at oracle.com (Jini George) Date: Mon, 11 Sep 2017 15:25:30 +0530 Subject: 4 issues for HSDB In-Reply-To: References: <189ee30e-d25e-3615-8ec4-b0d7d7c3f112@gmail.com> Message-ID: <364b37af-0431-c4c0-d597-ad9a5df31a55@oracle.com> Hi Yasumasa, I have assigned https://bugs.openjdk.java.net/browse/JDK-8175816 to you. Thanks, Jini. On 9/10/2017 6:52 PM, Yasumasa Suenaga wrote: > PING: Have you checked these issues? > > I want to know I can file them to JBS and can send webrev. > > > Yasumasa > > > On 2017/08/31 23:49, Yasumasa Suenaga wrote: >> Hi all, >> >> I attached HSDB to >> jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider . However, I >> found 4 issues. >> I propose patches for them, but they are not yet filed to JBS. I want >> to file and to send review request after this discussion. >> >> >> 1. Java Stack cannot be shown. >> >> - Suggested fix >> http://cr.openjdk.java.net/~ysuenaga/hsdb-fix/conflict-type/ >> >> - How to reproduce >> Choose "main" thread and click "Show Java stack trace" icon on >> "Java Threads" toolbar. >> >> - Stack trace >> ``` >> Exception in thread "AWT-EventQueue-0" >> sun.jvm.hotspot.utilities.AssertionFailure: type check >> at >> jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.StackValue.getObject(StackValue.java:59) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.StackValueCollection.oopHandleAt(StackValueCollection.java:51) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.ui.classbrowser.HTMLGenerator.genHTMLForJavaStackTrace(HTMLGenerator.java:1931) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.ui.JavaStackTracePanel.setJavaThread(JavaStackTracePanel.java:78) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.HSDB.showJavaStackTrace(HSDB.java:1526) >> ``` >> >> I guess it is caused by inlined method which is generated by JIT >> compiler. >> StackValue has T_CONFLICT value. It might be able to skip. >> I'm not sure about this. So I need comments. >> >> >> 2. ArrayIndexOutOfBoundsException is occurred on Stack Memory window >> >> - Suggested fix >> http://cr.openjdk.java.net/~ysuenaga/hsdb-fix/indy/ >> >> - How to reproduce >> Choose "main" thread and click "Stack Memory" icon on "Java >> Threads" toolbar. >> >> - Stack trace >> ``` >> Error while performing oopsDo for frame sp: 0x00007f80db89e590, >> unextendedSP: 0x00007f80db89e598, fp: 0x00007f80db89e5e8, pc: >> 0x00007f80bb7abf00 >> java.lang.ArrayIndexOutOfBoundsException: 384 57 >> at >> jdk.hotspot.agent/sun.jvm.hotspot.utilities.GenericArray.getIntegerAt(GenericArray.java:82) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.utilities.U2Array.at(U2Array.java:59) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.invokedynamicCPCacheIndex(ConstantPool.java:278) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.invokedynamicCPCacheEntryAt(ConstantPool.java:283) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.implNameAndTypeRefIndexAt(ConstantPool.java:292) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.implGetSignatureRefAt(ConstantPool.java:264) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.getSignatureRefAt(ConstantPool.java:256) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.doMethod(GenerateOopMap.java:1731) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.interp1(GenerateOopMap.java:1386) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.interpBB(GenerateOopMap.java:803) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.interpAll(GenerateOopMap.java:1109) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.doInterpretation(GenerateOopMap.java:982) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.computeMap(GenerateOopMap.java:2199) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.interpreter.OopMapForCacheEntry.computeMap(OopMapForCacheEntry.java:80) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.interpreter.OopMapCacheEntry.fill(OopMapCacheEntry.java:53) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.Method.getMaskFor(Method.java:261) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.oopsInterpretedDo(Frame.java:588) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.oopsDo(Frame.java:440) >> at jdk.hotspot.agent/sun.jvm.hotspot.HSDB$34.run(HSDB.java:1038) >> ``` >> It seems to relate to JDK-8175816. >> I guess SA handles incorrect data for ConstantPool for indy. It >> should be handled like invokedynamic_cp_cache_index(). >> >> >> 3. UnknownOopException is occurred on Stack Memory window >> >> - Suggested fix >> http://cr.openjdk.java.net/~ysuenaga/hsdb-fix/oopmap/ >> >> - How to reproduce >> Choose "output reader" thread and click "Stack Memory" icon on >> "Java Threads" toolbar. >> >> - Stack trace >> ``` >> Error while performing oopsDo for frame sp: 0x00007f80986cb630, >> unextendedSP: 0x00007f80986cb630, fp: null, pc: 0x00007f80c32edfeb >> sun.jvm.hotspot.oops.UnknownOopException >> at >> jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.newOop(ObjectHeap.java:264) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.HSDB$34$1.addAnnotation(HSDB.java:1098) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.HSDB$34$1.visitAddress(HSDB.java:1045) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.compiler.ImmutableOopMapSet$MyVisitor.visitOopLocation(ImmutableOopMapSet.java:58) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.compiler.ImmutableOopMapSet.allDo(ImmutableOopMapSet.java:230) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.compiler.ImmutableOopMapSet.oopsDo(ImmutableOopMapSet.java:179) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.oopsCodeBlobDo(Frame.java:618) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.oopsDo(Frame.java:444) >> at jdk.hotspot.agent/sun.jvm.hotspot.HSDB$34.run(HSDB.java:1038) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.utilities.WorkerThread$MainLoop.run(WorkerThread.java:70) >> at java.base/java.lang.Thread.run(Thread.java:844) >> ``` >> >> According to frame::oopmapreg_to_location(), >> Frame#oopMapRegToLocation() should be calculated with >> "VMRegImpl::stack_slot_size". Not address size. >> I saw similar exception and call stack at reverse pointer >> calculation. >> >> >> 4. [Unknown generation] is shown in Stack Memory for output reader >> thread >> >> - Suggested fix >> http://cr.openjdk.java.net/~ysuenaga/hsdb-fix/stackmemory-g1/ >> >> - How to reproduce >> Choose "output reader" thread and click "Stack Memory" icon on >> "Java Threads" toolbar. >> >> HSDB.java is not handles G1CollectedHeap. So it is not detect the >> generation of oop. >> >> >> Thanks, >> >> Yasumasa From erik.gahlin at oracle.com Mon Sep 11 13:44:22 2017 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 11 Sep 2017 15:44:22 +0200 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: <59AED139.4030102@oracle.com> Message-ID: <59B69336.7070200@oracle.com> Hi Harsha, I haven't looked at Jolokia, or know what is the most reasonable approach in this case, but as a principle, I think we should strive for the best possible design rather than trying to be compatible with third party tools. How will the command line look like to start the agent with the rest adapter? In the past there have been discussions about adding syntactic sugar for -Dcom.sun.management, i.e. -Xmanagement:ssl=false,port=7091,authenticate=false instead of -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.port=7091 -Dcom.sun.management.jmxremote.authenticate=false which is hard to remember, cumbersome to write and error prone since the parameters are not validated. If we are adding support for REST, it could perhaps be default, i.e. -Xmanagement:ssl=false,authenticate=false,port=80 If you want to use JMX over RMI you would specify protocol: -Xmanagement:ssl=false,port=7091,authenticate=false,protocol=rmi Has there been any thoughts about JMX notifications? I know it is outside the scope of the JEP, but I think we should take it into consideration when doing the design, so the functionality could be added on later without too much difficulty. Thanks Erik > Hi Martin, > > In my opinion, the interfaces exposed by current JEP are lot closer to > REST style than the interfaces exposed by Jolokia. > > For instance, HTTP GET by default should be used to read resources, > but it is made part of URL in Jolokia interfaces. > > /read/// > > I would wait on opinions from more people before considering changing > the current interfaces. > > Thanks > -Harsha > > On Wednesday 06 September 2017 11:40 AM, Martin Skarsaune wrote: >> Hello >> >> Would one at least consider adopting the same URL paths and payloads >> as Jolokia? This could make life a lot easier for third party tools >> that connect to it. >> >> Best Regards >> >> Martin Skarsaune >> >> ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B >> >: >> >> Hi Kirk, >> >> Yes. Jolokia was considered and is listed as an alternative in >> the JEP. >> >> * Jolokia can serve as a viable alternative but can be bulky. >> We are looking for simple and lightweight solution. >> >> >> -Harsha >> >> On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote: >>> Hi, >>> >>> Have you run into this project?https://jolokia.org. Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. >>> >>> Kind regards, >>> Kirk >>> >>>> On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: >>>> >>>> Hi Harsha, >>>> >>>> Looping in jmx-dev. >>>> >>>>> byte[], short[], int[], float[], double[] >>>> Should long[] be included there as well? >>>> >>>>> The REST adapter will come with a simple and lightweight JSON parser. >>>> Is this an internal parser or will it be exposed as an API? >>>> >>>> If so, how does it relate to JEP 198: Light-Weight JSON API? >>>> http://openjdk.java.net/jeps/198 >>>> >>>> Will com.sun.net.httpserver.HttpServer be used to serve the requests? >>>> >>>> Thanks >>>> Erik >>>> >>>>> Hi All, >>>>> >>>>> Please review the JEP for REST APIs for JMX : >>>>> https://bugs.openjdk.java.net/browse/JDK-8171311 >>>>> >>>>> The JEP aims at providing RESTful web interfaces to MBeans. >>>>> >>>>> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. >>>>> >>>>> Thanks >>>>> -Harsha >>>>> >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Mon Sep 11 13:47:40 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 11 Sep 2017 22:47:40 +0900 Subject: RFR: 8175816: SA: HSDB: Compute Liveness results in java.lang.IndexOutOfBoundsException Message-ID: <5097216b-f757-dd2b-70bc-b3a860bdebfa@gmail.com> Hi all, This review request is a part of [1]. JBS: https://bugs.openjdk.java.net/browse/JDK-8175816 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.00/ I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html From harsha.wardhana.b at oracle.com Mon Sep 11 14:08:59 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 11 Sep 2017 19:38:59 +0530 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <59B69336.7070200@oracle.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> Message-ID: <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> Hi Erik, On Monday 11 September 2017 07:14 PM, Erik Gahlin wrote: > Hi Harsha, > > I haven't looked at Jolokia, or know what is the most reasonable > approach in this case, but as a principle, I think we should strive > for the best possible design rather than trying to be compatible with > third party tools. Agreed. That will always be the first priority. That is the reason HTTP GET interfaces will not be changed. I am undecided if the POST payloads need to be changed (without compromising the REST design principles) to increase adoption of this feature. > > How will the command line look like to start the agent with the rest > adapter? > > In the past there have been discussions about adding syntactic sugar > for -Dcom.sun.management, i.e. > > -Xmanagement:ssl=false,port=7091,authenticate=false > > instead of > > -Dcom.sun.management.jmxremote.ssl=false > -Dcom.sun.management.jmxremote.port=7091 > -Dcom.sun.management.jmxremote.authenticate=false > > which is hard to remember, cumbersome to write and error prone since > the parameters are not validated. If we are adding support for REST, > it could perhaps be default, i.e. > > -Xmanagement:ssl=false,authenticate=false,port=80 > > If you want to use JMX over RMI you would specify protocol: > > -Xmanagement:ssl=false,port=7091,authenticate=false,protocol=rmi Yes. There is an enhancement request to add the -Xmanagemet:* syntatic sugar for -Dcom.sun.management.jmxremote.* flags. REST adapter will use one of the above flags though I haven't thought of the exact name for it yet. I will update the JEP with the details of the flag shortly. > > Has there been any thoughts about JMX notifications? Notifications will not be supported in this JEP. * MBean Notifications are not a widely used feature and will not be supported via the REST adapter. > > I know it is outside the scope of the JEP, but I think we should take > it into consideration when doing the design, so the functionality > could be added on later without too much difficulty. Notifications can be added without modifying the current design too much. If required, it will be worked upon via an enhancement request. > > Thanks > Erik > Thanks Harsha >> >> Hi Martin, >> >> In my opinion, the interfaces exposed by current JEP are lot closer >> to REST style than the interfaces exposed by Jolokia. >> >> For instance, HTTP GET by default should be used to read resources, >> but it is made part of URL in Jolokia interfaces. >> >> /read/// >> >> I would wait on opinions from more people before considering changing >> the current interfaces. >> >> Thanks >> -Harsha >> >> On Wednesday 06 September 2017 11:40 AM, Martin Skarsaune wrote: >>> Hello >>> >>> Would one at least consider adopting the same URL paths and payloads >>> as Jolokia? This could make life a lot easier for third party tools >>> that connect to it. >>> >>> Best Regards >>> >>> Martin Skarsaune >>> >>> ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B >>> >: >>> >>> Hi Kirk, >>> >>> Yes. Jolokia was considered and is listed as an alternative in >>> the JEP. >>> >>> * Jolokia can serve as a viable alternative but can be bulky. >>> We are looking for simple and lightweight solution. >>> >>> >>> -Harsha >>> >>> On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote: >>>> Hi, >>>> >>>> Have you run into this project?https://jolokia.org. Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. >>>> >>>> Kind regards, >>>> Kirk >>>> >>>>> On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: >>>>> >>>>> Hi Harsha, >>>>> >>>>> Looping in jmx-dev. >>>>> >>>>>> byte[], short[], int[], float[], double[] >>>>> Should long[] be included there as well? >>>>> >>>>>> The REST adapter will come with a simple and lightweight JSON parser. >>>>> Is this an internal parser or will it be exposed as an API? >>>>> >>>>> If so, how does it relate to JEP 198: Light-Weight JSON API? >>>>> http://openjdk.java.net/jeps/198 >>>>> >>>>> Will com.sun.net.httpserver.HttpServer be used to serve the requests? >>>>> >>>>> Thanks >>>>> Erik >>>>> >>>>>> Hi All, >>>>>> >>>>>> Please review the JEP for REST APIs for JMX : >>>>>> https://bugs.openjdk.java.net/browse/JDK-8171311 >>>>>> >>>>>> The JEP aims at providing RESTful web interfaces to MBeans. >>>>>> >>>>>> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. >>>>>> >>>>>> Thanks >>>>>> -Harsha >>>>>> >>>>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Mon Sep 11 15:35:45 2017 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Mon, 11 Sep 2017 17:35:45 +0200 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> Message-ID: <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> Hi Harsha, The only reason I mentioned Jolokia is that it?s a project that usefulness is some what limited because it is *not* a compliment JMX connector and as such cannot be used as a straight drop-in replacement for the current RMI based connector. Is your plan here to make it a fully compliant connector so that we could configure tooling such as the MBean viewers in jConsole and VisualVM (or JMC for that matter) to use a restful connector instead of an RMI based connector? IMHO, doing so would represent a huge win as I know of quite a few projects that cannot or will not use JMX because of it?s reliance on RMI. Consolidating all of the options under a single flag looks like another interesting win. Kind regards, Kirk > On Sep 11, 2017, at 4:08 PM, Harsha Wardhana B wrote: > > Hi Erik, > > On Monday 11 September 2017 07:14 PM, Erik Gahlin wrote: >> Hi Harsha, >> >> I haven't looked at Jolokia, or know what is the most reasonable approach in this case, but as a principle, I think we should strive for the best possible design rather than trying to be compatible with third party tools. > Agreed. That will always be the first priority. That is the reason HTTP GET interfaces will not be changed. I am undecided if the POST payloads need to be changed (without compromising the REST design principles) to increase adoption of this feature. >> >> How will the command line look like to start the agent with the rest adapter? >> >> In the past there have been discussions about adding syntactic sugar for -Dcom.sun.management, i.e. >> >> -Xmanagement:ssl=false,port=7091,authenticate=false >> >> instead of >> >> -Dcom.sun.management.jmxremote.ssl=false >> -Dcom.sun.management.jmxremote.port=7091 >> -Dcom.sun.management.jmxremote.authenticate=false >> >> which is hard to remember, cumbersome to write and error prone since the parameters are not validated. If we are adding support for REST, it could perhaps be default, i.e. >> >> -Xmanagement:ssl=false,authenticate=false,port=80 >> >> If you want to use JMX over RMI you would specify protocol: >> >> -Xmanagement:ssl=false,port=7091,authenticate=false,protocol=rmi > Yes. There is an enhancement request to add the -Xmanagemet:* syntatic sugar for -Dcom.sun.management.jmxremote.* flags. REST adapter will use one of the above flags though I haven't thought of the exact name for it yet. I will update the JEP with the details of the flag shortly. >> >> Has there been any thoughts about JMX notifications? > Notifications will not be supported in this JEP. > MBean Notifications are not a widely used feature and will not be supported via the REST adapter. >> >> I know it is outside the scope of the JEP, but I think we should take it into consideration when doing the design, so the functionality could be added on later without too much difficulty. > Notifications can be added without modifying the current design too much. If required, it will be worked upon via an enhancement request. >> >> Thanks >> Erik >> > Thanks > Harsha >>> Hi Martin, >>> >>> In my opinion, the interfaces exposed by current JEP are lot closer to REST style than the interfaces exposed by Jolokia. >>> For instance, HTTP GET by default should be used to read resources, but it is made part of URL in Jolokia interfaces. >>> >>> /read/// >>> >>> I would wait on opinions from more people before considering changing the current interfaces. >>> >>> Thanks >>> -Harsha >>> >>> On Wednesday 06 September 2017 11:40 AM, Martin Skarsaune wrote: >>>> Hello >>>> >>>> Would one at least consider adopting the same URL paths and payloads as Jolokia? This could make life a lot easier for third party tools that connect to it. >>>> >>>> Best Regards >>>> >>>> Martin Skarsaune >>>> >>>> ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B >: >>>> Hi Kirk, >>>> >>>> Yes. Jolokia was considered and is listed as an alternative in the JEP. >>>> >>>> Jolokia can serve as a viable alternative but can be bulky. We are looking for simple and lightweight solution. >>>> >>>> -Harsha >>>> >>>> On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote: >>>>> Hi, >>>>> >>>>> Have you run into this project? https://jolokia.org . Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. >>>>> >>>>> Kind regards, >>>>> Kirk >>>>> >>>> >>>>>> On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: >>>>>> >>>>>> Hi Harsha, >>>>>> >>>>>> Looping in jmx-dev. >>>>>> >>>>>>> byte[], short[], int[], float[], double[] >>>>>> Should long[] be included there as well? >>>>>> >>>>>>> The REST adapter will come with a simple and lightweight JSON parser. >>>>>> Is this an internal parser or will it be exposed as an API? >>>>>> >>>>>> If so, how does it relate to JEP 198: Light-Weight JSON API? >>>>>> http://openjdk.java.net/jeps/198 >>>>>> >>>>>> Will com.sun.net.httpserver.HttpServer be used to serve the requests? >>>>>> >>>>>> Thanks >>>>>> Erik >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> Please review the JEP for REST APIs for JMX : >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171311 >>>>>>> >>>>>>> The JEP aims at providing RESTful web interfaces to MBeans. >>>>>>> >>>>>>> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. >>>>>>> >>>>>>> Thanks >>>>>>> -Harsha >>>>>>> >>>>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at skarsaune.net Mon Sep 11 19:46:33 2017 From: martin at skarsaune.net (Martin Skarsaune) Date: Mon, 11 Sep 2017 19:46:33 +0000 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> Message-ID: Hi Harsha and Erik I certainly understand the desire to design the API well. My point was just that when there is a mature battle-tested de-facto solution out in the wild, it would be a pity not to see potential for interoperability where the solutions are in fact really close. To illustrate where I'm coming from, I hacked the source of a plugin that is able to control the flight recorder via JMX , to adapt the POST payloads to this JEP. Assuming I understood it correctly the changes are quite small, but would the require a complete rewrite of all plugins, a layer of indirection or even worse a compatibility layer to use it. Note: I assumed the arguments are still an array and not an object? ([] , not {}) ? You can see an example of what changes would typically be needed here: https://github.com/skarsaune/hawtio/commit/36ca65f495f05d20061b001fcc291ed3bc6e183f Cheers Martin man. 11. sep. 2017 kl. 17:36 skrev Kirk Pepperdine < kirk.pepperdine at gmail.com>: > Hi Harsha, > > The only reason I mentioned Jolokia is that it?s a project that usefulness > is some what limited because it is *not* a compliment JMX connector and as > such cannot be used as a straight drop-in replacement for the current RMI > based connector. Is your plan here to make it a fully compliant connector > so that we could configure tooling such as the MBean viewers in jConsole > and VisualVM (or JMC for that matter) to use a restful connector instead of > an RMI based connector? IMHO, doing so would represent a huge win as I know > of quite a few projects that cannot or will not use JMX because of it?s > reliance on RMI. > > Consolidating all of the options under a single flag looks like another > interesting win. > > Kind regards, > Kirk > > > > On Sep 11, 2017, at 4:08 PM, Harsha Wardhana B < > harsha.wardhana.b at oracle.com> wrote: > > Hi Erik, > > On Monday 11 September 2017 07:14 PM, Erik Gahlin wrote: > > Hi Harsha, > > I haven't looked at Jolokia, or know what is the most reasonable approach > in this case, but as a principle, I think we should strive for the best > possible design rather than trying to be compatible with third party tools. > > Agreed. That will always be the first priority. That is the reason HTTP > GET interfaces will not be changed. I am undecided if the POST payloads > need to be changed (without compromising the REST design principles) to > increase adoption of this feature. > > > How will the command line look like to start the agent with the rest > adapter? > > In the past there have been discussions about adding syntactic sugar for > -Dcom.sun.management, i.e. > > -Xmanagement:ssl=false,port=7091,authenticate=false > > instead of > > -Dcom.sun.management.jmxremote.ssl=false > -Dcom.sun.management.jmxremote.port=7091 > -Dcom.sun.management.jmxremote.authenticate=false > > which is hard to remember, cumbersome to write and error prone since the > parameters are not validated. If we are adding support for REST, it could > perhaps be default, i.e. > > -Xmanagement:ssl=false,authenticate=false,port=80 > > If you want to use JMX over RMI you would specify protocol: > > -Xmanagement:ssl=false,port=7091,authenticate=false,protocol=rmi > > Yes. There is an enhancement request to add the -Xmanagemet:* syntatic > sugar for -Dcom.sun.management.jmxremote.* flags. REST adapter will use one > of the above flags though I haven't thought of the exact name for it yet. I > will update the JEP with the details of the flag shortly. > > > Has there been any thoughts about JMX notifications? > > Notifications will not be supported in this JEP. > > - MBean Notifications are not a widely used feature and will not be > supported via the REST adapter. > > > I know it is outside the scope of the JEP, but I think we should take it > into consideration when doing the design, so the functionality could be > added on later without too much difficulty. > > Notifications can be added without modifying the current design too much. > If required, it will be worked upon via an enhancement request. > > > Thanks > Erik > > Thanks > Harsha > > Hi Martin, > > In my opinion, the interfaces exposed by current JEP are lot closer to > REST style than the interfaces exposed by Jolokia. > > For instance, HTTP GET by default should be used to read resources, but it > is made part of URL in Jolokia interfaces. > > /read/// > > > I would wait on opinions from more people before considering changing the > current interfaces. > > Thanks > -Harsha > > On Wednesday 06 September 2017 11:40 AM, Martin Skarsaune wrote: > > Hello > > Would one at least consider adopting the same URL paths and payloads as > Jolokia? This could make life a lot easier for third party tools that > connect to it. > > Best Regards > > Martin Skarsaune > > ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B < > harsha.wardhana.b at oracle.com>: > >> Hi Kirk, >> >> Yes. Jolokia was considered and is listed as an alternative in the JEP. >> >> >> - Jolokia can serve as a viable alternative but can be bulky. We are >> looking for simple and lightweight solution. >> >> >> -Harsha >> >> On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote: >> >> Hi, >> >> Have you run into this project? https://jolokia.org. Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. >> >> Kind regards, >> Kirk >> >> >> On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: >> >> Hi Harsha, >> >> Looping in jmx-dev. >> >> >> byte[], short[], int[], float[], double[] >> >> Should long[] be included there as well? >> >> >> The REST adapter will come with a simple and lightweight JSON parser. >> >> Is this an internal parser or will it be exposed as an API? >> >> If so, how does it relate to JEP 198: Light-Weight JSON API?http://openjdk.java.net/jeps/198 >> >> Will com.sun.net.httpserver.HttpServer be used to serve the requests? >> >> Thanks >> Erik >> >> >> Hi All, >> >> Please review the JEP for REST APIs for JMX : >> https://bugs.openjdk.java.net/browse/JDK-8171311 >> >> The JEP aims at providing RESTful web interfaces to MBeans. >> >> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. >> >> Thanks >> -Harsha >> >> >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Mon Sep 11 19:55:49 2017 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Mon, 11 Sep 2017 21:55:49 +0200 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> Message-ID: <22425ECF-1825-4764-9BBE-EF5A0B7904F7@gmail.com> > On Sep 11, 2017, at 9:46 PM, Martin Skarsaune wrote: > > Hi Harsha and Erik > > I certainly understand the desire to design the API well. > My point was just that when there is a mature battle-tested de-facto solution out in the wild, I would agree that there are lessons to be learned from Jolokia. It is a great/useful tool but it is not a JMXConnector. IMHO the REST layer should be implemented as a JMXConnector. It is the implementation that has the ability to integrate with widest set of exiting tooling. Kind regards, Kirk Pepperdine > it would be a pity not to see potential for interoperability where the solutions are in fact really close. > To illustrate where I'm coming from, I hacked the source of a plugin that is able to control the flight recorder via JMX , to adapt the POST payloads to this JEP. > Assuming I understood it correctly the changes are quite small, but would the require a complete rewrite of all plugins, a layer of indirection or even worse a compatibility layer to use it. > Note: I assumed the arguments are still an array and not an object? ([] , not {}) ? > > You can see an example of what changes would typically be needed here: > https://github.com/skarsaune/hawtio/commit/36ca65f495f05d20061b001fcc291ed3bc6e183f > > Cheers > > Martin > > > man. 11. sep. 2017 kl. 17:36 skrev Kirk Pepperdine >: > Hi Harsha, > > The only reason I mentioned Jolokia is that it?s a project that usefulness is some what limited because it is *not* a compliment JMX connector and as such cannot be used as a straight drop-in replacement for the current RMI based connector. Is your plan here to make it a fully compliant connector so that we could configure tooling such as the MBean viewers in jConsole and VisualVM (or JMC for that matter) to use a restful connector instead of an RMI based connector? IMHO, doing so would represent a huge win as I know of quite a few projects that cannot or will not use JMX because of it?s reliance on RMI. > > Consolidating all of the options under a single flag looks like another interesting win. > > Kind regards, > Kirk > > > >> On Sep 11, 2017, at 4:08 PM, Harsha Wardhana B > wrote: >> >> Hi Erik, >> >> On Monday 11 September 2017 07:14 PM, Erik Gahlin wrote: >>> Hi Harsha, >>> >>> I haven't looked at Jolokia, or know what is the most reasonable approach in this case, but as a principle, I think we should strive for the best possible design rather than trying to be compatible with third party tools. >> Agreed. That will always be the first priority. That is the reason HTTP GET interfaces will not be changed. I am undecided if the POST payloads need to be changed (without compromising the REST design principles) to increase adoption of this feature. >>> >>> How will the command line look like to start the agent with the rest adapter? >>> >>> In the past there have been discussions about adding syntactic sugar for -Dcom.sun.management, i.e. >>> >>> -Xmanagement:ssl=false,port=7091,authenticate=false >>> >>> instead of >>> >>> -Dcom.sun.management.jmxremote.ssl=false >>> -Dcom.sun.management.jmxremote.port=7091 >>> -Dcom.sun.management.jmxremote.authenticate=false >>> >>> which is hard to remember, cumbersome to write and error prone since the parameters are not validated. If we are adding support for REST, it could perhaps be default, i.e. >>> >>> -Xmanagement:ssl=false,authenticate=false,port=80 >>> >>> If you want to use JMX over RMI you would specify protocol: >>> >>> -Xmanagement:ssl=false,port=7091,authenticate=false,protocol=rmi >> Yes. There is an enhancement request to add the -Xmanagemet:* syntatic sugar for -Dcom.sun.management.jmxremote.* flags. REST adapter will use one of the above flags though I haven't thought of the exact name for it yet. I will update the JEP with the details of the flag shortly. >>> >>> Has there been any thoughts about JMX notifications? >> Notifications will not be supported in this JEP. >> MBean Notifications are not a widely used feature and will not be supported via the REST adapter. >>> >>> I know it is outside the scope of the JEP, but I think we should take it into consideration when doing the design, so the functionality could be added on later without too much difficulty. >> Notifications can be added without modifying the current design too much. If required, it will be worked upon via an enhancement request. >>> >>> Thanks >>> Erik >>> >> Thanks >> Harsha >>>> Hi Martin, >>>> >>>> In my opinion, the interfaces exposed by current JEP are lot closer to REST style than the interfaces exposed by Jolokia. >>>> For instance, HTTP GET by default should be used to read resources, but it is made part of URL in Jolokia interfaces. >>>> >>>> /read/// >>>> >>>> I would wait on opinions from more people before considering changing the current interfaces. >>>> >>>> Thanks >>>> -Harsha >>>> >>>> On Wednesday 06 September 2017 11:40 AM, Martin Skarsaune wrote: >>>>> Hello >>>>> >>>>> Would one at least consider adopting the same URL paths and payloads as Jolokia? This could make life a lot easier for third party tools that connect to it. >>>>> >>>>> Best Regards >>>>> >>>>> Martin Skarsaune >>>>> >>>>> ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B >: >>>>> Hi Kirk, >>>>> >>>>> Yes. Jolokia was considered and is listed as an alternative in the JEP. >>>>> >>>>> Jolokia can serve as a viable alternative but can be bulky. We are looking for simple and lightweight solution. >>>>> >>>>> -Harsha >>>>> >>>>> On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote: >>>>>> Hi, >>>>>> >>>>>> Have you run into this project? https://jolokia.org . Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. >>>>>> >>>>>> Kind regards, >>>>>> Kirk >>>>>> >>>>> >>>>>>> On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: >>>>>>> >>>>>>> Hi Harsha, >>>>>>> >>>>>>> Looping in jmx-dev. >>>>>>> >>>>>>>> byte[], short[], int[], float[], double[] >>>>>>> Should long[] be included there as well? >>>>>>> >>>>>>>> The REST adapter will come with a simple and lightweight JSON parser. >>>>>>> Is this an internal parser or will it be exposed as an API? >>>>>>> >>>>>>> If so, how does it relate to JEP 198: Light-Weight JSON API? >>>>>>> http://openjdk.java.net/jeps/198 >>>>>>> >>>>>>> Will com.sun.net.httpserver.HttpServer be used to serve the requests? >>>>>>> >>>>>>> Thanks >>>>>>> Erik >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Please review the JEP for REST APIs for JMX : >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171311 >>>>>>>> >>>>>>>> The JEP aims at providing RESTful web interfaces to MBeans. >>>>>>>> >>>>>>>> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Harsha >>>>>>>> >>>>>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at skarsaune.net Mon Sep 11 20:30:44 2017 From: martin at skarsaune.net (Martin Skarsaune) Date: Mon, 11 Sep 2017 20:30:44 +0000 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <22425ECF-1825-4764-9BBE-EF5A0B7904F7@gmail.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> <22425ECF-1825-4764-9BBE-EF5A0B7904F7@gmail.com> Message-ID: I can agree to that. To be concrete, what does the JEP as it currently stands offer over jolokia to be able to support JMXConnector? Could the client interface and protocol be two separate concerns? BTW: jolokia 2.0 will have support for JMX Notifications https://ro14nd.de/jolokia-notifications Best Regards Martin Skarsaune man. 11. sep. 2017 kl. 21:55 skrev Kirk Pepperdine < kirk.pepperdine at gmail.com>: > On Sep 11, 2017, at 9:46 PM, Martin Skarsaune > wrote: > > Hi Harsha and Erik > > I certainly understand the desire to design the API well. > My point was just that when there is a mature battle-tested de-facto > solution out in the wild, > > > I would agree that there are lessons to be learned from Jolokia. It is a > great/useful tool but it is not a JMXConnector. IMHO the REST layer should > be implemented as a JMXConnector. It is the implementation that has the > ability to integrate with widest set of exiting tooling. > > Kind regards, > Kirk Pepperdine > > it would be a pity not to see potential for interoperability where the > solutions are in fact really close. > To illustrate where I'm coming from, I hacked the source of a plugin that > is able to control the flight recorder via JMX , to adapt the POST payloads > to this JEP. > Assuming I understood it correctly the changes are quite small, but would > the require a complete rewrite of all plugins, a layer of indirection or > even worse a compatibility layer to use it. > Note: I assumed the arguments are still an array and not an object? ([] , > not {}) ? > > You can see an example of what changes would typically be needed here: > > https://github.com/skarsaune/hawtio/commit/36ca65f495f05d20061b001fcc291ed3bc6e183f > > Cheers > > Martin > > > man. 11. sep. 2017 kl. 17:36 skrev Kirk Pepperdine < > kirk.pepperdine at gmail.com>: > >> Hi Harsha, >> >> The only reason I mentioned Jolokia is that it?s a project that >> usefulness is some what limited because it is *not* a compliment JMX >> connector and as such cannot be used as a straight drop-in replacement for >> the current RMI based connector. Is your plan here to make it a fully >> compliant connector so that we could configure tooling such as the MBean >> viewers in jConsole and VisualVM (or JMC for that matter) to use a restful >> connector instead of an RMI based connector? IMHO, doing so would represent >> a huge win as I know of quite a few projects that cannot or will not use >> JMX because of it?s reliance on RMI. >> >> Consolidating all of the options under a single flag looks like another >> interesting win. >> >> Kind regards, >> Kirk >> >> >> >> On Sep 11, 2017, at 4:08 PM, Harsha Wardhana B < >> harsha.wardhana.b at oracle.com> wrote: >> >> Hi Erik, >> >> On Monday 11 September 2017 07:14 PM, Erik Gahlin wrote: >> >> Hi Harsha, >> >> I haven't looked at Jolokia, or know what is the most reasonable approach >> in this case, but as a principle, I think we should strive for the best >> possible design rather than trying to be compatible with third party tools. >> >> Agreed. That will always be the first priority. That is the reason HTTP >> GET interfaces will not be changed. I am undecided if the POST payloads >> need to be changed (without compromising the REST design principles) to >> increase adoption of this feature. >> >> >> How will the command line look like to start the agent with the rest >> adapter? >> >> In the past there have been discussions about adding syntactic sugar for >> -Dcom.sun.management, i.e. >> >> -Xmanagement:ssl=false,port=7091,authenticate=false >> >> instead of >> >> -Dcom.sun.management.jmxremote.ssl=false >> -Dcom.sun.management.jmxremote.port=7091 >> -Dcom.sun.management.jmxremote.authenticate=false >> >> which is hard to remember, cumbersome to write and error prone since the >> parameters are not validated. If we are adding support for REST, it could >> perhaps be default, i.e. >> >> -Xmanagement:ssl=false,authenticate=false,port=80 >> >> If you want to use JMX over RMI you would specify protocol: >> >> -Xmanagement:ssl=false,port=7091,authenticate=false,protocol=rmi >> >> Yes. There is an enhancement request to add the -Xmanagemet:* syntatic >> sugar for -Dcom.sun.management.jmxremote.* flags. REST adapter will use one >> of the above flags though I haven't thought of the exact name for it yet. I >> will update the JEP with the details of the flag shortly. >> >> >> Has there been any thoughts about JMX notifications? >> >> Notifications will not be supported in this JEP. >> >> - MBean Notifications are not a widely used feature and will not be >> supported via the REST adapter. >> >> >> I know it is outside the scope of the JEP, but I think we should take it >> into consideration when doing the design, so the functionality could be >> added on later without too much difficulty. >> >> Notifications can be added without modifying the current design too much. >> If required, it will be worked upon via an enhancement request. >> >> >> Thanks >> Erik >> >> Thanks >> Harsha >> >> Hi Martin, >> >> In my opinion, the interfaces exposed by current JEP are lot closer to >> REST style than the interfaces exposed by Jolokia. >> >> For instance, HTTP GET by default should be used to read resources, but >> it is made part of URL in Jolokia interfaces. >> >> /read/// >> >> >> I would wait on opinions from more people before considering changing the >> current interfaces. >> >> Thanks >> -Harsha >> >> On Wednesday 06 September 2017 11:40 AM, Martin Skarsaune wrote: >> >> Hello >> >> Would one at least consider adopting the same URL paths and payloads as >> Jolokia? This could make life a lot easier for third party tools that >> connect to it. >> >> Best Regards >> >> Martin Skarsaune >> >> ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B < >> harsha.wardhana.b at oracle.com>: >> >>> Hi Kirk, >>> >>> Yes. Jolokia was considered and is listed as an alternative in the JEP. >>> >>> >>> - Jolokia can serve as a viable alternative but can be bulky. We are >>> looking for simple and lightweight solution. >>> >>> >>> -Harsha >>> >>> On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote: >>> >>> Hi, >>> >>> Have you run into this project? https://jolokia.org. Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. >>> >>> Kind regards, >>> Kirk >>> >>> >>> On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: >>> >>> Hi Harsha, >>> >>> Looping in jmx-dev. >>> >>> >>> byte[], short[], int[], float[], double[] >>> >>> Should long[] be included there as well? >>> >>> >>> The REST adapter will come with a simple and lightweight JSON parser. >>> >>> Is this an internal parser or will it be exposed as an API? >>> >>> If so, how does it relate to JEP 198: Light-Weight JSON API?http://openjdk.java.net/jeps/198 >>> >>> Will com.sun.net.httpserver.HttpServer be used to serve the requests? >>> >>> Thanks >>> Erik >>> >>> >>> Hi All, >>> >>> Please review the JEP for REST APIs for JMX : >>> https://bugs.openjdk.java.net/browse/JDK-8171311 >>> >>> The JEP aims at providing RESTful web interfaces to MBeans. >>> >>> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. >>> >>> Thanks >>> -Harsha >>> >>> >>> >>> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Mon Sep 11 20:38:31 2017 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Mon, 11 Sep 2017 22:38:31 +0200 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> <22425ECF-1825-4764-9BBE-EF5A0B7904F7@gmail.com> Message-ID: > On Sep 11, 2017, at 10:30 PM, Martin Skarsaune wrote: > > I can agree to that. To be concrete, what does the JEP as it currently stands offer over jolokia to be able to support JMXConnector? Could the client interface and protocol be two separate concerns? The interface and the protocol clearly are two separate concerns. The interface in JMX is clearly defined and while the default protocol is RMI, it does not have to be RMI. > > BTW: jolokia 2.0 will have support for JMX Notifications https://ro14nd.de/jolokia-notifications Yes, my comment in the past has always been? it would be wonderful if jolokia fully supported JMXConnector but unfortunately it doesn?t which means you cannot easily use existing JMX clients with it. Other than that, it?s really useful in environments where using RMI is an issue. I think this where we can learn from jolokia. Kind regards, Kirk Pepperdine > > Best Regards > Martin Skarsaune > > man. 11. sep. 2017 kl. 21:55 skrev Kirk Pepperdine >: >> On Sep 11, 2017, at 9:46 PM, Martin Skarsaune > wrote: >> >> Hi Harsha and Erik >> >> I certainly understand the desire to design the API well. >> My point was just that when there is a mature battle-tested de-facto solution out in the wild, > > I would agree that there are lessons to be learned from Jolokia. It is a great/useful tool but it is not a JMXConnector. IMHO the REST layer should be implemented as a JMXConnector. It is the implementation that has the ability to integrate with widest set of exiting tooling. > > Kind regards, > Kirk Pepperdine > >> it would be a pity not to see potential for interoperability where the solutions are in fact really close. >> To illustrate where I'm coming from, I hacked the source of a plugin that is able to control the flight recorder via JMX , to adapt the POST payloads to this JEP. >> Assuming I understood it correctly the changes are quite small, but would the require a complete rewrite of all plugins, a layer of indirection or even worse a compatibility layer to use it. >> Note: I assumed the arguments are still an array and not an object? ([] , not {}) ? >> >> You can see an example of what changes would typically be needed here: >> https://github.com/skarsaune/hawtio/commit/36ca65f495f05d20061b001fcc291ed3bc6e183f >> >> Cheers >> >> Martin >> >> >> man. 11. sep. 2017 kl. 17:36 skrev Kirk Pepperdine >: >> Hi Harsha, >> >> The only reason I mentioned Jolokia is that it?s a project that usefulness is some what limited because it is *not* a compliment JMX connector and as such cannot be used as a straight drop-in replacement for the current RMI based connector. Is your plan here to make it a fully compliant connector so that we could configure tooling such as the MBean viewers in jConsole and VisualVM (or JMC for that matter) to use a restful connector instead of an RMI based connector? IMHO, doing so would represent a huge win as I know of quite a few projects that cannot or will not use JMX because of it?s reliance on RMI. >> >> Consolidating all of the options under a single flag looks like another interesting win. >> >> Kind regards, >> Kirk >> >> >> >>> On Sep 11, 2017, at 4:08 PM, Harsha Wardhana B > wrote: >>> >>> Hi Erik, >>> >>> On Monday 11 September 2017 07:14 PM, Erik Gahlin wrote: >>>> Hi Harsha, >>>> >>>> I haven't looked at Jolokia, or know what is the most reasonable approach in this case, but as a principle, I think we should strive for the best possible design rather than trying to be compatible with third party tools. >>> Agreed. That will always be the first priority. That is the reason HTTP GET interfaces will not be changed. I am undecided if the POST payloads need to be changed (without compromising the REST design principles) to increase adoption of this feature. >>>> >>>> How will the command line look like to start the agent with the rest adapter? >>>> >>>> In the past there have been discussions about adding syntactic sugar for -Dcom.sun.management, i.e. >>>> >>>> -Xmanagement:ssl=false,port=7091,authenticate=false >>>> >>>> instead of >>>> >>>> -Dcom.sun.management.jmxremote.ssl=false >>>> -Dcom.sun.management.jmxremote.port=7091 >>>> -Dcom.sun.management.jmxremote.authenticate=false >>>> >>>> which is hard to remember, cumbersome to write and error prone since the parameters are not validated. If we are adding support for REST, it could perhaps be default, i.e. >>>> >>>> -Xmanagement:ssl=false,authenticate=false,port=80 >>>> >>>> If you want to use JMX over RMI you would specify protocol: >>>> >>>> -Xmanagement:ssl=false,port=7091,authenticate=false,protocol=rmi >>> Yes. There is an enhancement request to add the -Xmanagemet:* syntatic sugar for -Dcom.sun.management.jmxremote.* flags. REST adapter will use one of the above flags though I haven't thought of the exact name for it yet. I will update the JEP with the details of the flag shortly. >>>> >>>> Has there been any thoughts about JMX notifications? >>> Notifications will not be supported in this JEP. >>> MBean Notifications are not a widely used feature and will not be supported via the REST adapter. >>>> >>>> I know it is outside the scope of the JEP, but I think we should take it into consideration when doing the design, so the functionality could be added on later without too much difficulty. >>> Notifications can be added without modifying the current design too much. If required, it will be worked upon via an enhancement request. >>>> >>>> Thanks >>>> Erik >>>> >>> Thanks >>> Harsha >>>>> Hi Martin, >>>>> >>>>> In my opinion, the interfaces exposed by current JEP are lot closer to REST style than the interfaces exposed by Jolokia. >>>>> For instance, HTTP GET by default should be used to read resources, but it is made part of URL in Jolokia interfaces. >>>>> >>>>> /read/// >>>>> >>>>> I would wait on opinions from more people before considering changing the current interfaces. >>>>> >>>>> Thanks >>>>> -Harsha >>>>> >>>>> On Wednesday 06 September 2017 11:40 AM, Martin Skarsaune wrote: >>>>>> Hello >>>>>> >>>>>> Would one at least consider adopting the same URL paths and payloads as Jolokia? This could make life a lot easier for third party tools that connect to it. >>>>>> >>>>>> Best Regards >>>>>> >>>>>> Martin Skarsaune >>>>>> >>>>>> ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B >: >>>>>> Hi Kirk, >>>>>> >>>>>> Yes. Jolokia was considered and is listed as an alternative in the JEP. >>>>>> >>>>>> Jolokia can serve as a viable alternative but can be bulky. We are looking for simple and lightweight solution. >>>>>> >>>>>> -Harsha >>>>>> >>>>>> On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Have you run into this project? https://jolokia.org . Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. >>>>>>> >>>>>>> Kind regards, >>>>>>> Kirk >>>>>>> >>>>>> >>>>>>>> On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: >>>>>>>> >>>>>>>> Hi Harsha, >>>>>>>> >>>>>>>> Looping in jmx-dev. >>>>>>>> >>>>>>>>> byte[], short[], int[], float[], double[] >>>>>>>> Should long[] be included there as well? >>>>>>>> >>>>>>>>> The REST adapter will come with a simple and lightweight JSON parser. >>>>>>>> Is this an internal parser or will it be exposed as an API? >>>>>>>> >>>>>>>> If so, how does it relate to JEP 198: Light-Weight JSON API? >>>>>>>> http://openjdk.java.net/jeps/198 >>>>>>>> >>>>>>>> Will com.sun.net.httpserver.HttpServer be used to serve the requests? >>>>>>>> >>>>>>>> Thanks >>>>>>>> Erik >>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Please review the JEP for REST APIs for JMX : >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171311 >>>>>>>>> >>>>>>>>> The JEP aims at providing RESTful web interfaces to MBeans. >>>>>>>>> >>>>>>>>> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> -Harsha >>>>>>>>> >>>>>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Mon Sep 11 20:49:10 2017 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 11 Sep 2017 13:49:10 -0700 Subject: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code In-Reply-To: <131072bd-7d03-4f79-8ca0-6c26f9bbe315@default> References: <131072bd-7d03-4f79-8ca0-6c26f9bbe315@default> Message-ID: <3b93b2b5-cf0c-42df-9673-5c61b2951ad3@oracle.com> On 9/4/17 3:11 AM, Shafi Ahmad wrote: > > > The method hasListeners() is referenced ?inside MemoryImpl.java and > defined in ?NotificationEmitterSupport. > > This method is not present in ?NotificationBroadcasterSupport so I > added it to NotificationBroadcasterSupport. > > Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8170299 > > Webrev link: http://cr.openjdk.java.net/~shshahma/8170299/webrev.01/ > > > This patch adds a new public method in NotificationBroadcasterSupport.? I think this fix wants to avoid adding this public method since this fix is intended to be backport. MemoryImpl checks if there is any listener registered to avoid instantiating the notification object if no listener handles it. Replacing the internal sun.management.NotificationEmitterSupport with NotificationBroadcasterSupport is a good change.? I suggest to file a RFE to consider adding hasListeners method as a separate issue. 171 static final class ThreadExecutor implements Executor { 172 public void execute(Runnable r) { new Thread(r).start(); } 173 } This creates a new thread for each listener to handle each notification which is overkill.?? You can create one system daemon thread to handle all notifications for all listeners. For this fix, you could simply update NotificationEmitterSupport to create a system daemon thread to handle all notifications. NotificationEmitterSupport::sendNotification should also be updated to ignore the exception (currently it throws an exception). Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Sep 12 01:13:00 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 11 Sep 2017 18:13:00 -0700 Subject: RFR(10)(M): 8179498: attach in linux should be relative to /proc/pid/root and namespace aware In-Reply-To: <27b7a7af-e95b-4b36-5808-be8607f1b30b@oracle.com> References: <6434ed9c-7ea0-fe2d-d185-eca74c06ea0b@oracle.com> <27b7a7af-e95b-4b36-5808-be8607f1b30b@oracle.com> Message-ID: <4436414c-6bbf-d173-3e23-e1fb7deec3f1@oracle.com> Hi Chris, This looks good to me. I'm not sure if all the nsk.aod and the AttachOnDemand tests from the nsk.jvmti are run in the hotspot tier1, 2, and 3 tests. It makes sense to double-check it. Thanks, Serguei On 9/10/17 20:34, Chris Plummer wrote: > [re-sending - sent to wrong alias first time] > > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8179498 > http://cr.openjdk.java.net/~cjplummer/8179498/webrev.00/webrev_jdk/ > > The CR has the relevant details. Some previous discussions can be > found here: > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/021237.html > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-May/021249.html > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021679.html > > > Testing with docker has been limited to just making sure jcmd now > works with the docker setup I was provided. I currently don't see how > we can run our existing tests in a way that would test the docker > support without doing some rewriting of the tests. > > I also ran all our hotspot tier1, 2, and 3 tests, along with > jdk/test/tools and jdk/test/sun/tools tests to make sure existing > functionality is not broken with these changes. > > thanks, > > Chris From chris.plummer at oracle.com Tue Sep 12 03:03:12 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 11 Sep 2017 20:03:12 -0700 Subject: RFR(10)(M): 8179498: attach in linux should be relative to /proc/pid/root and namespace aware In-Reply-To: <4436414c-6bbf-d173-3e23-e1fb7deec3f1@oracle.com> References: <6434ed9c-7ea0-fe2d-d185-eca74c06ea0b@oracle.com> <27b7a7af-e95b-4b36-5808-be8607f1b30b@oracle.com> <4436414c-6bbf-d173-3e23-e1fb7deec3f1@oracle.com> Message-ID: <7574486e-124d-ffe1-df36-1c7911844cde@oracle.com> Ok, I will. Thanks. Chris On 9/11/17 6:13 PM, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > This looks good to me. > > I'm not sure if all the nsk.aod and the AttachOnDemand tests from > the nsk.jvmti are run in the hotspot tier1, 2, and 3 tests. > It makes sense to double-check it. > > > Thanks, > Serguei > > > On 9/10/17 20:34, Chris Plummer wrote: >> [re-sending - sent to wrong alias first time] >> >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8179498 >> http://cr.openjdk.java.net/~cjplummer/8179498/webrev.00/webrev_jdk/ >> >> The CR has the relevant details. Some previous discussions can be >> found here: >> >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/021237.html >> >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-May/021249.html >> >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021679.html >> >> >> Testing with docker has been limited to just making sure jcmd now >> works with the docker setup I was provided. I currently don't see how >> we can run our existing tests in a way that would test the docker >> support without doing some rewriting of the tests. >> >> I also ran all our hotspot tier1, 2, and 3 tests, along with >> jdk/test/tools and jdk/test/sun/tools tests to make sure existing >> functionality is not broken with these changes. >> >> thanks, >> >> Chris > From harsha.wardhana.b at oracle.com Tue Sep 12 07:04:43 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 12 Sep 2017 12:34:43 +0530 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> Message-ID: <74d24494-fef5-9e5d-d3c2-1996ba0e8ff6@oracle.com> Hi Kirk, REST APIs work as an adapter and cannot work as a connector. To quote from the JEP, > The REST adapter is a part of the Distributed services level. > Connectors mirror the interfaces of agent level services to remote > clients, whereas adapters transform agent level services to different > protocol. The proposed functionality will transform Agent level > services to REST APIs, hence the name "REST adapter". A connector *must* adhere to the JMX remoting spec. REST APIs cannot adhere to that because they expose APIs via HTTP and not Java. Hence it is called an Adapter and not a connector. It can never work as a 'drop-in' replacement for JMX/RMI Connector. Existing tools using using RMIConnector will have to be modified to use REST APIs. The current JEP does not allow all of the CRUD operations on MBeans. In the spirit of keeping the APIs language agnostic, only read/write is supported. It is not possible to specify create/delete REST APIs for JMX without incorporating language specific features. I would welcome discussions around including create/delete APIs for MBeans. In lieu of the above, as of now REST adapter cannot exist independently and will have to live along-side RMIConnector. -Harsha On Monday 11 September 2017 09:05 PM, Kirk Pepperdine wrote: > Hi Harsha, > > The only reason I mentioned Jolokia is that it?s a project that > usefulness is some what limited because it is *not* a compliment JMX > connector and as such cannot be used as a straight drop-in replacement > for the current RMI based connector. Is your plan here to make it a > fully compliant connector so that we could configure tooling such as > the MBean viewers in jConsole and VisualVM (or JMC for that matter) to > use a restful connector instead of an RMI based connector? IMHO, doing > so would represent a huge win as I know of quite a few projects that > cannot or will not use JMX because of it?s reliance on RMI. > > Consolidating all of the options under a single flag looks like > another interesting win. > > Kind regards, > Kirk > > > >> On Sep 11, 2017, at 4:08 PM, Harsha Wardhana B >> > >> wrote: >> >> Hi Erik, >> >> >> On Monday 11 September 2017 07:14 PM, Erik Gahlin wrote: >>> Hi Harsha, >>> >>> I haven't looked at Jolokia, or know what is the most reasonable >>> approach in this case, but as a principle, I think we should strive >>> for the best possible design rather than trying to be compatible >>> with third party tools. >> Agreed. That will always be the first priority. That is the reason >> HTTP GET interfaces will not be changed. I am undecided if the POST >> payloads need to be changed (without compromising the REST design >> principles) to increase adoption of this feature. >>> >>> How will the command line look like to start the agent with the rest >>> adapter? >>> >>> In the past there have been discussions about adding syntactic sugar >>> for -Dcom.sun.management, i.e. >>> >>> -Xmanagement:ssl=false,port=7091,authenticate=false >>> >>> instead of >>> >>> -Dcom.sun.management.jmxremote.ssl=false >>> -Dcom.sun.management.jmxremote.port=7091 >>> -Dcom.sun.management.jmxremote.authenticate=false >>> >>> which is hard to remember, cumbersome to write and error prone since >>> the parameters are not validated. If we are adding support for REST, >>> it could perhaps be default, i.e. >>> >>> -Xmanagement:ssl=false,authenticate=false,port=80 >>> >>> If you want to use JMX over RMI you would specify protocol: >>> >>> -Xmanagement:ssl=false,port=7091,authenticate=false,protocol=rmi >> Yes. There is an enhancement request to add the -Xmanagemet:* >> syntatic sugar for -Dcom.sun.management.jmxremote.* flags. REST >> adapter will use one of the above flags though I haven't thought of >> the exact name for it yet. I will update the JEP with the details of >> the flag shortly. >>> >>> Has there been any thoughts about JMX notifications? >> Notifications will not be supported in this JEP. >> >> * MBean Notifications are not a widely used feature and will not be >> supported via the REST adapter. >> >>> >>> I know it is outside the scope of the JEP, but I think we should >>> take it into consideration when doing the design, so the >>> functionality could be added on later without too much difficulty. >> Notifications can be added without modifying the current design too >> much. If required, it will be worked upon via an enhancement request. >>> >>> Thanks >>> Erik >>> >> Thanks >> Harsha >>>> >>>> Hi Martin, >>>> >>>> In my opinion, the interfaces exposed by current JEP are lot closer >>>> to REST style than the interfaces exposed by Jolokia. >>>> >>>> For instance, HTTP GET by default should be used to read resources, >>>> but it is made part of URL in Jolokia interfaces. >>>> >>>> /read/// >>>> >>>> I would wait on opinions from more people before considering >>>> changing the current interfaces. >>>> >>>> Thanks >>>> -Harsha >>>> >>>> On Wednesday 06 September 2017 11:40 AM, Martin Skarsaune wrote: >>>>> Hello >>>>> >>>>> Would one at least consider adopting the same URL paths and >>>>> payloads as Jolokia? This could make life a lot easier for third >>>>> party tools that connect to it. >>>>> >>>>> Best Regards >>>>> >>>>> Martin Skarsaune >>>>> >>>>> ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B >>>>> >: >>>>> >>>>> Hi Kirk, >>>>> >>>>> Yes. Jolokia was considered and is listed as an alternative in >>>>> the JEP. >>>>> >>>>> * Jolokia can serve as a viable alternative but can be >>>>> bulky. We are looking for simple and lightweight solution. >>>>> >>>>> >>>>> -Harsha >>>>> >>>>> On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote: >>>>>> Hi, >>>>>> >>>>>> Have you run into this project?https://jolokia.org . Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. >>>>>> >>>>>> Kind regards, >>>>>> Kirk >>>>>> >>>>>>> On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: >>>>>>> >>>>>>> Hi Harsha, >>>>>>> >>>>>>> Looping in jmx-dev. >>>>>>> >>>>>>>> byte[], short[], int[], float[], double[] >>>>>>> Should long[] be included there as well? >>>>>>> >>>>>>>> The REST adapter will come with a simple and lightweight JSON parser. >>>>>>> Is this an internal parser or will it be exposed as an API? >>>>>>> >>>>>>> If so, how does it relate to JEP 198: Light-Weight JSON API? >>>>>>> http://openjdk.java.net/jeps/198 >>>>>>> >>>>>>> Will com.sun.net.httpserver.HttpServer be used to serve the requests? >>>>>>> >>>>>>> Thanks >>>>>>> Erik >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Please review the JEP for REST APIs for JMX : >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171311 >>>>>>>> >>>>>>>> The JEP aims at providing RESTful web interfaces to MBeans. >>>>>>>> >>>>>>>> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Harsha >>>>>>>> >>>>>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Tue Sep 12 07:26:55 2017 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Tue, 12 Sep 2017 09:26:55 +0200 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <74d24494-fef5-9e5d-d3c2-1996ba0e8ff6@oracle.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> <74d24494-fef5-9e5d-d3c2-1996ba0e8ff6@oracle.com> Message-ID: Hi Harsha, From Chapter 5 of the JMX documentation. "Many different implementations of connectors are possible. In particular, there are many possibilities for the protocol used to communicate over a connection between client and server.? It goes on in the Generic Connector section under "User-Defined Protocols? to say; "While the RMI connector must be present in every implementation of the JMX Remote API, you can also implement a connector based on a protocol that is not defined in the JMX Remote API standard. A typical example of this is a connector based on a protocol that uses HTTP/S. Other protocols are also possible. The JMX specification describes how to implement a connector based on a user-defined protocol.? Unless I?m missing something, this all suggests that there is nothing inherently wrong is using REST behind a JMXConnector. As written this JEP pretty much looks like Jolokia. Jolokia is a great project and as such I fail to see the benefits of simply duplicating it. I?d also argue that the usefulness of that project has been some what muted because it is not a drop in replacement for the standard RMI connector meaning that one has to modify an entire tool chain just to make use of it. However, creating a REST based JMXConnector would be immediately useful. As an aside, Jus last week I started on a JMXConnector that uses a shared memory segment for communications. Of course this implementation would only be available for local communications but it offers some advantages over using a socket based protocol, even if that comms is over local loopback. Kind regards, Kirk Pepperdine > On Sep 12, 2017, at 9:04 AM, Harsha Wardhana B wrote: > > Hi Kirk, > > REST APIs work as an adapter and cannot work as a connector. To quote from the JEP, > > >> The REST adapter is a part of the Distributed services level. Connectors mirror the interfaces of agent level services to remote clients, whereas adapters transform agent level services to different protocol. The proposed functionality will transform Agent level services to REST APIs, hence the name "REST adapter". > A connector *must* adhere to the JMX remoting spec. REST APIs cannot adhere to that because they expose APIs via HTTP and not Java. Hence it is called an Adapter and not a connector. It can never work as a 'drop-in' replacement for JMX/RMI Connector. Existing tools using using RMIConnector will have to be modified to use REST APIs. > > The current JEP does not allow all of the CRUD operations on MBeans. In the spirit of keeping the APIs language agnostic, only read/write is supported. It is not possible to specify create/delete REST APIs for JMX without incorporating language specific features. I would welcome discussions around including create/delete APIs for MBeans. > In lieu of the above, as of now REST adapter cannot exist independently and will have to live along-side RMIConnector. > -Harsha > > On Monday 11 September 2017 09:05 PM, Kirk Pepperdine wrote: >> Hi Harsha, >> >> The only reason I mentioned Jolokia is that it?s a project that usefulness is some what limited because it is *not* a compliment JMX connector and as such cannot be used as a straight drop-in replacement for the current RMI based connector. Is your plan here to make it a fully compliant connector so that we could configure tooling such as the MBean viewers in jConsole and VisualVM (or JMC for that matter) to use a restful connector instead of an RMI based connector? IMHO, doing so would represent a huge win as I know of quite a few projects that cannot or will not use JMX because of it?s reliance on RMI. >> >> Consolidating all of the options under a single flag looks like another interesting win. >> >> Kind regards, >> Kirk >> >> >> >>> On Sep 11, 2017, at 4:08 PM, Harsha Wardhana B > wrote: >>> >>> Hi Erik, >>> >>> On Monday 11 September 2017 07:14 PM, Erik Gahlin wrote: >>>> Hi Harsha, >>>> >>>> I haven't looked at Jolokia, or know what is the most reasonable approach in this case, but as a principle, I think we should strive for the best possible design rather than trying to be compatible with third party tools. >>> Agreed. That will always be the first priority. That is the reason HTTP GET interfaces will not be changed. I am undecided if the POST payloads need to be changed (without compromising the REST design principles) to increase adoption of this feature. >>>> >>>> How will the command line look like to start the agent with the rest adapter? >>>> >>>> In the past there have been discussions about adding syntactic sugar for -Dcom.sun.management, i.e. >>>> >>>> -Xmanagement:ssl=false,port=7091,authenticate=false >>>> >>>> instead of >>>> >>>> -Dcom.sun.management.jmxremote.ssl=false >>>> -Dcom.sun.management.jmxremote.port=7091 >>>> -Dcom.sun.management.jmxremote.authenticate=false >>>> >>>> which is hard to remember, cumbersome to write and error prone since the parameters are not validated. If we are adding support for REST, it could perhaps be default, i.e. >>>> >>>> -Xmanagement:ssl=false,authenticate=false,port=80 >>>> >>>> If you want to use JMX over RMI you would specify protocol: >>>> >>>> -Xmanagement:ssl=false,port=7091,authenticate=false,protocol=rmi >>> Yes. There is an enhancement request to add the -Xmanagemet:* syntatic sugar for -Dcom.sun.management.jmxremote.* flags. REST adapter will use one of the above flags though I haven't thought of the exact name for it yet. I will update the JEP with the details of the flag shortly. >>>> >>>> Has there been any thoughts about JMX notifications? >>> Notifications will not be supported in this JEP. >>> MBean Notifications are not a widely used feature and will not be supported via the REST adapter. >>>> >>>> I know it is outside the scope of the JEP, but I think we should take it into consideration when doing the design, so the functionality could be added on later without too much difficulty. >>> Notifications can be added without modifying the current design too much. If required, it will be worked upon via an enhancement request. >>>> >>>> Thanks >>>> Erik >>>> >>> Thanks >>> Harsha >>>>> Hi Martin, >>>>> >>>>> In my opinion, the interfaces exposed by current JEP are lot closer to REST style than the interfaces exposed by Jolokia. >>>>> For instance, HTTP GET by default should be used to read resources, but it is made part of URL in Jolokia interfaces. >>>>> >>>>> /read/// >>>>> >>>>> I would wait on opinions from more people before considering changing the current interfaces. >>>>> >>>>> Thanks >>>>> -Harsha >>>>> >>>>> On Wednesday 06 September 2017 11:40 AM, Martin Skarsaune wrote: >>>>>> Hello >>>>>> >>>>>> Would one at least consider adopting the same URL paths and payloads as Jolokia? This could make life a lot easier for third party tools that connect to it. >>>>>> >>>>>> Best Regards >>>>>> >>>>>> Martin Skarsaune >>>>>> >>>>>> ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B >: >>>>>> Hi Kirk, >>>>>> >>>>>> Yes. Jolokia was considered and is listed as an alternative in the JEP. >>>>>> >>>>>> Jolokia can serve as a viable alternative but can be bulky. We are looking for simple and lightweight solution. >>>>>> >>>>>> -Harsha >>>>>> >>>>>> On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Have you run into this project? https://jolokia.org . Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. >>>>>>> >>>>>>> Kind regards, >>>>>>> Kirk >>>>>>> >>>>>> >>>>>>>> On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: >>>>>>>> >>>>>>>> Hi Harsha, >>>>>>>> >>>>>>>> Looping in jmx-dev. >>>>>>>> >>>>>>>>> byte[], short[], int[], float[], double[] >>>>>>>> Should long[] be included there as well? >>>>>>>> >>>>>>>>> The REST adapter will come with a simple and lightweight JSON parser. >>>>>>>> Is this an internal parser or will it be exposed as an API? >>>>>>>> >>>>>>>> If so, how does it relate to JEP 198: Light-Weight JSON API? >>>>>>>> http://openjdk.java.net/jeps/198 >>>>>>>> >>>>>>>> Will com.sun.net.httpserver.HttpServer be used to serve the requests? >>>>>>>> >>>>>>>> Thanks >>>>>>>> Erik >>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Please review the JEP for REST APIs for JMX : >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171311 >>>>>>>>> >>>>>>>>> The JEP aims at providing RESTful web interfaces to MBeans. >>>>>>>>> >>>>>>>>> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> -Harsha >>>>>>>>> >>>>>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Tue Sep 12 08:40:27 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 12 Sep 2017 14:10:27 +0530 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> <74d24494-fef5-9e5d-d3c2-1996ba0e8ff6@oracle.com> Message-ID: <9bae5d49-6f3a-3aca-4635-4b2ec896e14a@oracle.com> Hi Kirk, I guess the term 'connector' here is loosely applied. When I say connector, I mean the connector that provides implementation of the package below, https://docs.oracle.com/javase/8/docs/api/javax/management/remote/package-summary.html RMIConnector is one implementation of above connector. On Tuesday 12 September 2017 12:56 PM, Kirk Pepperdine wrote: > Hi Harsha, > > From Chapter 5 of the JMX documentation. "Many different > implementations of connectors are possible. In particular, there are > many possibilities for the protocol used to communicate over a > connection between client and server.? > > It goes on in the Generic Connector section under "User-Defined > Protocols? to say; "While the RMI connector must be present in every > implementation of the JMX Remote API, you can also implement a > connector based on a protocol that is not defined in the JMX Remote > API standard. A typical example of this is a connector based on a > protocol that uses HTTP/S. Other protocols are also possible. The JMX > specification describes how to implement a connector based on a > user-defined protocol.? > > Unless I?m missing something, this all suggests that there is > nothing inherently wrong is using REST behind a JMXConnector. I hope above should clarify what I refer to when I say JMXConnector. In that sense, REST APIs alone cannot work as connector. In fact, it stands parallel to connector, as in it directly wraps the MBeanServer and does not wrap any JMXConnector. The JEP has detailed information about where the REST adapter sits in the JMX architecture. Are you suggesting that we implement a JMXConnector that works over REST? > > As written this JEP pretty much looks like Jolokia. Jolokia is a great > project and as such I fail to see the benefits of simply duplicating > it. I?d also argue that the usefulness of that project has been some > what muted because it is not a drop in replacement for the standard > RMI connector meaning that one has to modify an entire tool chain just > to make use of it. However, creating a REST based JMXConnector would > be immediately useful. > As an aside, Jus last week I started on a JMXConnector that uses a > shared memory segment for communications. Of course this > implementation would only be available for local communications but it > offers some advantages over using a socket based protocol, even if > that comms is over local loopback. > > Kind regards, > Kirk Pepperdine Thanks Harsha > > > >> On Sep 12, 2017, at 9:04 AM, Harsha Wardhana B >> > >> wrote: >> >> Hi Kirk, >> >> REST APIs work as an adapter and cannot work as a connector. To quote >> from the JEP, >> >> >>> The REST adapter is a part of the Distributed services level. >>> Connectors mirror the interfaces of agent level services to remote >>> clients, whereas adapters transform agent level services to >>> different protocol. The proposed functionality will transform Agent >>> level services to REST APIs, hence the name "REST adapter". >> A connector *must* adhere to the JMX remoting spec. REST APIs cannot >> adhere to that because they expose APIs via HTTP and not Java. Hence >> it is called an Adapter and not a connector. It can never work as a >> 'drop-in' replacement for JMX/RMI Connector. Existing tools using >> using RMIConnector will have to be modified to use REST APIs. >> >> The current JEP does not allow all of the CRUD operations on MBeans. >> In the spirit of keeping the APIs language agnostic, only read/write >> is supported. It is not possible to specify create/delete REST APIs >> for JMX without incorporating language specific features. I would >> welcome discussions around including create/delete APIs for MBeans. >> >> In lieu of the above, as of now REST adapter cannot exist >> independently and will have to live along-side RMIConnector. >> >> -Harsha >> >> >> On Monday 11 September 2017 09:05 PM, Kirk Pepperdine wrote: >>> Hi Harsha, >>> >>> The only reason I mentioned Jolokia is that it?s a project that >>> usefulness is some what limited because it is *not* a compliment JMX >>> connector and as such cannot be used as a straight drop-in >>> replacement for the current RMI based connector. Is your plan here >>> to make it a fully compliant connector so that we could configure >>> tooling such as the MBean viewers in jConsole and VisualVM (or JMC >>> for that matter) to use a restful connector instead of an RMI based >>> connector? IMHO, doing so would represent a huge win as I know of >>> quite a few projects that cannot or will not use JMX because of it?s >>> reliance on RMI. >>> >>> Consolidating all of the options under a single flag looks like >>> another interesting win. >>> >>> Kind regards, >>> Kirk >>> >>> >>> >>>> On Sep 11, 2017, at 4:08 PM, Harsha Wardhana B >>>> >>> > wrote: >>>> >>>> Hi Erik, >>>> >>>> >>>> On Monday 11 September 2017 07:14 PM, Erik Gahlin wrote: >>>>> Hi Harsha, >>>>> >>>>> I haven't looked at Jolokia, or know what is the most reasonable >>>>> approach in this case, but as a principle, I think we should >>>>> strive for the best possible design rather than trying to be >>>>> compatible with third party tools. >>>> Agreed. That will always be the first priority. That is the reason >>>> HTTP GET interfaces will not be changed. I am undecided if the POST >>>> payloads need to be changed (without compromising the REST design >>>> principles) to increase adoption of this feature. >>>>> >>>>> How will the command line look like to start the agent with the >>>>> rest adapter? >>>>> >>>>> In the past there have been discussions about adding syntactic >>>>> sugar for -Dcom.sun.management, i.e. >>>>> >>>>> -Xmanagement:ssl=false,port=7091,authenticate=false >>>>> >>>>> instead of >>>>> >>>>> -Dcom.sun.management.jmxremote.ssl=false >>>>> -Dcom.sun.management.jmxremote.port=7091 >>>>> -Dcom.sun.management.jmxremote.authenticate=false >>>>> >>>>> which is hard to remember, cumbersome to write and error prone >>>>> since the parameters are not validated. If we are adding support >>>>> for REST, it could perhaps be default, i.e. >>>>> >>>>> -Xmanagement:ssl=false,authenticate=false,port=80 >>>>> >>>>> If you want to use JMX over RMI you would specify protocol: >>>>> >>>>> -Xmanagement:ssl=false,port=7091,authenticate=false,protocol=rmi >>>> Yes. There is an enhancement request to add the -Xmanagemet:* >>>> syntatic sugar for -Dcom.sun.management.jmxremote.* flags. REST >>>> adapter will use one of the above flags though I haven't thought of >>>> the exact name for it yet. I will update the JEP with the details >>>> of the flag shortly. >>>>> >>>>> Has there been any thoughts about JMX notifications? >>>> Notifications will not be supported in this JEP. >>>> >>>> * MBean Notifications are not a widely used feature and will not >>>> be supported via the REST adapter. >>>> >>>>> >>>>> I know it is outside the scope of the JEP, but I think we should >>>>> take it into consideration when doing the design, so the >>>>> functionality could be added on later without too much difficulty. >>>> Notifications can be added without modifying the current design too >>>> much. If required, it will be worked upon via an enhancement request. >>>>> >>>>> Thanks >>>>> Erik >>>>> >>>> Thanks >>>> Harsha >>>>>> >>>>>> Hi Martin, >>>>>> >>>>>> In my opinion, the interfaces exposed by current JEP are lot >>>>>> closer to REST style than the interfaces exposed by Jolokia. >>>>>> >>>>>> For instance, HTTP GET by default should be used to read >>>>>> resources, but it is made part of URL in Jolokia interfaces. >>>>>> >>>>>> /read/// >>>>>> >>>>>> I would wait on opinions from more people before considering >>>>>> changing the current interfaces. >>>>>> >>>>>> Thanks >>>>>> -Harsha >>>>>> >>>>>> On Wednesday 06 September 2017 11:40 AM, Martin Skarsaune wrote: >>>>>>> Hello >>>>>>> >>>>>>> Would one at least consider adopting the same URL paths and >>>>>>> payloads as Jolokia? This could make life a lot easier for third >>>>>>> party tools that connect to it. >>>>>>> >>>>>>> Best Regards >>>>>>> >>>>>>> Martin Skarsaune >>>>>>> >>>>>>> ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B >>>>>>> >>>>>> >: >>>>>>> >>>>>>> Hi Kirk, >>>>>>> >>>>>>> Yes. Jolokia was considered and is listed as an alternative >>>>>>> in the JEP. >>>>>>> >>>>>>> * Jolokia can serve as a viable alternative but can be >>>>>>> bulky. We are looking for simple and lightweight solution. >>>>>>> >>>>>>> >>>>>>> -Harsha >>>>>>> >>>>>>> On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Have you run into this project?https://jolokia.org . Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> Kirk >>>>>>>> >>>>>>>>> On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: >>>>>>>>> >>>>>>>>> Hi Harsha, >>>>>>>>> >>>>>>>>> Looping in jmx-dev. >>>>>>>>> >>>>>>>>>> byte[], short[], int[], float[], double[] >>>>>>>>> Should long[] be included there as well? >>>>>>>>> >>>>>>>>>> The REST adapter will come with a simple and lightweight JSON parser. >>>>>>>>> Is this an internal parser or will it be exposed as an API? >>>>>>>>> >>>>>>>>> If so, how does it relate to JEP 198: Light-Weight JSON API? >>>>>>>>> http://openjdk.java.net/jeps/198 >>>>>>>>> >>>>>>>>> Will com.sun.net.httpserver.HttpServer be used to serve the requests? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Erik >>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Please review the JEP for REST APIs for JMX : >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171311 >>>>>>>>>> >>>>>>>>>> The JEP aims at providing RESTful web interfaces to MBeans. >>>>>>>>>> >>>>>>>>>> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> -Harsha >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.gahlin at oracle.com Tue Sep 12 10:44:12 2017 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 12 Sep 2017 12:44:12 +0200 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <9bae5d49-6f3a-3aca-4635-4b2ec896e14a@oracle.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> <74d24494-fef5-9e5d-d3c2-1996ba0e8ff6@oracle.com> <9bae5d49-6f3a-3aca-4635-4b2ec896e14a@oracle.com> Message-ID: <59B7BA7C.5080009@oracle.com> I guess there are two use cases: 1) Simple interoperability with other languages. 2) A drop in replacement for RMI Can a JMX connector be written that support both use cases? I don't know, but if not it could be that we need both a connector and an adapter. Erik > Hi Kirk, > > I guess the term 'connector' here is loosely applied. When I say > connector, I mean the connector that provides implementation of the > package below, > > https://docs.oracle.com/javase/8/docs/api/javax/management/remote/package-summary.html > > RMIConnector is one implementation of above connector. > > > On Tuesday 12 September 2017 12:56 PM, Kirk Pepperdine wrote: >> Hi Harsha, >> >> From Chapter 5 of the JMX documentation. "Many different >> implementations of connectors are possible. In particular, there are >> many possibilities for the protocol used to communicate over a >> connection between client and server.? >> >> It goes on in the Generic Connector section under "User-Defined >> Protocols? to say; "While the RMI connector must be present in every >> implementation of the JMX Remote API, you can also implement a >> connector based on a protocol that is not defined in the JMX Remote >> API standard. A typical example of this is a connector based on a >> protocol that uses HTTP/S. Other protocols are also possible. The JMX >> specification describes how to implement a connector based on a >> user-defined protocol.? >> >> Unless I?m missing something, this all suggests that there is >> nothing inherently wrong is using REST behind a JMXConnector. > I hope above should clarify what I refer to when I say JMXConnector. > In that sense, REST APIs alone cannot work as connector. In fact, it > stands parallel to connector, as in it directly wraps the MBeanServer > and does not wrap any JMXConnector. The JEP has detailed information > about where the REST adapter sits in the JMX architecture. > > Are you suggesting that we implement a JMXConnector that works over REST? >> >> As written this JEP pretty much looks like Jolokia. Jolokia is a >> great project and as such I fail to see the benefits of simply >> duplicating it. I?d also argue that the usefulness of that project >> has been some what muted because it is not a drop in replacement for >> the standard RMI connector meaning that one has to modify an entire >> tool chain just to make use of it. However, creating a REST based >> JMXConnector would be immediately useful. >> As an aside, Jus last week I started on a JMXConnector that uses a >> shared memory segment for communications. Of course this >> implementation would only be available for local communications but >> it offers some advantages over using a socket based protocol, even if >> that comms is over local loopback. >> >> Kind regards, >> Kirk Pepperdine > > Thanks > Harsha >> >> >> >>> On Sep 12, 2017, at 9:04 AM, Harsha Wardhana B >>> > >>> wrote: >>> >>> Hi Kirk, >>> >>> REST APIs work as an adapter and cannot work as a connector. To >>> quote from the JEP, >>> >>> >>>> The REST adapter is a part of the Distributed services level. >>>> Connectors mirror the interfaces of agent level services to remote >>>> clients, whereas adapters transform agent level services to >>>> different protocol. The proposed functionality will transform Agent >>>> level services to REST APIs, hence the name "REST adapter". >>> A connector *must* adhere to the JMX remoting spec. REST APIs cannot >>> adhere to that because they expose APIs via HTTP and not Java. Hence >>> it is called an Adapter and not a connector. It can never work as a >>> 'drop-in' replacement for JMX/RMI Connector. Existing tools using >>> using RMIConnector will have to be modified to use REST APIs. >>> >>> The current JEP does not allow all of the CRUD operations on MBeans. >>> In the spirit of keeping the APIs language agnostic, only read/write >>> is supported. It is not possible to specify create/delete REST APIs >>> for JMX without incorporating language specific features. I would >>> welcome discussions around including create/delete APIs for MBeans. >>> >>> In lieu of the above, as of now REST adapter cannot exist >>> independently and will have to live along-side RMIConnector. >>> >>> -Harsha >>> >>> >>> On Monday 11 September 2017 09:05 PM, Kirk Pepperdine wrote: >>>> Hi Harsha, >>>> >>>> The only reason I mentioned Jolokia is that it?s a project that >>>> usefulness is some what limited because it is *not* a compliment >>>> JMX connector and as such cannot be used as a straight drop-in >>>> replacement for the current RMI based connector. Is your plan here >>>> to make it a fully compliant connector so that we could configure >>>> tooling such as the MBean viewers in jConsole and VisualVM (or JMC >>>> for that matter) to use a restful connector instead of an RMI based >>>> connector? IMHO, doing so would represent a huge win as I know of >>>> quite a few projects that cannot or will not use JMX because of >>>> it?s reliance on RMI. >>>> >>>> Consolidating all of the options under a single flag looks like >>>> another interesting win. >>>> >>>> Kind regards, >>>> Kirk >>>> >>>> >>>> >>>>> On Sep 11, 2017, at 4:08 PM, Harsha Wardhana B >>>>> >>>> > wrote: >>>>> >>>>> Hi Erik, >>>>> >>>>> >>>>> On Monday 11 September 2017 07:14 PM, Erik Gahlin wrote: >>>>>> Hi Harsha, >>>>>> >>>>>> I haven't looked at Jolokia, or know what is the most reasonable >>>>>> approach in this case, but as a principle, I think we should >>>>>> strive for the best possible design rather than trying to be >>>>>> compatible with third party tools. >>>>> Agreed. That will always be the first priority. That is the reason >>>>> HTTP GET interfaces will not be changed. I am undecided if the >>>>> POST payloads need to be changed (without compromising the REST >>>>> design principles) to increase adoption of this feature. >>>>>> >>>>>> How will the command line look like to start the agent with the >>>>>> rest adapter? >>>>>> >>>>>> In the past there have been discussions about adding syntactic >>>>>> sugar for -Dcom.sun.management, i.e. >>>>>> >>>>>> -Xmanagement:ssl=false,port=7091,authenticate=false >>>>>> >>>>>> instead of >>>>>> >>>>>> -Dcom.sun.management.jmxremote.ssl=false >>>>>> -Dcom.sun.management.jmxremote.port=7091 >>>>>> -Dcom.sun.management.jmxremote.authenticate=false >>>>>> >>>>>> which is hard to remember, cumbersome to write and error prone >>>>>> since the parameters are not validated. If we are adding support >>>>>> for REST, it could perhaps be default, i.e. >>>>>> >>>>>> -Xmanagement:ssl=false,authenticate=false,port=80 >>>>>> >>>>>> If you want to use JMX over RMI you would specify protocol: >>>>>> >>>>>> -Xmanagement:ssl=false,port=7091,authenticate=false,protocol=rmi >>>>> Yes. There is an enhancement request to add the -Xmanagemet:* >>>>> syntatic sugar for -Dcom.sun.management.jmxremote.* flags. REST >>>>> adapter will use one of the above flags though I haven't thought >>>>> of the exact name for it yet. I will update the JEP with the >>>>> details of the flag shortly. >>>>>> >>>>>> Has there been any thoughts about JMX notifications? >>>>> Notifications will not be supported in this JEP. >>>>> >>>>> * MBean Notifications are not a widely used feature and will not >>>>> be supported via the REST adapter. >>>>> >>>>>> >>>>>> I know it is outside the scope of the JEP, but I think we should >>>>>> take it into consideration when doing the design, so the >>>>>> functionality could be added on later without too much difficulty. >>>>> Notifications can be added without modifying the current design >>>>> too much. If required, it will be worked upon via an enhancement >>>>> request. >>>>>> >>>>>> Thanks >>>>>> Erik >>>>>> >>>>> Thanks >>>>> Harsha >>>>>>> >>>>>>> Hi Martin, >>>>>>> >>>>>>> In my opinion, the interfaces exposed by current JEP are lot >>>>>>> closer to REST style than the interfaces exposed by Jolokia. >>>>>>> >>>>>>> For instance, HTTP GET by default should be used to read >>>>>>> resources, but it is made part of URL in Jolokia interfaces. >>>>>>> >>>>>>> /read/// >>>>>>> >>>>>>> I would wait on opinions from more people before considering >>>>>>> changing the current interfaces. >>>>>>> >>>>>>> Thanks >>>>>>> -Harsha >>>>>>> >>>>>>> On Wednesday 06 September 2017 11:40 AM, Martin Skarsaune wrote: >>>>>>>> Hello >>>>>>>> >>>>>>>> Would one at least consider adopting the same URL paths and >>>>>>>> payloads as Jolokia? This could make life a lot easier for >>>>>>>> third party tools that connect to it. >>>>>>>> >>>>>>>> Best Regards >>>>>>>> >>>>>>>> Martin Skarsaune >>>>>>>> >>>>>>>> ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B >>>>>>>> >>>>>>> >: >>>>>>>> >>>>>>>> Hi Kirk, >>>>>>>> >>>>>>>> Yes. Jolokia was considered and is listed as an alternative >>>>>>>> in the JEP. >>>>>>>> >>>>>>>> * Jolokia can serve as a viable alternative but can be >>>>>>>> bulky. We are looking for simple and lightweight solution. >>>>>>>> >>>>>>>> >>>>>>>> -Harsha >>>>>>>> >>>>>>>> On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Have you run into this project?https://jolokia.org . Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. >>>>>>>>> >>>>>>>>> Kind regards, >>>>>>>>> Kirk >>>>>>>>> >>>>>>>>>> On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: >>>>>>>>>> >>>>>>>>>> Hi Harsha, >>>>>>>>>> >>>>>>>>>> Looping in jmx-dev. >>>>>>>>>> >>>>>>>>>>> byte[], short[], int[], float[], double[] >>>>>>>>>> Should long[] be included there as well? >>>>>>>>>> >>>>>>>>>>> The REST adapter will come with a simple and lightweight JSON parser. >>>>>>>>>> Is this an internal parser or will it be exposed as an API? >>>>>>>>>> >>>>>>>>>> If so, how does it relate to JEP 198: Light-Weight JSON API? >>>>>>>>>> http://openjdk.java.net/jeps/198 >>>>>>>>>> >>>>>>>>>> Will com.sun.net.httpserver.HttpServer be used to serve the requests? >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Erik >>>>>>>>>> >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> Please review the JEP for REST APIs for JMX : >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171311 >>>>>>>>>>> >>>>>>>>>>> The JEP aims at providing RESTful web interfaces to MBeans. >>>>>>>>>>> >>>>>>>>>>> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> -Harsha >>>>>>>>>>> >>>>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Tue Sep 12 10:55:18 2017 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Tue, 12 Sep 2017 12:55:18 +0200 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <9bae5d49-6f3a-3aca-4635-4b2ec896e14a@oracle.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> <74d24494-fef5-9e5d-d3c2-1996ba0e8ff6@oracle.com> <9bae5d49-6f3a-3aca-4635-4b2ec896e14a@oracle.com> Message-ID: <1CF0E23E-387A-41C4-BE9E-2E80424DA4F8@gmail.com> Hi Harsha, > On Sep 12, 2017, at 10:40 AM, Harsha Wardhana B wrote: > > Hi Kirk, > > I guess the term 'connector' here is loosely applied. When I say connector, I mean the connector that provides implementation of the package below, > > https://docs.oracle.com/javase/8/docs/api/javax/management/remote/package-summary.html > RMIConnector is one implementation of above connector. > Yes, this is the precise definition that I?ve been referring to. > > On Tuesday 12 September 2017 12:56 PM, Kirk Pepperdine wrote: >> Hi Harsha, >> >> From Chapter 5 of the JMX documentation. "Many different implementations of connectors are possible. In particular, there are many possibilities for the protocol used to communicate over a connection between client and server.? >> >> It goes on in the Generic Connector section under "User-Defined Protocols? to say; "While the RMI connector must be present in every implementation of the JMX Remote API, you can also implement a connector based on a protocol that is not defined in the JMX Remote API standard. A typical example of this is a connector based on a protocol that uses HTTP/S. Other protocols are also possible. The JMX specification describes how to implement a connector based on a user-defined protocol.? >> >> Unless I?m missing something, this all suggests that there is nothing inherently wrong is using REST behind a JMXConnector. > I hope above should clarify what I refer to when I say JMXConnector. In that sense, REST APIs alone cannot work as connector. Indeed it cannot because they are not part of the JMXConnector API. Ok, I reread and see I misunderstood the use cases that you?re trying to cover off. It seems you?re only goal is to duplicate Jolokia whereas I?m looking at a different use case. The primary use case I encounter is motivated by the inability of various sites to use JMX simply because of the operational restrictions that prevent them from using RMI. This JEP will help with that use case. That said, adding a JMXConnector with a RESTful JMXConnector would open up an entire JMX tool chain to them rather than have them have to define a new tool chain but this is outside the scope of this JEP. > In fact, it stands parallel to connector, as in it directly wraps the MBeanServer and does not wrap any JMXConnector. The JEP has detailed information about where the REST adapter sits in the JMX architecture. > > Are you suggesting that we implement a JMXConnector that works over REST? Yes, adding a JMXConnector with a RESTful JMXConnector would open up an entire JMX tool chain to them rather than have them have to define a new tool chain but this appears to be outside the scope of this JEP. Kind regards, Kirk -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Tue Sep 12 10:57:30 2017 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Tue, 12 Sep 2017 12:57:30 +0200 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <59B7BA7C.5080009@oracle.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> <74d24494-fef5-9e5d-d3c2-1996ba0e8ff6@oracle.com> <9bae5d49-6f3a-3aca-4635-4b2ec896e14a@oracle.com> <59B7BA7C.5080009@oracle.com> Message-ID: <010313AA-BBA2-4C48-805A-E88FC98AFBD2@gmail.com> > On Sep 12, 2017, at 12:44 PM, Erik Gahlin wrote: > > I guess there are two use cases: > > 1) Simple interoperability with other languages. > 2) A drop in replacement for RMI > > Can a JMX connector be written that support both use cases? I don't know, but if not it could be that we need both a connector and an adapter. I think if you were to extend JMXConnector to wrap the REST API you might be able to expose both. But I?m not sure it would be a great solution. I think a second JEP would be a better option. ? Kirk > > Erik > >> Hi Kirk, >> >> I guess the term 'connector' here is loosely applied. When I say connector, I mean the connector that provides implementation of the package below, >> >> https://docs.oracle.com/javase/8/docs/api/javax/management/remote/package-summary.html >> RMIConnector is one implementation of above connector. >> >> On Tuesday 12 September 2017 12:56 PM, Kirk Pepperdine wrote: >>> Hi Harsha, >>> >>> From Chapter 5 of the JMX documentation. "Many different implementations of connectors are possible. In particular, there are many possibilities for the protocol used to communicate over a connection between client and server.? >>> >>> It goes on in the Generic Connector section under "User-Defined Protocols? to say; "While the RMI connector must be present in every implementation of the JMX Remote API, you can also implement a connector based on a protocol that is not defined in the JMX Remote API standard. A typical example of this is a connector based on a protocol that uses HTTP/S. Other protocols are also possible. The JMX specification describes how to implement a connector based on a user-defined protocol.? >>> >>> Unless I?m missing something, this all suggests that there is nothing inherently wrong is using REST behind a JMXConnector. >> I hope above should clarify what I refer to when I say JMXConnector. In that sense, REST APIs alone cannot work as connector. In fact, it stands parallel to connector, as in it directly wraps the MBeanServer and does not wrap any JMXConnector. The JEP has detailed information about where the REST adapter sits in the JMX architecture. >> >> Are you suggesting that we implement a JMXConnector that works over REST? >>> >>> As written this JEP pretty much looks like Jolokia. Jolokia is a great project and as such I fail to see the benefits of simply duplicating it. I?d also argue that the usefulness of that project has been some what muted because it is not a drop in replacement for the standard RMI connector meaning that one has to modify an entire tool chain just to make use of it. However, creating a REST based JMXConnector would be immediately useful. >>> As an aside, Jus last week I started on a JMXConnector that uses a shared memory segment for communications. Of course this implementation would only be available for local communications but it offers some advantages over using a socket based protocol, even if that comms is over local loopback. >>> >>> Kind regards, >>> Kirk Pepperdine >> >> Thanks >> Harsha >>> >>> >>> >>>> On Sep 12, 2017, at 9:04 AM, Harsha Wardhana B < harsha.wardhana.b at oracle.com > wrote: >>>> >>>> Hi Kirk, >>>> >>>> REST APIs work as an adapter and cannot work as a connector. To quote from the JEP, >>>> >>>> >>>>> The REST adapter is a part of the Distributed services level. Connectors mirror the interfaces of agent level services to remote clients, whereas adapters transform agent level services to different protocol. The proposed functionality will transform Agent level services to REST APIs, hence the name "REST adapter". >>>> A connector *must* adhere to the JMX remoting spec. REST APIs cannot adhere to that because they expose APIs via HTTP and not Java. Hence it is called an Adapter and not a connector. It can never work as a 'drop-in' replacement for JMX/RMI Connector. Existing tools using using RMIConnector will have to be modified to use REST APIs. >>>> >>>> The current JEP does not allow all of the CRUD operations on MBeans. In the spirit of keeping the APIs language agnostic, only read/write is supported. It is not possible to specify create/delete REST APIs for JMX without incorporating language specific features. I would welcome discussions around including create/delete APIs for MBeans. >>>> In lieu of the above, as of now REST adapter cannot exist independently and will have to live along-side RMIConnector. >>>> -Harsha >>>> >>>> On Monday 11 September 2017 09:05 PM, Kirk Pepperdine wrote: >>>>> Hi Harsha, >>>>> >>>>> The only reason I mentioned Jolokia is that it?s a project that usefulness is some what limited because it is *not* a compliment JMX connector and as such cannot be used as a straight drop-in replacement for the current RMI based connector. Is your plan here to make it a fully compliant connector so that we could configure tooling such as the MBean viewers in jConsole and VisualVM (or JMC for that matter) to use a restful connector instead of an RMI based connector? IMHO, doing so would represent a huge win as I know of quite a few projects that cannot or will not use JMX because of it?s reliance on RMI. >>>>> >>>>> Consolidating all of the options under a single flag looks like another interesting win. >>>>> >>>>> Kind regards, >>>>> Kirk >>>>> >>>>> >>>>> >>>>>> On Sep 11, 2017, at 4:08 PM, Harsha Wardhana B < harsha.wardhana.b at oracle.com > wrote: >>>>>> >>>>>> Hi Erik, >>>>>> >>>>>> On Monday 11 September 2017 07:14 PM, Erik Gahlin wrote: >>>>>>> Hi Harsha, >>>>>>> >>>>>>> I haven't looked at Jolokia, or know what is the most reasonable approach in this case, but as a principle, I think we should strive for the best possible design rather than trying to be compatible with third party tools. >>>>>> Agreed. That will always be the first priority. That is the reason HTTP GET interfaces will not be changed. I am undecided if the POST payloads need to be changed (without compromising the REST design principles) to increase adoption of this feature. >>>>>>> >>>>>>> How will the command line look like to start the agent with the rest adapter? >>>>>>> >>>>>>> In the past there have been discussions about adding syntactic sugar for -Dcom.sun.management, i.e. >>>>>>> >>>>>>> -Xmanagement:ssl=false,port=7091,authenticate=false >>>>>>> >>>>>>> instead of >>>>>>> >>>>>>> -Dcom.sun.management.jmxremote.ssl=false >>>>>>> -Dcom.sun.management.jmxremote.port=7091 >>>>>>> -Dcom.sun.management.jmxremote.authenticate=false >>>>>>> >>>>>>> which is hard to remember, cumbersome to write and error prone since the parameters are not validated. If we are adding support for REST, it could perhaps be default, i.e. >>>>>>> >>>>>>> -Xmanagement:ssl=false,authenticate=false,port=80 >>>>>>> >>>>>>> If you want to use JMX over RMI you would specify protocol: >>>>>>> >>>>>>> -Xmanagement:ssl=false,port=7091,authenticate=false,protocol=rmi >>>>>> Yes. There is an enhancement request to add the -Xmanagemet:* syntatic sugar for -Dcom.sun.management.jmxremote.* flags. REST adapter will use one of the above flags though I haven't thought of the exact name for it yet. I will update the JEP with the details of the flag shortly. >>>>>>> >>>>>>> Has there been any thoughts about JMX notifications? >>>>>> Notifications will not be supported in this JEP. >>>>>> MBean Notifications are not a widely used feature and will not be supported via the REST adapter. >>>>>>> >>>>>>> I know it is outside the scope of the JEP, but I think we should take it into consideration when doing the design, so the functionality could be added on later without too much difficulty. >>>>>> Notifications can be added without modifying the current design too much. If required, it will be worked upon via an enhancement request. >>>>>>> >>>>>>> Thanks >>>>>>> Erik >>>>>>> >>>>>> Thanks >>>>>> Harsha >>>>>>>> Hi Martin, >>>>>>>> >>>>>>>> In my opinion, the interfaces exposed by current JEP are lot closer to REST style than the interfaces exposed by Jolokia. >>>>>>>> For instance, HTTP GET by default should be used to read resources, but it is made part of URL in Jolokia interfaces. >>>>>>>> >>>>>>>> /read/// >>>>>>>> >>>>>>>> I would wait on opinions from more people before considering changing the current interfaces. >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Harsha >>>>>>>> >>>>>>>> On Wednesday 06 September 2017 11:40 AM, Martin Skarsaune wrote: >>>>>>>>> Hello >>>>>>>>> >>>>>>>>> Would one at least consider adopting the same URL paths and payloads as Jolokia? This could make life a lot easier for third party tools that connect to it. >>>>>>>>> >>>>>>>>> Best Regards >>>>>>>>> >>>>>>>>> Martin Skarsaune >>>>>>>>> >>>>>>>>> ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B < harsha.wardhana.b at oracle.com >: >>>>>>>>> Hi Kirk, >>>>>>>>> >>>>>>>>> Yes. Jolokia was considered and is listed as an alternative in the JEP. >>>>>>>>> >>>>>>>>> Jolokia can serve as a viable alternative but can be bulky. We are looking for simple and lightweight solution. >>>>>>>>> >>>>>>>>> -Harsha >>>>>>>>> >>>>>>>>> On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Have you run into this project? https://jolokia.org . Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. >>>>>>>>>> >>>>>>>>>> Kind regards, >>>>>>>>>> Kirk >>>>>>>>>> >>>>>>>>> >>>>>>>>>>> On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Harsha, >>>>>>>>>>> >>>>>>>>>>> Looping in jmx-dev. >>>>>>>>>>> >>>>>>>>>>>> byte[], short[], int[], float[], double[] >>>>>>>>>>> Should long[] be included there as well? >>>>>>>>>>> >>>>>>>>>>>> The REST adapter will come with a simple and lightweight JSON parser. >>>>>>>>>>> Is this an internal parser or will it be exposed as an API? >>>>>>>>>>> >>>>>>>>>>> If so, how does it relate to JEP 198: Light-Weight JSON API? >>>>>>>>>>> http://openjdk.java.net/jeps/198 >>>>>>>>>>> >>>>>>>>>>> Will com.sun.net.httpserver.HttpServer be used to serve the requests? >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Erik >>>>>>>>>>> >>>>>>>>>>>> Hi All, >>>>>>>>>>>> >>>>>>>>>>>> Please review the JEP for REST APIs for JMX : >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171311 >>>>>>>>>>>> >>>>>>>>>>>> The JEP aims at providing RESTful web interfaces to MBeans. >>>>>>>>>>>> >>>>>>>>>>>> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> -Harsha >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Tue Sep 12 14:16:15 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 12 Sep 2017 19:46:15 +0530 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <010313AA-BBA2-4C48-805A-E88FC98AFBD2@gmail.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> <74d24494-fef5-9e5d-d3c2-1996ba0e8ff6@oracle.com> <9bae5d49-6f3a-3aca-4635-4b2ec896e14a@oracle.com> <59B7BA7C.5080009@oracle.com> <010313AA-BBA2-4C48-805A-E88FC98AFBD2@gmail.com> Message-ID: Hi Kirk,Erik, The current JEP addresses the first use-case. Second use case can be realized by adding a JMXConnector that operates over REST APIs provided by the current JEP. But that is outside the scope of this JEP. -Harsha On Tuesday 12 September 2017 04:27 PM, Kirk Pepperdine wrote: > >> On Sep 12, 2017, at 12:44 PM, Erik Gahlin > > wrote: >> >> I guess there are two use cases: >> >> 1) Simple interoperability with other languages. >> 2) A drop in replacement for RMI >> >> Can a JMX connector be written that support both use cases? I don't >> know, but if not it could be that we need both a connector and an >> adapter. > > I think if you were to extend JMXConnector to wrap the REST API you > might be able to expose both. But I?m not sure it would be a great > solution. I think a second JEP would be a better option. > > ? Kirk > >> >> Erik >> >>> Hi Kirk, >>> >>> I guess the term 'connector' here is loosely applied. When I say >>> connector, I mean the connector that provides implementation of the >>> package below, >>> >>> https://docs.oracle.com/javase/8/docs/api/javax/management/remote/package-summary.html >>> >>> RMIConnector is one implementation of above connector. >>> >>> >>> On Tuesday 12 September 2017 12:56 PM, Kirk Pepperdine wrote: >>>> Hi Harsha, >>>> >>>> From Chapter 5 of the JMX documentation. "Many different >>>> implementations of connectors are possible. In particular, there >>>> are many possibilities for the protocol used to communicate over a >>>> connection between client and server.? >>>> >>>> It goes on in the Generic Connector section under "User-Defined >>>> Protocols? to say; "While the RMI connector must be present in >>>> every implementation of the JMX Remote API, you can also implement >>>> a connector based on a protocol that is not defined in the JMX >>>> Remote API standard. A typical example of this is a connector based >>>> on a protocol that uses HTTP/S. Other protocols are also possible. >>>> The JMX specification describes how to implement a connector based >>>> on a user-defined protocol.? >>>> >>>> Unless I?m missing something, this all suggests that there is >>>> nothing inherently wrong is using REST behind a JMXConnector. >>> I hope above should clarify what I refer to when I say JMXConnector. >>> In that sense, REST APIs alone cannot work as connector. In fact, it >>> stands parallel to connector, as in it directly wraps the >>> MBeanServer and does not wrap any JMXConnector. The JEP has detailed >>> information about where the REST adapter sits in the JMX architecture. >>> >>> Are you suggesting that we implement a JMXConnector that works over >>> REST? >>>> >>>> As written this JEP pretty much looks like Jolokia. Jolokia is a >>>> great project and as such I fail to see the benefits of simply >>>> duplicating it. I?d also argue that the usefulness of that project >>>> has been some what muted because it is not a drop in replacement >>>> for the standard RMI connector meaning that one has to modify an >>>> entire tool chain just to make use of it. However, creating a REST >>>> based JMXConnector would be immediately useful. >>>> As an aside, Jus last week I started on a JMXConnector that uses a >>>> shared memory segment for communications. Of course this >>>> implementation would only be available for local communications but >>>> it offers some advantages over using a socket based protocol, even >>>> if that comms is over local loopback. >>>> >>>> Kind regards, >>>> Kirk Pepperdine >>> >>> Thanks >>> Harsha >>>> >>>> >>>> >>>>> On Sep 12, 2017, at 9:04 AM, Harsha Wardhana B >>>>> wrote: >>>>> >>>>> Hi Kirk, >>>>> >>>>> REST APIs work as an adapter and cannot work as a connector. To >>>>> quote from the JEP, >>>>> >>>>> >>>>>> The REST adapter is a part of the Distributed services level. >>>>>> Connectors mirror the interfaces of agent level services to >>>>>> remote clients, whereas adapters transform agent level services >>>>>> to different protocol. The proposed functionality will transform >>>>>> Agent level services to REST APIs, hence the name "REST adapter". >>>>> A connector *must* adhere to the JMX remoting spec. REST APIs >>>>> cannot adhere to that because they expose APIs via HTTP and not >>>>> Java. Hence it is called an Adapter and not a connector. It can >>>>> never work as a 'drop-in' replacement for JMX/RMI Connector. >>>>> Existing tools using using RMIConnector will have to be modified >>>>> to use REST APIs. >>>>> >>>>> The current JEP does not allow all of the CRUD operations on >>>>> MBeans. In the spirit of keeping the APIs language agnostic, only >>>>> read/write is supported. It is not possible to specify >>>>> create/delete REST APIs for JMX without incorporating language >>>>> specific features. I would welcome discussions around including >>>>> create/delete APIs for MBeans. >>>>> >>>>> In lieu of the above, as of now REST adapter cannot exist >>>>> independently and will have to live along-side RMIConnector. >>>>> >>>>> -Harsha >>>>> >>>>> >>>>> On Monday 11 September 2017 09:05 PM, Kirk Pepperdine wrote: >>>>>> Hi Harsha, >>>>>> >>>>>> The only reason I mentioned Jolokia is that it?s a project that >>>>>> usefulness is some what limited because it is *not* a compliment >>>>>> JMX connector and as such cannot be used as a straight drop-in >>>>>> replacement for the current RMI based connector. Is your plan >>>>>> here to make it a fully compliant connector so that we could >>>>>> configure tooling such as the MBean viewers in jConsole and >>>>>> VisualVM (or JMC for that matter) to use a restful connector >>>>>> instead of an RMI based connector? IMHO, doing so would represent >>>>>> a huge win as I know of quite a few projects that cannot or will >>>>>> not use JMX because of it?s reliance on RMI. >>>>>> >>>>>> Consolidating all of the options under a single flag looks like >>>>>> another interesting win. >>>>>> >>>>>> Kind regards, >>>>>> Kirk >>>>>> >>>>>> >>>>>> >>>>>>> On Sep 11, 2017, at 4:08 PM, Harsha Wardhana B >>>>>>> wrote: >>>>>>> >>>>>>> Hi Erik, >>>>>>> >>>>>>> >>>>>>> On Monday 11 September 2017 07:14 PM, Erik Gahlin wrote: >>>>>>>> Hi Harsha, >>>>>>>> >>>>>>>> I haven't looked at Jolokia, or know what is the most >>>>>>>> reasonable approach in this case, but as a principle, I think >>>>>>>> we should strive for the best possible design rather than >>>>>>>> trying to be compatible with third party tools. >>>>>>> Agreed. That will always be the first priority. That is the >>>>>>> reason HTTP GET interfaces will not be changed. I am undecided >>>>>>> if the POST payloads need to be changed (without compromising >>>>>>> the REST design principles) to increase adoption of this feature. >>>>>>>> >>>>>>>> How will the command line look like to start the agent with the >>>>>>>> rest adapter? >>>>>>>> >>>>>>>> In the past there have been discussions about adding syntactic >>>>>>>> sugar for -Dcom.sun.management, i.e. >>>>>>>> >>>>>>>> -Xmanagement:ssl=false,port=7091,authenticate=false >>>>>>>> >>>>>>>> instead of >>>>>>>> >>>>>>>> -Dcom.sun.management.jmxremote.ssl=false >>>>>>>> -Dcom.sun.management.jmxremote.port=7091 >>>>>>>> -Dcom.sun.management.jmxremote.authenticate=false >>>>>>>> >>>>>>>> which is hard to remember, cumbersome to write and error prone >>>>>>>> since the parameters are not validated. If we are adding >>>>>>>> support for REST, it could perhaps be default, i.e. >>>>>>>> >>>>>>>> -Xmanagement:ssl=false,authenticate=false,port=80 >>>>>>>> >>>>>>>> If you want to use JMX over RMI you would specify protocol: >>>>>>>> >>>>>>>> -Xmanagement:ssl=false,port=7091,authenticate=false,protocol=rmi >>>>>>> Yes. There is an enhancement request to add the -Xmanagemet:* >>>>>>> syntatic sugar for -Dcom.sun.management.jmxremote.* flags. REST >>>>>>> adapter will use one of the above flags though I haven't thought >>>>>>> of the exact name for it yet. I will update the JEP with the >>>>>>> details of the flag shortly. >>>>>>>> >>>>>>>> Has there been any thoughts about JMX notifications? >>>>>>> Notifications will not be supported in this JEP. >>>>>>> >>>>>>> * MBean Notifications are not a widely used feature and will >>>>>>> not be supported via the REST adapter. >>>>>>> >>>>>>>> >>>>>>>> I know it is outside the scope of the JEP, but I think we >>>>>>>> should take it into consideration when doing the design, so the >>>>>>>> functionality could be added on later without too much difficulty. >>>>>>> Notifications can be added without modifying the current design >>>>>>> too much. If required, it will be worked upon via an enhancement >>>>>>> request. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Erik >>>>>>>> >>>>>>> Thanks >>>>>>> Harsha >>>>>>>>> >>>>>>>>> Hi Martin, >>>>>>>>> >>>>>>>>> In my opinion, the interfaces exposed by current JEP are lot >>>>>>>>> closer to REST style than the interfaces exposed by Jolokia. >>>>>>>>> >>>>>>>>> For instance, HTTP GET by default should be used to read >>>>>>>>> resources, but it is made part of URL in Jolokia interfaces. >>>>>>>>> >>>>>>>>> /read/// >>>>>>>>> >>>>>>>>> I would wait on opinions from more people before considering >>>>>>>>> changing the current interfaces. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> -Harsha >>>>>>>>> >>>>>>>>> On Wednesday 06 September 2017 11:40 AM, Martin Skarsaune wrote: >>>>>>>>>> Hello >>>>>>>>>> >>>>>>>>>> Would one at least consider adopting the same URL paths and >>>>>>>>>> payloads as Jolokia? This could make life a lot easier for >>>>>>>>>> third party tools that connect to it. >>>>>>>>>> >>>>>>>>>> Best Regards >>>>>>>>>> >>>>>>>>>> Martin Skarsaune >>>>>>>>>> >>>>>>>>>> ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B >>>>>>>>>> : >>>>>>>>>> >>>>>>>>>> Hi Kirk, >>>>>>>>>> >>>>>>>>>> Yes. Jolokia was considered and is listed as an >>>>>>>>>> alternative in the JEP. >>>>>>>>>> >>>>>>>>>> * Jolokia can serve as a viable alternative but can be >>>>>>>>>> bulky. We are looking for simple and lightweight >>>>>>>>>> solution. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Harsha >>>>>>>>>> >>>>>>>>>> On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine >>>>>>>>>> wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Have you run into this project?https://jolokia.org . Unfortunately it?s not exactly a drop in replacement for the standard RMI based JMX connector but it?s not far off. >>>>>>>>>>> >>>>>>>>>>> Kind regards, >>>>>>>>>>> Kirk >>>>>>>>>>> >>>>>>>>>>>> On Sep 5, 2017, at 6:30 PM, Erik Gahlin wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Harsha, >>>>>>>>>>>> >>>>>>>>>>>> Looping in jmx-dev. >>>>>>>>>>>> >>>>>>>>>>>>> byte[], short[], int[], float[], double[] >>>>>>>>>>>> Should long[] be included there as well? >>>>>>>>>>>> >>>>>>>>>>>>> The REST adapter will come with a simple and lightweight JSON parser. >>>>>>>>>>>> Is this an internal parser or will it be exposed as an API? >>>>>>>>>>>> >>>>>>>>>>>> If so, how does it relate to JEP 198: Light-Weight JSON API? >>>>>>>>>>>> http://openjdk.java.net/jeps/198 >>>>>>>>>>>> >>>>>>>>>>>> Will com.sun.net.httpserver.HttpServer be used to serve the requests? >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Erik >>>>>>>>>>>> >>>>>>>>>>>>> Hi All, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review the JEP for REST APIs for JMX : >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171311 >>>>>>>>>>>>> >>>>>>>>>>>>> The JEP aims at providing RESTful web interfaces to MBeans. >>>>>>>>>>>>> >>>>>>>>>>>>> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> -Harsha >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.tulach at oracle.com Tue Sep 12 17:44:07 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Tue, 12 Sep 2017 19:44:07 +0200 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <1906851.CDFazpJ8ns@pracovni> Message-ID: <1595796.xe8q7Anfpj@pracovni> Dear reviewers, after several reconsiderations I have webrev #4 ready for your review. Can you please take a look at http://cr.openjdk.java.net/~jtulach/8182701/webrev.04/ and let me know if it is in a reasonable shape? Thanks a lot. -jt From mandy.chung at oracle.com Tue Sep 12 18:19:45 2017 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 12 Sep 2017 11:19:45 -0700 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <1595796.xe8q7Anfpj@pracovni> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <1906851.CDFazpJ8ns@pracovni> <1595796.xe8q7Anfpj@pracovni> Message-ID: On 9/12/17 10:44 AM, Jaroslav Tulach wrote: > Dear reviewers, > after several reconsiderations I have webrev #4 ready for your review. Can you > please take a look at > > http://cr.openjdk.java.net/~jtulach/8182701/webrev.04/ > > and let me know if it is in a reasonable shape? Thanks a lot. > -jt Yes defining a new provider module for the platform mbean registration is a reasonable solution.? Generally the patch looks right.? I have a question on the build and a comment on the new mbean method. ./make/common/Modules.gmk ??? Nit: can you move jdk.internal.vm.compiler.management to keep the list in alphabetical order 199 # Filter out Graal specific modules if Graal build is disabled 200 201 ifeq ($(INCLUDE_GRAAL), false) 202 MODULES_FILTER += jdk.internal.vm.compiler 203 endif When will INCLUDE_GRAAL be set to false?? I think jdk.internal.vm.compiler.management should also be filtered if jdk.internal.vm.compiler is disabled. Is jdk.internal.vm.compiler and jdk.internal.vm.compiler.management built for all platforms in JDK 10? If not, ?? jdk/src/java.management/share/classes/module-info.java may fail to compile when jdk.internal.vm.compiler.management is not present.?? We can consult with the build team when you find out what configuration that jdk.internal.vm.compiler is not built. hotspot/src/jdk.internal.vm.compiler/share/classes/module-info.java 29 requires transitive jdk.internal.vm.ci; do you get any error without this requires transitive? jdk.internal.vm.compiler.management already requires jdk.internal.vm.ci.? I would think this requires transitive is not necessary. Is HotSpotGraalCompiler::mbean method necessary?? In GraalMBeans.java 53 public static Object findGraalRuntimeBean() { 54 JVMCIRuntime r = JVMCI.getRuntime(); 55 JVMCICompiler c = r.getCompiler(); 56 if (c instanceof HotSpotGraalCompiler) { 57 return ((HotSpotGraalCompiler) c).mbean(); 58 } 59 return null; 60 } It seems that you can call HotspotGraalRuntime::mbean directly.? As we discussed offline, we agree that HotSpotRuntimeMBean should belong to this new module but it requires some refactoring which may take some amount of work.? Such clean up will be followed up in a separate JBS issue. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Wed Sep 13 09:28:39 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 13 Sep 2017 10:28:39 +0100 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <1595796.xe8q7Anfpj@pracovni> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <1906851.CDFazpJ8ns@pracovni> <1595796.xe8q7Anfpj@pracovni> Message-ID: Hi Jaroslav, GraalMBeans.java: 77 @Override 78 public Set mbeanInterfaceNames() { 79 return Collections.singleton(name); 80 } This is not correct. The return set should be a set of MXBean interface names, as in Class.getName(), not a set of MXBean ObjectName strings. The interface in question must be implemented by the concrete MBean instance and must be a subclass of PlatformManagedObject. It is not required for an MBean to implement such an interface - if it doesn't then it simply won't be obtainable from ManagementFactory::getPlatformMXBean or ManagementFactory::getPlatformMXBeans. So I suspect that in your case, since mbeanInterfaces() returns an empty set then mbeanInterfaceNames() should also return an empty set. IIRC mbeanInterfaceNames() was introduced so that you could query for a particular MBean implementing a given interface without necessarily triggering the loading and initialization of all interfaces implemented by all MBeans. best regards, -- daniel On 12/09/2017 18:44, Jaroslav Tulach wrote: > Dear reviewers, > after several reconsiderations I have webrev #4 ready for your review. Can you > please take a look at > > http://cr.openjdk.java.net/~jtulach/8182701/webrev.04/ > > and let me know if it is in a reasonable shape? Thanks a lot. > -jt > From shafi.s.ahmad at oracle.com Wed Sep 13 11:40:51 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Wed, 13 Sep 2017 11:40:51 +0000 (UTC) Subject: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code In-Reply-To: <3b93b2b5-cf0c-42df-9673-5c61b2951ad3@oracle.com> References: <131072bd-7d03-4f79-8ca0-6c26f9bbe315@default> <3b93b2b5-cf0c-42df-9673-5c61b2951ad3@oracle.com> Message-ID: <8ae3e612-5b05-42ce-a7ed-6d193ec637f0@default> Hi Mandy, Thank you for the review comments. >> I suggest to file a RFE to consider adding hasListeners method as a separate issue. I will file a RFE for this. >> This creates a new thread for each listener to handle each notification which is overkill. You can create one system daemon thread to handle all notifications for all listeners. Please correct me if I don't understand correctly, instead of using thread as an Executor I should use system daemon thread as an Executor. >> For this fix, you could simply update NotificationEmitterSupport to create a system daemon thread to handle all notifications. I have a doubt if I will update the NotificationEmitterSupport then I am not sure how to pass an Executor. NotificationEmitterSupport doesn't takes an Executor. Regards, Shafi From: mandy chung Sent: Tuesday, September 12, 2017 2:19 AM To: Shafi Ahmad ; serviceability-dev at openjdk.java.net Cc: Poonam Parhar Subject: Re: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code On 9/4/17 3:11 AM, Shafi Ahmad wrote: The method hasListeners() is referenced inside MemoryImpl.java and defined in NotificationEmitterSupport. This method is not present in NotificationBroadcasterSupport so I added it to NotificationBroadcasterSupport. Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8170299 Webrev link: HYPERLINK "http://cr.openjdk.java.net/%7Eshshahma/8170299/webrev.01/"http://cr.openjdk.java.net/~shshahma/8170299/webrev.01/ This patch adds a new public method in NotificationBroadcasterSupport. I think this fix wants to avoid adding this public method since this fix is intended to be backport. MemoryImpl checks if there is any listener registered to avoid instantiating the notification object if no listener handles it. Replacing the internal sun.management.NotificationEmitterSupport with NotificationBroadcasterSupport is a good change. I suggest to file a RFE to consider adding hasListeners method as a separate issue. 171 static final class ThreadExecutor implements Executor { 172 public void execute(Runnable r) { new Thread(r).start(); } 173 } This creates a new thread for each listener to handle each notification which is overkill. You can create one system daemon thread to handle all notifications for all listeners. For this fix, you could simply update NotificationEmitterSupport to create a system daemon thread to handle all notifications. NotificationEmitterSupport::sendNotification should also be updated to ignore the exception (currently it throws an exception). Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Wed Sep 13 15:23:22 2017 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 13 Sep 2017 08:23:22 -0700 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <1906851.CDFazpJ8ns@pracovni> <1595796.xe8q7Anfpj@pracovni> Message-ID: <14ccc931-d861-1672-9d26-a95e51e2f440@oracle.com> On 9/13/17 2:28 AM, Daniel Fuchs wrote: > Hi Jaroslav, > > GraalMBeans.java: > > ? 77???????? @Override > ? 78???????? public Set mbeanInterfaceNames() { > ? 79???????????? return Collections.singleton(name); > ? 80???????? } Good catch, Daniel.? This should return empty set as mbeanInterfaces() returns.? mbeanInterfaceNames returns the class name of the mbean interfaces. Mandy > > This is not correct. The return set should be a set of > MXBean interface names, as in Class.getName(), not a set > of MXBean ObjectName strings. > > The interface in question must be implemented by the > concrete MBean instance and must be a subclass of > PlatformManagedObject. > > It is not required for an MBean to implement such > an interface - if it doesn't then it simply won't > be obtainable from ManagementFactory::getPlatformMXBean > or ManagementFactory::getPlatformMXBeans. > > So I suspect that in your case, since mbeanInterfaces() > returns an empty set then mbeanInterfaceNames() should > also return an empty set. > > IIRC mbeanInterfaceNames() was introduced so that > you could query for a particular MBean implementing > a given interface without necessarily triggering the > loading and initialization of all interfaces implemented > by all MBeans. > > best regards, > > -- daniel > > > > On 12/09/2017 18:44, Jaroslav Tulach wrote: >> Dear reviewers, >> after several reconsiderations I have webrev #4 ready for your >> review. Can you >> please take a look at >> >> http://cr.openjdk.java.net/~jtulach/8182701/webrev.04/ >> >> and let me know if it is in a reasonable shape? Thanks a lot. >> -jt >> > From mandy.chung at oracle.com Wed Sep 13 16:41:19 2017 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 13 Sep 2017 09:41:19 -0700 Subject: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code In-Reply-To: <8ae3e612-5b05-42ce-a7ed-6d193ec637f0@default> References: <131072bd-7d03-4f79-8ca0-6c26f9bbe315@default> <3b93b2b5-cf0c-42df-9673-5c61b2951ad3@oracle.com> <8ae3e612-5b05-42ce-a7ed-6d193ec637f0@default> Message-ID: <3f0135e8-5dbf-4c86-6a1d-5db97893c45c@oracle.com> On 9/13/17 4:40 AM, Shafi Ahmad wrote: > > Hi Mandy, > > Thank you for the review comments. > > >> I suggest to file a RFE to consider adding hasListeners method as a > separate issue. > > I will file a RFE for this. > > >> This creates a new thread for each listener to handle each notification which is overkill.?? You > can create one system daemon thread to handle all notifications for > all listeners. > > Please correct me if I don?t understand correctly, instead of using > thread as an Executor I should use system daemon thread as an Executor. > You can still use Executor and what I meant is to use one single thread for handling the low memory notification rather than one thread per notification. See Executors::newSingleThreadExecutor(ThreadFactory factory) and the thread factory can create one InnocuousThreadFactory::newSystemThread and set it to daemon thread. > >> For this fix, you could simply update NotificationEmitterSupport to create a system daemon thread to > handle all notifications. > > I have a doubt if I will update the NotificationEmitterSupport then I > am not sure how to pass an Executor. NotificationEmitterSupport > doesn?t takes an Executor. > Modify NotificationEmitterSupport to have a static Executor initialized as described above.? I can send you the sample code to do that - just let me know. Mandy > > Regards, > > Shafi > > *From:*mandy chung > *Sent:* Tuesday, September 12, 2017 2:19 AM > *To:* Shafi Ahmad ; > serviceability-dev at openjdk.java.net > *Cc:* Poonam Parhar > *Subject:* Re: [10] RFR for JDK-8170299: Debugger does not stop inside > the low memory notifications code > > On 9/4/17 3:11 AM, Shafi Ahmad wrote: > > > > The method hasListeners() is referenced ?inside MemoryImpl.java > and defined in ?NotificationEmitterSupport. > > This method is not present in ?NotificationBroadcasterSupport so I > added it to NotificationBroadcasterSupport. > > Jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8170299 > > Webrev link: > http://cr.openjdk.java.net/~shshahma/8170299/webrev.01/ > > > This patch adds a new public method in > NotificationBroadcasterSupport.? I think this fix wants to avoid > adding this public method since this fix is intended to be backport. > > MemoryImpl checks if there is any listener registered to avoid > instantiating the notification object if no listener handles it. > > Replacing the internal sun.management.NotificationEmitterSupport with > NotificationBroadcasterSupport is a good change.? I suggest to file a > RFE to consider adding hasListeners method as a separate issue. > > ?171???? static final class ThreadExecutor implements Executor { > 172???????? public void execute(Runnable r) { new Thread(r).start(); } > 173???? } > > This creates a new thread for each listener to handle each > notification which is overkill. You can create one system daemon > thread to handle all notifications for all listeners. > > For this fix, you could simply update NotificationEmitterSupport to > create a system daemon thread to handle all notifications. > NotificationEmitterSupport::sendNotification should also be updated to > ignore the exception (currently it throws an exception). > > Mandy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Sep 13 22:23:33 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 13 Sep 2017 15:23:33 -0700 Subject: RFR(10)(M): 8179498: attach in linux should be relative to /proc/pid/root and namespace aware In-Reply-To: <7574486e-124d-ffe1-df36-1c7911844cde@oracle.com> References: <6434ed9c-7ea0-fe2d-d185-eca74c06ea0b@oracle.com> <27b7a7af-e95b-4b36-5808-be8607f1b30b@oracle.com> <4436414c-6bbf-d173-3e23-e1fb7deec3f1@oracle.com> <7574486e-124d-ffe1-df36-1c7911844cde@oracle.com> Message-ID: <08bf2b33-53bf-c168-01b5-dc3d71b2f7b1@oracle.com> I could use one more reviewer. thanks, Chris On 9/11/17 8:03 PM, Chris Plummer wrote: > Ok, I will. Thanks. > > Chris > > On 9/11/17 6:13 PM, serguei.spitsyn at oracle.com wrote: >> Hi Chris, >> >> This looks good to me. >> >> I'm not sure if all the nsk.aod and the AttachOnDemand tests from >> the nsk.jvmti are run in the hotspot tier1, 2, and 3 tests. >> It makes sense to double-check it. >> >> >> Thanks, >> Serguei >> >> >> On 9/10/17 20:34, Chris Plummer wrote: >>> [re-sending - sent to wrong alias first time] >>> >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8179498 >>> http://cr.openjdk.java.net/~cjplummer/8179498/webrev.00/webrev_jdk/ >>> >>> The CR has the relevant details. Some previous discussions can be >>> found here: >>> >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/021237.html >>> >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-May/021249.html >>> >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021679.html >>> >>> >>> Testing with docker has been limited to just making sure jcmd now >>> works with the docker setup I was provided. I currently don't see >>> how we can run our existing tests in a way that would test the >>> docker support without doing some rewriting of the tests. >>> >>> I also ran all our hotspot tier1, 2, and 3 tests, along with >>> jdk/test/tools and jdk/test/sun/tools tests to make sure existing >>> functionality is not broken with these changes. >>> >>> thanks, >>> >>> Chris >> > From david.holmes at oracle.com Thu Sep 14 00:12:17 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Sep 2017 10:12:17 +1000 Subject: RFR(10)(M): 8179498: attach in linux should be relative to /proc/pid/root and namespace aware In-Reply-To: <08bf2b33-53bf-c168-01b5-dc3d71b2f7b1@oracle.com> References: <6434ed9c-7ea0-fe2d-d185-eca74c06ea0b@oracle.com> <27b7a7af-e95b-4b36-5808-be8607f1b30b@oracle.com> <4436414c-6bbf-d173-3e23-e1fb7deec3f1@oracle.com> <7574486e-124d-ffe1-df36-1c7911844cde@oracle.com> <08bf2b33-53bf-c168-01b5-dc3d71b2f7b1@oracle.com> Message-ID: Hi Chris, On 14/09/2017 8:23 AM, Chris Plummer wrote: > I could use one more reviewer. Generally this seems okay to me. One query though ... in createAttachFile don't you need to alter the tmpdir using part in a similar manner to how findSocketFile was modified? Minor note - you can collapse your catch blocks into 1 using something like } catch (NumberFormatException | IOException x) { throw new AttachNotSupportedException("Unable to parse namespace"); } Cheers, David > thanks, > > Chris > > On 9/11/17 8:03 PM, Chris Plummer wrote: >> Ok, I will. Thanks. >> >> Chris >> >> On 9/11/17 6:13 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Chris, >>> >>> This looks good to me. >>> >>> I'm not sure if all the nsk.aod and the AttachOnDemand tests from >>> the nsk.jvmti are run in the hotspot tier1, 2, and 3 tests. >>> It makes sense to double-check it. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 9/10/17 20:34, Chris Plummer wrote: >>>> [re-sending - sent to wrong alias first time] >>>> >>>> Hello, >>>> >>>> Please review the following: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8179498 >>>> http://cr.openjdk.java.net/~cjplummer/8179498/webrev.00/webrev_jdk/ >>>> >>>> The CR has the relevant details. Some previous discussions can be >>>> found here: >>>> >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/021237.html >>>> >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-May/021249.html >>>> >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021679.html >>>> >>>> >>>> Testing with docker has been limited to just making sure jcmd now >>>> works with the docker setup I was provided. I currently don't see >>>> how we can run our existing tests in a way that would test the >>>> docker support without doing some rewriting of the tests. >>>> >>>> I also ran all our hotspot tier1, 2, and 3 tests, along with >>>> jdk/test/tools and jdk/test/sun/tools tests to make sure existing >>>> functionality is not broken with these changes. >>>> >>>> thanks, >>>> >>>> Chris >>> >> > From chris.plummer at oracle.com Thu Sep 14 03:03:06 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 13 Sep 2017 20:03:06 -0700 Subject: RFR(10)(M): 8179498: attach in linux should be relative to /proc/pid/root and namespace aware In-Reply-To: References: <6434ed9c-7ea0-fe2d-d185-eca74c06ea0b@oracle.com> <27b7a7af-e95b-4b36-5808-be8607f1b30b@oracle.com> <4436414c-6bbf-d173-3e23-e1fb7deec3f1@oracle.com> <7574486e-124d-ffe1-df36-1c7911844cde@oracle.com> <08bf2b33-53bf-c168-01b5-dc3d71b2f7b1@oracle.com> Message-ID: Hi David, On 9/13/17 5:12 PM, David Holmes wrote: > Hi Chris, > > On 14/09/2017 8:23 AM, Chris Plummer wrote: >> I could use one more reviewer. > > Generally this seems okay to me. > > One query though ... in createAttachFile don't you need to alter the > tmpdir using part in a similar manner to how findSocketFile was modified? The fix in findSocketFile is not just to make sure the client uses the correct pid in the .java_pid file files, but also (as you point out) to make sure that the client properly references the target jvm's tmp directory when accessing the .java_pid file. findSocketFile is a little different. You still have to map to the proper from pid to ns_pid when referencing the .attach_pid file, but you don't have the /tmp mount point differences to deal with. /proc//cwd should work even if the pid is for a docker. You don't even have to map to the pid as the docker sees it. /proc//cwd from the client's POV should be the same as /proc//cwd from the target JVM's POV. > > Minor note - you can collapse your catch blocks into 1 using something > like > > ??????? } catch (NumberFormatException | IOException x) { > ???????????? throw new AttachNotSupportedException("Unable to parse > namespace"); > ??????? } I'll make that change. thanks, Chris > > Cheers, > David >> thanks, >> >> Chris >> >> On 9/11/17 8:03 PM, Chris Plummer wrote: >>> Ok, I will. Thanks. >>> >>> Chris >>> >>> On 9/11/17 6:13 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Chris, >>>> >>>> This looks good to me. >>>> >>>> I'm not sure if all the nsk.aod and the AttachOnDemand tests from >>>> the nsk.jvmti are run in the hotspot tier1, 2, and 3 tests. >>>> It makes sense to double-check it. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 9/10/17 20:34, Chris Plummer wrote: >>>>> [re-sending - sent to wrong alias first time] >>>>> >>>>> Hello, >>>>> >>>>> Please review the following: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8179498 >>>>> http://cr.openjdk.java.net/~cjplummer/8179498/webrev.00/webrev_jdk/ >>>>> >>>>> The CR has the relevant details. Some previous discussions can be >>>>> found here: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/021237.html >>>>> >>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-May/021249.html >>>>> >>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021679.html >>>>> >>>>> >>>>> Testing with docker has been limited to just making sure jcmd now >>>>> works with the docker setup I was provided. I currently don't see >>>>> how we can run our existing tests in a way that would test the >>>>> docker support without doing some rewriting of the tests. >>>>> >>>>> I also ran all our hotspot tier1, 2, and 3 tests, along with >>>>> jdk/test/tools and jdk/test/sun/tools tests to make sure existing >>>>> functionality is not broken with these changes. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>> >>> >> From david.holmes at oracle.com Thu Sep 14 04:00:40 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Sep 2017 14:00:40 +1000 Subject: RFR(10)(M): 8179498: attach in linux should be relative to /proc/pid/root and namespace aware In-Reply-To: References: <6434ed9c-7ea0-fe2d-d185-eca74c06ea0b@oracle.com> <27b7a7af-e95b-4b36-5808-be8607f1b30b@oracle.com> <4436414c-6bbf-d173-3e23-e1fb7deec3f1@oracle.com> <7574486e-124d-ffe1-df36-1c7911844cde@oracle.com> <08bf2b33-53bf-c168-01b5-dc3d71b2f7b1@oracle.com> Message-ID: Hi Chris, On 14/09/2017 1:03 PM, Chris Plummer wrote: > Hi David, > > On 9/13/17 5:12 PM, David Holmes wrote: >> Hi Chris, >> >> On 14/09/2017 8:23 AM, Chris Plummer wrote: >>> I could use one more reviewer. >> >> Generally this seems okay to me. >> >> One query though ... in createAttachFile don't you need to alter the >> tmpdir using part in a similar manner to how findSocketFile was modified? > The fix in findSocketFile is not just to make sure the client uses the > correct pid in the .java_pid file files, but also (as you point out) to > make sure that the client properly references the target jvm's tmp > directory when accessing the .java_pid file. findSocketFile is a little I presume you mean createAttachFile there. > different. You still have to map to the proper from pid to ns_pid when > referencing the .attach_pid file, but you don't have the /tmp mount > point differences to deal with. /proc//cwd should work even if the > pid is for a docker. You don't even have to map to the pid as the docker > sees it. /proc//cwd from the client's POV should be the same as > /proc//cwd from the target JVM's POV. Sorry but I don't follow. If findSocketFile has to look in /proc//root/ for the socket file, why does the createAttachFile not also have to write the attach file into /proc//root/ ?? In both cases it needs to find the tmpdir of the target process. Thanks, David >> >> Minor note - you can collapse your catch blocks into 1 using something >> like >> >> ??????? } catch (NumberFormatException | IOException x) { >> ???????????? throw new AttachNotSupportedException("Unable to parse >> namespace"); >> ??????? } > I'll make that change. > > thanks, > > Chris >> >> Cheers, >> David >>> thanks, >>> >>> Chris >>> >>> On 9/11/17 8:03 PM, Chris Plummer wrote: >>>> Ok, I will. Thanks. >>>> >>>> Chris >>>> >>>> On 9/11/17 6:13 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Chris, >>>>> >>>>> This looks good to me. >>>>> >>>>> I'm not sure if all the nsk.aod and the AttachOnDemand tests from >>>>> the nsk.jvmti are run in the hotspot tier1, 2, and 3 tests. >>>>> It makes sense to double-check it. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 9/10/17 20:34, Chris Plummer wrote: >>>>>> [re-sending - sent to wrong alias first time] >>>>>> >>>>>> Hello, >>>>>> >>>>>> Please review the following: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8179498 >>>>>> http://cr.openjdk.java.net/~cjplummer/8179498/webrev.00/webrev_jdk/ >>>>>> >>>>>> The CR has the relevant details. Some previous discussions can be >>>>>> found here: >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/021237.html >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-May/021249.html >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021679.html >>>>>> >>>>>> >>>>>> Testing with docker has been limited to just making sure jcmd now >>>>>> works with the docker setup I was provided. I currently don't see >>>>>> how we can run our existing tests in a way that would test the >>>>>> docker support without doing some rewriting of the tests. >>>>>> >>>>>> I also ran all our hotspot tier1, 2, and 3 tests, along with >>>>>> jdk/test/tools and jdk/test/sun/tools tests to make sure existing >>>>>> functionality is not broken with these changes. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>> >>>> >>> > > From chris.plummer at oracle.com Thu Sep 14 04:15:53 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 13 Sep 2017 21:15:53 -0700 Subject: RFR(10)(M): 8179498: attach in linux should be relative to /proc/pid/root and namespace aware In-Reply-To: References: <6434ed9c-7ea0-fe2d-d185-eca74c06ea0b@oracle.com> <27b7a7af-e95b-4b36-5808-be8607f1b30b@oracle.com> <4436414c-6bbf-d173-3e23-e1fb7deec3f1@oracle.com> <7574486e-124d-ffe1-df36-1c7911844cde@oracle.com> <08bf2b33-53bf-c168-01b5-dc3d71b2f7b1@oracle.com> Message-ID: <630e7085-46d7-eaa2-72f7-268ddce1bda7@oracle.com> On 9/13/17 9:00 PM, David Holmes wrote: > Hi Chris, > > On 14/09/2017 1:03 PM, Chris Plummer wrote: >> Hi David, >> >> On 9/13/17 5:12 PM, David Holmes wrote: >>> Hi Chris, >>> >>> On 14/09/2017 8:23 AM, Chris Plummer wrote: >>>> I could use one more reviewer. >>> >>> Generally this seems okay to me. >>> >>> One query though ... in createAttachFile don't you need to alter the >>> tmpdir using part in a similar manner to how findSocketFile was >>> modified? >> The fix in findSocketFile is not just to make sure the client uses >> the correct pid in the .java_pid file files, but also (as you point >> out) to make sure that the client properly references the target >> jvm's tmp directory when accessing the .java_pid file. findSocketFile >> is a little > > I presume you mean createAttachFile there. Yes. > >> different. You still have to map to the proper from pid to ns_pid >> when referencing the .attach_pid file, but you don't have the /tmp >> mount point differences to deal with. /proc//cwd should work >> even if the pid is for a docker. You don't even have to map to the >> pid as the docker sees it. /proc//cwd from the client's POV >> should be the same as /proc//cwd from the target JVM's POV. > > Sorry but I don't follow. If findSocketFile has to look in > /proc//root/ for the socket file, why does the > createAttachFile not also have to write the attach file into > /proc//root/ ?? In both cases it needs to find the tmpdir > of the target process. Fortunately I have some old printlns that might help: ***getNamespacePid - ns_pid: 125 ***findSocketFile - f: /proc/24445/root/tmp/.java_pid125 ***createAttachFile - path: /proc/24445/cwd/.attach_pid125 So this is a case where the real pid is 24445, but the namespace pid in the docker is 125. The docker can (and does) reference /tmp/.java_pid125, but the client needs to reference /proc/24445/root/tmp/.java_pid125 to get to the same file. For .attach_pid125, the client can get to it through /proc/24445/cwd/.attach_pid125, and the docker process will look in cwd for the file. This is done in AttachListener::is_init_trigger(). BTW, comments like the following are no longer correct due to JDK-7132199: ??? // "/tmp" is used as a global well-known location for the files ??? // .java_pid. and .attach_pid. It is important that this ??? // location is the same for all processes, otherwise the tools ??? // will not be able to find all Hotspot processes. ??? // Any changes to this needs to be synchronized with HotSpot. ??? private static final String tmpdir = "/tmp"; So now .attach_pid is always created in cwd as you can see in createAttachFile(), although AttachListener::is_init_trigger() does check tmp, but only after cwd. thanks, Chris > > Thanks, > David > >>> >>> Minor note - you can collapse your catch blocks into 1 using >>> something like >>> >>> ??????? } catch (NumberFormatException | IOException x) { >>> ???????????? throw new AttachNotSupportedException("Unable to parse >>> namespace"); >>> ??????? } >> I'll make that change. >> >> thanks, >> >> Chris >>> >>> Cheers, >>> David >>>> thanks, >>>> >>>> Chris >>>> >>>> On 9/11/17 8:03 PM, Chris Plummer wrote: >>>>> Ok, I will. Thanks. >>>>> >>>>> Chris >>>>> >>>>> On 9/11/17 6:13 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Chris, >>>>>> >>>>>> This looks good to me. >>>>>> >>>>>> I'm not sure if all the nsk.aod and the AttachOnDemand tests from >>>>>> the nsk.jvmti are run in the hotspot tier1, 2, and 3 tests. >>>>>> It makes sense to double-check it. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 9/10/17 20:34, Chris Plummer wrote: >>>>>>> [re-sending - sent to wrong alias first time] >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Please review the following: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8179498 >>>>>>> http://cr.openjdk.java.net/~cjplummer/8179498/webrev.00/webrev_jdk/ >>>>>>> >>>>>>> The CR has the relevant details. Some previous discussions can >>>>>>> be found here: >>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/021237.html >>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-May/021249.html >>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021679.html >>>>>>> >>>>>>> >>>>>>> Testing with docker has been limited to just making sure jcmd >>>>>>> now works with the docker setup I was provided. I currently >>>>>>> don't see how we can run our existing tests in a way that would >>>>>>> test the docker support without doing some rewriting of the tests. >>>>>>> >>>>>>> I also ran all our hotspot tier1, 2, and 3 tests, along with >>>>>>> jdk/test/tools and jdk/test/sun/tools tests to make sure >>>>>>> existing functionality is not broken with these changes. >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>> >>>>> >>>> >> >> From david.holmes at oracle.com Thu Sep 14 05:36:41 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Sep 2017 15:36:41 +1000 Subject: RFR(10)(M): 8179498: attach in linux should be relative to /proc/pid/root and namespace aware In-Reply-To: <630e7085-46d7-eaa2-72f7-268ddce1bda7@oracle.com> References: <6434ed9c-7ea0-fe2d-d185-eca74c06ea0b@oracle.com> <27b7a7af-e95b-4b36-5808-be8607f1b30b@oracle.com> <4436414c-6bbf-d173-3e23-e1fb7deec3f1@oracle.com> <7574486e-124d-ffe1-df36-1c7911844cde@oracle.com> <08bf2b33-53bf-c168-01b5-dc3d71b2f7b1@oracle.com> <630e7085-46d7-eaa2-72f7-268ddce1bda7@oracle.com> Message-ID: <98f4eac4-2e45-21be-3f6f-df443894eeae@oracle.com> On 14/09/2017 2:15 PM, Chris Plummer wrote: > On 9/13/17 9:00 PM, David Holmes wrote: >> Hi Chris, >> >> On 14/09/2017 1:03 PM, Chris Plummer wrote: >>> Hi David, >>> >>> On 9/13/17 5:12 PM, David Holmes wrote: >>>> Hi Chris, >>>> >>>> On 14/09/2017 8:23 AM, Chris Plummer wrote: >>>>> I could use one more reviewer. >>>> >>>> Generally this seems okay to me. >>>> >>>> One query though ... in createAttachFile don't you need to alter the >>>> tmpdir using part in a similar manner to how findSocketFile was >>>> modified? >>> The fix in findSocketFile is not just to make sure the client uses >>> the correct pid in the .java_pid file files, but also (as you point >>> out) to make sure that the client properly references the target >>> jvm's tmp directory when accessing the .java_pid file. findSocketFile >>> is a little >> >> I presume you mean createAttachFile there. > Yes. >> >>> different. You still have to map to the proper from pid to ns_pid >>> when referencing the .attach_pid file, but you don't have the /tmp >>> mount point differences to deal with. /proc//cwd should work >>> even if the pid is for a docker. You don't even have to map to the >>> pid as the docker sees it. /proc//cwd from the client's POV >>> should be the same as /proc//cwd from the target JVM's POV. >> >> Sorry but I don't follow. If findSocketFile has to look in >> /proc//root/ for the socket file, why does the >> createAttachFile not also have to write the attach file into >> /proc//root/ ?? In both cases it needs to find the tmpdir >> of the target process. > Fortunately I have some old printlns that might help: > > ***getNamespacePid - ns_pid: 125 > ***findSocketFile - f: /proc/24445/root/tmp/.java_pid125 > ***createAttachFile - path: /proc/24445/cwd/.attach_pid125 > > So this is a case where the real pid is 24445, but the namespace pid in > the docker is 125. The docker can (and does) reference > /tmp/.java_pid125, but the client needs to reference > /proc/24445/root/tmp/.java_pid125 to get to the same file. For > .attach_pid125, the client can get to it through > /proc/24445/cwd/.attach_pid125, and the docker process will look in cwd > for the file. This is done in AttachListener::is_init_trigger(). That's fine it isn't the cwd code path at issue. > BTW, comments like the following are no longer correct due to JDK-7132199: > > ??? // "/tmp" is used as a global well-known location for the files > ??? // .java_pid. and .attach_pid. It is important that this > ??? // location is the same for all processes, otherwise the tools > ??? // will not be able to find all Hotspot processes. > ??? // Any changes to this needs to be synchronized with HotSpot. > ??? private static final String tmpdir = "/tmp"; > > So now .attach_pid is always created in cwd as you can see in > createAttachFile(), although AttachListener::is_init_trigger() does > check tmp, but only after cwd. 294 } catch (IOException x) { 295 f = new File(tmpdir, fn); 296 f.createNewFile(); 297 } This is the backup in case cwd fails for some reason. I have no idea why it might fail but either: a) it can fail in which case I still think the tmpfile case needs to be updated; or b) it can't fail, in which case the code above should be removed along with any other code that checks in tmpdir. Thanks, David > thanks, > > Chris >> >> Thanks, >> David >> >>>> >>>> Minor note - you can collapse your catch blocks into 1 using >>>> something like >>>> >>>> ??????? } catch (NumberFormatException | IOException x) { >>>> ???????????? throw new AttachNotSupportedException("Unable to parse >>>> namespace"); >>>> ??????? } >>> I'll make that change. >>> >>> thanks, >>> >>> Chris >>>> >>>> Cheers, >>>> David >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 9/11/17 8:03 PM, Chris Plummer wrote: >>>>>> Ok, I will. Thanks. >>>>>> >>>>>> Chris >>>>>> >>>>>> On 9/11/17 6:13 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Chris, >>>>>>> >>>>>>> This looks good to me. >>>>>>> >>>>>>> I'm not sure if all the nsk.aod and the AttachOnDemand tests from >>>>>>> the nsk.jvmti are run in the hotspot tier1, 2, and 3 tests. >>>>>>> It makes sense to double-check it. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 9/10/17 20:34, Chris Plummer wrote: >>>>>>>> [re-sending - sent to wrong alias first time] >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review the following: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8179498 >>>>>>>> http://cr.openjdk.java.net/~cjplummer/8179498/webrev.00/webrev_jdk/ >>>>>>>> >>>>>>>> The CR has the relevant details. Some previous discussions can >>>>>>>> be found here: >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/021237.html >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-May/021249.html >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021679.html >>>>>>>> >>>>>>>> >>>>>>>> Testing with docker has been limited to just making sure jcmd >>>>>>>> now works with the docker setup I was provided. I currently >>>>>>>> don't see how we can run our existing tests in a way that would >>>>>>>> test the docker support without doing some rewriting of the tests. >>>>>>>> >>>>>>>> I also ran all our hotspot tier1, 2, and 3 tests, along with >>>>>>>> jdk/test/tools and jdk/test/sun/tools tests to make sure >>>>>>>> existing functionality is not broken with these changes. >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>>> >>>>>> >>>>> >>> >>> > > From ecki at zusammenkunft.net Thu Sep 14 06:01:43 2017 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 14 Sep 2017 06:01:43 +0000 Subject: RFR(10)(M): 8179498: attach in linux should be relative to /proc/pid/root and namespace aware In-Reply-To: <98f4eac4-2e45-21be-3f6f-df443894eeae@oracle.com> References: <6434ed9c-7ea0-fe2d-d185-eca74c06ea0b@oracle.com> <27b7a7af-e95b-4b36-5808-be8607f1b30b@oracle.com> <4436414c-6bbf-d173-3e23-e1fb7deec3f1@oracle.com> <7574486e-124d-ffe1-df36-1c7911844cde@oracle.com> <08bf2b33-53bf-c168-01b5-dc3d71b2f7b1@oracle.com> <630e7085-46d7-eaa2-72f7-268ddce1bda7@oracle.com>, <98f4eac4-2e45-21be-3f6f-df443894eeae@oracle.com> Message-ID: I think the /tmp fallback is there because cwd might not be writeable by the application user. (In fact I am not sure why it does not insist on /tmp in the first place as that one needs to be writeable for the attach to work anyway. It is certainly less surprising to create a file there instead of a random cwd of another process. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: David Holmes Sent: Thursday, September 14, 2017 7:36:41 AM To: Chris Plummer; serguei.spitsyn at oracle.com; serviceability-dev; TJ.Fontaine at oracle.com; Bernd Eckenfels Subject: Re: RFR(10)(M): 8179498: attach in linux should be relative to /proc/pid/root and namespace aware On 14/09/2017 2:15 PM, Chris Plummer wrote: > On 9/13/17 9:00 PM, David Holmes wrote: >> Hi Chris, >> >> On 14/09/2017 1:03 PM, Chris Plummer wrote: >>> Hi David, >>> >>> On 9/13/17 5:12 PM, David Holmes wrote: >>>> Hi Chris, >>>> >>>> On 14/09/2017 8:23 AM, Chris Plummer wrote: >>>>> I could use one more reviewer. >>>> >>>> Generally this seems okay to me. >>>> >>>> One query though ... in createAttachFile don't you need to alter the >>>> tmpdir using part in a similar manner to how findSocketFile was >>>> modified? >>> The fix in findSocketFile is not just to make sure the client uses >>> the correct pid in the .java_pid file files, but also (as you point >>> out) to make sure that the client properly references the target >>> jvm's tmp directory when accessing the .java_pid file. findSocketFile >>> is a little >> >> I presume you mean createAttachFile there. > Yes. >> >>> different. You still have to map to the proper from pid to ns_pid >>> when referencing the .attach_pid file, but you don't have the /tmp >>> mount point differences to deal with. /proc//cwd should work >>> even if the pid is for a docker. You don't even have to map to the >>> pid as the docker sees it. /proc//cwd from the client's POV >>> should be the same as /proc//cwd from the target JVM's POV. >> >> Sorry but I don't follow. If findSocketFile has to look in >> /proc//root/ for the socket file, why does the >> createAttachFile not also have to write the attach file into >> /proc//root/ ?? In both cases it needs to find the tmpdir >> of the target process. > Fortunately I have some old printlns that might help: > > ***getNamespacePid - ns_pid: 125 > ***findSocketFile - f: /proc/24445/root/tmp/.java_pid125 > ***createAttachFile - path: /proc/24445/cwd/.attach_pid125 > > So this is a case where the real pid is 24445, but the namespace pid in > the docker is 125. The docker can (and does) reference > /tmp/.java_pid125, but the client needs to reference > /proc/24445/root/tmp/.java_pid125 to get to the same file. For > .attach_pid125, the client can get to it through > /proc/24445/cwd/.attach_pid125, and the docker process will look in cwd > for the file. This is done in AttachListener::is_init_trigger(). That's fine it isn't the cwd code path at issue. > BTW, comments like the following are no longer correct due to JDK-7132199: > > // "/tmp" is used as a global well-known location for the files > // .java_pid. and .attach_pid. It is important that this > // location is the same for all processes, otherwise the tools > // will not be able to find all Hotspot processes. > // Any changes to this needs to be synchronized with HotSpot. > private static final String tmpdir = "/tmp"; > > So now .attach_pid is always created in cwd as you can see in > createAttachFile(), although AttachListener::is_init_trigger() does > check tmp, but only after cwd. 294 } catch (IOException x) { 295 f = new File(tmpdir, fn); 296 f.createNewFile(); 297 } This is the backup in case cwd fails for some reason. I have no idea why it might fail but either: a) it can fail in which case I still think the tmpfile case needs to be updated; or b) it can't fail, in which case the code above should be removed along with any other code that checks in tmpdir. Thanks, David > thanks, > > Chris >> >> Thanks, >> David >> >>>> >>>> Minor note - you can collapse your catch blocks into 1 using >>>> something like >>>> >>>> ??????? } catch (NumberFormatException | IOException x) { >>>> ???????????? throw new AttachNotSupportedException("Unable to parse >>>> namespace"); >>>> ??????? } >>> I'll make that change. >>> >>> thanks, >>> >>> Chris >>>> >>>> Cheers, >>>> David >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 9/11/17 8:03 PM, Chris Plummer wrote: >>>>>> Ok, I will. Thanks. >>>>>> >>>>>> Chris >>>>>> >>>>>> On 9/11/17 6:13 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Chris, >>>>>>> >>>>>>> This looks good to me. >>>>>>> >>>>>>> I'm not sure if all the nsk.aod and the AttachOnDemand tests from >>>>>>> the nsk.jvmti are run in the hotspot tier1, 2, and 3 tests. >>>>>>> It makes sense to double-check it. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 9/10/17 20:34, Chris Plummer wrote: >>>>>>>> [re-sending - sent to wrong alias first time] >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review the following: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8179498 >>>>>>>> http://cr.openjdk.java.net/~cjplummer/8179498/webrev.00/webrev_jdk/ >>>>>>>> >>>>>>>> The CR has the relevant details. Some previous discussions can >>>>>>>> be found here: >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/021237.html >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-May/021249.html >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021679.html >>>>>>>> >>>>>>>> >>>>>>>> Testing with docker has been limited to just making sure jcmd >>>>>>>> now works with the docker setup I was provided. I currently >>>>>>>> don't see how we can run our existing tests in a way that would >>>>>>>> test the docker support without doing some rewriting of the tests. >>>>>>>> >>>>>>>> I also ran all our hotspot tier1, 2, and 3 tests, along with >>>>>>>> jdk/test/tools and jdk/test/sun/tools tests to make sure >>>>>>>> existing functionality is not broken with these changes. >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>>> >>>>>> >>>>> >>> >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dms at samersoff.net Thu Sep 14 07:53:29 2017 From: dms at samersoff.net (Dmitry Samersoff) Date: Thu, 14 Sep 2017 10:53:29 +0300 Subject: RFR(10)(M): 8179498: attach in linux should be relative to /proc/pid/root and namespace aware In-Reply-To: <630e7085-46d7-eaa2-72f7-268ddce1bda7@oracle.com> References: <6434ed9c-7ea0-fe2d-d185-eca74c06ea0b@oracle.com> <27b7a7af-e95b-4b36-5808-be8607f1b30b@oracle.com> <4436414c-6bbf-d173-3e23-e1fb7deec3f1@oracle.com> <7574486e-124d-ffe1-df36-1c7911844cde@oracle.com> <08bf2b33-53bf-c168-01b5-dc3d71b2f7b1@oracle.com> <630e7085-46d7-eaa2-72f7-268ddce1bda7@oracle.com> Message-ID: <14c9e33c-abf8-82f2-ef5d-89c306fa3cc0@samersoff.net> Chris, > So now .attach_pid is always created in cwd as you can see in > createAttachFile(), although AttachListener::is_init_trigger() does > check tmp, but only after cwd. > ***getNamespacePid - ns_pid: 125 > ***findSocketFile - f: /proc/24445/root/tmp/.java_pid125 > ***createAttachFile - path: /proc/24445/cwd/.attach_pid125 Could we always use tmp ? IMHO cwd is not a right choice for such kind of files, it should be either $HOME or tmp. -Dmitry On 14.09.2017 07:15, Chris Plummer wrote: > On 9/13/17 9:00 PM, David Holmes wrote: >> Hi Chris, >> >> On 14/09/2017 1:03 PM, Chris Plummer wrote: >>> Hi David, >>> >>> On 9/13/17 5:12 PM, David Holmes wrote: >>>> Hi Chris, >>>> >>>> On 14/09/2017 8:23 AM, Chris Plummer wrote: >>>>> I could use one more reviewer. >>>> >>>> Generally this seems okay to me. >>>> >>>> One query though ... in createAttachFile don't you need to alter the >>>> tmpdir using part in a similar manner to how findSocketFile was >>>> modified? >>> The fix in findSocketFile is not just to make sure the client uses >>> the correct pid in the .java_pid file files, but also (as you point >>> out) to make sure that the client properly references the target >>> jvm's tmp directory when accessing the .java_pid file. findSocketFile >>> is a little >> >> I presume you mean createAttachFile there. > Yes. >> >>> different. You still have to map to the proper from pid to ns_pid >>> when referencing the .attach_pid file, but you don't have the /tmp >>> mount point differences to deal with. /proc//cwd should work >>> even if the pid is for a docker. You don't even have to map to the >>> pid as the docker sees it. /proc//cwd from the client's POV >>> should be the same as /proc//cwd from the target JVM's POV. >> >> Sorry but I don't follow. If findSocketFile has to look in >> /proc//root/ for the socket file, why does the >> createAttachFile not also have to write the attach file into >> /proc//root/ ?? In both cases it needs to find the tmpdir >> of the target process. > Fortunately I have some old printlns that might help: > > ***getNamespacePid - ns_pid: 125 > ***findSocketFile - f: /proc/24445/root/tmp/.java_pid125 > ***createAttachFile - path: /proc/24445/cwd/.attach_pid125 > > So this is a case where the real pid is 24445, but the namespace pid in > the docker is 125. The docker can (and does) reference > /tmp/.java_pid125, but the client needs to reference > /proc/24445/root/tmp/.java_pid125 to get to the same file. For > .attach_pid125, the client can get to it through > /proc/24445/cwd/.attach_pid125, and the docker process will look in cwd > for the file. This is done in AttachListener::is_init_trigger(). > > BTW, comments like the following are no longer correct due to JDK-7132199: > > // "/tmp" is used as a global well-known location for the files > // .java_pid. and .attach_pid. It is important that this > // location is the same for all processes, otherwise the tools > // will not be able to find all Hotspot processes. > // Any changes to this needs to be synchronized with HotSpot. > private static final String tmpdir = "/tmp"; > > So now .attach_pid is always created in cwd as you can see in > createAttachFile(), although AttachListener::is_init_trigger() does > check tmp, but only after cwd. > > thanks, > > Chris >> >> Thanks, >> David >> >>>> >>>> Minor note - you can collapse your catch blocks into 1 using >>>> something like >>>> >>>> ??????? } catch (NumberFormatException | IOException x) { >>>> ???????????? throw new AttachNotSupportedException("Unable to parse >>>> namespace"); >>>> ??????? } >>> I'll make that change. >>> >>> thanks, >>> >>> Chris >>>> >>>> Cheers, >>>> David >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 9/11/17 8:03 PM, Chris Plummer wrote: >>>>>> Ok, I will. Thanks. >>>>>> >>>>>> Chris >>>>>> >>>>>> On 9/11/17 6:13 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Chris, >>>>>>> >>>>>>> This looks good to me. >>>>>>> >>>>>>> I'm not sure if all the nsk.aod and the AttachOnDemand tests from >>>>>>> the nsk.jvmti are run in the hotspot tier1, 2, and 3 tests. >>>>>>> It makes sense to double-check it. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 9/10/17 20:34, Chris Plummer wrote: >>>>>>>> [re-sending - sent to wrong alias first time] >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review the following: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8179498 >>>>>>>> http://cr.openjdk.java.net/~cjplummer/8179498/webrev.00/webrev_jdk/ >>>>>>>> >>>>>>>> The CR has the relevant details. Some previous discussions can >>>>>>>> be found here: >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/021237.html >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-May/021249.html >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021679.html >>>>>>>> >>>>>>>> >>>>>>>> Testing with docker has been limited to just making sure jcmd >>>>>>>> now works with the docker setup I was provided. I currently >>>>>>>> don't see how we can run our existing tests in a way that would >>>>>>>> test the docker support without doing some rewriting of the tests. >>>>>>>> >>>>>>>> I also ran all our hotspot tier1, 2, and 3 tests, along with >>>>>>>> jdk/test/tools and jdk/test/sun/tools tests to make sure >>>>>>>> existing functionality is not broken with these changes. >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>>> >>>>>> >>>>> >>> >>> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From david.holmes at oracle.com Thu Sep 14 08:45:47 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Sep 2017 18:45:47 +1000 Subject: RFR(10)(M): 8179498: attach in linux should be relative to /proc/pid/root and namespace aware In-Reply-To: <14c9e33c-abf8-82f2-ef5d-89c306fa3cc0@samersoff.net> References: <6434ed9c-7ea0-fe2d-d185-eca74c06ea0b@oracle.com> <27b7a7af-e95b-4b36-5808-be8607f1b30b@oracle.com> <4436414c-6bbf-d173-3e23-e1fb7deec3f1@oracle.com> <7574486e-124d-ffe1-df36-1c7911844cde@oracle.com> <08bf2b33-53bf-c168-01b5-dc3d71b2f7b1@oracle.com> <630e7085-46d7-eaa2-72f7-268ddce1bda7@oracle.com> <14c9e33c-abf8-82f2-ef5d-89c306fa3cc0@samersoff.net> Message-ID: <2e7a873e-a2c3-a8e5-2c02-8acc7d7e03bb@oracle.com> On 14/09/2017 5:53 PM, Dmitry Samersoff wrote: > Chris, > >> So now .attach_pid is always created in cwd as you can see in >> createAttachFile(), although AttachListener::is_init_trigger() does >> check tmp, but only after cwd. > >> ***getNamespacePid - ns_pid: 125 >> ***findSocketFile - f: /proc/24445/root/tmp/.java_pid125 >> ***createAttachFile - path: /proc/24445/cwd/.attach_pid125 > > Could we always use tmp ? > > IMHO cwd is not a right choice for such kind of files, it should be > either $HOME or tmp. And we hardwired /tmp and stopped using cwd under https://bugs.openjdk.java.net/browse/JDK-7132199 So I'm a bit confused as to how this has evolved back into using cwd. ?? David > -Dmitry > > On 14.09.2017 07:15, Chris Plummer wrote: >> On 9/13/17 9:00 PM, David Holmes wrote: >>> Hi Chris, >>> >>> On 14/09/2017 1:03 PM, Chris Plummer wrote: >>>> Hi David, >>>> >>>> On 9/13/17 5:12 PM, David Holmes wrote: >>>>> Hi Chris, >>>>> >>>>> On 14/09/2017 8:23 AM, Chris Plummer wrote: >>>>>> I could use one more reviewer. >>>>> >>>>> Generally this seems okay to me. >>>>> >>>>> One query though ... in createAttachFile don't you need to alter the >>>>> tmpdir using part in a similar manner to how findSocketFile was >>>>> modified? >>>> The fix in findSocketFile is not just to make sure the client uses >>>> the correct pid in the .java_pid file files, but also (as you point >>>> out) to make sure that the client properly references the target >>>> jvm's tmp directory when accessing the .java_pid file. findSocketFile >>>> is a little >>> >>> I presume you mean createAttachFile there. >> Yes. >>> >>>> different. You still have to map to the proper from pid to ns_pid >>>> when referencing the .attach_pid file, but you don't have the /tmp >>>> mount point differences to deal with. /proc//cwd should work >>>> even if the pid is for a docker. You don't even have to map to the >>>> pid as the docker sees it. /proc//cwd from the client's POV >>>> should be the same as /proc//cwd from the target JVM's POV. >>> >>> Sorry but I don't follow. If findSocketFile has to look in >>> /proc//root/ for the socket file, why does the >>> createAttachFile not also have to write the attach file into >>> /proc//root/ ?? In both cases it needs to find the tmpdir >>> of the target process. >> Fortunately I have some old printlns that might help: >> >> ***getNamespacePid - ns_pid: 125 >> ***findSocketFile - f: /proc/24445/root/tmp/.java_pid125 >> ***createAttachFile - path: /proc/24445/cwd/.attach_pid125 >> >> So this is a case where the real pid is 24445, but the namespace pid in >> the docker is 125. The docker can (and does) reference >> /tmp/.java_pid125, but the client needs to reference >> /proc/24445/root/tmp/.java_pid125 to get to the same file. For >> .attach_pid125, the client can get to it through >> /proc/24445/cwd/.attach_pid125, and the docker process will look in cwd >> for the file. This is done in AttachListener::is_init_trigger(). >> >> BTW, comments like the following are no longer correct due to JDK-7132199: >> >> // "/tmp" is used as a global well-known location for the files >> // .java_pid. and .attach_pid. It is important that this >> // location is the same for all processes, otherwise the tools >> // will not be able to find all Hotspot processes. >> // Any changes to this needs to be synchronized with HotSpot. >> private static final String tmpdir = "/tmp"; >> >> So now .attach_pid is always created in cwd as you can see in >> createAttachFile(), although AttachListener::is_init_trigger() does >> check tmp, but only after cwd. >> >> thanks, >> >> Chris >>> >>> Thanks, >>> David >>> >>>>> >>>>> Minor note - you can collapse your catch blocks into 1 using >>>>> something like >>>>> >>>>> ??????? } catch (NumberFormatException | IOException x) { >>>>> ???????????? throw new AttachNotSupportedException("Unable to parse >>>>> namespace"); >>>>> ??????? } >>>> I'll make that change. >>>> >>>> thanks, >>>> >>>> Chris >>>>> >>>>> Cheers, >>>>> David >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> On 9/11/17 8:03 PM, Chris Plummer wrote: >>>>>>> Ok, I will. Thanks. >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 9/11/17 6:13 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Chris, >>>>>>>> >>>>>>>> This looks good to me. >>>>>>>> >>>>>>>> I'm not sure if all the nsk.aod and the AttachOnDemand tests from >>>>>>>> the nsk.jvmti are run in the hotspot tier1, 2, and 3 tests. >>>>>>>> It makes sense to double-check it. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 9/10/17 20:34, Chris Plummer wrote: >>>>>>>>> [re-sending - sent to wrong alias first time] >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review the following: >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8179498 >>>>>>>>> http://cr.openjdk.java.net/~cjplummer/8179498/webrev.00/webrev_jdk/ >>>>>>>>> >>>>>>>>> The CR has the relevant details. Some previous discussions can >>>>>>>>> be found here: >>>>>>>>> >>>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/021237.html >>>>>>>>> >>>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-May/021249.html >>>>>>>>> >>>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021679.html >>>>>>>>> >>>>>>>>> >>>>>>>>> Testing with docker has been limited to just making sure jcmd >>>>>>>>> now works with the docker setup I was provided. I currently >>>>>>>>> don't see how we can run our existing tests in a way that would >>>>>>>>> test the docker support without doing some rewriting of the tests. >>>>>>>>> >>>>>>>>> I also ran all our hotspot tier1, 2, and 3 tests, along with >>>>>>>>> jdk/test/tools and jdk/test/sun/tools tests to make sure >>>>>>>>> existing functionality is not broken with these changes. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> >>>>>>>>> Chris >>>>>>>> >>>>>>> >>>>>> >>>> >>>> >> >> > > From chris.plummer at oracle.com Thu Sep 14 16:56:42 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 14 Sep 2017 09:56:42 -0700 Subject: RFR(10)(M): 8179498: attach in linux should be relative to /proc/pid/root and namespace aware In-Reply-To: <2e7a873e-a2c3-a8e5-2c02-8acc7d7e03bb@oracle.com> References: <6434ed9c-7ea0-fe2d-d185-eca74c06ea0b@oracle.com> <27b7a7af-e95b-4b36-5808-be8607f1b30b@oracle.com> <4436414c-6bbf-d173-3e23-e1fb7deec3f1@oracle.com> <7574486e-124d-ffe1-df36-1c7911844cde@oracle.com> <08bf2b33-53bf-c168-01b5-dc3d71b2f7b1@oracle.com> <630e7085-46d7-eaa2-72f7-268ddce1bda7@oracle.com> <14c9e33c-abf8-82f2-ef5d-89c306fa3cc0@samersoff.net> <2e7a873e-a2c3-a8e5-2c02-8acc7d7e03bb@oracle.com> Message-ID: <804bdbc6-cce5-2b1e-9e46-8e5ca9143427@oracle.com> On 9/14/17 1:45 AM, David Holmes wrote: > On 14/09/2017 5:53 PM, Dmitry Samersoff wrote: >> Chris, >> >>> So now .attach_pid is always created in cwd as you can see in >>> createAttachFile(), although AttachListener::is_init_trigger() does >>> check tmp, but only after cwd. >> >>> ***getNamespacePid - ns_pid: 125 >>> ***findSocketFile - f: /proc/24445/root/tmp/.java_pid125 >>> ***createAttachFile - path: /proc/24445/cwd/.attach_pid125 >> >> Could we always use tmp ? >> >> IMHO cwd is not a right choice for such kind of files, it should be >> either $HOME or tmp. > > And we hardwired /tmp and stopped using cwd under > > https://bugs.openjdk.java.net/browse/JDK-7132199 > > So I'm a bit confused as to how this has evolved back into using cwd. ?? Yeah, I had this backwards with my earlier comment. Before JDK-7132199 we actually do it the way we do now, trying cwd first, and then tmp if it fails. JDK-7132199 made it only use tmp, but only for findSocketFile(). createAttachFile() still tries cwd first and then tmp, and I see nothing in the history to indicate this was ever changed, other than to force the location of tmp to /tmp with JDK-6950927. So the question is do we get rid of the cwd support and always use tmp? If yes, I think it's best not to do that as part of this CR. I'd rather just add the docker /tmp support to createAttachFile() now, and have a separate CR deal with removing all cwd support (or maybe even push changes for it before the docker support fix). thanks, Chris > > David > > >> -Dmitry >> >> On 14.09.2017 07:15, Chris Plummer wrote: >>> On 9/13/17 9:00 PM, David Holmes wrote: >>>> Hi Chris, >>>> >>>> On 14/09/2017 1:03 PM, Chris Plummer wrote: >>>>> Hi David, >>>>> >>>>> On 9/13/17 5:12 PM, David Holmes wrote: >>>>>> Hi Chris, >>>>>> >>>>>> On 14/09/2017 8:23 AM, Chris Plummer wrote: >>>>>>> I could use one more reviewer. >>>>>> >>>>>> Generally this seems okay to me. >>>>>> >>>>>> One query though ... in createAttachFile don't you need to alter the >>>>>> tmpdir using part in a similar manner to how findSocketFile was >>>>>> modified? >>>>> The fix in findSocketFile is not just to make sure the client uses >>>>> the correct pid in the .java_pid file files, but also (as you point >>>>> out) to make sure that the client properly references the target >>>>> jvm's tmp directory when accessing the .java_pid file. findSocketFile >>>>> is a little >>>> >>>> I presume you mean createAttachFile there. >>> Yes. >>>> >>>>> different. You still have to map to the proper from pid to ns_pid >>>>> when referencing the .attach_pid file, but you don't have the /tmp >>>>> mount point differences to deal with. /proc//cwd should work >>>>> even if the pid is for a docker. You don't even have to map to the >>>>> pid as the docker sees it. /proc//cwd from the client's POV >>>>> should be the same as /proc//cwd from the target JVM's POV. >>>> >>>> Sorry but I don't follow. If findSocketFile has to look in >>>> /proc//root/ for the socket file, why does the >>>> createAttachFile not also have to write the attach file into >>>> /proc//root/ ?? In both cases it needs to find the tmpdir >>>> of the target process. >>> Fortunately I have some old printlns that might help: >>> >>> ***getNamespacePid - ns_pid: 125 >>> ***findSocketFile - f: /proc/24445/root/tmp/.java_pid125 >>> ***createAttachFile - path: /proc/24445/cwd/.attach_pid125 >>> >>> So this is a case where the real pid is 24445, but the namespace pid in >>> the docker is 125. The docker can (and does) reference >>> /tmp/.java_pid125, but the client needs to reference >>> /proc/24445/root/tmp/.java_pid125 to get to the same file. For >>> .attach_pid125, the client can get to it through >>> /proc/24445/cwd/.attach_pid125, and the docker process will look in cwd >>> for the file. This is done in AttachListener::is_init_trigger(). >>> >>> BTW, comments like the following are no longer correct due to >>> JDK-7132199: >>> >>> ???? // "/tmp" is used as a global well-known location for the files >>> ???? // .java_pid. and .attach_pid. It is important that this >>> ???? // location is the same for all processes, otherwise the tools >>> ???? // will not be able to find all Hotspot processes. >>> ???? // Any changes to this needs to be synchronized with HotSpot. >>> ???? private static final String tmpdir = "/tmp"; >>> >>> So now .attach_pid is always created in cwd as you can see in >>> createAttachFile(), although AttachListener::is_init_trigger() does >>> check tmp, but only after cwd. >>> >>> thanks, >>> >>> Chris >>>> >>>> Thanks, >>>> David >>>> >>>>>> >>>>>> Minor note - you can collapse your catch blocks into 1 using >>>>>> something like >>>>>> >>>>>> ??????? } catch (NumberFormatException | IOException x) { >>>>>> ???????????? throw new AttachNotSupportedException("Unable to parse >>>>>> namespace"); >>>>>> ??????? } >>>>> I'll make that change. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>>> >>>>>> Cheers, >>>>>> David >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 9/11/17 8:03 PM, Chris Plummer wrote: >>>>>>>> Ok, I will. Thanks. >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 9/11/17 6:13 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi Chris, >>>>>>>>> >>>>>>>>> This looks good to me. >>>>>>>>> >>>>>>>>> I'm not sure if all the nsk.aod and the AttachOnDemand tests from >>>>>>>>> the nsk.jvmti are run in the hotspot tier1, 2, and 3 tests. >>>>>>>>> It makes sense to double-check it. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/10/17 20:34, Chris Plummer wrote: >>>>>>>>>> [re-sending - sent to wrong alias first time] >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review the following: >>>>>>>>>> >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8179498 >>>>>>>>>> http://cr.openjdk.java.net/~cjplummer/8179498/webrev.00/webrev_jdk/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The CR has the relevant details. Some previous discussions can >>>>>>>>>> be found here: >>>>>>>>>> >>>>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/021237.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-May/021249.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021679.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Testing with docker has been limited to just making sure jcmd >>>>>>>>>> now works with the docker setup I was provided. I currently >>>>>>>>>> don't see how we can run our existing tests in a way that would >>>>>>>>>> test the docker support without doing some rewriting of the >>>>>>>>>> tests. >>>>>>>>>> >>>>>>>>>> I also ran all our hotspot tier1, 2, and 3 tests, along with >>>>>>>>>> jdk/test/tools and jdk/test/sun/tools tests to make sure >>>>>>>>>> existing functionality is not broken with these changes. >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>> >>> >> >> From daniel.daugherty at oracle.com Thu Sep 14 21:53:13 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Sep 2017 15:53:13 -0600 Subject: RFR(S) 8177901: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: References: <1405f243-f3f8-613b-2d16-0b9016a782f7@oracle.com> Message-ID: <2e00861b-6057-0746-1684-dea5a108a5ba@oracle.com> On 9/4/17 11:23 PM, serguei.spitsyn at oracle.com wrote: > Hi David, > > > On 9/4/17 21:43, David Holmes wrote: >> Hi Serguei, >> >> This looks good to me. One not below. >> >> On 2/09/2017 6:30 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review a fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8177901 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177901-jdi-wrong_phase.1 >>> >> >> src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c >> >> +???? // Release commandLoop vmDeathLock if necessary >> +???? void commandLoop_exitVmDeathLockOnError(void); >> +???? commandLoop_exitVmDeathLockOnError(); >> >> The declaration should be in the eventHelper.h header file. It looks >> really odd to declare the function then call it. > > Ok, I'll move it to the header. I did look for a newer webrev and didn't find one. General comments: ? - Please update the copyright years as needed before pushing. src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c ??? No comments (other than agreeing with David H). src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c ??? L1289: ??? /* ??? L1290: ???? * The VM will die soon after the completion of this callback - we ??? L1291: ???? * may need to do a final synchronization with the command loop to ??? L1292: ???? * avoid the VM terminating with replying to the final (resume) ??? L1293: ???? * command. ??? L1294: ???? */ ??? L1295: ??? commandLoop_sync(); ??????? Seems like your addition of the call to commandLoop_sync() ??????? might resolve what appears (to me) to be a placeholder ??????? comment for a future change. Perhaps the comment should be ??????? something like this: ??????? /* ???????? * The VM will die soon after the completion of this callback - ???????? * we synchronize with both the command loop and the debug loop ???????? * for a more orderly shutdown. ???????? */ src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c ??? L772: void commandLoop_exitVmDeathLockOnError() { ??????? The '{' should be on a line by itself to keep in the ??????? same existing style. ??? L127: static jrawMonitorID vmDeathLock; ??? L708: ??????????? debugMonitorEnter(vmDeathLock); ??? L714: ??????????? debugMonitorExit(vmDeathLock); ??? L778: ??? err = JVMTI_FUNC_PTR(gdata->jvmti, GetCurrentThread) ??? L779: ????????????? (gdata->jvmti, &cur_thread); ??? L794: ??? debugMonitorExit(vmDeathLock); ??????? L794 assumes that the vmDeathLock is held by the Command ??????? Loop Thread. Perhaps add a new volatile flag after L127 ??????? that is set to true after L708 and set to false before ??????? L714. Check the flag before calling GetCurrentThread() ??????? on L778 and return early if the flag is not true. src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.h ??? L57: void commandLoop_sync(void); /* commandLoop sync with cbVMDeath */ ??????? Extra space before 'cbVMDeath'. Dan > > Thank you a lot for he review! > Serguei > >> >> Thanks, >> David >> ----- >> >>> >>> Summary: >>> >>> ?? The approach to fix this is to introduce a new lock vmDeathLock >>> in eventHelper.c >>> ?? and use it to sync the commandLoop with the JVMTI event callback >>> cbVMDeath >>> ?? the same way as it was done for debugLoop_run. >>> ?? (see the fix of: https://bugs.openjdk.java.net/browse/JDK-8134103) >>> >>> ?? One potential issue with it is that the commandLoop() >>> transitively uses some helper >>> ?? functions (e.g. from util.c) that use the macro EXIT_ERROR, and >>> so, can abort. >>> ?? It seems, in such a case the vmDeathLock will remain locked, and so, >>> ?? the cbVMDeath() will block on it causing a deadlock. >>> ?? Note, that these helper functions can be also called from >>> different contexts/threads >>> ?? (not from the commandLoop thread only). In such contexts the >>> commandLoop vmDeathLock >>> ?? is not being entered, and so, should not be exited. >>> >>> ?? To fix this potential issue, new function, >>> commandLoop_exitVmDeathLockOnError(), >>> ?? is introduced, and it is called from the debugInit_exit(). >>> The commandLoop_exitVmDeathLockOnError() always checks if current >>> thread is >>> ?? the commandLoop thread and only in such a case unlocks the >>> vmDeathLock. >>> >>> Testing: >>> ?? Ran the nsk.jdi, nsk.jdwp and jtreg jdk_jdi for both release and >>> fastdebug builds. >>> ?? All tests are passed. >>> >>> Thanks, >>> Serguei >>> > From daniel.daugherty at oracle.com Thu Sep 14 22:48:26 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Sep 2017 16:48:26 -0600 Subject: RFR: SA: MacOS X: 8184042: several serviceability/sa tests timed out on MacOS X In-Reply-To: References: Message-ID: <69512c98-57d1-01c0-d8d1-674024776a11@oracle.com> On 8/18/17 4:00 AM, Jini George wrote: > Hi all, > > Requesting reviews for: https://bugs.openjdk.java.net/browse/JDK-8184042 > > Webrev: http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/ hotspot/src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m ??? L832: ? result = mach_port_insert_right (mach_task_self(), ??????? Nit - extra blank before '(' ??? L860-863 - nit - indents don't match the other func calls. ??? I read through all the changes and looked at logic flow, error ??? returns, variable usage, etc. The problem is I'm not conversant ??? in Mach exception programming so there could easily be things ??? that I missed here. ??? You really need to have a MacOS X person look at these changes ??? also. hotspot/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ??? No comments. hotspot/src/jdk.hotspot.agent/macosx/native/libsaproc/mach_exc.h hotspot/src/jdk.hotspot.agent/macosx/native/libsaproc/mach_excServer.c hotspot/src/jdk.hotspot.agent/macosx/native/libsaproc/mach_excUser.c ??? These files are generated by a tool and will be replaced ??? by build changes. I didn't review them. hotspot/test/serviceability/sa/TestAttachDetach.java ??? L35: import java.util.ArrayList; ??? L36: import java.util.List; ??? L37: import java.util.Arrays; ??? L38: import java.util.Optional; ??? L40: import jdk.test.lib.Utils; ??? L41: import jdk.test.lib.process.OutputAnalyzer; ??? L42: import jdk.test.lib.process.ProcessTools; ??????? These imports do not seem to be needed. ??? L45: import jdk.test.lib.JDKToolLauncher; ??????? Duplicate import. ??? L98: ??????????????????????????? "The String 'Attaching to process' appears " + ??? L99: ???????????????????????????? numberOfMatches + " number of times"); ??????? Would be helpful to include the expected value also. jdk/test/ProblemList.txt ??? Thanks for remembering to update the ProblemList.txt file! I don't have any comments other than nits. However, I don't know mach exceptions so I can't really do a functional review. We need someone that knows MacOS X mach exceptions to chime in on this thread. I'm adding Gerard Z to this review thread in the hopes that he can help... Dan > > Problem gist: The deprecated ptrace() command, PT_ATTACH was changed > to PT_ATTACHEXC, which causes mach exceptions (and not UNIX signals) > to be delivered via mach messages.This caused SA to hang at waitpid() > waiting for a signal, which does not arrive. > > Solution in a nutshell: The solution is to make the required changes > to handle mach 'soft signal' exceptions in the form of mach messages > instead of signals, while attaching to and detaching from the target > process. The detailed steps are outlined in JBS. > > The changes appear huge due to the inclusion of pre-generated mach > exception handling files (mach_exc*). Since this is an integration > blocker, it would be great to get quick reviews on this. > > Thank you, > Jini. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Sep 14 23:26:44 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 14 Sep 2017 16:26:44 -0700 Subject: RFR(S) 8177901: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: <2e00861b-6057-0746-1684-dea5a108a5ba@oracle.com> References: <1405f243-f3f8-613b-2d16-0b9016a782f7@oracle.com> <2e00861b-6057-0746-1684-dea5a108a5ba@oracle.com> Message-ID: Hi Dan, Thank you a lot for reviewing! All your suggestions are accepted. The updated webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177901-jdi-wrong_phase.2/ Just a sanity check is needed. Thanks, Serguei On 9/14/17 14:53, Daniel D. Daugherty wrote: > On 9/4/17 11:23 PM, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> >> On 9/4/17 21:43, David Holmes wrote: >>> Hi Serguei, >>> >>> This looks good to me. One not below. >>> >>> On 2/09/2017 6:30 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review a fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8177901 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177901-jdi-wrong_phase.1 >>>> >>> >>> src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c >>> >>> +???? // Release commandLoop vmDeathLock if necessary >>> +???? void commandLoop_exitVmDeathLockOnError(void); >>> +???? commandLoop_exitVmDeathLockOnError(); >>> >>> The declaration should be in the eventHelper.h header file. It looks >>> really odd to declare the function then call it. >> >> Ok, I'll move it to the header. > > I did look for a newer webrev and didn't find one. > > > General comments: > ? - Please update the copyright years as needed before pushing. > > src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c > ??? No comments (other than agreeing with David H). > > src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c > ??? L1289: ??? /* > ??? L1290: ???? * The VM will die soon after the completion of this > callback - we > ??? L1291: ???? * may need to do a final synchronization with the > command loop to > ??? L1292: ???? * avoid the VM terminating with replying to the final > (resume) > ??? L1293: ???? * command. > ??? L1294: ???? */ > ??? L1295: ??? commandLoop_sync(); > > ??????? Seems like your addition of the call to commandLoop_sync() > ??????? might resolve what appears (to me) to be a placeholder > ??????? comment for a future change. Perhaps the comment should be > ??????? something like this: > > ??????? /* > ???????? * The VM will die soon after the completion of this callback - > ???????? * we synchronize with both the command loop and the debug loop > ???????? * for a more orderly shutdown. > ???????? */ > > src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c > ??? L772: void commandLoop_exitVmDeathLockOnError() { > ??????? The '{' should be on a line by itself to keep in the > ??????? same existing style. > > ??? L127: static jrawMonitorID vmDeathLock; > ??? L708: ??????????? debugMonitorEnter(vmDeathLock); > ??? L714: ??????????? debugMonitorExit(vmDeathLock); > ??? L778: ??? err = JVMTI_FUNC_PTR(gdata->jvmti, GetCurrentThread) > ??? L779: ????????????? (gdata->jvmti, &cur_thread); > ??? L794: ??? debugMonitorExit(vmDeathLock); > ??????? L794 assumes that the vmDeathLock is held by the Command > ??????? Loop Thread. Perhaps add a new volatile flag after L127 > ??????? that is set to true after L708 and set to false before > ??????? L714. Check the flag before calling GetCurrentThread() > ??????? on L778 and return early if the flag is not true. > > src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.h > ??? L57: void commandLoop_sync(void); /* commandLoop sync with > cbVMDeath */ > ??????? Extra space before 'cbVMDeath'. > > Dan > > >> >> Thank you a lot for he review! >> Serguei >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> >>>> Summary: >>>> >>>> ?? The approach to fix this is to introduce a new lock vmDeathLock >>>> in eventHelper.c >>>> ?? and use it to sync the commandLoop with the JVMTI event callback >>>> cbVMDeath >>>> ?? the same way as it was done for debugLoop_run. >>>> ?? (see the fix of: https://bugs.openjdk.java.net/browse/JDK-8134103) >>>> >>>> ?? One potential issue with it is that the commandLoop() >>>> transitively uses some helper >>>> ?? functions (e.g. from util.c) that use the macro EXIT_ERROR, and >>>> so, can abort. >>>> ?? It seems, in such a case the vmDeathLock will remain locked, and >>>> so, >>>> ?? the cbVMDeath() will block on it causing a deadlock. >>>> ?? Note, that these helper functions can be also called from >>>> different contexts/threads >>>> ?? (not from the commandLoop thread only). In such contexts the >>>> commandLoop vmDeathLock >>>> ?? is not being entered, and so, should not be exited. >>>> >>>> ?? To fix this potential issue, new function, >>>> commandLoop_exitVmDeathLockOnError(), >>>> ?? is introduced, and it is called from the debugInit_exit(). >>>> The commandLoop_exitVmDeathLockOnError() always checks if current >>>> thread is >>>> ?? the commandLoop thread and only in such a case unlocks the >>>> vmDeathLock. >>>> >>>> Testing: >>>> ?? Ran the nsk.jdi, nsk.jdwp and jtreg jdk_jdi for both release and >>>> fastdebug builds. >>>> ?? All tests are passed. >>>> >>>> Thanks, >>>> Serguei >>>> >> > From daniel.daugherty at oracle.com Thu Sep 14 23:40:04 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Sep 2017 17:40:04 -0600 Subject: RFR(S) 8177901: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: References: <1405f243-f3f8-613b-2d16-0b9016a782f7@oracle.com> <2e00861b-6057-0746-1684-dea5a108a5ba@oracle.com> Message-ID: <29fe62ec-47db-2e45-a390-d4f50a7876c2@oracle.com> On 9/14/17 5:26 PM, serguei.spitsyn at oracle.com wrote: > Hi Dan, > > Thank you a lot for reviewing! > All your suggestions are accepted. > > The updated webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177901-jdi-wrong_phase.2/ > Re-reviewed all the files. Thumbs up! Dan > > > Just a sanity check is needed. > > Thanks, > Serguei > > > > On 9/14/17 14:53, Daniel D. Daugherty wrote: >> On 9/4/17 11:23 PM, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> >>> On 9/4/17 21:43, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> This looks good to me. One not below. >>>> >>>> On 2/09/2017 6:30 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review a fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8177901 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177901-jdi-wrong_phase.1 >>>>> >>>> >>>> src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c >>>> >>>> +???? // Release commandLoop vmDeathLock if necessary >>>> +???? void commandLoop_exitVmDeathLockOnError(void); >>>> +???? commandLoop_exitVmDeathLockOnError(); >>>> >>>> The declaration should be in the eventHelper.h header file. It >>>> looks really odd to declare the function then call it. >>> >>> Ok, I'll move it to the header. >> >> I did look for a newer webrev and didn't find one. >> >> >> General comments: >> ? - Please update the copyright years as needed before pushing. >> >> src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c >> ??? No comments (other than agreeing with David H). >> >> src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c >> ??? L1289: ??? /* >> ??? L1290: ???? * The VM will die soon after the completion of this >> callback - we >> ??? L1291: ???? * may need to do a final synchronization with the >> command loop to >> ??? L1292: ???? * avoid the VM terminating with replying to the final >> (resume) >> ??? L1293: ???? * command. >> ??? L1294: ???? */ >> ??? L1295: ??? commandLoop_sync(); >> >> ??????? Seems like your addition of the call to commandLoop_sync() >> ??????? might resolve what appears (to me) to be a placeholder >> ??????? comment for a future change. Perhaps the comment should be >> ??????? something like this: >> >> ??????? /* >> ???????? * The VM will die soon after the completion of this callback - >> ???????? * we synchronize with both the command loop and the debug loop >> ???????? * for a more orderly shutdown. >> ???????? */ >> >> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >> ??? L772: void commandLoop_exitVmDeathLockOnError() { >> ??????? The '{' should be on a line by itself to keep in the >> ??????? same existing style. >> >> ??? L127: static jrawMonitorID vmDeathLock; >> ??? L708: ??????????? debugMonitorEnter(vmDeathLock); >> ??? L714: ??????????? debugMonitorExit(vmDeathLock); >> ??? L778: ??? err = JVMTI_FUNC_PTR(gdata->jvmti, GetCurrentThread) >> ??? L779: ????????????? (gdata->jvmti, &cur_thread); >> ??? L794: ??? debugMonitorExit(vmDeathLock); >> ??????? L794 assumes that the vmDeathLock is held by the Command >> ??????? Loop Thread. Perhaps add a new volatile flag after L127 >> ??????? that is set to true after L708 and set to false before >> ??????? L714. Check the flag before calling GetCurrentThread() >> ??????? on L778 and return early if the flag is not true. >> >> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.h >> ??? L57: void commandLoop_sync(void); /* commandLoop sync with >> cbVMDeath */ >> ??????? Extra space before 'cbVMDeath'. >> >> Dan >> >> >>> >>> Thank you a lot for he review! >>> Serguei >>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>> Summary: >>>>> >>>>> ?? The approach to fix this is to introduce a new lock vmDeathLock >>>>> in eventHelper.c >>>>> ?? and use it to sync the commandLoop with the JVMTI event >>>>> callback cbVMDeath >>>>> ?? the same way as it was done for debugLoop_run. >>>>> ?? (see the fix of: https://bugs.openjdk.java.net/browse/JDK-8134103) >>>>> >>>>> ?? One potential issue with it is that the commandLoop() >>>>> transitively uses some helper >>>>> ?? functions (e.g. from util.c) that use the macro EXIT_ERROR, and >>>>> so, can abort. >>>>> ?? It seems, in such a case the vmDeathLock will remain locked, >>>>> and so, >>>>> ?? the cbVMDeath() will block on it causing a deadlock. >>>>> ?? Note, that these helper functions can be also called from >>>>> different contexts/threads >>>>> ?? (not from the commandLoop thread only). In such contexts the >>>>> commandLoop vmDeathLock >>>>> ?? is not being entered, and so, should not be exited. >>>>> >>>>> ?? To fix this potential issue, new function, >>>>> commandLoop_exitVmDeathLockOnError(), >>>>> ?? is introduced, and it is called from the debugInit_exit(). >>>>> The commandLoop_exitVmDeathLockOnError() always checks if current >>>>> thread is >>>>> ?? the commandLoop thread and only in such a case unlocks the >>>>> vmDeathLock. >>>>> >>>>> Testing: >>>>> ?? Ran the nsk.jdi, nsk.jdwp and jtreg jdk_jdi for both release >>>>> and fastdebug builds. >>>>> ?? All tests are passed. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>> >> > From serguei.spitsyn at oracle.com Thu Sep 14 23:41:28 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 14 Sep 2017 16:41:28 -0700 Subject: RFR(S) 8177901: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: <29fe62ec-47db-2e45-a390-d4f50a7876c2@oracle.com> References: <1405f243-f3f8-613b-2d16-0b9016a782f7@oracle.com> <2e00861b-6057-0746-1684-dea5a108a5ba@oracle.com> <29fe62ec-47db-2e45-a390-d4f50a7876c2@oracle.com> Message-ID: <04027ef1-bd97-3506-aa17-7e04ecfeeeea@oracle.com> On 9/14/17 16:40, Daniel D. Daugherty wrote: > On 9/14/17 5:26 PM, serguei.spitsyn at oracle.com wrote: >> Hi Dan, >> >> Thank you a lot for reviewing! >> All your suggestions are accepted. >> >> The updated webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177901-jdi-wrong_phase.2/ >> > > Re-reviewed all the files. Thumbs up! Thanks, Dan! Serguei > > Dan > > >> >> >> Just a sanity check is needed. >> >> Thanks, >> Serguei >> >> >> >> On 9/14/17 14:53, Daniel D. Daugherty wrote: >>> On 9/4/17 11:23 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi David, >>>> >>>> >>>> On 9/4/17 21:43, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> This looks good to me. One not below. >>>>> >>>>> On 2/09/2017 6:30 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review a fix for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8177901 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177901-jdi-wrong_phase.1 >>>>>> >>>>> >>>>> src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c >>>>> >>>>> +???? // Release commandLoop vmDeathLock if necessary >>>>> +???? void commandLoop_exitVmDeathLockOnError(void); >>>>> +???? commandLoop_exitVmDeathLockOnError(); >>>>> >>>>> The declaration should be in the eventHelper.h header file. It >>>>> looks really odd to declare the function then call it. >>>> >>>> Ok, I'll move it to the header. >>> >>> I did look for a newer webrev and didn't find one. >>> >>> >>> General comments: >>> ? - Please update the copyright years as needed before pushing. >>> >>> src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c >>> ??? No comments (other than agreeing with David H). >>> >>> src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c >>> ??? L1289: ??? /* >>> ??? L1290: ???? * The VM will die soon after the completion of this >>> callback - we >>> ??? L1291: ???? * may need to do a final synchronization with the >>> command loop to >>> ??? L1292: ???? * avoid the VM terminating with replying to the >>> final (resume) >>> ??? L1293: ???? * command. >>> ??? L1294: ???? */ >>> ??? L1295: ??? commandLoop_sync(); >>> >>> ??????? Seems like your addition of the call to commandLoop_sync() >>> ??????? might resolve what appears (to me) to be a placeholder >>> ??????? comment for a future change. Perhaps the comment should be >>> ??????? something like this: >>> >>> ??????? /* >>> ???????? * The VM will die soon after the completion of this callback - >>> ???????? * we synchronize with both the command loop and the debug loop >>> ???????? * for a more orderly shutdown. >>> ???????? */ >>> >>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>> ??? L772: void commandLoop_exitVmDeathLockOnError() { >>> ??????? The '{' should be on a line by itself to keep in the >>> ??????? same existing style. >>> >>> ??? L127: static jrawMonitorID vmDeathLock; >>> ??? L708: ??????????? debugMonitorEnter(vmDeathLock); >>> ??? L714: ??????????? debugMonitorExit(vmDeathLock); >>> ??? L778: ??? err = JVMTI_FUNC_PTR(gdata->jvmti, GetCurrentThread) >>> ??? L779: ????????????? (gdata->jvmti, &cur_thread); >>> ??? L794: ??? debugMonitorExit(vmDeathLock); >>> ??????? L794 assumes that the vmDeathLock is held by the Command >>> ??????? Loop Thread. Perhaps add a new volatile flag after L127 >>> ??????? that is set to true after L708 and set to false before >>> ??????? L714. Check the flag before calling GetCurrentThread() >>> ??????? on L778 and return early if the flag is not true. >>> >>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.h >>> ??? L57: void commandLoop_sync(void); /* commandLoop sync with >>> cbVMDeath */ >>> ??????? Extra space before 'cbVMDeath'. >>> >>> Dan >>> >>> >>>> >>>> Thank you a lot for he review! >>>> Serguei >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> ?? The approach to fix this is to introduce a new lock >>>>>> vmDeathLock in eventHelper.c >>>>>> ?? and use it to sync the commandLoop with the JVMTI event >>>>>> callback cbVMDeath >>>>>> ?? the same way as it was done for debugLoop_run. >>>>>> ?? (see the fix of: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8134103) >>>>>> >>>>>> ?? One potential issue with it is that the commandLoop() >>>>>> transitively uses some helper >>>>>> ?? functions (e.g. from util.c) that use the macro EXIT_ERROR, >>>>>> and so, can abort. >>>>>> ?? It seems, in such a case the vmDeathLock will remain locked, >>>>>> and so, >>>>>> ?? the cbVMDeath() will block on it causing a deadlock. >>>>>> ?? Note, that these helper functions can be also called from >>>>>> different contexts/threads >>>>>> ?? (not from the commandLoop thread only). In such contexts the >>>>>> commandLoop vmDeathLock >>>>>> ?? is not being entered, and so, should not be exited. >>>>>> >>>>>> ?? To fix this potential issue, new function, >>>>>> commandLoop_exitVmDeathLockOnError(), >>>>>> ?? is introduced, and it is called from the debugInit_exit(). >>>>>> The commandLoop_exitVmDeathLockOnError() always checks if current >>>>>> thread is >>>>>> ?? the commandLoop thread and only in such a case unlocks the >>>>>> vmDeathLock. >>>>>> >>>>>> Testing: >>>>>> ?? Ran the nsk.jdi, nsk.jdwp and jtreg jdk_jdi for both release >>>>>> and fastdebug builds. >>>>>> ?? All tests are passed. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>> >>> >> > From david.holmes at oracle.com Fri Sep 15 02:07:07 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Sep 2017 12:07:07 +1000 Subject: RFR(S) 8177901: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: References: <1405f243-f3f8-613b-2d16-0b9016a782f7@oracle.com> <2e00861b-6057-0746-1684-dea5a108a5ba@oracle.com> Message-ID: <5085bbae-ab92-0a6b-5dbf-96baad93d56b@oracle.com> On 15/09/2017 9:26 AM, serguei.spitsyn at oracle.com wrote: > Hi Dan, > > Thank you a lot for reviewing! > All your suggestions are accepted. > > The updated webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177901-jdi-wrong_phase.2/ Not sure the new flag was actually needed if the only way to get to the commandLoop_exitVmDeathLockOnError in the event helper thread is via completeCommand(command) - which is within the locked region. But its harmless. So thumbs up. Cheers, David > > > Just a sanity check is needed. > > Thanks, > Serguei > > > > On 9/14/17 14:53, Daniel D. Daugherty wrote: >> On 9/4/17 11:23 PM, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> >>> On 9/4/17 21:43, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> This looks good to me. One not below. >>>> >>>> On 2/09/2017 6:30 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review a fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8177901 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177901-jdi-wrong_phase.1 >>>>> >>>> >>>> src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c >>>> >>>> +???? // Release commandLoop vmDeathLock if necessary >>>> +???? void commandLoop_exitVmDeathLockOnError(void); >>>> +???? commandLoop_exitVmDeathLockOnError(); >>>> >>>> The declaration should be in the eventHelper.h header file. It looks >>>> really odd to declare the function then call it. >>> >>> Ok, I'll move it to the header. >> >> I did look for a newer webrev and didn't find one. >> >> >> General comments: >> ? - Please update the copyright years as needed before pushing. >> >> src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c >> ??? No comments (other than agreeing with David H). >> >> src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c >> ??? L1289: ??? /* >> ??? L1290: ???? * The VM will die soon after the completion of this >> callback - we >> ??? L1291: ???? * may need to do a final synchronization with the >> command loop to >> ??? L1292: ???? * avoid the VM terminating with replying to the final >> (resume) >> ??? L1293: ???? * command. >> ??? L1294: ???? */ >> ??? L1295: ??? commandLoop_sync(); >> >> ??????? Seems like your addition of the call to commandLoop_sync() >> ??????? might resolve what appears (to me) to be a placeholder >> ??????? comment for a future change. Perhaps the comment should be >> ??????? something like this: >> >> ??????? /* >> ???????? * The VM will die soon after the completion of this callback - >> ???????? * we synchronize with both the command loop and the debug loop >> ???????? * for a more orderly shutdown. >> ???????? */ >> >> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >> ??? L772: void commandLoop_exitVmDeathLockOnError() { >> ??????? The '{' should be on a line by itself to keep in the >> ??????? same existing style. >> >> ??? L127: static jrawMonitorID vmDeathLock; >> ??? L708: ??????????? debugMonitorEnter(vmDeathLock); >> ??? L714: ??????????? debugMonitorExit(vmDeathLock); >> ??? L778: ??? err = JVMTI_FUNC_PTR(gdata->jvmti, GetCurrentThread) >> ??? L779: ????????????? (gdata->jvmti, &cur_thread); >> ??? L794: ??? debugMonitorExit(vmDeathLock); >> ??????? L794 assumes that the vmDeathLock is held by the Command >> ??????? Loop Thread. Perhaps add a new volatile flag after L127 >> ??????? that is set to true after L708 and set to false before >> ??????? L714. Check the flag before calling GetCurrentThread() >> ??????? on L778 and return early if the flag is not true. >> >> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.h >> ??? L57: void commandLoop_sync(void); /* commandLoop sync with >> cbVMDeath */ >> ??????? Extra space before 'cbVMDeath'. >> >> Dan >> >> >>> >>> Thank you a lot for he review! >>> Serguei >>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>> Summary: >>>>> >>>>> ?? The approach to fix this is to introduce a new lock vmDeathLock >>>>> in eventHelper.c >>>>> ?? and use it to sync the commandLoop with the JVMTI event callback >>>>> cbVMDeath >>>>> ?? the same way as it was done for debugLoop_run. >>>>> ?? (see the fix of: https://bugs.openjdk.java.net/browse/JDK-8134103) >>>>> >>>>> ?? One potential issue with it is that the commandLoop() >>>>> transitively uses some helper >>>>> ?? functions (e.g. from util.c) that use the macro EXIT_ERROR, and >>>>> so, can abort. >>>>> ?? It seems, in such a case the vmDeathLock will remain locked, and >>>>> so, >>>>> ?? the cbVMDeath() will block on it causing a deadlock. >>>>> ?? Note, that these helper functions can be also called from >>>>> different contexts/threads >>>>> ?? (not from the commandLoop thread only). In such contexts the >>>>> commandLoop vmDeathLock >>>>> ?? is not being entered, and so, should not be exited. >>>>> >>>>> ?? To fix this potential issue, new function, >>>>> commandLoop_exitVmDeathLockOnError(), >>>>> ?? is introduced, and it is called from the debugInit_exit(). >>>>> The commandLoop_exitVmDeathLockOnError() always checks if current >>>>> thread is >>>>> ?? the commandLoop thread and only in such a case unlocks the >>>>> vmDeathLock. >>>>> >>>>> Testing: >>>>> ?? Ran the nsk.jdi, nsk.jdwp and jtreg jdk_jdi for both release and >>>>> fastdebug builds. >>>>> ?? All tests are passed. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>> >> > From serguei.spitsyn at oracle.com Fri Sep 15 03:12:20 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 14 Sep 2017 20:12:20 -0700 Subject: RFR(S) 8177901: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: <5085bbae-ab92-0a6b-5dbf-96baad93d56b@oracle.com> References: <1405f243-f3f8-613b-2d16-0b9016a782f7@oracle.com> <2e00861b-6057-0746-1684-dea5a108a5ba@oracle.com> <5085bbae-ab92-0a6b-5dbf-96baad93d56b@oracle.com> Message-ID: On 9/14/17 19:07, David Holmes wrote: > On 15/09/2017 9:26 AM, serguei.spitsyn at oracle.com wrote: >> Hi Dan, >> >> Thank you a lot for reviewing! >> All your suggestions are accepted. >> >> The updated webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177901-jdi-wrong_phase.2/ > > > Not sure the new flag was actually needed if the only way to get to > the commandLoop_exitVmDeathLockOnError in the event helper thread is > via completeCommand(command) - which is within the locked region. But > its harmless. Yes, it is harmless. > > So thumbs up. Thank you a lot, David! Serguei > > Cheers, > David > >> >> >> Just a sanity check is needed. >> >> Thanks, >> Serguei >> >> >> >> On 9/14/17 14:53, Daniel D. Daugherty wrote: >>> On 9/4/17 11:23 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi David, >>>> >>>> >>>> On 9/4/17 21:43, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> This looks good to me. One not below. >>>>> >>>>> On 2/09/2017 6:30 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review a fix for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8177901 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177901-jdi-wrong_phase.1 >>>>>> >>>>> >>>>> src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c >>>>> >>>>> +???? // Release commandLoop vmDeathLock if necessary >>>>> +???? void commandLoop_exitVmDeathLockOnError(void); >>>>> +???? commandLoop_exitVmDeathLockOnError(); >>>>> >>>>> The declaration should be in the eventHelper.h header file. It >>>>> looks really odd to declare the function then call it. >>>> >>>> Ok, I'll move it to the header. >>> >>> I did look for a newer webrev and didn't find one. >>> >>> >>> General comments: >>> ? - Please update the copyright years as needed before pushing. >>> >>> src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c >>> ??? No comments (other than agreeing with David H). >>> >>> src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c >>> ??? L1289: ??? /* >>> ??? L1290: ???? * The VM will die soon after the completion of this >>> callback - we >>> ??? L1291: ???? * may need to do a final synchronization with the >>> command loop to >>> ??? L1292: ???? * avoid the VM terminating with replying to the >>> final (resume) >>> ??? L1293: ???? * command. >>> ??? L1294: ???? */ >>> ??? L1295: ??? commandLoop_sync(); >>> >>> ??????? Seems like your addition of the call to commandLoop_sync() >>> ??????? might resolve what appears (to me) to be a placeholder >>> ??????? comment for a future change. Perhaps the comment should be >>> ??????? something like this: >>> >>> ??????? /* >>> ???????? * The VM will die soon after the completion of this callback - >>> ???????? * we synchronize with both the command loop and the debug loop >>> ???????? * for a more orderly shutdown. >>> ???????? */ >>> >>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>> ??? L772: void commandLoop_exitVmDeathLockOnError() { >>> ??????? The '{' should be on a line by itself to keep in the >>> ??????? same existing style. >>> >>> ??? L127: static jrawMonitorID vmDeathLock; >>> ??? L708: ??????????? debugMonitorEnter(vmDeathLock); >>> ??? L714: ??????????? debugMonitorExit(vmDeathLock); >>> ??? L778: ??? err = JVMTI_FUNC_PTR(gdata->jvmti, GetCurrentThread) >>> ??? L779: ????????????? (gdata->jvmti, &cur_thread); >>> ??? L794: ??? debugMonitorExit(vmDeathLock); >>> ??????? L794 assumes that the vmDeathLock is held by the Command >>> ??????? Loop Thread. Perhaps add a new volatile flag after L127 >>> ??????? that is set to true after L708 and set to false before >>> ??????? L714. Check the flag before calling GetCurrentThread() >>> ??????? on L778 and return early if the flag is not true. >>> >>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.h >>> ??? L57: void commandLoop_sync(void); /* commandLoop sync with >>> cbVMDeath */ >>> ??????? Extra space before 'cbVMDeath'. >>> >>> Dan >>> >>> >>>> >>>> Thank you a lot for he review! >>>> Serguei >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> ?? The approach to fix this is to introduce a new lock >>>>>> vmDeathLock in eventHelper.c >>>>>> ?? and use it to sync the commandLoop with the JVMTI event >>>>>> callback cbVMDeath >>>>>> ?? the same way as it was done for debugLoop_run. >>>>>> ?? (see the fix of: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8134103) >>>>>> >>>>>> ?? One potential issue with it is that the commandLoop() >>>>>> transitively uses some helper >>>>>> ?? functions (e.g. from util.c) that use the macro EXIT_ERROR, >>>>>> and so, can abort. >>>>>> ?? It seems, in such a case the vmDeathLock will remain locked, >>>>>> and so, >>>>>> ?? the cbVMDeath() will block on it causing a deadlock. >>>>>> ?? Note, that these helper functions can be also called from >>>>>> different contexts/threads >>>>>> ?? (not from the commandLoop thread only). In such contexts the >>>>>> commandLoop vmDeathLock >>>>>> ?? is not being entered, and so, should not be exited. >>>>>> >>>>>> ?? To fix this potential issue, new function, >>>>>> commandLoop_exitVmDeathLockOnError(), >>>>>> ?? is introduced, and it is called from the debugInit_exit(). >>>>>> The commandLoop_exitVmDeathLockOnError() always checks if current >>>>>> thread is >>>>>> ?? the commandLoop thread and only in such a case unlocks the >>>>>> vmDeathLock. >>>>>> >>>>>> Testing: >>>>>> ?? Ran the nsk.jdi, nsk.jdwp and jtreg jdk_jdi for both release >>>>>> and fastdebug builds. >>>>>> ?? All tests are passed. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>> >>> >> From jini.george at oracle.com Fri Sep 15 03:17:17 2017 From: jini.george at oracle.com (Jini George) Date: Fri, 15 Sep 2017 08:47:17 +0530 Subject: RFR: SA: MacOS X: 8184042: several serviceability/sa tests timed out on MacOS X In-Reply-To: <69512c98-57d1-01c0-d8d1-674024776a11@oracle.com> References: <69512c98-57d1-01c0-d8d1-674024776a11@oracle.com> Message-ID: Thanks much, Dan. -Jini. On 9/15/2017 4:18 AM, Daniel D. Daugherty wrote: > On 8/18/17 4:00 AM, Jini George wrote: >> Hi all, >> >> Requesting reviews for: https://bugs.openjdk.java.net/browse/JDK-8184042 >> >> Webrev: http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/ > > hotspot/src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m > L832: result = mach_port_insert_right (mach_task_self(), > Nit - extra blank before '(' > > L860-863 - nit - indents don't match the other func calls. > > I read through all the changes and looked at logic flow, error > returns, variable usage, etc. The problem is I'm not conversant > in Mach exception programming so there could easily be things > that I missed here. > > You really need to have a MacOS X person look at these changes > also. > > hotspot/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java > No comments. > > hotspot/src/jdk.hotspot.agent/macosx/native/libsaproc/mach_exc.h > hotspot/src/jdk.hotspot.agent/macosx/native/libsaproc/mach_excServer.c > hotspot/src/jdk.hotspot.agent/macosx/native/libsaproc/mach_excUser.c > These files are generated by a tool and will be replaced > by build changes. I didn't review them. > > hotspot/test/serviceability/sa/TestAttachDetach.java > L35: import java.util.ArrayList; > L36: import java.util.List; > L37: import java.util.Arrays; > L38: import java.util.Optional; > L40: import jdk.test.lib.Utils; > L41: import jdk.test.lib.process.OutputAnalyzer; > L42: import jdk.test.lib.process.ProcessTools; > These imports do not seem to be needed. > > L45: import jdk.test.lib.JDKToolLauncher; > Duplicate import. > > L98: "The String 'Attaching to > process' appears " + > L99: numberOfMatches + " number of > times"); > Would be helpful to include the expected value also. > > jdk/test/ProblemList.txt > Thanks for remembering to update the ProblemList.txt file! > > I don't have any comments other than nits. However, I don't > know mach exceptions so I can't really do a functional review. > > We need someone that knows MacOS X mach exceptions to chime > in on this thread. I'm adding Gerard Z to this review thread > in the hopes that he can help... > > Dan > > >> >> Problem gist: The deprecated ptrace() command, PT_ATTACH was changed >> to PT_ATTACHEXC, which causes mach exceptions (and not UNIX signals) >> to be delivered via mach messages.This caused SA to hang at waitpid() >> waiting for a signal, which does not arrive. >> >> Solution in a nutshell: The solution is to make the required changes >> to handle mach 'soft signal' exceptions in the form of mach messages >> instead of signals, while attaching to and detaching from the target >> process. The detailed steps are outlined in JBS. >> >> The changes appear huge due to the inclusion of pre-generated mach >> exception handling files (mach_exc*). Since this is an integration >> blocker, it would be great to get quick reviews on this. >> >> Thank you, >> Jini. >> >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Fri Sep 15 03:28:53 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Sep 2017 21:28:53 -0600 Subject: RFR(S) 8177901: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: References: <1405f243-f3f8-613b-2d16-0b9016a782f7@oracle.com> <2e00861b-6057-0746-1684-dea5a108a5ba@oracle.com> <5085bbae-ab92-0a6b-5dbf-96baad93d56b@oracle.com> Message-ID: On 9/14/17 9:12 PM, serguei.spitsyn at oracle.com wrote: > On 9/14/17 19:07, David Holmes wrote: >> On 15/09/2017 9:26 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Dan, >>> >>> Thank you a lot for reviewing! >>> All your suggestions are accepted. >>> >>> The updated webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177901-jdi-wrong_phase.2/ >> >> >> >> Not sure the new flag was actually needed if the only way to get to >> the commandLoop_exitVmDeathLockOnError in the event helper thread is >> via completeCommand(command) - which is within the locked region. But >> its harmless. > > Yes, it is harmless. Think of it as insurance against someone changing the code in the future. :-) Dan > > >> >> So thumbs up. > > Thank you a lot, David! > Serguei > >> >> Cheers, >> David >> >>> >>> >>> Just a sanity check is needed. >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 9/14/17 14:53, Daniel D. Daugherty wrote: >>>> On 9/4/17 11:23 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi David, >>>>> >>>>> >>>>> On 9/4/17 21:43, David Holmes wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> This looks good to me. One not below. >>>>>> >>>>>> On 2/09/2017 6:30 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review a fix for: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8177901 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177901-jdi-wrong_phase.1 >>>>>>> >>>>>> >>>>>> src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c >>>>>> >>>>>> +???? // Release commandLoop vmDeathLock if necessary >>>>>> +???? void commandLoop_exitVmDeathLockOnError(void); >>>>>> +???? commandLoop_exitVmDeathLockOnError(); >>>>>> >>>>>> The declaration should be in the eventHelper.h header file. It >>>>>> looks really odd to declare the function then call it. >>>>> >>>>> Ok, I'll move it to the header. >>>> >>>> I did look for a newer webrev and didn't find one. >>>> >>>> >>>> General comments: >>>> ? - Please update the copyright years as needed before pushing. >>>> >>>> src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c >>>> ??? No comments (other than agreeing with David H). >>>> >>>> src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c >>>> ??? L1289: ??? /* >>>> ??? L1290: ???? * The VM will die soon after the completion of this >>>> callback - we >>>> ??? L1291: ???? * may need to do a final synchronization with the >>>> command loop to >>>> ??? L1292: ???? * avoid the VM terminating with replying to the >>>> final (resume) >>>> ??? L1293: ???? * command. >>>> ??? L1294: ???? */ >>>> ??? L1295: ??? commandLoop_sync(); >>>> >>>> ??????? Seems like your addition of the call to commandLoop_sync() >>>> ??????? might resolve what appears (to me) to be a placeholder >>>> ??????? comment for a future change. Perhaps the comment should be >>>> ??????? something like this: >>>> >>>> ??????? /* >>>> ???????? * The VM will die soon after the completion of this >>>> callback - >>>> ???????? * we synchronize with both the command loop and the debug >>>> loop >>>> ???????? * for a more orderly shutdown. >>>> ???????? */ >>>> >>>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>>> ??? L772: void commandLoop_exitVmDeathLockOnError() { >>>> ??????? The '{' should be on a line by itself to keep in the >>>> ??????? same existing style. >>>> >>>> ??? L127: static jrawMonitorID vmDeathLock; >>>> ??? L708: ??????????? debugMonitorEnter(vmDeathLock); >>>> ??? L714: ??????????? debugMonitorExit(vmDeathLock); >>>> ??? L778: ??? err = JVMTI_FUNC_PTR(gdata->jvmti, GetCurrentThread) >>>> ??? L779: ????????????? (gdata->jvmti, &cur_thread); >>>> ??? L794: ??? debugMonitorExit(vmDeathLock); >>>> ??????? L794 assumes that the vmDeathLock is held by the Command >>>> ??????? Loop Thread. Perhaps add a new volatile flag after L127 >>>> ??????? that is set to true after L708 and set to false before >>>> ??????? L714. Check the flag before calling GetCurrentThread() >>>> ??????? on L778 and return early if the flag is not true. >>>> >>>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.h >>>> ??? L57: void commandLoop_sync(void); /* commandLoop sync with >>>> cbVMDeath */ >>>> ??????? Extra space before 'cbVMDeath'. >>>> >>>> Dan >>>> >>>> >>>>> >>>>> Thank you a lot for he review! >>>>> Serguei >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> ?? The approach to fix this is to introduce a new lock >>>>>>> vmDeathLock in eventHelper.c >>>>>>> ?? and use it to sync the commandLoop with the JVMTI event >>>>>>> callback cbVMDeath >>>>>>> ?? the same way as it was done for debugLoop_run. >>>>>>> ?? (see the fix of: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134103) >>>>>>> >>>>>>> ?? One potential issue with it is that the commandLoop() >>>>>>> transitively uses some helper >>>>>>> ?? functions (e.g. from util.c) that use the macro EXIT_ERROR, >>>>>>> and so, can abort. >>>>>>> ?? It seems, in such a case the vmDeathLock will remain locked, >>>>>>> and so, >>>>>>> ?? the cbVMDeath() will block on it causing a deadlock. >>>>>>> ?? Note, that these helper functions can be also called from >>>>>>> different contexts/threads >>>>>>> ?? (not from the commandLoop thread only). In such contexts the >>>>>>> commandLoop vmDeathLock >>>>>>> ?? is not being entered, and so, should not be exited. >>>>>>> >>>>>>> ?? To fix this potential issue, new function, >>>>>>> commandLoop_exitVmDeathLockOnError(), >>>>>>> ?? is introduced, and it is called from the debugInit_exit(). >>>>>>> The commandLoop_exitVmDeathLockOnError() always checks if >>>>>>> current thread is >>>>>>> ?? the commandLoop thread and only in such a case unlocks the >>>>>>> vmDeathLock. >>>>>>> >>>>>>> Testing: >>>>>>> ?? Ran the nsk.jdi, nsk.jdwp and jtreg jdk_jdi for both release >>>>>>> and fastdebug builds. >>>>>>> ?? All tests are passed. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>> >>>> >>> > From chris.plummer at oracle.com Fri Sep 15 04:19:03 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 14 Sep 2017 21:19:03 -0700 Subject: RFR(10)(M): 8179498: attach in linux should be relative to /proc/pid/root and namespace aware In-Reply-To: <804bdbc6-cce5-2b1e-9e46-8e5ca9143427@oracle.com> References: <6434ed9c-7ea0-fe2d-d185-eca74c06ea0b@oracle.com> <27b7a7af-e95b-4b36-5808-be8607f1b30b@oracle.com> <4436414c-6bbf-d173-3e23-e1fb7deec3f1@oracle.com> <7574486e-124d-ffe1-df36-1c7911844cde@oracle.com> <08bf2b33-53bf-c168-01b5-dc3d71b2f7b1@oracle.com> <630e7085-46d7-eaa2-72f7-268ddce1bda7@oracle.com> <14c9e33c-abf8-82f2-ef5d-89c306fa3cc0@samersoff.net> <2e7a873e-a2c3-a8e5-2c02-8acc7d7e03bb@oracle.com> <804bdbc6-cce5-2b1e-9e46-8e5ca9143427@oracle.com> Message-ID: <481f824e-24c3-98b9-c7e2-8501249070ec@oracle.com> On 9/14/17 9:56 AM, Chris Plummer wrote: > On 9/14/17 1:45 AM, David Holmes wrote: >> On 14/09/2017 5:53 PM, Dmitry Samersoff wrote: >>> Chris, >>> >>>> So now .attach_pid is always created in cwd as you can see in >>>> createAttachFile(), although AttachListener::is_init_trigger() does >>>> check tmp, but only after cwd. >>> >>>> ***getNamespacePid - ns_pid: 125 >>>> ***findSocketFile - f: /proc/24445/root/tmp/.java_pid125 >>>> ***createAttachFile - path: /proc/24445/cwd/.attach_pid125 >>> >>> Could we always use tmp ? >>> >>> IMHO cwd is not a right choice for such kind of files, it should be >>> either $HOME or tmp. >> >> And we hardwired /tmp and stopped using cwd under >> >> https://bugs.openjdk.java.net/browse/JDK-7132199 >> >> So I'm a bit confused as to how this has evolved back into using cwd. ?? > Yeah, I had this backwards with my earlier comment. Before JDK-7132199 > we actually do it the way we do now, trying cwd first, and then tmp if > it fails. JDK-7132199 made it only use tmp, but only for > findSocketFile(). createAttachFile() still tries cwd first and then > tmp, and I see nothing in the history to indicate this was ever > changed, other than to force the location of tmp to /tmp with > JDK-6950927. > > So the question is do we get rid of the cwd support and always use > tmp? If yes, I think it's best not to do that as part of this CR. I'd > rather just add the docker /tmp support to createAttachFile() now, and > have a separate CR deal with removing all cwd support (or maybe even > push changes for it before the docker support fix). Here's an updated webrev with the tmpdir fix in createAttachFile(): http://cr.openjdk.java.net/~cjplummer/8179498/webrev.02/webrev_jdk/ I ran all the same tests again, including testing with docker. To make sure it was hitting the tmpdir code, I forced the cwd code to error out by making it use cwdX instead. There are also two other changes to fix an issue I noticed when you provide a bad pid. You are suppose to get an error message like this: java.io.IOException: No such process ??? at jdk.attach/sun.tools.attach.VirtualMachineImpl.sendQuitTo(Native Method) ??? at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:80) ??? at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) ??? at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) ??? at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:114) ??? at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:98) However, I was seeing the following due to the docker related changes: java.nio.file.NoSuchFileException: /proc/7777/status ??? at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) ??? at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) ??? at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) ??? at java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:215) ??? at java.base/java.nio.file.Files.newByteChannel(Files.java:369) ??? at java.base/java.nio.file.Files.newByteChannel(Files.java:415) ??? at java.base/java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384) ??? at java.base/java.nio.file.Files.newInputStream(Files.java:154) ??? at java.base/java.nio.file.Files.newBufferedReader(Files.java:2830) ??? at java.base/java.nio.file.Files.readAllLines(Files.java:3260) ??? at jdk.attach/sun.tools.attach.VirtualMachineImpl.getNamespacePid(VirtualMachineImpl.java:334) ??? at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:71) ??? at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) ??? at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) ??? at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:114) ??? at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:98) I fixed getNamespacePid() to validate that /proc//status exists before trying to process it. If it doesn't, it just returns pid rather than trying to find ns_pid. However, that led to: java.io.IOException: No such file or directory ??? at java.base/java.io.UnixFileSystem.createFileExclusively(Native Method) ??? at java.base/java.io.File.createNewFile(File.java:1024) ??? at jdk.attach/sun.tools.attach.VirtualMachineImpl.createAttachFile(VirtualMachineImpl.java:300) ??? at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:78) ??? at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) ??? at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) ??? at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:114) ??? at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:98) This is because createAttachFile() first tried to create the file in /proc//cwd, and after that failed with IOException (which is caught), it tried in /proc//root/tmp, which fails with the above uncaught IOException. I changed the code to only try /proc//root/tmp if pid != ns_pid (which means either it is a docker situation and the pid is valid). Otherwise it reverts to the old behavior just using /tmp. thanks, Chris > > thanks, > > Chris >> >> David >> >> >>> -Dmitry >>> >>> On 14.09.2017 07:15, Chris Plummer wrote: >>>> On 9/13/17 9:00 PM, David Holmes wrote: >>>>> Hi Chris, >>>>> >>>>> On 14/09/2017 1:03 PM, Chris Plummer wrote: >>>>>> Hi David, >>>>>> >>>>>> On 9/13/17 5:12 PM, David Holmes wrote: >>>>>>> Hi Chris, >>>>>>> >>>>>>> On 14/09/2017 8:23 AM, Chris Plummer wrote: >>>>>>>> I could use one more reviewer. >>>>>>> >>>>>>> Generally this seems okay to me. >>>>>>> >>>>>>> One query though ... in createAttachFile don't you need to alter >>>>>>> the >>>>>>> tmpdir using part in a similar manner to how findSocketFile was >>>>>>> modified? >>>>>> The fix in findSocketFile is not just to make sure the client uses >>>>>> the correct pid in the .java_pid file files, but also (as you point >>>>>> out) to make sure that the client properly references the target >>>>>> jvm's tmp directory when accessing the .java_pid file. >>>>>> findSocketFile >>>>>> is a little >>>>> >>>>> I presume you mean createAttachFile there. >>>> Yes. >>>>> >>>>>> different. You still have to map to the proper from pid to ns_pid >>>>>> when referencing the .attach_pid file, but you don't have the /tmp >>>>>> mount point differences to deal with. /proc//cwd should work >>>>>> even if the pid is for a docker. You don't even have to map to the >>>>>> pid as the docker sees it. /proc//cwd from the client's POV >>>>>> should be the same as /proc//cwd from the target JVM's POV. >>>>> >>>>> Sorry but I don't follow. If findSocketFile has to look in >>>>> /proc//root/ for the socket file, why does the >>>>> createAttachFile not also have to write the attach file into >>>>> /proc//root/ ?? In both cases it needs to find the >>>>> tmpdir >>>>> of the target process. >>>> Fortunately I have some old printlns that might help: >>>> >>>> ***getNamespacePid - ns_pid: 125 >>>> ***findSocketFile - f: /proc/24445/root/tmp/.java_pid125 >>>> ***createAttachFile - path: /proc/24445/cwd/.attach_pid125 >>>> >>>> So this is a case where the real pid is 24445, but the namespace >>>> pid in >>>> the docker is 125. The docker can (and does) reference >>>> /tmp/.java_pid125, but the client needs to reference >>>> /proc/24445/root/tmp/.java_pid125 to get to the same file. For >>>> .attach_pid125, the client can get to it through >>>> /proc/24445/cwd/.attach_pid125, and the docker process will look in >>>> cwd >>>> for the file. This is done in AttachListener::is_init_trigger(). >>>> >>>> BTW, comments like the following are no longer correct due to >>>> JDK-7132199: >>>> >>>> ???? // "/tmp" is used as a global well-known location for the files >>>> ???? // .java_pid. and .attach_pid. It is important that >>>> this >>>> ???? // location is the same for all processes, otherwise the tools >>>> ???? // will not be able to find all Hotspot processes. >>>> ???? // Any changes to this needs to be synchronized with HotSpot. >>>> ???? private static final String tmpdir = "/tmp"; >>>> >>>> So now .attach_pid is always created in cwd as you can see in >>>> createAttachFile(), although AttachListener::is_init_trigger() does >>>> check tmp, but only after cwd. >>>> >>>> thanks, >>>> >>>> Chris >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>>> >>>>>>> Minor note - you can collapse your catch blocks into 1 using >>>>>>> something like >>>>>>> >>>>>>> ??????? } catch (NumberFormatException | IOException x) { >>>>>>> ???????????? throw new AttachNotSupportedException("Unable to parse >>>>>>> namespace"); >>>>>>> ??????? } >>>>>> I'll make that change. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 9/11/17 8:03 PM, Chris Plummer wrote: >>>>>>>>> Ok, I will. Thanks. >>>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>>> On 9/11/17 6:13 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi Chris, >>>>>>>>>> >>>>>>>>>> This looks good to me. >>>>>>>>>> >>>>>>>>>> I'm not sure if all the nsk.aod and the AttachOnDemand tests >>>>>>>>>> from >>>>>>>>>> the nsk.jvmti are run in the hotspot tier1, 2, and 3 tests. >>>>>>>>>> It makes sense to double-check it. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 9/10/17 20:34, Chris Plummer wrote: >>>>>>>>>>> [re-sending - sent to wrong alias first time] >>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Please review the following: >>>>>>>>>>> >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8179498 >>>>>>>>>>> http://cr.openjdk.java.net/~cjplummer/8179498/webrev.00/webrev_jdk/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The CR has the relevant details. Some previous discussions can >>>>>>>>>>> be found here: >>>>>>>>>>> >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/021237.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-May/021249.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021679.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Testing with docker has been limited to just making sure jcmd >>>>>>>>>>> now works with the docker setup I was provided. I currently >>>>>>>>>>> don't see how we can run our existing tests in a way that would >>>>>>>>>>> test the docker support without doing some rewriting of the >>>>>>>>>>> tests. >>>>>>>>>>> >>>>>>>>>>> I also ran all our hotspot tier1, 2, and 3 tests, along with >>>>>>>>>>> jdk/test/tools and jdk/test/sun/tools tests to make sure >>>>>>>>>>> existing functionality is not broken with these changes. >>>>>>>>>>> >>>>>>>>>>> thanks, >>>>>>>>>>> >>>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >>> >>> > > From serguei.spitsyn at oracle.com Fri Sep 15 06:52:39 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 14 Sep 2017 23:52:39 -0700 Subject: RFR(S) 8177901: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface In-Reply-To: References: <1405f243-f3f8-613b-2d16-0b9016a782f7@oracle.com> <2e00861b-6057-0746-1684-dea5a108a5ba@oracle.com> <5085bbae-ab92-0a6b-5dbf-96baad93d56b@oracle.com> Message-ID: On 9/14/17 20:28, Daniel D. Daugherty wrote: > On 9/14/17 9:12 PM, serguei.spitsyn at oracle.com wrote: >> On 9/14/17 19:07, David Holmes wrote: >>> On 15/09/2017 9:26 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi Dan, >>>> >>>> Thank you a lot for reviewing! >>>> All your suggestions are accepted. >>>> >>>> The updated webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177901-jdi-wrong_phase.2/ >>> >>> >>> >>> >>> Not sure the new flag was actually needed if the only way to get to >>> the commandLoop_exitVmDeathLockOnError in the event helper thread is >>> via completeCommand(command) - which is within the locked region. >>> But its harmless. >> >> Yes, it is harmless. > > Think of it as insurance against someone changing the code in > the future. :-) Yes, it is the point. :) Thanks, Serguei > > Dan > > >> >> >>> >>> So thumbs up. >> >> Thank you a lot, David! >> Serguei >> >>> >>> Cheers, >>> David >>> >>>> >>>> >>>> Just a sanity check is needed. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 9/14/17 14:53, Daniel D. Daugherty wrote: >>>>> On 9/4/17 11:23 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi David, >>>>>> >>>>>> >>>>>> On 9/4/17 21:43, David Holmes wrote: >>>>>>> Hi Serguei, >>>>>>> >>>>>>> This looks good to me. One not below. >>>>>>> >>>>>>> On 2/09/2017 6:30 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Please, review a fix for: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8177901 >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177901-jdi-wrong_phase.1 >>>>>>>> >>>>>>> >>>>>>> src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c >>>>>>> >>>>>>> +???? // Release commandLoop vmDeathLock if necessary >>>>>>> +???? void commandLoop_exitVmDeathLockOnError(void); >>>>>>> +???? commandLoop_exitVmDeathLockOnError(); >>>>>>> >>>>>>> The declaration should be in the eventHelper.h header file. It >>>>>>> looks really odd to declare the function then call it. >>>>>> >>>>>> Ok, I'll move it to the header. >>>>> >>>>> I did look for a newer webrev and didn't find one. >>>>> >>>>> >>>>> General comments: >>>>> ? - Please update the copyright years as needed before pushing. >>>>> >>>>> src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c >>>>> ??? No comments (other than agreeing with David H). >>>>> >>>>> src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c >>>>> ??? L1289: ??? /* >>>>> ??? L1290: ???? * The VM will die soon after the completion of >>>>> this callback - we >>>>> ??? L1291: ???? * may need to do a final synchronization with the >>>>> command loop to >>>>> ??? L1292: ???? * avoid the VM terminating with replying to the >>>>> final (resume) >>>>> ??? L1293: ???? * command. >>>>> ??? L1294: ???? */ >>>>> ??? L1295: ??? commandLoop_sync(); >>>>> >>>>> ??????? Seems like your addition of the call to commandLoop_sync() >>>>> ??????? might resolve what appears (to me) to be a placeholder >>>>> ??????? comment for a future change. Perhaps the comment should be >>>>> ??????? something like this: >>>>> >>>>> ??????? /* >>>>> ???????? * The VM will die soon after the completion of this >>>>> callback - >>>>> ???????? * we synchronize with both the command loop and the debug >>>>> loop >>>>> ???????? * for a more orderly shutdown. >>>>> ???????? */ >>>>> >>>>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>>>> ??? L772: void commandLoop_exitVmDeathLockOnError() { >>>>> ??????? The '{' should be on a line by itself to keep in the >>>>> ??????? same existing style. >>>>> >>>>> ??? L127: static jrawMonitorID vmDeathLock; >>>>> ??? L708: ??????????? debugMonitorEnter(vmDeathLock); >>>>> ??? L714: ??????????? debugMonitorExit(vmDeathLock); >>>>> ??? L778: ??? err = JVMTI_FUNC_PTR(gdata->jvmti, GetCurrentThread) >>>>> ??? L779: ????????????? (gdata->jvmti, &cur_thread); >>>>> ??? L794: ??? debugMonitorExit(vmDeathLock); >>>>> ??????? L794 assumes that the vmDeathLock is held by the Command >>>>> ??????? Loop Thread. Perhaps add a new volatile flag after L127 >>>>> ??????? that is set to true after L708 and set to false before >>>>> ??????? L714. Check the flag before calling GetCurrentThread() >>>>> ??????? on L778 and return early if the flag is not true. >>>>> >>>>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.h >>>>> ??? L57: void commandLoop_sync(void); /* commandLoop sync with >>>>> cbVMDeath */ >>>>> ??????? Extra space before 'cbVMDeath'. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> Thank you a lot for he review! >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> >>>>>>>> Summary: >>>>>>>> >>>>>>>> ?? The approach to fix this is to introduce a new lock >>>>>>>> vmDeathLock in eventHelper.c >>>>>>>> ?? and use it to sync the commandLoop with the JVMTI event >>>>>>>> callback cbVMDeath >>>>>>>> ?? the same way as it was done for debugLoop_run. >>>>>>>> ?? (see the fix of: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8134103) >>>>>>>> >>>>>>>> ?? One potential issue with it is that the commandLoop() >>>>>>>> transitively uses some helper >>>>>>>> ?? functions (e.g. from util.c) that use the macro EXIT_ERROR, >>>>>>>> and so, can abort. >>>>>>>> ?? It seems, in such a case the vmDeathLock will remain locked, >>>>>>>> and so, >>>>>>>> ?? the cbVMDeath() will block on it causing a deadlock. >>>>>>>> ?? Note, that these helper functions can be also called from >>>>>>>> different contexts/threads >>>>>>>> ?? (not from the commandLoop thread only). In such contexts the >>>>>>>> commandLoop vmDeathLock >>>>>>>> ?? is not being entered, and so, should not be exited. >>>>>>>> >>>>>>>> ?? To fix this potential issue, new function, >>>>>>>> commandLoop_exitVmDeathLockOnError(), >>>>>>>> ?? is introduced, and it is called from the debugInit_exit(). >>>>>>>> The commandLoop_exitVmDeathLockOnError() always checks if >>>>>>>> current thread is >>>>>>>> ?? the commandLoop thread and only in such a case unlocks the >>>>>>>> vmDeathLock. >>>>>>>> >>>>>>>> Testing: >>>>>>>> ?? Ran the nsk.jdi, nsk.jdwp and jtreg jdk_jdi for both release >>>>>>>> and fastdebug builds. >>>>>>>> ?? All tests are passed. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>> >>>>> >>>> >> > From jaroslav.tulach at oracle.com Fri Sep 15 12:32:04 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Fri, 15 Sep 2017 14:32:04 +0200 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <1595796.xe8q7Anfpj@pracovni> Message-ID: <2523912.QeZCepiec8@pracovni> Thanks for the review Mandy, Daniel. Now, that the consolidated JDK10 repository is available, I have updated my webrev to its structure. In addition to that I addressed your comments: On ?ter? 12. z??? 2017 11:19:45 CEST mandy chung wrote: > ./make/common/Modules.gmk > Nit: can you move jdk.internal.vm.compiler.management to keep the > list in alphabetical order Inserted at appropriate place. > 199 # Filter out Graal specific modules if Graal build is disabled > 200 > 201 ifeq ($(INCLUDE_GRAAL), false) > 202 MODULES_FILTER += jdk.internal.vm.compiler > 203 endif > > When will INCLUDE_GRAAL be set to false? I think > jdk.internal.vm.compiler.management should also be filtered if > jdk.internal.vm.compiler is disabled. That is probably true. Fixed. > > Is jdk.internal.vm.compiler and jdk.internal.vm.compiler.management > built for all platforms in JDK 10? If not, > jdk/src/java.management/share/classes/module-info.java may fail to > compile when jdk.internal.vm.compiler.management is not present. We > can consult with the build team when you find out what configuration > that jdk.internal.vm.compiler is not built. I haven't found configuration where jdk.internal.vm.compiler wouldn't be built. However I wasn't looking very extensively... > hotspot/src/jdk.internal.vm.compiler/share/classes/module-info.java 29 > requires transitive jdk.internal.vm.ci; > do you get any error without this requires transitive? > jdk.internal.vm.compiler.management already requires > jdk.internal.vm.ci. I would think this requires transitive is not > necessary. Looks like this change isn't necessary. I am not sure what was the problem before, when I introduced it. > Is HotSpotGraalCompiler::mbean method necessary? In GraalMBeans.java > > 53 public static Object findGraalRuntimeBean() { > 54 JVMCIRuntime r = JVMCI.getRuntime(); > 55 JVMCICompiler c = r.getCompiler(); > 56 if (c instanceof HotSpotGraalCompiler) { > 57 return ((HotSpotGraalCompiler) c).mbean(); > 58 } > 59 return null; > 60 } > > It seems that you can call HotspotGraalRuntime::mbean directly. I don't think I can. There is no way to get to HotspotGraalRuntime except asking the HotSpotGraalCompiler. The HotspotGraalRuntime isn't JVMCIRuntime... At least I think so, there is slightly too much runtimes and providers in the codebase for my taste. However that isn't something I can change as part of JDK-8182701 > As we > discussed offline, we agree that HotSpotRuntimeMBean should belong to > this new module but it requires some refactoring which may take some > amount of work. Such clean up will be followed up in a separate JBS issue. Right. > GraalMBeans.java: > > 77 @Override > 78 public Set mbeanInterfaceNames() { > 79 return Collections.singleton(name); > 80 } > > This is not correct. The return set should be a set of > MXBean interface names, as in Class.getName(), not a set > of MXBean ObjectName strings. I see. Thanks. On st?eda 13. z??? 2017 8:23:22 CEST mandy chung wrote: > On 9/13/17 2:28 AM, Daniel Fuchs wrote: > Good catch, Daniel. This should return empty set as mbeanInterfaces() > returns. mbeanInterfaceNames returns the class name of the mbean > interfaces. OK, returning empty set. The webrev #5 is available at http://cr.openjdk.java.net/~jtulach/8182701/webrev.05/ -jt From doug.simon at oracle.com Fri Sep 15 12:47:00 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 15 Sep 2017 14:47:00 +0200 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <2523912.QeZCepiec8@pracovni> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <1595796.xe8q7Anfpj@pracovni> <2523912.QeZCepiec8@pracovni> Message-ID: > On 15 Sep 2017, at 14:32, Jaroslav Tulach wrote: > > Thanks for the review Mandy, Daniel. Now, that the consolidated JDK10 > repository is available, I have updated my webrev to its structure. In > addition to that I addressed your comments: > > On ?ter? 12. z??? 2017 11:19:45 CEST mandy chung wrote: >> ./make/common/Modules.gmk >> Nit: can you move jdk.internal.vm.compiler.management to keep the >> list in alphabetical order > > Inserted at appropriate place. > >> 199 # Filter out Graal specific modules if Graal build is disabled >> 200 >> 201 ifeq ($(INCLUDE_GRAAL), false) >> 202 MODULES_FILTER += jdk.internal.vm.compiler >> 203 endif >> >> When will INCLUDE_GRAAL be set to false? I think >> jdk.internal.vm.compiler.management should also be filtered if >> jdk.internal.vm.compiler is disabled. > > That is probably true. Fixed. > >> >> Is jdk.internal.vm.compiler and jdk.internal.vm.compiler.management >> built for all platforms in JDK 10? If not, >> jdk/src/java.management/share/classes/module-info.java may fail to >> compile when jdk.internal.vm.compiler.management is not present. We >> can consult with the build team when you find out what configuration >> that jdk.internal.vm.compiler is not built. > > I haven't found configuration where jdk.internal.vm.compiler wouldn't be built. > However I wasn't looking very extensively... > >> hotspot/src/jdk.internal.vm.compiler/share/classes/module-info.java 29 >> requires transitive jdk.internal.vm.ci; >> do you get any error without this requires transitive? >> jdk.internal.vm.compiler.management already requires >> jdk.internal.vm.ci. I would think this requires transitive is not >> necessary. > > Looks like this change isn't necessary. I am not sure what was the problem > before, when I introduced it. > >> Is HotSpotGraalCompiler::mbean method necessary? In GraalMBeans.java >> >> 53 public static Object findGraalRuntimeBean() { >> 54 JVMCIRuntime r = JVMCI.getRuntime(); >> 55 JVMCICompiler c = r.getCompiler(); >> 56 if (c instanceof HotSpotGraalCompiler) { >> 57 return ((HotSpotGraalCompiler) c).mbean(); >> 58 } >> 59 return null; >> 60 } >> >> It seems that you can call HotspotGraalRuntime::mbean directly. > > I don't think I can. There is no way to get to HotspotGraalRuntime except > asking the HotSpotGraalCompiler. The HotspotGraalRuntime isn't JVMCIRuntime... > At least I think so That is correct - you have to obtain a HotspotGraalRuntime from a HotSpotGraalCompiler. There can be other HotspotGraalRuntime instances (e.g., Truffle has it's own HotSpotGraalCompiler/HotSpotGraalRuntime). -Doug From gerard.ziemski at oracle.com Fri Sep 15 14:51:29 2017 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Fri, 15 Sep 2017 09:51:29 -0500 Subject: RFR: SA: MacOS X: 8184042: several serviceability/sa tests timed out on MacOS X In-Reply-To: <69512c98-57d1-01c0-d8d1-674024776a11@oracle.com> References: <69512c98-57d1-01c0-d8d1-674024776a11@oracle.com> Message-ID: Sorry, I?m not familiar with mach exceptions. > On Sep 14, 2017, at 5:48 PM, Daniel D. Daugherty wrote: > > We need someone that knows MacOS X mach exceptions to chime > in on this thread. I'm adding Gerard Z to this review thread > in the hopes that he can help... From mandy.chung at oracle.com Fri Sep 15 17:53:45 2017 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 15 Sep 2017 10:53:45 -0700 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <1595796.xe8q7Anfpj@pracovni> <2523912.QeZCepiec8@pracovni> Message-ID: <48a815cd-2943-d328-d955-f301d39d7b86@oracle.com> On 9/15/17 5:47 AM, Doug Simon wrote: >> I don't think I can. There is no way to get to HotspotGraalRuntime except >> asking the HotSpotGraalCompiler. The HotspotGraalRuntime isn't JVMCIRuntime... >> At least I think so > That is correct - you have to obtain a HotspotGraalRuntime from a HotSpotGraalCompiler. There can be other HotspotGraalRuntime instances (e.g., Truffle has it's own HotSpotGraalCompiler/HotSpotGraalRuntime). Ah... that explains why you need two mbean() methods in this version. > http://cr.openjdk.java.net/~jtulach/8182701/webrev.05/index.html Looks good. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From poonam.bajaj at oracle.com Fri Sep 15 19:48:24 2017 From: poonam.bajaj at oracle.com (Poonam Parhar) Date: Fri, 15 Sep 2017 12:48:24 -0700 Subject: RFR: SA: MacOS X: 8184042: several serviceability/sa tests timed out on MacOS X In-Reply-To: References: <69512c98-57d1-01c0-d8d1-674024776a11@oracle.com> Message-ID: Hello Jini, I don't know much about the mach exceptions either. I read through your wiki page and looked at the relevant gdb and lldb code to understand how it works. A few points regarding the changes for this CR: File: src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m 1. In the lldb code, a separate thread is being used to catch and handle the mach exceptions. I am assuming we don't need to do that since we use the mach exceptions mechanism only during the attach process, and after which we suspend all the threads in the target process.Is that correct? 2. 823 if (result != KERN_SUCCESS) { 824 print_error("attach: mach_port_allocate() failed: '%s' (%d)\n", 825 mach_error_string(result), result); For all the mach calls in this function, would it make sense to print the exception_port as well while reporting errors to make is easier to debug the attach failures. 3. 843 result = task_get_exception_ports(gTask, 844 EXC_MASK_ALL, 845 saved_masks, 846 &saved_exception_types_count, 847 saved_ports, 848 saved_behaviors, 849 saved_flavors); A comment for this call explaining why we are getting and saving the exceptions info here would be good. e.g. we need to restore the exceptions state for the process when we detach from it. 4. It would make the code look cleaner to have all these exception details that we need to save as the fields of a structure. 5. /tgt_exception_port/ and /saved_exception_types_count/ are saved on the Java side, but /saved_masks, //saved_ports, //saved_behaviors and //saved_flavors/ are defined as static on the native side. All of these values are process specific, and are needed when we detach from a process. Why are these being treated differently? Thanks, Poonam On 9/14/2017 8:17 PM, Jini George wrote: > Thanks much, Dan. > > -Jini. > > On 9/15/2017 4:18 AM, Daniel D. Daugherty wrote: >> On 8/18/17 4:00 AM, Jini George wrote: >>> Hi all, >>> >>> Requesting reviews for: https://bugs.openjdk.java.net/browse/JDK-8184042 >>> >>> Webrev: http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/ >> >> hotspot/src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m >> ??? L832: ? result = mach_port_insert_right (mach_task_self(), >> ??????? Nit - extra blank before '(' >> >> ??? L860-863 - nit - indents don't match the other func calls. >> >> ??? I read through all the changes and looked at logic flow, error >> ??? returns, variable usage, etc. The problem is I'm not conversant >> ??? in Mach exception programming so there could easily be things >> ??? that I missed here. >> >> ??? You really need to have a MacOS X person look at these changes >> ??? also. >> >> hotspot/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java >> ??? No comments. >> >> hotspot/src/jdk.hotspot.agent/macosx/native/libsaproc/mach_exc.h >> hotspot/src/jdk.hotspot.agent/macosx/native/libsaproc/mach_excServer.c >> hotspot/src/jdk.hotspot.agent/macosx/native/libsaproc/mach_excUser.c >> ??? These files are generated by a tool and will be replaced >> ??? by build changes. I didn't review them. >> >> hotspot/test/serviceability/sa/TestAttachDetach.java >> ??? L35: import java.util.ArrayList; >> ??? L36: import java.util.List; >> ??? L37: import java.util.Arrays; >> ??? L38: import java.util.Optional; >> ??? L40: import jdk.test.lib.Utils; >> ??? L41: import jdk.test.lib.process.OutputAnalyzer; >> ??? L42: import jdk.test.lib.process.ProcessTools; >> ??????? These imports do not seem to be needed. >> >> ??? L45: import jdk.test.lib.JDKToolLauncher; >> ??????? Duplicate import. >> >> ??? L98: ??????????????????????????? "The String 'Attaching to >> process' appears " + >> ??? L99: ???????????????????????????? numberOfMatches + " number of >> times"); >> ??????? Would be helpful to include the expected value also. >> >> jdk/test/ProblemList.txt >> ??? Thanks for remembering to update the ProblemList.txt file! >> >> I don't have any comments other than nits. However, I don't >> know mach exceptions so I can't really do a functional review. >> >> We need someone that knows MacOS X mach exceptions to chime >> in on this thread. I'm adding Gerard Z to this review thread >> in the hopes that he can help... >> >> Dan >> >> >>> >>> Problem gist: The deprecated ptrace() command, PT_ATTACH was changed >>> to PT_ATTACHEXC, which causes mach exceptions (and not UNIX signals) >>> to be delivered via mach messages.This caused SA to hang at >>> waitpid() waiting for a signal, which does not arrive. >>> >>> Solution in a nutshell: The solution is to make the required changes >>> to handle mach 'soft signal' exceptions in the form of mach messages >>> instead of signals, while attaching to and detaching from the target >>> process. The detailed steps are outlined in JBS. >>> >>> The changes appear huge due to the inclusion of pre-generated mach >>> exception handling files (mach_exc*). Since this is an integration >>> blocker, it would be great to get quick reviews on this. >>> >>> Thank you, >>> Jini. >>> >>> >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Sat Sep 16 12:20:07 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 16 Sep 2017 21:20:07 +0900 Subject: RFR: JDK-8187597: WrongTypeException is occurred at CLHSDB jstack after JDK-8186837 Message-ID: <39e4a81a-0a12-1ee7-dedb-0b9853d89fce@gmail.com> Hi all, I tried to get thread dump via jstack command on CLHSDB. But it was failed as below: ``` Caused by: sun.jvm.hotspot.types.WrongTypeException: field "_stack_traversal_mark" in type nmethod is not of type jlong, but instead of type long at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:206) at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:212) at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getJLongField(BasicType.java:249) at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.initialize(NMethod.java:108) at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.access$000(NMethod.java:35) at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod$1.update(NMethod.java:81) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:451) at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.(NMethod.java:79) ... 23 more ``` I think this exception is caused by JDK-8186837. This changeset has changed the type of `nmethod::_stack_traversal_mark` to `long` from `jlong`. SA should follow this change. I uploaded a webrev for this issue. This webrev is generated from consolidated repo (jdk10/master). Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.00/ I cannot access JPRT. So I need reviewer. Thanks, Yasumasa From chris.plummer at oracle.com Sat Sep 16 18:58:56 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Sat, 16 Sep 2017 11:58:56 -0700 Subject: RFR: JDK-8187597: WrongTypeException is occurred at CLHSDB jstack after JDK-8186837 In-Reply-To: <39e4a81a-0a12-1ee7-dedb-0b9853d89fce@gmail.com> References: <39e4a81a-0a12-1ee7-dedb-0b9853d89fce@gmail.com> Message-ID: Hi Yasumasa, Is this on a 32-bit system? I don't see how you could otherwise call getCIntegerField() on a long type. jlong is always 64-bit and long is (generally) 32-bit on 32-bit systems, and 64-bit on 64-bit systems, at least that seems to be the case with linux. From what I can see, _stack_traversal_mark is now the only long type in vmStructs.cpp. I don't know that we have a mechanism to safely fetch it on both 32-bit and 64-bit systems. _stack_traversal_mark seems to be a long because _traversals is also a long. ? ? static long????? _traversals;?????????????????? // Stack scan count, also sweep ID. This too might be considered a bug. I'm not sure why you would want the size of this field to vary between 32-bit and 64-bit systems (adding compiler-dev to help answer that). So, while I would agree that your fix is generally in the right direction, I think we first need to revisit the use of long for these fields. If they can be changed to an int, then your fix is correct (pending the changes to int). If not, then maybe we need getCLongField() support. And lastly, we really should have a test to detect this bug. Maybe we already do, and it is failing but is going unnoticed for some reason. I'll try to look into that some more on Monday. thanks, Chris On 9/16/17 5:20 AM, Yasumasa Suenaga wrote: > Hi all, > > I tried to get thread dump via jstack command on CLHSDB. But it was > failed as below: > > ``` > Caused by: sun.jvm.hotspot.types.WrongTypeException: field > "_stack_traversal_mark" in type nmethod is not of type jlong, but > instead of type long > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:206) > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:212) > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getJLongField(BasicType.java:249) > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.initialize(NMethod.java:108) > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.access$000(NMethod.java:35) > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod$1.update(NMethod.java:81) > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:451) > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.(NMethod.java:79) > ??????? ... 23 more > ``` > > I think this exception is caused by JDK-8186837. > This changeset has changed the type of > `nmethod::_stack_traversal_mark` to `long` from `jlong`. > > SA should follow this change. > > I uploaded a webrev for this issue. This webrev is generated from > consolidated repo (jdk10/master). > Could you review it? > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.00/ > > > I cannot access JPRT. So I need reviewer. > > > Thanks, > > Yasumasa > From yasuenag at gmail.com Sun Sep 17 08:13:19 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 17 Sep 2017 17:13:19 +0900 Subject: RFR: JDK-8187597: WrongTypeException is occurred at CLHSDB jstack after JDK-8186837 In-Reply-To: References: <39e4a81a-0a12-1ee7-dedb-0b9853d89fce@gmail.com> Message-ID: <6f369ad1-ee23-32b1-37ae-3bb60629960c@gmail.com> Hi Chris, I've tested this issue on Fedora 26 x86_64. I think we can sue CIntegerField at this point because CIntegerField is not specialized for various int size [1]. In fact, CIntegerField had been used at this point [2], and HSDB worked fine. Thanks, Yasumasa [1] http://hg.openjdk.java.net/jdk10/master/file/fd36993f7bf5/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/CIntegerField.java#l29 [2] http://hg.openjdk.java.net/jdk10/master/rev/cbfdbefc6ea3 On 2017/09/17 3:58, Chris Plummer wrote: > Hi Yasumasa, > > Is this on a 32-bit system? I don't see how you could otherwise call getCIntegerField() on a long type. jlong is always 64-bit and long is (generally) 32-bit on 32-bit systems, and 64-bit on 64-bit systems, at least that seems to be the case with linux. > > From what I can see, _stack_traversal_mark is now the only long type in vmStructs.cpp. I don't know that we have a mechanism to safely fetch it on both 32-bit and 64-bit systems. > > _stack_traversal_mark seems to be a long because _traversals is also a long. > > ? ? static long????? _traversals;?????????????????? // Stack scan count, also sweep ID. > > This too might be considered a bug. I'm not sure why you would want the size of this field to vary between 32-bit and 64-bit systems (adding compiler-dev to help answer that). > > So, while I would agree that your fix is generally in the right direction, I think we first need to revisit the use of long for these fields. If they can be changed to an int, then your fix is correct (pending the changes to int). If not, then maybe we need getCLongField() support. > > And lastly, we really should have a test to detect this bug. Maybe we already do, and it is failing but is going unnoticed for some reason. I'll try to look into that some more on Monday. > > thanks, > > Chris > > On 9/16/17 5:20 AM, Yasumasa Suenaga wrote: >> Hi all, >> >> I tried to get thread dump via jstack command on CLHSDB. But it was failed as below: >> >> ``` >> Caused by: sun.jvm.hotspot.types.WrongTypeException: field "_stack_traversal_mark" in type nmethod is not of type jlong, but instead of type long >> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:206) >> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:212) >> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getJLongField(BasicType.java:249) >> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.initialize(NMethod.java:108) >> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.access$000(NMethod.java:35) >> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod$1.update(NMethod.java:81) >> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:451) >> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.(NMethod.java:79) >> ??????? ... 23 more >> ``` >> >> I think this exception is caused by JDK-8186837. >> This changeset has changed the type of `nmethod::_stack_traversal_mark` to `long` from `jlong`. >> >> SA should follow this change. >> >> I uploaded a webrev for this issue. This webrev is generated from consolidated repo (jdk10/master). >> Could you review it? >> >> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.00/ >> >> >> I cannot access JPRT. So I need reviewer. >> >> >> Thanks, >> >> Yasumasa >> > > From david.holmes at oracle.com Mon Sep 18 00:17:08 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Sep 2017 10:17:08 +1000 Subject: RFR(10)(M): 8179498: attach in linux should be relative to /proc/pid/root and namespace aware In-Reply-To: <481f824e-24c3-98b9-c7e2-8501249070ec@oracle.com> References: <6434ed9c-7ea0-fe2d-d185-eca74c06ea0b@oracle.com> <27b7a7af-e95b-4b36-5808-be8607f1b30b@oracle.com> <4436414c-6bbf-d173-3e23-e1fb7deec3f1@oracle.com> <7574486e-124d-ffe1-df36-1c7911844cde@oracle.com> <08bf2b33-53bf-c168-01b5-dc3d71b2f7b1@oracle.com> <630e7085-46d7-eaa2-72f7-268ddce1bda7@oracle.com> <14c9e33c-abf8-82f2-ef5d-89c306fa3cc0@samersoff.net> <2e7a873e-a2c3-a8e5-2c02-8acc7d7e03bb@oracle.com> <804bdbc6-cce5-2b1e-9e46-8e5ca9143427@oracle.com> <481f824e-24c3-98b9-c7e2-8501249070ec@oracle.com> Message-ID: Hi Chris, On 15/09/2017 2:19 PM, Chris Plummer wrote: > On 9/14/17 9:56 AM, Chris Plummer wrote: >> On 9/14/17 1:45 AM, David Holmes wrote: >>> On 14/09/2017 5:53 PM, Dmitry Samersoff wrote: >>>> Chris, >>>> >>>>> So now .attach_pid is always created in cwd as you can see in >>>>> createAttachFile(), although AttachListener::is_init_trigger() does >>>>> check tmp, but only after cwd. >>>> >>>>> ***getNamespacePid - ns_pid: 125 >>>>> ***findSocketFile - f: /proc/24445/root/tmp/.java_pid125 >>>>> ***createAttachFile - path: /proc/24445/cwd/.attach_pid125 >>>> >>>> Could we always use tmp ? >>>> >>>> IMHO cwd is not a right choice for such kind of files, it should be >>>> either $HOME or tmp. >>> >>> And we hardwired /tmp and stopped using cwd under >>> >>> https://bugs.openjdk.java.net/browse/JDK-7132199 >>> >>> So I'm a bit confused as to how this has evolved back into using cwd. ?? >> Yeah, I had this backwards with my earlier comment. Before JDK-7132199 >> we actually do it the way we do now, trying cwd first, and then tmp if >> it fails. JDK-7132199 made it only use tmp, but only for >> findSocketFile(). createAttachFile() still tries cwd first and then >> tmp, and I see nothing in the history to indicate this was ever >> changed, other than to force the location of tmp to /tmp with >> JDK-6950927. >> >> So the question is do we get rid of the cwd support and always use >> tmp? If yes, I think it's best not to do that as part of this CR. I'd >> rather just add the docker /tmp support to createAttachFile() now, and >> have a separate CR deal with removing all cwd support (or maybe even >> push changes for it before the docker support fix). > Here's an updated webrev with the tmpdir fix in createAttachFile(): > > http://cr.openjdk.java.net/~cjplummer/8179498/webrev.02/webrev_jdk/ > > I ran all the same tests again, including testing with docker. To make > sure it was hitting the tmpdir code, I forced the cwd code to error out > by making it use cwdX instead. > > There are also two other changes to fix an issue I noticed when you > provide a bad pid. You are suppose to get an error message like this: > > java.io.IOException: No such process > ??? at jdk.attach/sun.tools.attach.VirtualMachineImpl.sendQuitTo(Native > Method) > ??? at > jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:80) > > ??? at > jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) > > ??? at > jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) > > ??? at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:114) > ??? at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:98) > > However, I was seeing the following due to the docker related changes: > > java.nio.file.NoSuchFileException: /proc/7777/status > ??? at > java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) > > ??? at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) > > ??? at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) > > ??? at > java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:215) > > ??? at java.base/java.nio.file.Files.newByteChannel(Files.java:369) > ??? at java.base/java.nio.file.Files.newByteChannel(Files.java:415) > ??? at > java.base/java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384) > > ??? at java.base/java.nio.file.Files.newInputStream(Files.java:154) > ??? at java.base/java.nio.file.Files.newBufferedReader(Files.java:2830) > ??? at java.base/java.nio.file.Files.readAllLines(Files.java:3260) > ??? at > jdk.attach/sun.tools.attach.VirtualMachineImpl.getNamespacePid(VirtualMachineImpl.java:334) > > ??? at > jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:71) > > ??? at > jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) > > ??? at > jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) > > ??? at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:114) > ??? at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:98) > > I fixed getNamespacePid() to validate that /proc//status exists > before trying to process it. If it doesn't, it just returns pid rather > than trying to find ns_pid. However, that led to: > > java.io.IOException: No such file or directory > ??? at java.base/java.io.UnixFileSystem.createFileExclusively(Native > Method) > ??? at java.base/java.io.File.createNewFile(File.java:1024) > ??? at > jdk.attach/sun.tools.attach.VirtualMachineImpl.createAttachFile(VirtualMachineImpl.java:300) > > ??? at > jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:78) > > ??? at > jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) > > ??? at > jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) > > ??? at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:114) > ??? at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:98) > > This is because createAttachFile() first tried to create the file in > /proc//cwd, and after that failed with IOException (which is > caught), it tried in /proc//root/tmp, which fails with the above > uncaught IOException. I changed the code to only try > /proc//root/tmp if pid != ns_pid (which means either it is a docker > situation and the pid is valid). Otherwise it reverts to the old > behavior just using /tmp. This all seems okay. One suggestion: 359 } catch (NumberFormatException | IOException x) { 360 throw new AttachNotSupportedException("Unable to parse namespace"); 361 } Set "x" as the cause of the AttachNotSupportedException before throwing it. That will give more diagnostics if we ever see this exception. Thans, David > thanks, > > Chris >> >> thanks, >> >> Chris >>> >>> David >>> >>> >>>> -Dmitry >>>> >>>> On 14.09.2017 07:15, Chris Plummer wrote: >>>>> On 9/13/17 9:00 PM, David Holmes wrote: >>>>>> Hi Chris, >>>>>> >>>>>> On 14/09/2017 1:03 PM, Chris Plummer wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On 9/13/17 5:12 PM, David Holmes wrote: >>>>>>>> Hi Chris, >>>>>>>> >>>>>>>> On 14/09/2017 8:23 AM, Chris Plummer wrote: >>>>>>>>> I could use one more reviewer. >>>>>>>> >>>>>>>> Generally this seems okay to me. >>>>>>>> >>>>>>>> One query though ... in createAttachFile don't you need to alter >>>>>>>> the >>>>>>>> tmpdir using part in a similar manner to how findSocketFile was >>>>>>>> modified? >>>>>>> The fix in findSocketFile is not just to make sure the client uses >>>>>>> the correct pid in the .java_pid file files, but also (as you point >>>>>>> out) to make sure that the client properly references the target >>>>>>> jvm's tmp directory when accessing the .java_pid file. >>>>>>> findSocketFile >>>>>>> is a little >>>>>> >>>>>> I presume you mean createAttachFile there. >>>>> Yes. >>>>>> >>>>>>> different. You still have to map to the proper from pid to ns_pid >>>>>>> when referencing the .attach_pid file, but you don't have the /tmp >>>>>>> mount point differences to deal with. /proc//cwd should work >>>>>>> even if the pid is for a docker. You don't even have to map to the >>>>>>> pid as the docker sees it. /proc//cwd from the client's POV >>>>>>> should be the same as /proc//cwd from the target JVM's POV. >>>>>> >>>>>> Sorry but I don't follow. If findSocketFile has to look in >>>>>> /proc//root/ for the socket file, why does the >>>>>> createAttachFile not also have to write the attach file into >>>>>> /proc//root/ ?? In both cases it needs to find the >>>>>> tmpdir >>>>>> of the target process. >>>>> Fortunately I have some old printlns that might help: >>>>> >>>>> ***getNamespacePid - ns_pid: 125 >>>>> ***findSocketFile - f: /proc/24445/root/tmp/.java_pid125 >>>>> ***createAttachFile - path: /proc/24445/cwd/.attach_pid125 >>>>> >>>>> So this is a case where the real pid is 24445, but the namespace >>>>> pid in >>>>> the docker is 125. The docker can (and does) reference >>>>> /tmp/.java_pid125, but the client needs to reference >>>>> /proc/24445/root/tmp/.java_pid125 to get to the same file. For >>>>> .attach_pid125, the client can get to it through >>>>> /proc/24445/cwd/.attach_pid125, and the docker process will look in >>>>> cwd >>>>> for the file. This is done in AttachListener::is_init_trigger(). >>>>> >>>>> BTW, comments like the following are no longer correct due to >>>>> JDK-7132199: >>>>> >>>>> ???? // "/tmp" is used as a global well-known location for the files >>>>> ???? // .java_pid. and .attach_pid. It is important that >>>>> this >>>>> ???? // location is the same for all processes, otherwise the tools >>>>> ???? // will not be able to find all Hotspot processes. >>>>> ???? // Any changes to this needs to be synchronized with HotSpot. >>>>> ???? private static final String tmpdir = "/tmp"; >>>>> >>>>> So now .attach_pid is always created in cwd as you can see in >>>>> createAttachFile(), although AttachListener::is_init_trigger() does >>>>> check tmp, but only after cwd. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>>> >>>>>>>> Minor note - you can collapse your catch blocks into 1 using >>>>>>>> something like >>>>>>>> >>>>>>>> ??????? } catch (NumberFormatException | IOException x) { >>>>>>>> ???????????? throw new AttachNotSupportedException("Unable to parse >>>>>>>> namespace"); >>>>>>>> ??????? } >>>>>>> I'll make that change. >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>>> thanks, >>>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>>> On 9/11/17 8:03 PM, Chris Plummer wrote: >>>>>>>>>> Ok, I will. Thanks. >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> On 9/11/17 6:13 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Hi Chris, >>>>>>>>>>> >>>>>>>>>>> This looks good to me. >>>>>>>>>>> >>>>>>>>>>> I'm not sure if all the nsk.aod and the AttachOnDemand tests >>>>>>>>>>> from >>>>>>>>>>> the nsk.jvmti are run in the hotspot tier1, 2, and 3 tests. >>>>>>>>>>> It makes sense to double-check it. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 9/10/17 20:34, Chris Plummer wrote: >>>>>>>>>>>> [re-sending - sent to wrong alias first time] >>>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Please review the following: >>>>>>>>>>>> >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8179498 >>>>>>>>>>>> http://cr.openjdk.java.net/~cjplummer/8179498/webrev.00/webrev_jdk/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The CR has the relevant details. Some previous discussions can >>>>>>>>>>>> be found here: >>>>>>>>>>>> >>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/021237.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-May/021249.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021679.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Testing with docker has been limited to just making sure jcmd >>>>>>>>>>>> now works with the docker setup I was provided. I currently >>>>>>>>>>>> don't see how we can run our existing tests in a way that would >>>>>>>>>>>> test the docker support without doing some rewriting of the >>>>>>>>>>>> tests. >>>>>>>>>>>> >>>>>>>>>>>> I also ran all our hotspot tier1, 2, and 3 tests, along with >>>>>>>>>>>> jdk/test/tools and jdk/test/sun/tools tests to make sure >>>>>>>>>>>> existing functionality is not broken with these changes. >>>>>>>>>>>> >>>>>>>>>>>> thanks, >>>>>>>>>>>> >>>>>>>>>>>> Chris >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>>> >> >> > > From jini.george at oracle.com Mon Sep 18 10:01:38 2017 From: jini.george at oracle.com (Jini George) Date: Mon, 18 Sep 2017 15:31:38 +0530 Subject: RFR: SA: MacOS X: 8184042: several serviceability/sa tests timed out on MacOS X In-Reply-To: References: <69512c98-57d1-01c0-d8d1-674024776a11@oracle.com> Message-ID: Thanks very much, Poonam, for this. My comments inline. On 9/16/2017 1:18 AM, Poonam Parhar wrote: > Hello Jini, > > I don't know much about the mach exceptions either. I read through your > wiki page and looked at the relevant gdb and lldb code to understand how > it works. > > A few points regarding the changes for this CR: > > File: src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m > > 1. In the lldb code, a separate thread is being used to catch and handle > the mach exceptions. I am assuming we don't need to do that since we use > the mach exceptions mechanism only during the attach process, and after > which we suspend all the threads in the target process.Is that correct? Yes. > > 823 if (result != KERN_SUCCESS) { > 824 print_error("attach: mach_port_allocate() failed: '%s' (%d)\n", > 825 mach_error_string(result), result); > > For all the mach calls in this function, would it make sense to print > the exception_port as well while reporting errors to make is easier to > debug the attach failures. Will do. > > 3. > 843 result = task_get_exception_ports(gTask, 844 EXC_MASK_ALL, 845 > saved_masks, 846 &saved_exception_types_count, 847 saved_ports, 848 > saved_behaviors, 849 saved_flavors); > > A comment for this call explaining why we are getting and saving the > exceptions info here would be good. e.g. we need to restore the > exceptions state for the process when we detach from it. Makes sense. Will do. > 4. It would make the code look cleaner to have all these exception > details that we need to save as the fields of a structure. Will do. > > 5. /tgt_exception_port/ and /saved_exception_types_count/ are saved on > the Java side, but /saved_masks, //saved_ports, //saved_behaviors and > //saved_flavors/ are defined as static on the native side. All of these > values are process specific, and are needed when we detach from a > process. Why are these being treated differently? "tgt_exception_port" and "saved_exception_types_count" can also be moved to the native side -- will do this. Looks like this would apply to "symbolicator" and "task" too. Thanks, Jini. > > Thanks, > Poonam > > > On 9/14/2017 8:17 PM, Jini George wrote: >> Thanks much, Dan. >> >> -Jini. >> >> On 9/15/2017 4:18 AM, Daniel D. Daugherty wrote: >>> On 8/18/17 4:00 AM, Jini George wrote: >>>> Hi all, >>>> >>>> Requesting reviews for: https://bugs.openjdk.java.net/browse/JDK-8184042 >>>> >>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/ >>> >>> hotspot/src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m >>> L832: result = mach_port_insert_right (mach_task_self(), >>> Nit - extra blank before '(' >>> >>> L860-863 - nit - indents don't match the other func calls. >>> >>> I read through all the changes and looked at logic flow, error >>> returns, variable usage, etc. The problem is I'm not conversant >>> in Mach exception programming so there could easily be things >>> that I missed here. >>> >>> You really need to have a MacOS X person look at these changes >>> also. >>> >>> hotspot/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java >>> No comments. >>> >>> hotspot/src/jdk.hotspot.agent/macosx/native/libsaproc/mach_exc.h >>> hotspot/src/jdk.hotspot.agent/macosx/native/libsaproc/mach_excServer.c >>> hotspot/src/jdk.hotspot.agent/macosx/native/libsaproc/mach_excUser.c >>> These files are generated by a tool and will be replaced >>> by build changes. I didn't review them. >>> >>> hotspot/test/serviceability/sa/TestAttachDetach.java >>> L35: import java.util.ArrayList; >>> L36: import java.util.List; >>> L37: import java.util.Arrays; >>> L38: import java.util.Optional; >>> L40: import jdk.test.lib.Utils; >>> L41: import jdk.test.lib.process.OutputAnalyzer; >>> L42: import jdk.test.lib.process.ProcessTools; >>> These imports do not seem to be needed. >>> >>> L45: import jdk.test.lib.JDKToolLauncher; >>> Duplicate import. >>> >>> L98: "The String 'Attaching to >>> process' appears " + >>> L99: numberOfMatches + " number of >>> times"); >>> Would be helpful to include the expected value also. >>> >>> jdk/test/ProblemList.txt >>> Thanks for remembering to update the ProblemList.txt file! >>> >>> I don't have any comments other than nits. However, I don't >>> know mach exceptions so I can't really do a functional review. >>> >>> We need someone that knows MacOS X mach exceptions to chime >>> in on this thread. I'm adding Gerard Z to this review thread >>> in the hopes that he can help... >>> >>> Dan >>> >>> >>>> >>>> Problem gist: The deprecated ptrace() command, PT_ATTACH was changed >>>> to PT_ATTACHEXC, which causes mach exceptions (and not UNIX signals) >>>> to be delivered via mach messages.This caused SA to hang at >>>> waitpid() waiting for a signal, which does not arrive. >>>> >>>> Solution in a nutshell: The solution is to make the required changes >>>> to handle mach 'soft signal' exceptions in the form of mach messages >>>> instead of signals, while attaching to and detaching from the target >>>> process. The detailed steps are outlined in JBS. >>>> >>>> The changes appear huge due to the inclusion of pre-generated mach >>>> exception handling files (mach_exc*). Since this is an integration >>>> blocker, it would be great to get quick reviews on this. >>>> >>>> Thank you, >>>> Jini. >>>> >>>> >>>> >>>> >>>> >>>> >>> >> > From robbin.ehn at oracle.com Mon Sep 18 13:14:17 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 18 Sep 2017 15:14:17 +0200 Subject: RFR: JDK-8187597: WrongTypeException is occurred at CLHSDB jstack after JDK-8186837 In-Reply-To: <6f369ad1-ee23-32b1-37ae-3bb60629960c@gmail.com> References: <39e4a81a-0a12-1ee7-dedb-0b9853d89fce@gmail.com> <6f369ad1-ee23-32b1-37ae-3bb60629960c@gmail.com> Message-ID: Hi, FYI: It's been long since duke: 0: nonstatic_field(nmethod, _stack_traversal_mark, long) \ It's now also volatile. The correct type should/could probably be some like (u)int_fast32_t/intx or whatever. If there is an issue with variable length types in vmStructs we have had that issue for very long AFAICT. But looking at error message below: field "_stack_traversal_mark" in type nmethod is not of type jlong, but instead of type long It was jlong for about a month until I reverted that change (back to long but volatile). So it looks like you are running tools from an older build with a newer vm or something like that ? /Robbin On 09/17/2017 10:13 AM, Yasumasa Suenaga wrote: > Hi Chris, > > I've tested this issue on Fedora 26 x86_64. > I think we can sue CIntegerField at this point because CIntegerField is not specialized for various int size [1]. > In fact, CIntegerField had been used at this point [2], and HSDB worked fine. > > > Thanks, > > Yasumasa > > > [1] http://hg.openjdk.java.net/jdk10/master/file/fd36993f7bf5/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/CIntegerField.java#l29 > [2] http://hg.openjdk.java.net/jdk10/master/rev/cbfdbefc6ea3 > > > On 2017/09/17 3:58, Chris Plummer wrote: >> Hi Yasumasa, >> >> Is this on a 32-bit system? I don't see how you could otherwise call getCIntegerField() on a long type. jlong is always 64-bit and long is (generally) 32-bit on 32-bit >> systems, and 64-bit on 64-bit systems, at least that seems to be the case with linux. >> >> ?From what I can see, _stack_traversal_mark is now the only long type in vmStructs.cpp. I don't know that we have a mechanism to safely fetch it on both 32-bit and 64-bit >> systems. >> >> _stack_traversal_mark seems to be a long because _traversals is also a long. >> >> ?? ? static long????? _traversals;?????????????????? // Stack scan count, also sweep ID. >> >> This too might be considered a bug. I'm not sure why you would want the size of this field to vary between 32-bit and 64-bit systems (adding compiler-dev to help answer >> that). >> >> So, while I would agree that your fix is generally in the right direction, I think we first need to revisit the use of long for these fields. If they can be changed to an >> int, then your fix is correct (pending the changes to int). If not, then maybe we need getCLongField() support. >> >> And lastly, we really should have a test to detect this bug. Maybe we already do, and it is failing but is going unnoticed for some reason. I'll try to look into that >> some more on Monday. >> >> thanks, >> >> Chris >> >> On 9/16/17 5:20 AM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I tried to get thread dump via jstack command on CLHSDB. But it was failed as below: >>> >>> ``` >>> Caused by: sun.jvm.hotspot.types.WrongTypeException: field "_stack_traversal_mark" in type nmethod is not of type jlong, but instead of type long >>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:206) >>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:212) >>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getJLongField(BasicType.java:249) >>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.initialize(NMethod.java:108) >>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.access$000(NMethod.java:35) >>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod$1.update(NMethod.java:81) >>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:451) >>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.(NMethod.java:79) >>> ??????? ... 23 more >>> ``` >>> >>> I think this exception is caused by JDK-8186837. >>> This changeset has changed the type of `nmethod::_stack_traversal_mark` to `long` from `jlong`. >>> >>> SA should follow this change. >>> >>> I uploaded a webrev for this issue. This webrev is generated from consolidated repo (jdk10/master). >>> Could you review it? >>> >>> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.00/ >>> >>> >>> I cannot access JPRT. So I need reviewer. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >> >> From yasuenag at gmail.com Mon Sep 18 13:54:44 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 18 Sep 2017 22:54:44 +0900 Subject: RFR: JDK-8187597: WrongTypeException is occurred at CLHSDB jstack after JDK-8186837 In-Reply-To: References: <39e4a81a-0a12-1ee7-dedb-0b9853d89fce@gmail.com> <6f369ad1-ee23-32b1-37ae-3bb60629960c@gmail.com> Message-ID: > So it looks like you are running tools from an older build with a newer vm or something like that ? No. I've applied this change to changeset 47219. ---------------- changeset: 47219:fd36993f7bf5 tag: tip user: ihse date: Fri Sep 15 09:18:00 2017 -0700 summary: 8187542: Remove superfluous *_TOPDIR variables ---------------- I've tested jshell and HSDB from this source. Yasumasa On 2017/09/18 22:14, Robbin Ehn wrote: > Hi, > > FYI: It's been long since duke: > > ?? 0:?? nonstatic_field(nmethod,???????????? _stack_traversal_mark,???????????????????????? long)????????????????????????????????? \ > > It's now also volatile. > > The correct type should/could probably be some like (u)int_fast32_t/intx or whatever. > > If there is an issue with variable length types in vmStructs we have had that issue for very long AFAICT. > > But looking at error message below: > field "_stack_traversal_mark" in type nmethod is not of type jlong, but instead of type long > > It was jlong for about a month until I reverted that change (back to long but volatile). > So it looks like you are running tools from an older build with a newer vm or something like that ? > > /Robbin > > On 09/17/2017 10:13 AM, Yasumasa Suenaga wrote: >> Hi Chris, >> >> I've tested this issue on Fedora 26 x86_64. >> I think we can sue CIntegerField at this point because CIntegerField is not specialized for various int size [1]. >> In fact, CIntegerField had been used at this point [2], and HSDB worked fine. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] http://hg.openjdk.java.net/jdk10/master/file/fd36993f7bf5/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/CIntegerField.java#l29 >> [2] http://hg.openjdk.java.net/jdk10/master/rev/cbfdbefc6ea3 >> >> >> On 2017/09/17 3:58, Chris Plummer wrote: >>> Hi Yasumasa, >>> >>> Is this on a 32-bit system? I don't see how you could otherwise call getCIntegerField() on a long type. jlong is always 64-bit and long is (generally) 32-bit on 32-bit systems, and 64-bit on 64-bit systems, at least that seems to be the case with linux. >>> >>> ?From what I can see, _stack_traversal_mark is now the only long type in vmStructs.cpp. I don't know that we have a mechanism to safely fetch it on both 32-bit and 64-bit systems. >>> >>> _stack_traversal_mark seems to be a long because _traversals is also a long. >>> >>> ?? ? static long????? _traversals;?????????????????? // Stack scan count, also sweep ID. >>> >>> This too might be considered a bug. I'm not sure why you would want the size of this field to vary between 32-bit and 64-bit systems (adding compiler-dev to help answer that). >>> >>> So, while I would agree that your fix is generally in the right direction, I think we first need to revisit the use of long for these fields. If they can be changed to an int, then your fix is correct (pending the changes to int). If not, then maybe we need getCLongField() support. >>> >>> And lastly, we really should have a test to detect this bug. Maybe we already do, and it is failing but is going unnoticed for some reason. I'll try to look into that some more on Monday. >>> >>> thanks, >>> >>> Chris >>> >>> On 9/16/17 5:20 AM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> I tried to get thread dump via jstack command on CLHSDB. But it was failed as below: >>>> >>>> ``` >>>> Caused by: sun.jvm.hotspot.types.WrongTypeException: field "_stack_traversal_mark" in type nmethod is not of type jlong, but instead of type long >>>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:206) >>>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:212) >>>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getJLongField(BasicType.java:249) >>>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.initialize(NMethod.java:108) >>>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.access$000(NMethod.java:35) >>>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod$1.update(NMethod.java:81) >>>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:451) >>>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.(NMethod.java:79) >>>> ??????? ... 23 more >>>> ``` >>>> >>>> I think this exception is caused by JDK-8186837. >>>> This changeset has changed the type of `nmethod::_stack_traversal_mark` to `long` from `jlong`. >>>> >>>> SA should follow this change. >>>> >>>> I uploaded a webrev for this issue. This webrev is generated from consolidated repo (jdk10/master). >>>> Could you review it? >>>> >>>> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.00/ >>>> >>>> >>>> I cannot access JPRT. So I need reviewer. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>> >>> From robbin.ehn at oracle.com Mon Sep 18 14:14:14 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 18 Sep 2017 16:14:14 +0200 Subject: RFR: JDK-8187597: WrongTypeException is occurred at CLHSDB jstack after JDK-8186837 In-Reply-To: References: <39e4a81a-0a12-1ee7-dedb-0b9853d89fce@gmail.com> <6f369ad1-ee23-32b1-37ae-3bb60629960c@gmail.com> Message-ID: Hi, I missed that there was another commit to revert. (obviously if we have jlong here and it is long you will get that exception but there might be an old bug regrading long 32/64, e.g. CInt) Your fix looks correct, thanks for fixing! /Robbin [rehn at rehn-ws hotspot]$ hg log -r13303 -p changeset: 13303:777b211c54ba parent: 13301:681389dce7a6 user: rkennke date: Mon Jul 24 17:14:32 2017 +0200 summary: 8185102: TestSAServer.java fails due to "sun.jvm.hotspot.types.WrongTypeException: field "_stack_traversal_mark" diff -r 681389dce7a6 -r 777b211c54ba src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java Mon Jul 24 09:32:35 2017 -0400 +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java Mon Jul 24 17:14:32 2017 +0200 @@ -71,7 +71,7 @@ stack. An not_entrant method can be removed when there is no more activations, i.e., when the _stack_traversal_mark is less than current sweep traversal index. */ - private static CIntegerField stackTraversalMarkField; + private static JLongField stackTraversalMarkField; private static CIntegerField compLevelField; @@ -105,7 +105,7 @@ verifiedEntryPointField = type.getAddressField("_verified_entry_point"); osrEntryPointField = type.getAddressField("_osr_entry_point"); lockCountField = type.getJIntField("_lock_count"); - stackTraversalMarkField = type.getCIntegerField("_stack_traversal_mark"); + stackTraversalMarkField = type.getJLongField("_stack_traversal_mark"); compLevelField = type.getCIntegerField("_comp_level"); pcDescSize = db.lookupType("PcDesc").getSize(); } On 09/18/2017 03:54 PM, Yasumasa Suenaga wrote: >> So it looks like you are running tools from an older build with a newer vm or something like that ? > > No. I've applied this change to changeset 47219. > ---------------- > changeset:?? 47219:fd36993f7bf5 > tag:???????? tip > user:??????? ihse > date:??????? Fri Sep 15 09:18:00 2017 -0700 > summary:???? 8187542: Remove superfluous *_TOPDIR variables > ---------------- > > I've tested jshell and HSDB from this source. > > > Yasumasa > > > On 2017/09/18 22:14, Robbin Ehn wrote: >> Hi, >> >> FYI: It's been long since duke: >> >> ??? 0:?? nonstatic_field(nmethod,???????????? _stack_traversal_mark,???????????????????????? long)????????????????????????????????? \ >> >> It's now also volatile. >> >> The correct type should/could probably be some like (u)int_fast32_t/intx or whatever. >> >> If there is an issue with variable length types in vmStructs we have had that issue for very long AFAICT. >> >> But looking at error message below: >> field "_stack_traversal_mark" in type nmethod is not of type jlong, but instead of type long >> >> It was jlong for about a month until I reverted that change (back to long but volatile). >> So it looks like you are running tools from an older build with a newer vm or something like that ? >> >> /Robbin >> >> On 09/17/2017 10:13 AM, Yasumasa Suenaga wrote: >>> Hi Chris, >>> >>> I've tested this issue on Fedora 26 x86_64. >>> I think we can sue CIntegerField at this point because CIntegerField is not specialized for various int size [1]. >>> In fact, CIntegerField had been used at this point [2], and HSDB worked fine. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] http://hg.openjdk.java.net/jdk10/master/file/fd36993f7bf5/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/CIntegerField.java#l29 >>> [2] http://hg.openjdk.java.net/jdk10/master/rev/cbfdbefc6ea3 >>> >>> >>> On 2017/09/17 3:58, Chris Plummer wrote: >>>> Hi Yasumasa, >>>> >>>> Is this on a 32-bit system? I don't see how you could otherwise call getCIntegerField() on a long type. jlong is always 64-bit and long is (generally) 32-bit on 32-bit >>>> systems, and 64-bit on 64-bit systems, at least that seems to be the case with linux. >>>> >>>> ?From what I can see, _stack_traversal_mark is now the only long type in vmStructs.cpp. I don't know that we have a mechanism to safely fetch it on both 32-bit and >>>> 64-bit systems. >>>> >>>> _stack_traversal_mark seems to be a long because _traversals is also a long. >>>> >>>> ?? ? static long????? _traversals;?????????????????? // Stack scan count, also sweep ID. >>>> >>>> This too might be considered a bug. I'm not sure why you would want the size of this field to vary between 32-bit and 64-bit systems (adding compiler-dev to help answer >>>> that). >>>> >>>> So, while I would agree that your fix is generally in the right direction, I think we first need to revisit the use of long for these fields. If they can be changed to >>>> an int, then your fix is correct (pending the changes to int). If not, then maybe we need getCLongField() support. >>>> >>>> And lastly, we really should have a test to detect this bug. Maybe we already do, and it is failing but is going unnoticed for some reason. I'll try to look into that >>>> some more on Monday. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 9/16/17 5:20 AM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> I tried to get thread dump via jstack command on CLHSDB. But it was failed as below: >>>>> >>>>> ``` >>>>> Caused by: sun.jvm.hotspot.types.WrongTypeException: field "_stack_traversal_mark" in type nmethod is not of type jlong, but instead of type long >>>>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:206) >>>>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:212) >>>>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getJLongField(BasicType.java:249) >>>>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.initialize(NMethod.java:108) >>>>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.access$000(NMethod.java:35) >>>>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod$1.update(NMethod.java:81) >>>>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:451) >>>>> ??????? at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.(NMethod.java:79) >>>>> ??????? ... 23 more >>>>> ``` >>>>> >>>>> I think this exception is caused by JDK-8186837. >>>>> This changeset has changed the type of `nmethod::_stack_traversal_mark` to `long` from `jlong`. >>>>> >>>>> SA should follow this change. >>>>> >>>>> I uploaded a webrev for this issue. This webrev is generated from consolidated repo (jdk10/master). >>>>> Could you review it? >>>>> >>>>> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.00/ >>>>> >>>>> >>>>> I cannot access JPRT. So I need reviewer. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>> >>>> From jcbeyler at google.com Mon Sep 18 17:45:14 2017 From: jcbeyler at google.com (JC Beyler) Date: Mon, 18 Sep 2017 10:45:14 -0700 Subject: When does MONITOR_WAITED get thrown? Message-ID: Hi all, When looking at the documentation of https://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#MonitorWaited , I see the following description: "Sent when a thread finishes waiting on an object." However, there seems to be a slight issue when the MONITOR_WAIT event handler throws an exception. Consider the following code: A) The monitor wait handler throws static void JNICALL monitor_wait(jvmtiEnv* jvmti, JNIEnv *env, jthread thread, jobject object, jlong timeout) { fprintf(stderr, "Waiting!\n"); jclass newExcCls = env->FindClass("java/lang/IllegalArgumentException"); // Unable to find the new exception class, give up. if (newExcCls == 0) { return; } env->ThrowNew(newExcCls, "Exception from monitor_wait"); } B) The monitor waited handler does a printf: static void JNICALL monitor_waited(jvmtiEnv* jvmti, JNIEnv *env, jthread thread, jobject object, jboolean timed_out) { fprintf(stderr, "Waited!\n"); } B) A second thread that will be asked to wait: class SecondThread extends Thread { public void run() { try { Thread.sleep(1); } catch(Exception e) { } System.out.println("Hello from A"); } } C) The main thread with the wait: class Main extends Thread { public static void main(String[] args) { SecondThread st = new SecondThread(); synchronized (st) { st.start(); try { st.wait(); } catch(InterruptedException e) { System.out.println("Exception caught!"); } } System.out.println("Done"); } } D) If I do this, what happens is that I get: Waiting! Waited! Exception in thread "main" java.lang.IllegalArgumentException: Exception from monitor_wait at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at Main.main(Main.java:9) Hello from A - As we see, we get the print out from waiting, print out from waited and then the exception in the waiting. E) If instead, we do st.wait(-100) in the main method, we get: Waiting! Exception in thread "main" java.lang.IllegalArgumentException: Exception from monitor_wait at java.lang.Object.wait(Native Method) at Main.main(Main.java:9) Hello from A Notes: the stack is slightly different, the printout waited is no longer there however F) If finally, we don't throw in the waiting handler but leave the st.wait(-100) in place: Waiting! Exception in thread "main" java.lang.IllegalArgumentException: timeout value is negative at java.lang.Object.wait(Native Method) at Main.main(Main.java:9) Hello from A The question thus becomes: is this normal that there is a slight difference between D/E/F? Should we try to fix it to have a single behavior in the three cases, and if so, which would be the behavior that should be the default? Let me know if you would like to see a full code to easily replicate, I gave the big parts but left out the Agent_OnLoad method for example. Thanks! Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Mon Sep 18 18:11:18 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 18 Sep 2017 11:11:18 -0700 Subject: RFR(10)(M): 8179498: attach in linux should be relative to /proc/pid/root and namespace aware In-Reply-To: References: <6434ed9c-7ea0-fe2d-d185-eca74c06ea0b@oracle.com> <27b7a7af-e95b-4b36-5808-be8607f1b30b@oracle.com> <4436414c-6bbf-d173-3e23-e1fb7deec3f1@oracle.com> <7574486e-124d-ffe1-df36-1c7911844cde@oracle.com> <08bf2b33-53bf-c168-01b5-dc3d71b2f7b1@oracle.com> <630e7085-46d7-eaa2-72f7-268ddce1bda7@oracle.com> <14c9e33c-abf8-82f2-ef5d-89c306fa3cc0@samersoff.net> <2e7a873e-a2c3-a8e5-2c02-8acc7d7e03bb@oracle.com> <804bdbc6-cce5-2b1e-9e46-8e5ca9143427@oracle.com> <481f824e-24c3-98b9-c7e2-8501249070ec@oracle.com> Message-ID: On 9/17/17 5:17 PM, David Holmes wrote: > Hi Chris, > > On 15/09/2017 2:19 PM, Chris Plummer wrote: >> On 9/14/17 9:56 AM, Chris Plummer wrote: >>> On 9/14/17 1:45 AM, David Holmes wrote: >>>> On 14/09/2017 5:53 PM, Dmitry Samersoff wrote: >>>>> Chris, >>>>> >>>>>> So now .attach_pid is always created in cwd as you can see in >>>>>> createAttachFile(), although AttachListener::is_init_trigger() does >>>>>> check tmp, but only after cwd. >>>>> >>>>>> ***getNamespacePid - ns_pid: 125 >>>>>> ***findSocketFile - f: /proc/24445/root/tmp/.java_pid125 >>>>>> ***createAttachFile - path: /proc/24445/cwd/.attach_pid125 >>>>> >>>>> Could we always use tmp ? >>>>> >>>>> IMHO cwd is not a right choice for such kind of files, it should be >>>>> either $HOME or tmp. >>>> >>>> And we hardwired /tmp and stopped using cwd under >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-7132199 >>>> >>>> So I'm a bit confused as to how this has evolved back into using >>>> cwd. ?? >>> Yeah, I had this backwards with my earlier comment. Before >>> JDK-7132199 we actually do it the way we do now, trying cwd first, >>> and then tmp if it fails. JDK-7132199 made it only use tmp, but only >>> for findSocketFile(). createAttachFile() still tries cwd first and >>> then tmp, and I see nothing in the history to indicate this was ever >>> changed, other than to force the location of tmp to /tmp with >>> JDK-6950927. >>> >>> So the question is do we get rid of the cwd support and always use >>> tmp? If yes, I think it's best not to do that as part of this CR. >>> I'd rather just add the docker /tmp support to createAttachFile() >>> now, and have a separate CR deal with removing all cwd support (or >>> maybe even push changes for it before the docker support fix). >> Here's an updated webrev with the tmpdir fix in createAttachFile(): >> >> http://cr.openjdk.java.net/~cjplummer/8179498/webrev.02/webrev_jdk/ >> >> I ran all the same tests again, including testing with docker. To >> make sure it was hitting the tmpdir code, I forced the cwd code to >> error out by making it use cwdX instead. >> >> There are also two other changes to fix an issue I noticed when you >> provide a bad pid. You are suppose to get an error message like this: >> >> java.io.IOException: No such process >> ???? at >> jdk.attach/sun.tools.attach.VirtualMachineImpl.sendQuitTo(Native Method) >> ???? at >> jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:80) >> >> ???? at >> jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) >> >> ???? at >> jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) >> >> ???? at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:114) >> ???? at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:98) >> >> However, I was seeing the following due to the docker related changes: >> >> java.nio.file.NoSuchFileException: /proc/7777/status >> ???? at >> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) >> >> ???? at >> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) >> >> ???? at >> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) >> >> ???? at >> java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:215) >> >> ???? at java.base/java.nio.file.Files.newByteChannel(Files.java:369) >> ???? at java.base/java.nio.file.Files.newByteChannel(Files.java:415) >> ???? at >> java.base/java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384) >> >> ???? at java.base/java.nio.file.Files.newInputStream(Files.java:154) >> ???? at java.base/java.nio.file.Files.newBufferedReader(Files.java:2830) >> ???? at java.base/java.nio.file.Files.readAllLines(Files.java:3260) >> ???? at >> jdk.attach/sun.tools.attach.VirtualMachineImpl.getNamespacePid(VirtualMachineImpl.java:334) >> >> ???? at >> jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:71) >> >> ???? at >> jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) >> >> ???? at >> jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) >> >> ???? at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:114) >> ???? at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:98) >> >> I fixed getNamespacePid() to validate that /proc//status exists >> before trying to process it. If it doesn't, it just returns pid >> rather than trying to find ns_pid. However, that led to: >> >> java.io.IOException: No such file or directory >> ???? at java.base/java.io.UnixFileSystem.createFileExclusively(Native >> Method) >> ???? at java.base/java.io.File.createNewFile(File.java:1024) >> ???? at >> jdk.attach/sun.tools.attach.VirtualMachineImpl.createAttachFile(VirtualMachineImpl.java:300) >> >> ???? at >> jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:78) >> >> ???? at >> jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) >> >> ???? at >> jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) >> >> ???? at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:114) >> ???? at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:98) >> >> This is because createAttachFile() first tried to create the file in >> /proc//cwd, and after that failed with IOException (which is >> caught), it tried in /proc//root/tmp, which fails with the above >> uncaught IOException. I changed the code to only try >> /proc//root/tmp if pid != ns_pid (which means either it is a >> docker situation and the pid is valid). Otherwise it reverts to the >> old behavior just using /tmp. > Hi David, > This all seems okay. > > One suggestion: > > ?359???????? } catch (NumberFormatException | IOException x) { > ?360???????????? throw new AttachNotSupportedException("Unable to > parse namespace"); > ?361???????? } > > Set "x" as the cause of the AttachNotSupportedException before > throwing it. That will give more diagnostics if we ever see this > exception. Ok. I'll make this change. thanks, Chris > > Thans, > David > >> thanks, >> >> Chris >>> >>> thanks, >>> >>> Chris >>>> >>>> David >>>> >>>> >>>>> -Dmitry >>>>> >>>>> On 14.09.2017 07:15, Chris Plummer wrote: >>>>>> On 9/13/17 9:00 PM, David Holmes wrote: >>>>>>> Hi Chris, >>>>>>> >>>>>>> On 14/09/2017 1:03 PM, Chris Plummer wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> On 9/13/17 5:12 PM, David Holmes wrote: >>>>>>>>> Hi Chris, >>>>>>>>> >>>>>>>>> On 14/09/2017 8:23 AM, Chris Plummer wrote: >>>>>>>>>> I could use one more reviewer. >>>>>>>>> >>>>>>>>> Generally this seems okay to me. >>>>>>>>> >>>>>>>>> One query though ... in createAttachFile don't you need to >>>>>>>>> alter the >>>>>>>>> tmpdir using part in a similar manner to how findSocketFile was >>>>>>>>> modified? >>>>>>>> The fix in findSocketFile is not just to make sure the client uses >>>>>>>> the correct pid in the .java_pid file files, but also (as you >>>>>>>> point >>>>>>>> out) to make sure that the client properly references the target >>>>>>>> jvm's tmp directory when accessing the .java_pid file. >>>>>>>> findSocketFile >>>>>>>> is a little >>>>>>> >>>>>>> I presume you mean createAttachFile there. >>>>>> Yes. >>>>>>> >>>>>>>> different. You still have to map to the proper from pid to ns_pid >>>>>>>> when referencing the .attach_pid file, but you don't have the /tmp >>>>>>>> mount point differences to deal with. /proc//cwd should work >>>>>>>> even if the pid is for a docker. You don't even have to map to the >>>>>>>> pid as the docker sees it. /proc//cwd from the client's POV >>>>>>>> should be the same as /proc//cwd from the target JVM's >>>>>>>> POV. >>>>>>> >>>>>>> Sorry but I don't follow. If findSocketFile has to look in >>>>>>> /proc//root/ for the socket file, why does the >>>>>>> createAttachFile not also have to write the attach file into >>>>>>> /proc//root/ ?? In both cases it needs to find the >>>>>>> tmpdir >>>>>>> of the target process. >>>>>> Fortunately I have some old printlns that might help: >>>>>> >>>>>> ***getNamespacePid - ns_pid: 125 >>>>>> ***findSocketFile - f: /proc/24445/root/tmp/.java_pid125 >>>>>> ***createAttachFile - path: /proc/24445/cwd/.attach_pid125 >>>>>> >>>>>> So this is a case where the real pid is 24445, but the namespace >>>>>> pid in >>>>>> the docker is 125. The docker can (and does) reference >>>>>> /tmp/.java_pid125, but the client needs to reference >>>>>> /proc/24445/root/tmp/.java_pid125 to get to the same file. For >>>>>> .attach_pid125, the client can get to it through >>>>>> /proc/24445/cwd/.attach_pid125, and the docker process will look >>>>>> in cwd >>>>>> for the file. This is done in AttachListener::is_init_trigger(). >>>>>> >>>>>> BTW, comments like the following are no longer correct due to >>>>>> JDK-7132199: >>>>>> >>>>>> ???? // "/tmp" is used as a global well-known location for the files >>>>>> ???? // .java_pid. and .attach_pid. It is important >>>>>> that this >>>>>> ???? // location is the same for all processes, otherwise the tools >>>>>> ???? // will not be able to find all Hotspot processes. >>>>>> ???? // Any changes to this needs to be synchronized with HotSpot. >>>>>> ???? private static final String tmpdir = "/tmp"; >>>>>> >>>>>> So now .attach_pid is always created in cwd as you can see in >>>>>> createAttachFile(), although AttachListener::is_init_trigger() does >>>>>> check tmp, but only after cwd. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>>> >>>>>>>>> Minor note - you can collapse your catch blocks into 1 using >>>>>>>>> something like >>>>>>>>> >>>>>>>>> ??????? } catch (NumberFormatException | IOException x) { >>>>>>>>> ???????????? throw new AttachNotSupportedException("Unable to >>>>>>>>> parse >>>>>>>>> namespace"); >>>>>>>>> ??????? } >>>>>>>> I'll make that change. >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> David >>>>>>>>>> thanks, >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> On 9/11/17 8:03 PM, Chris Plummer wrote: >>>>>>>>>>> Ok, I will. Thanks. >>>>>>>>>>> >>>>>>>>>>> Chris >>>>>>>>>>> >>>>>>>>>>> On 9/11/17 6:13 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> Hi Chris, >>>>>>>>>>>> >>>>>>>>>>>> This looks good to me. >>>>>>>>>>>> >>>>>>>>>>>> I'm not sure if all the nsk.aod and the AttachOnDemand >>>>>>>>>>>> tests from >>>>>>>>>>>> the nsk.jvmti are run in the hotspot tier1, 2, and 3 tests. >>>>>>>>>>>> It makes sense to double-check it. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 9/10/17 20:34, Chris Plummer wrote: >>>>>>>>>>>>> [re-sending - sent to wrong alias first time] >>>>>>>>>>>>> >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review the following: >>>>>>>>>>>>> >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8179498 >>>>>>>>>>>>> http://cr.openjdk.java.net/~cjplummer/8179498/webrev.00/webrev_jdk/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The CR has the relevant details. Some previous discussions >>>>>>>>>>>>> can >>>>>>>>>>>>> be found here: >>>>>>>>>>>>> >>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/021237.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-May/021249.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-August/021679.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Testing with docker has been limited to just making sure jcmd >>>>>>>>>>>>> now works with the docker setup I was provided. I currently >>>>>>>>>>>>> don't see how we can run our existing tests in a way that >>>>>>>>>>>>> would >>>>>>>>>>>>> test the docker support without doing some rewriting of >>>>>>>>>>>>> the tests. >>>>>>>>>>>>> >>>>>>>>>>>>> I also ran all our hotspot tier1, 2, and 3 tests, along with >>>>>>>>>>>>> jdk/test/tools and jdk/test/sun/tools tests to make sure >>>>>>>>>>>>> existing functionality is not broken with these changes. >>>>>>>>>>>>> >>>>>>>>>>>>> thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Chris >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>> >>> >> >> From david.holmes at oracle.com Mon Sep 18 22:04:31 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Sep 2017 08:04:31 +1000 Subject: When does MONITOR_WAITED get thrown? In-Reply-To: References: Message-ID: Hi Jc, I found your example very difficult to follow. AFAICS you will potentially encounter monitor related events that are unrelated to the st.wait in your test code. And there are races in the test - as soon as st.wait releases the monitor lock then SecondThread can run, complete the sleep and print "Hello from A". I don't think it is specified exactly when the MONIOR_WAIT event is sent with respect to the releasing of the monitor lock. David On 19/09/2017 3:45 AM, JC Beyler wrote: > Hi all, > > When looking at the documentation of > https://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#MonitorWaited > , I see the following description: > "Sent when a thread finishes waiting on an object." > > However, there seems to be a slight issue when the MONITOR_WAIT event > handler throws an exception. > > Consider the following code: > > A) The monitor wait handler throws > > static void JNICALL > monitor_wait(jvmtiEnv* jvmti, JNIEnv *env, > ? ? ? ? ? ? ?jthread thread, jobject object, jlong timeout) { > ? fprintf(stderr, "Waiting!\n"); > > ? jclass newExcCls = env->FindClass("java/lang/IllegalArgumentException"); > ? // Unable to find the new exception class, give up. > ? if (newExcCls == 0) { > ? ? return; > ? } > ? env->ThrowNew(newExcCls, "Exception from monitor_wait"); > } > > B) The monitor waited handler does a printf: > static void JNICALL > monitor_waited(jvmtiEnv* jvmti, JNIEnv *env, > ? ? ? ? ? ? ? ?jthread thread, jobject object, jboolean timed_out) { > ? fprintf(stderr, "Waited!\n"); > } > > B) A second thread that will be asked to wait: > ?class SecondThread extends Thread { > ? public void run() { > ? ? try { > ? ? ? Thread.sleep(1); > ? ? } catch(Exception e) { > ? ? } > ? ? System.out.println("Hello from A"); > ? } > } > > C) The main thread with the wait: > class Main extends Thread { > ? public static void main(String[] args) { > ? ? SecondThread st = new SecondThread(); > > ? ? synchronized (st) { > ? ? ? st.start(); > > ? ? ? try { > ? ? ? ? st.wait(); > ? ? ? } catch(InterruptedException e) { > ? ? ? ? System.out.println("Exception caught!"); > ? ? ? } > ? ? } > > ? ? System.out.println("Done"); > ? } > } > > D) If I do this, what happens is that I get: > > Waiting! > Waited! > Exception in thread "main" java.lang.IllegalArgumentException: Exception > from monitor_wait > at java.lang.Object.wait(Native Method) > at java.lang.Object.wait(Object.java:502) > at Main.main(Main.java:9) > Hello from A > > - As we see, we get the print out from waiting, print out from waited > and then the exception in the waiting. > > > E) If instead, we do st.wait(-100) in the main method, we get: > Waiting! > Exception in thread "main" java.lang.IllegalArgumentException: Exception > from monitor_wait > at java.lang.Object.wait(Native Method) > at Main.main(Main.java:9) > Hello from A > > Notes: the stack is slightly different, the printout waited is no longer > there however > > F) If finally, we don't throw in the waiting handler but leave the > st.wait(-100) in place: > Waiting! > Exception in thread "main" java.lang.IllegalArgumentException: timeout > value is negative > at java.lang.Object.wait(Native Method) > at Main.main(Main.java:9) > Hello from A > > > The question thus becomes: is this normal that there is a slight > difference between D/E/F? > > Should we try to fix it to have a single behavior in the three cases, > and if so, which would be the behavior that should be the default? > > Let me know if you would like to see a full code to easily replicate, I > gave the big parts but left out the Agent_OnLoad method for example. > > Thanks! > Jc > From chris.plummer at oracle.com Mon Sep 18 22:14:43 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 18 Sep 2017 15:14:43 -0700 Subject: RFR: JDK-8187597: WrongTypeException is occurred at CLHSDB jstack after JDK-8186837 In-Reply-To: <6f369ad1-ee23-32b1-37ae-3bb60629960c@gmail.com> References: <39e4a81a-0a12-1ee7-dedb-0b9853d89fce@gmail.com> <6f369ad1-ee23-32b1-37ae-3bb60629960c@gmail.com> Message-ID: <9bfc8e1d-8438-21f2-3c06-e53bb95afb6c@oracle.com> Hi Yasumasa, Ok, I see now that CIntegerField is just an interface, so it's up to a class to implement getValue() to fetch the field. I'm a bit unclear on how that part works, but from responses by others, it seems this is ok. I've run all the tests I can find that use jstack or jhsdb, and the assert was not triggered. Probably need to have a NMethod on the stack to trigger the code you are fixing. thanks, Chris On 9/17/17 1:13 AM, Yasumasa Suenaga wrote: > Hi Chris, > > I've tested this issue on Fedora 26 x86_64. > I think we can sue CIntegerField at this point because CIntegerField > is not specialized for various int size [1]. > In fact, CIntegerField had been used at this point [2], and HSDB > worked fine. > > > Thanks, > > Yasumasa > > > [1] > http://hg.openjdk.java.net/jdk10/master/file/fd36993f7bf5/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/CIntegerField.java#l29 > [2] http://hg.openjdk.java.net/jdk10/master/rev/cbfdbefc6ea3 > > > On 2017/09/17 3:58, Chris Plummer wrote: >> Hi Yasumasa, >> >> Is this on a 32-bit system? I don't see how you could otherwise call >> getCIntegerField() on a long type. jlong is always 64-bit and long is >> (generally) 32-bit on 32-bit systems, and 64-bit on 64-bit systems, >> at least that seems to be the case with linux. >> >> ?From what I can see, _stack_traversal_mark is now the only long type >> in vmStructs.cpp. I don't know that we have a mechanism to safely >> fetch it on both 32-bit and 64-bit systems. >> >> _stack_traversal_mark seems to be a long because _traversals is also >> a long. >> >> ?? ? static long????? _traversals;?????????????????? // Stack scan >> count, also sweep ID. >> >> This too might be considered a bug. I'm not sure why you would want >> the size of this field to vary between 32-bit and 64-bit systems >> (adding compiler-dev to help answer that). >> >> So, while I would agree that your fix is generally in the right >> direction, I think we first need to revisit the use of long for these >> fields. If they can be changed to an int, then your fix is correct >> (pending the changes to int). If not, then maybe we need >> getCLongField() support. >> >> And lastly, we really should have a test to detect this bug. Maybe we >> already do, and it is failing but is going unnoticed for some reason. >> I'll try to look into that some more on Monday. >> >> thanks, >> >> Chris >> >> On 9/16/17 5:20 AM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I tried to get thread dump via jstack command on CLHSDB. But it was >>> failed as below: >>> >>> ``` >>> Caused by: sun.jvm.hotspot.types.WrongTypeException: field >>> "_stack_traversal_mark" in type nmethod is not of type jlong, but >>> instead of type long >>> ??????? at >>> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:206) >>> ??????? at >>> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:212) >>> ??????? at >>> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getJLongField(BasicType.java:249) >>> ??????? at >>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.initialize(NMethod.java:108) >>> ??????? at >>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.access$000(NMethod.java:35) >>> ??????? at >>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod$1.update(NMethod.java:81) >>> >>> ??????? at >>> jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:451) >>> ??????? at >>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.(NMethod.java:79) >>> ??????? ... 23 more >>> ``` >>> >>> I think this exception is caused by JDK-8186837. >>> This changeset has changed the type of >>> `nmethod::_stack_traversal_mark` to `long` from `jlong`. >>> >>> SA should follow this change. >>> >>> I uploaded a webrev for this issue. This webrev is generated from >>> consolidated repo (jdk10/master). >>> Could you review it? >>> >>> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.00/ >>> >>> >>> I cannot access JPRT. So I need reviewer. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >> >> From chris.plummer at oracle.com Mon Sep 18 22:17:56 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 18 Sep 2017 15:17:56 -0700 Subject: RFR: JDK-8187597: WrongTypeException is occurred at CLHSDB jstack after JDK-8186837 In-Reply-To: References: <39e4a81a-0a12-1ee7-dedb-0b9853d89fce@gmail.com> <6f369ad1-ee23-32b1-37ae-3bb60629960c@gmail.com> Message-ID: <00e64ebc-bf8a-31fa-6378-667a9005c797@oracle.com> On 9/18/17 6:14 AM, Robbin Ehn wrote: > Hi, > > FYI: It's been long since duke: > > ?? 0:?? nonstatic_field(nmethod, _stack_traversal_mark, > long)????????????????????????????????? \ > > It's now also volatile. > > The correct type should/could probably be some like > (u)int_fast32_t/intx or whatever. > > If there is an issue with variable length types in vmStructs we have > had that issue for very long AFAICT. Hi Robbin, I was more concerned with it being variable in general between 32-bit and 64-bit platforms, not that it was an issue for vmStructs. This does not seem like the type of value that would need to be a different size depending on the bitness, so it should be made whichever smallest size that is big enough. As you point out, something like intx, although the data structure it is in is full of ints, so probably int would be sufficient. thanks, Chris > > But looking at error message below: > field "_stack_traversal_mark" in type nmethod is not of type jlong, > but instead of type long > > It was jlong for about a month until I reverted that change (back to > long but volatile). > So it looks like you are running tools from an older build with a > newer vm or something like that ? > > /Robbin > > On 09/17/2017 10:13 AM, Yasumasa Suenaga wrote: >> Hi Chris, >> >> I've tested this issue on Fedora 26 x86_64. >> I think we can sue CIntegerField at this point because CIntegerField >> is not specialized for various int size [1]. >> In fact, CIntegerField had been used at this point [2], and HSDB >> worked fine. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] >> http://hg.openjdk.java.net/jdk10/master/file/fd36993f7bf5/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/CIntegerField.java#l29 >> [2] http://hg.openjdk.java.net/jdk10/master/rev/cbfdbefc6ea3 >> >> >> On 2017/09/17 3:58, Chris Plummer wrote: >>> Hi Yasumasa, >>> >>> Is this on a 32-bit system? I don't see how you could otherwise call >>> getCIntegerField() on a long type. jlong is always 64-bit and long >>> is (generally) 32-bit on 32-bit systems, and 64-bit on 64-bit >>> systems, at least that seems to be the case with linux. >>> >>> ?From what I can see, _stack_traversal_mark is now the only long >>> type in vmStructs.cpp. I don't know that we have a mechanism to >>> safely fetch it on both 32-bit and 64-bit systems. >>> >>> _stack_traversal_mark seems to be a long because _traversals is also >>> a long. >>> >>> ?? ? static long????? _traversals;?????????????????? // Stack scan >>> count, also sweep ID. >>> >>> This too might be considered a bug. I'm not sure why you would want >>> the size of this field to vary between 32-bit and 64-bit systems >>> (adding compiler-dev to help answer that). >>> >>> So, while I would agree that your fix is generally in the right >>> direction, I think we first need to revisit the use of long for >>> these fields. If they can be changed to an int, then your fix is >>> correct (pending the changes to int). If not, then maybe we need >>> getCLongField() support. >>> >>> And lastly, we really should have a test to detect this bug. Maybe >>> we already do, and it is failing but is going unnoticed for some >>> reason. I'll try to look into that some more on Monday. >>> >>> thanks, >>> >>> Chris >>> >>> On 9/16/17 5:20 AM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> I tried to get thread dump via jstack command on CLHSDB. But it was >>>> failed as below: >>>> >>>> ``` >>>> Caused by: sun.jvm.hotspot.types.WrongTypeException: field >>>> "_stack_traversal_mark" in type nmethod is not of type jlong, but >>>> instead of type long >>>> ??????? at >>>> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:206) >>>> ??????? at >>>> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:212) >>>> ??????? at >>>> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getJLongField(BasicType.java:249) >>>> ??????? at >>>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.initialize(NMethod.java:108) >>>> ??????? at >>>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.access$000(NMethod.java:35) >>>> ??????? at >>>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod$1.update(NMethod.java:81) >>>> >>>> ??????? at >>>> jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:451) >>>> ??????? at >>>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.(NMethod.java:79) >>>> ??????? ... 23 more >>>> ``` >>>> >>>> I think this exception is caused by JDK-8186837. >>>> This changeset has changed the type of >>>> `nmethod::_stack_traversal_mark` to `long` from `jlong`. >>>> >>>> SA should follow this change. >>>> >>>> I uploaded a webrev for this issue. This webrev is generated from >>>> consolidated repo (jdk10/master). >>>> Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.00/ >>>> >>>> >>>> I cannot access JPRT. So I need reviewer. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>> >>> From yasuenag at gmail.com Tue Sep 19 02:55:34 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 19 Sep 2017 11:55:34 +0900 Subject: RFR: JDK-8187597: WrongTypeException is occurred at CLHSDB jstack after JDK-8186837 In-Reply-To: References: <39e4a81a-0a12-1ee7-dedb-0b9853d89fce@gmail.com> <6f369ad1-ee23-32b1-37ae-3bb60629960c@gmail.com> <9bfc8e1d-8438-21f2-3c06-e53bb95afb6c@oracle.com> Message-ID: Thanks Chris, Robbin, I'm waiting reviewer(s) for this change. Yasumasa 2017/09/19 ??7:14 "Chris Plummer" : Hi Yasumasa, Ok, I see now that CIntegerField is just an interface, so it's up to a class to implement getValue() to fetch the field. I'm a bit unclear on how that part works, but from responses by others, it seems this is ok. I've run all the tests I can find that use jstack or jhsdb, and the assert was not triggered. Probably need to have a NMethod on the stack to trigger the code you are fixing. thanks, Chris On 9/17/17 1:13 AM, Yasumasa Suenaga wrote: > Hi Chris, > > I've tested this issue on Fedora 26 x86_64. > I think we can sue CIntegerField at this point because CIntegerField is > not specialized for various int size [1]. > In fact, CIntegerField had been used at this point [2], and HSDB worked > fine. > > > Thanks, > > Yasumasa > > > [1] http://hg.openjdk.java.net/jdk10/master/file/fd36993f7bf5/ > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/ > CIntegerField.java#l29 > [2] http://hg.openjdk.java.net/jdk10/master/rev/cbfdbefc6ea3 > > > On 2017/09/17 3:58, Chris Plummer wrote: > >> Hi Yasumasa, >> >> Is this on a 32-bit system? I don't see how you could otherwise call >> getCIntegerField() on a long type. jlong is always 64-bit and long is >> (generally) 32-bit on 32-bit systems, and 64-bit on 64-bit systems, at >> least that seems to be the case with linux. >> >> From what I can see, _stack_traversal_mark is now the only long type in >> vmStructs.cpp. I don't know that we have a mechanism to safely fetch it on >> both 32-bit and 64-bit systems. >> >> _stack_traversal_mark seems to be a long because _traversals is also a >> long. >> >> static long _traversals; // Stack scan count, >> also sweep ID. >> >> This too might be considered a bug. I'm not sure why you would want the >> size of this field to vary between 32-bit and 64-bit systems (adding >> compiler-dev to help answer that). >> >> So, while I would agree that your fix is generally in the right >> direction, I think we first need to revisit the use of long for these >> fields. If they can be changed to an int, then your fix is correct (pending >> the changes to int). If not, then maybe we need getCLongField() support. >> >> And lastly, we really should have a test to detect this bug. Maybe we >> already do, and it is failing but is going unnoticed for some reason. I'll >> try to look into that some more on Monday. >> >> thanks, >> >> Chris >> >> On 9/16/17 5:20 AM, Yasumasa Suenaga wrote: >> >>> Hi all, >>> >>> I tried to get thread dump via jstack command on CLHSDB. But it was >>> failed as below: >>> >>> ``` >>> Caused by: sun.jvm.hotspot.types.WrongTypeException: field >>> "_stack_traversal_mark" in type nmethod is not of type jlong, but instead >>> of type long >>> at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getF >>> ield(BasicType.java:206) >>> at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getF >>> ield(BasicType.java:212) >>> at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getJ >>> LongField(BasicType.java:249) >>> at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.initialize( >>> NMethod.java:108) >>> at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.access$000( >>> NMethod.java:35) >>> at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod$1.update(NMethod.java:81) >>> >>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMIniti >>> alizedObserver(VM.java:451) >>> at jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.(NMet >>> hod.java:79) >>> ... 23 more >>> ``` >>> >>> I think this exception is caused by JDK-8186837. >>> This changeset has changed the type of `nmethod::_stack_traversal_mark` >>> to `long` from `jlong`. >>> >>> SA should follow this change. >>> >>> I uploaded a webrev for this issue. This webrev is generated from >>> consolidated repo (jdk10/master). >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.00/ >>> >>> >>> I cannot access JPRT. So I need reviewer. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Sep 19 03:08:17 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Sep 2017 13:08:17 +1000 Subject: RFR: JDK-8187597: WrongTypeException is occurred at CLHSDB jstack after JDK-8186837 In-Reply-To: References: <39e4a81a-0a12-1ee7-dedb-0b9853d89fce@gmail.com> <6f369ad1-ee23-32b1-37ae-3bb60629960c@gmail.com> <9bfc8e1d-8438-21f2-3c06-e53bb95afb6c@oracle.com> Message-ID: <0ee1ed46-5c27-8693-fb6d-396a3059335e@oracle.com> Hi Yasumasa, On 19/09/2017 12:55 PM, Yasumasa Suenaga wrote: > Thanks Chris, Robbin, > > I'm waiting reviewer(s) for this change. Reviewed. This simply reverts the change of 8185102. Thanks, David ----- > > Yasumasa > > > 2017/09/19 ??7:14 "Chris Plummer" >: > > Hi Yasumasa, > > Ok, I see now that CIntegerField is just an interface, so it's up to > a class to implement getValue() to fetch the field. I'm a bit > unclear on how that part works, but from responses by others, it > seems this is ok. > > I've run all the tests I can find that use jstack or jhsdb, and the > assert was not triggered. Probably need to have a NMethod on the > stack to trigger the code you are fixing. > > thanks, > > Chris > > > On 9/17/17 1:13 AM, Yasumasa Suenaga wrote: > > Hi Chris, > > I've tested this issue on Fedora 26 x86_64. > I think we can sue CIntegerField at this point because > CIntegerField is not specialized for various int size [1]. > In fact, CIntegerField had been used at this point [2], and HSDB > worked fine. > > > Thanks, > > Yasumasa > > > [1] > http://hg.openjdk.java.net/jdk10/master/file/fd36993f7bf5/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/CIntegerField.java#l29 > > [2] http://hg.openjdk.java.net/jdk10/master/rev/cbfdbefc6ea3 > > > > On 2017/09/17 3:58, Chris Plummer wrote: > > Hi Yasumasa, > > Is this on a 32-bit system? I don't see how you could > otherwise call getCIntegerField() on a long type. jlong is > always 64-bit and long is (generally) 32-bit on 32-bit > systems, and 64-bit on 64-bit systems, at least that seems > to be the case with linux. > > ?From what I can see, _stack_traversal_mark is now the only > long type in vmStructs.cpp. I don't know that we have a > mechanism to safely fetch it on both 32-bit and 64-bit systems. > > _stack_traversal_mark seems to be a long because _traversals > is also a long. > > ?? ? static long????? _traversals;?????????????????? // > Stack scan count, also sweep ID. > > This too might be considered a bug. I'm not sure why you > would want the size of this field to vary between 32-bit and > 64-bit systems (adding compiler-dev to help answer that). > > So, while I would agree that your fix is generally in the > right direction, I think we first need to revisit the use of > long for these fields. If they can be changed to an int, > then your fix is correct (pending the changes to int). If > not, then maybe we need getCLongField() support. > > And lastly, we really should have a test to detect this bug. > Maybe we already do, and it is failing but is going > unnoticed for some reason. I'll try to look into that some > more on Monday. > > thanks, > > Chris > > On 9/16/17 5:20 AM, Yasumasa Suenaga wrote: > > Hi all, > > I tried to get thread dump via jstack command on CLHSDB. > But it was failed as below: > > ``` > Caused by: sun.jvm.hotspot.types.WrongTypeException: > field "_stack_traversal_mark" in type nmethod is not of > type jlong, but instead of type long > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:206) > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:212) > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getJLongField(BasicType.java:249) > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.initialize(NMethod.java:108) > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.access$000(NMethod.java:35) > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod$1.update(NMethod.java:81) > > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:451) > ??????? at > jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.(NMethod.java:79) > ??????? ... 23 more > ``` > > I think this exception is caused by JDK-8186837. > This changeset has changed the type of > `nmethod::_stack_traversal_mark` to `long` from `jlong`. > > SA should follow this change. > > I uploaded a webrev for this issue. This webrev is > generated from consolidated repo (jdk10/master). > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.00/ > > > > I cannot access JPRT. So I need reviewer. > > > Thanks, > > Yasumasa > > > > > > From yasuenag at gmail.com Tue Sep 19 03:19:40 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 19 Sep 2017 12:19:40 +0900 Subject: RFR: JDK-8187597: WrongTypeException is occurred at CLHSDB jstack after JDK-8186837 In-Reply-To: <0ee1ed46-5c27-8693-fb6d-396a3059335e@oracle.com> References: <39e4a81a-0a12-1ee7-dedb-0b9853d89fce@gmail.com> <6f369ad1-ee23-32b1-37ae-3bb60629960c@gmail.com> <9bfc8e1d-8438-21f2-3c06-e53bb95afb6c@oracle.com> <0ee1ed46-5c27-8693-fb6d-396a3059335e@oracle.com> Message-ID: Thanks David, BTW, can I push this change after jdk10/master is opened? I cannot access JPRT. Yasumasa 2017/09/19 ??0:08 "David Holmes" : > Hi Yasumasa, > > On 19/09/2017 12:55 PM, Yasumasa Suenaga wrote: > >> Thanks Chris, Robbin, >> >> I'm waiting reviewer(s) for this change. >> > > Reviewed. > > This simply reverts the change of 8185102. > > Thanks, > David > ----- > > >> Yasumasa >> >> >> 2017/09/19 ??7:14 "Chris Plummer" > chris.plummer at oracle.com>>: >> >> Hi Yasumasa, >> >> Ok, I see now that CIntegerField is just an interface, so it's up to >> a class to implement getValue() to fetch the field. I'm a bit >> unclear on how that part works, but from responses by others, it >> seems this is ok. >> >> I've run all the tests I can find that use jstack or jhsdb, and the >> assert was not triggered. Probably need to have a NMethod on the >> stack to trigger the code you are fixing. >> >> thanks, >> >> Chris >> >> >> On 9/17/17 1:13 AM, Yasumasa Suenaga wrote: >> >> Hi Chris, >> >> I've tested this issue on Fedora 26 x86_64. >> I think we can sue CIntegerField at this point because >> CIntegerField is not specialized for various int size [1]. >> In fact, CIntegerField had been used at this point [2], and HSDB >> worked fine. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] >> http://hg.openjdk.java.net/jdk10/master/file/fd36993f7bf5/ >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/ >> CIntegerField.java#l29 >> > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/ >> CIntegerField.java#l29> >> [2] http://hg.openjdk.java.net/jdk10/master/rev/cbfdbefc6ea3 >> >> >> >> On 2017/09/17 3:58, Chris Plummer wrote: >> >> Hi Yasumasa, >> >> Is this on a 32-bit system? I don't see how you could >> otherwise call getCIntegerField() on a long type. jlong is >> always 64-bit and long is (generally) 32-bit on 32-bit >> systems, and 64-bit on 64-bit systems, at least that seems >> to be the case with linux. >> >> From what I can see, _stack_traversal_mark is now the only >> long type in vmStructs.cpp. I don't know that we have a >> mechanism to safely fetch it on both 32-bit and 64-bit >> systems. >> >> _stack_traversal_mark seems to be a long because _traversals >> is also a long. >> >> static long _traversals; // >> Stack scan count, also sweep ID. >> >> This too might be considered a bug. I'm not sure why you >> would want the size of this field to vary between 32-bit and >> 64-bit systems (adding compiler-dev to help answer that). >> >> So, while I would agree that your fix is generally in the >> right direction, I think we first need to revisit the use of >> long for these fields. If they can be changed to an int, >> then your fix is correct (pending the changes to int). If >> not, then maybe we need getCLongField() support. >> >> And lastly, we really should have a test to detect this bug. >> Maybe we already do, and it is failing but is going >> unnoticed for some reason. I'll try to look into that some >> more on Monday. >> >> thanks, >> >> Chris >> >> On 9/16/17 5:20 AM, Yasumasa Suenaga wrote: >> >> Hi all, >> >> I tried to get thread dump via jstack command on CLHSDB. >> But it was failed as below: >> >> ``` >> Caused by: sun.jvm.hotspot.types.WrongTypeException: >> field "_stack_traversal_mark" in type nmethod is not of >> type jlong, but instead of type long >> at >> jdk.hotspot.agent/sun.jvm.hots >> pot.types.basic.BasicType.getField(BasicType.java:206) >> at >> jdk.hotspot.agent/sun.jvm.hots >> pot.types.basic.BasicType.getField(BasicType.java:212) >> at >> jdk.hotspot.agent/sun.jvm.hots >> pot.types.basic.BasicType.getJLongField(BasicType.java:249) >> at >> jdk.hotspot.agent/sun.jvm.hots >> pot.code.NMethod.initialize(NMethod.java:108) >> at >> jdk.hotspot.agent/sun.jvm.hots >> pot.code.NMethod.access$000(NMethod.java:35) >> at >> jdk.hotspot.agent/sun.jvm.hots >> pot.code.NMethod$1.update(NMethod.java:81) >> >> at >> jdk.hotspot.agent/sun.jvm.hots >> pot.runtime.VM.registerVMInitializedObserver(VM.java:451) >> at >> jdk.hotspot.agent/sun.jvm.hots >> pot.code.NMethod.(NMethod.java:79) >> ... 23 more >> ``` >> >> I think this exception is caused by JDK-8186837. >> This changeset has changed the type of >> `nmethod::_stack_traversal_mark` to `long` from `jlong`. >> >> SA should follow this change. >> >> I uploaded a webrev for this issue. This webrev is >> generated from consolidated repo (jdk10/master). >> Could you review it? >> >> http://cr.openjdk.java.net/~ys >> uenaga/JDK-8187597/webrev.00/ >> > suenaga/JDK-8187597/webrev.00/> >> >> >> I cannot access JPRT. So I need reviewer. >> >> >> Thanks, >> >> Yasumasa >> >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Sep 19 03:31:22 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Sep 2017 13:31:22 +1000 Subject: RFR: JDK-8187597: WrongTypeException is occurred at CLHSDB jstack after JDK-8186837 In-Reply-To: References: <39e4a81a-0a12-1ee7-dedb-0b9853d89fce@gmail.com> <6f369ad1-ee23-32b1-37ae-3bb60629960c@gmail.com> <9bfc8e1d-8438-21f2-3c06-e53bb95afb6c@oracle.com> <0ee1ed46-5c27-8693-fb6d-396a3059335e@oracle.com> Message-ID: <13b177d1-e04c-dd86-7a86-b55b165d5830@oracle.com> On 19/09/2017 1:19 PM, Yasumasa Suenaga wrote: > Thanks David, > > BTW, can I push this change after jdk10/master is opened? > I cannot access JPRT. I think we'd probably prefer this to go into jdk10/hs - once it is open - and for that you need a sponsor. Thanks, David > > Yasumasa > > > 2017/09/19 ??0:08 "David Holmes" >: > > Hi Yasumasa, > > On 19/09/2017 12:55 PM, Yasumasa Suenaga wrote: > > Thanks Chris, Robbin, > > I'm waiting reviewer(s) for this change. > > > Reviewed. > > This simply reverts the change of 8185102. > > Thanks, > David > ----- > > > Yasumasa > > > 2017/09/19 ??7:14 "Chris Plummer" > >>: > > ? ? Hi Yasumasa, > > ? ? Ok, I see now that CIntegerField is just an interface, so > it's up to > ? ? a class to implement getValue() to fetch the field. I'm a bit > ? ? unclear on how that part works, but from responses by > others, it > ? ? seems this is ok. > > ? ? I've run all the tests I can find that use jstack or jhsdb, > and the > ? ? assert was not triggered. Probably need to have a NMethod > on the > ? ? stack to trigger the code you are fixing. > > ? ? thanks, > > ? ? Chris > > > ? ? On 9/17/17 1:13 AM, Yasumasa Suenaga wrote: > > ? ? ? ? Hi Chris, > > ? ? ? ? I've tested this issue on Fedora 26 x86_64. > ? ? ? ? I think we can sue CIntegerField at this point because > ? ? ? ? CIntegerField is not specialized for various int size [1]. > ? ? ? ? In fact, CIntegerField had been used at this point [2], > and HSDB > ? ? ? ? worked fine. > > > ? ? ? ? Thanks, > > ? ? ? ? Yasumasa > > > ? ? ? ? [1] > http://hg.openjdk.java.net/jdk10/master/file/fd36993f7bf5/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/CIntegerField.java#l29 > > > > > ? ? ? ? [2] > http://hg.openjdk.java.net/jdk10/master/rev/cbfdbefc6ea3 > > > > > > > ? ? ? ? On 2017/09/17 3:58, Chris Plummer wrote: > > ? ? ? ? ? ? Hi Yasumasa, > > ? ? ? ? ? ? Is this on a 32-bit system? I don't see how you could > ? ? ? ? ? ? otherwise call getCIntegerField() on a long type. > jlong is > ? ? ? ? ? ? always 64-bit and long is (generally) 32-bit on 32-bit > ? ? ? ? ? ? systems, and 64-bit on 64-bit systems, at least > that seems > ? ? ? ? ? ? to be the case with linux. > > ? ? ? ? ? ? ??From what I can see, _stack_traversal_mark is now > the only > ? ? ? ? ? ? long type in vmStructs.cpp. I don't know that we have a > ? ? ? ? ? ? mechanism to safely fetch it on both 32-bit and > 64-bit systems. > > ? ? ? ? ? ? _stack_traversal_mark seems to be a long because > _traversals > ? ? ? ? ? ? is also a long. > > ? ? ? ? ? ? ??? ? static long > _traversals;?????????????????? // > ? ? ? ? ? ? Stack scan count, also sweep ID. > > ? ? ? ? ? ? This too might be considered a bug. I'm not sure > why you > ? ? ? ? ? ? would want the size of this field to vary between > 32-bit and > ? ? ? ? ? ? 64-bit systems (adding compiler-dev to help answer > that). > > ? ? ? ? ? ? So, while I would agree that your fix is generally > in the > ? ? ? ? ? ? right direction, I think we first need to revisit > the use of > ? ? ? ? ? ? long for these fields. If they can be changed to an > int, > ? ? ? ? ? ? then your fix is correct (pending the changes to > int). If > ? ? ? ? ? ? not, then maybe we need getCLongField() support. > > ? ? ? ? ? ? And lastly, we really should have a test to detect > this bug. > ? ? ? ? ? ? Maybe we already do, and it is failing but is going > ? ? ? ? ? ? unnoticed for some reason. I'll try to look into > that some > ? ? ? ? ? ? more on Monday. > > ? ? ? ? ? ? thanks, > > ? ? ? ? ? ? Chris > > ? ? ? ? ? ? On 9/16/17 5:20 AM, Yasumasa Suenaga wrote: > > ? ? ? ? ? ? ? ? Hi all, > > ? ? ? ? ? ? ? ? I tried to get thread dump via jstack command > on CLHSDB. > ? ? ? ? ? ? ? ? But it was failed as below: > > ? ? ? ? ? ? ? ? ``` > ? ? ? ? ? ? ? ? Caused by: > sun.jvm.hotspot.types.WrongTypeException: > ? ? ? ? ? ? ? ? field "_stack_traversal_mark" in type nmethod > is not of > ? ? ? ? ? ? ? ? type jlong, but instead of type long > ? ? ? ? ? ? ? ? ???????? at > > jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:206) > ? ? ? ? ? ? ? ? ???????? at > > jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:212) > ? ? ? ? ? ? ? ? ???????? at > > jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getJLongField(BasicType.java:249) > ? ? ? ? ? ? ? ? ???????? at > > jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.initialize(NMethod.java:108) > ? ? ? ? ? ? ? ? ???????? at > > jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.access$000(NMethod.java:35) > ? ? ? ? ? ? ? ? ???????? at > > jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod$1.update(NMethod.java:81) > > ? ? ? ? ? ? ? ? ???????? at > > jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:451) > ? ? ? ? ? ? ? ? ???????? at > > jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.(NMethod.java:79) > ? ? ? ? ? ? ? ? ???????? ... 23 more > ? ? ? ? ? ? ? ? ``` > > ? ? ? ? ? ? ? ? I think this exception is caused by JDK-8186837. > ? ? ? ? ? ? ? ? This changeset has changed the type of > ? ? ? ? ? ? ? ? `nmethod::_stack_traversal_mark` to `long` from > `jlong`. > > ? ? ? ? ? ? ? ? SA should follow this change. > > ? ? ? ? ? ? ? ? I uploaded a webrev for this issue. This webrev is > ? ? ? ? ? ? ? ? generated from consolidated repo (jdk10/master). > ? ? ? ? ? ? ? ? Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.00/ > > > > > > > ? ? ? ? ? ? ? ? I cannot access JPRT. So I need reviewer. > > > ? ? ? ? ? ? ? ? Thanks, > > ? ? ? ? ? ? ? ? Yasumasa > > > > > > From jaroslav.tulach at oracle.com Tue Sep 19 12:56:45 2017 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Tue, 19 Sep 2017 14:56:45 +0200 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <48a815cd-2943-d328-d955-f301d39d7b86@oracle.com> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <48a815cd-2943-d328-d955-f301d39d7b86@oracle.com> Message-ID: <2954772.sIDvmWlhCn@pracovni> On p?tek 15. z??? 2017 10:53:45 CEST mandy chung wrote: > > http://cr.openjdk.java.net/~jtulach/8182701/webrev.05/index.html > > Looks good. Great. Unless there are further comments, then we can plan integration of my changes. Vladimir, are you "sponsor" of my change? Will you integrate it somewhere? This is my first change that has a chance to get into JDK, so I don't think I have push rights. But I am thrilled. -jt From jcbeyler at google.com Tue Sep 19 16:26:23 2017 From: jcbeyler at google.com (JC Beyler) Date: Tue, 19 Sep 2017 09:26:23 -0700 Subject: When does MONITOR_WAITED get thrown? In-Reply-To: References: Message-ID: Hi David, First off, thanks for looking at this case! I really apologize for my example being difficult to follow. I hope you won't mind if I try again :). The question is less about ordering and more on the fact that sometimes the MONITOR_WAITED does not get emitted it seems depending on what is happening for the MONITOR_WAIT event. Let me give a full working code at the bottom of this that show cases my question/issue. Basically, there are three cases I can think of for this test: 1) The MONITOR_WAIT callback throws an illegal exception (or another exception I expect would have the same issue) 2) The actual call from Java world to the wait is illegal due to a negative value for example: thread.wait(-100) AND the MONITOR_WAIT callback throws an illegal exception 3) The actual call from Java world to the wait is illegal due to a negative value for example: thread.wait(-100) AND the MONITOR_WAIT callback does not throw an exception What I've noticed is that the behavior is slightly different depending on the case: 1) In the case 1 above, we get a MONITOR_WAITED event 2) In the case 2 above, we get exactly the same error and I believe that probably because we check the argument to wait after doing the callback to MONITOR_WAIT; however we get MONITOR_WAITED callback at all 3) In the case 3 above, however, we get an illegal argument due to the -100 for the wait call, however we do get a MONITOR_WAITED callback. My question is really the following: - Should we not have the same behavior (Whatever that may be by the way) in all three cases? In all three cases, we do not wait due to an exception being thrown but 2 out of 3 do not have a MONITOR_WAITED event sent out. - When I look at the code, why this is happening is because the code seems to be doing this: Do the JVM_MonitorWait in jvm.cpp A) post the monitor wait callback B) Do the actual wait via ObjectSynchronizer i) Check the argument in ObjectSynchronizer::wait (src/share/vm/runtime/synchronizer.cpp) 1) All good? Go in ObjectMonitor::wait (src/share/vm/runtime/objectMonitor.cpp) - Check if the JNI threw, bail there after posting for waited 2) Not good? bail without throwing Note: I've added the whole code below and refactored it so that the output is more clear and you have all cases together in one code (I augmented the sleep to 5 seconds to make it clear :)): Thanks for your help, Jc -------------------------------------------------------------------------------------- A) Here is the agent code: #include #include #include static void JNICALL monitor_wait(jvmtiEnv* jvmti, JNIEnv *env, jthread thread, jobject object, jlong timeout) { fprintf(stderr, "Waiting!\n"); // Throw only every other time the first few times, then never again (Works out well for the Java test :)): // - We want it to throw the first wait but not the first join. // - We want it to throw the second wait but not the second join. // - We want it to no longer throw at all. static int cnt = 0; if (cnt++ % 2 == 0 && cnt < 4) { jclass newExcCls = env->FindClass("java/lang/IllegalArgumentException"); // Unable to find the new exception class, give up. if (newExcCls == 0) { return; } env->ThrowNew(newExcCls, "Exception from monitor_wait"); } } static void JNICALL monitor_waited(jvmtiEnv* jvmti, JNIEnv *env, jthread thread, jobject object, jboolean timed_out) { fprintf(stderr, "Waited!\n"); } extern "C" JNIEXPORT jint JNICALL Agent_OnLoad(JavaVM *jvm, char *options, void *reserved) { int ernum; jvmtiEnv *jvmti; if (jvm->GetEnv(reinterpret_cast(&jvmti), JVMTI_VERSION) != JNI_OK) { return JNI_ERR; } jvmtiEventCallbacks callbacks; memset(&callbacks, 0, sizeof(callbacks)); callbacks.MonitorWait = &monitor_wait; callbacks.MonitorWaited = &monitor_waited; jvmtiCapabilities caps; memset(&caps, 0, sizeof(caps)); caps.can_generate_monitor_events = 1; ernum = jvmti->AddCapabilities(&caps); ernum = jvmti->SetEventCallbacks(&callbacks, sizeof(jvmtiEventCallbacks)); ernum = jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_MONITOR_WAIT, NULL); ernum = jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_MONITOR_WAITED, NULL); return ernum; } B) Here is the Java code, it's a bit long but I added comments and made it clear (I really hope :)): public class Main extends Thread { public static void main(String[] args) { for (int i = 0; i < 3; i++) { SecondThread st = new SecondThread("first"); synchronized (st) { st.start(); System.err.println("Starting with simple wait"); try { st.wait(); } catch(Exception e) { System.out.println("Here we got a monitor_waited call, the underlying monitor_wait callback threw: " + e); } System.err.println("\n\nJoining so wait/waited will show"); try { st.join(); } catch(Exception e) { System.err.println("Join exception, not intended for this test: " + e); } } st = new SecondThread("second"); synchronized (st) { st.start(); System.err.println("\n\nStarting with negative wait"); try { st.wait(-100); } catch(Exception e) { System.err.println("Here we did not get a callback to monitor_waited though same exception as above: " + e); } System.err.println("\n\nJoining so wait/waited will show"); try { st.join(); } catch(Exception e) { System.err.println("Join exception, not intended for this test: " + e); } } st = new SecondThread("third"); synchronized (st) { st.start(); System.err.println("\n\nStarting with simple wait, monitor_wait won't throw anymore"); try { st.wait(-100); } catch(Exception e) { System.err.println("Here we did not get a callback to monitor_waited though different exception as above: " + e); } System.err.println("\n\nJoining so wait/waited will show"); try { st.join(); } catch(Exception e) { System.err.println("Join exception, not intended for this test: " + e); } } System.out.println("Done"); } } class SecondThread extends Thread { private String name; public SecondThread(String name) { this.name = name; } public void run() { try { Thread.sleep(5000); } catch(Exception e) { System.err.println(e); } System.err.println("Hello from " + name); } } C) The output I get is: Starting with simple wait Waiting! Waited! Here we got a monitor_waited call, the underlying monitor_wait callback threw: java.lang.IllegalArgumentException: Exception from monitor_wait Joining so wait/waited will show Waiting! Hello from first Waited! Starting with negative wait Waiting! Here we did not get a callback to monitor_waited though same exception as above: java.lang.IllegalArgumentException: Exception from monitor_wait Joining so wait/waited will show Waiting! Hello from second Waited! Starting with simple wait, monitor_wait won't throw anymore Waiting! Here we did not get a callback to monitor_waited though different exception as above: java.lang.IllegalArgumentException: timeout value is negative Joining so wait/waited will show Waiting! Hello from third Waited! Done On Mon, Sep 18, 2017 at 3:04 PM, David Holmes wrote: > Hi Jc, > > I found your example very difficult to follow. AFAICS you will > potentially encounter monitor related events that are unrelated to the > st.wait in your test code. And there are races in the test - as soon as > st.wait releases the monitor lock then SecondThread can run, complete the > sleep and print "Hello from A". I don't think it is specified exactly when > the MONIOR_WAIT event is sent with respect to the releasing of the monitor > lock. > > David > > > On 19/09/2017 3:45 AM, JC Beyler wrote: > >> Hi all, >> >> When looking at the documentation of >> https://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti. >> html#MonitorWaited , I see the following description: >> "Sent when a thread finishes waiting on an object." >> >> However, there seems to be a slight issue when the MONITOR_WAIT event >> handler throws an exception. >> >> Consider the following code: >> >> A) The monitor wait handler throws >> >> static void JNICALL >> monitor_wait(jvmtiEnv* jvmti, JNIEnv *env, >> jthread thread, jobject object, jlong timeout) { >> fprintf(stderr, "Waiting!\n"); >> >> jclass newExcCls = env->FindClass("java/lang/Ille >> galArgumentException"); >> // Unable to find the new exception class, give up. >> if (newExcCls == 0) { >> return; >> } >> env->ThrowNew(newExcCls, "Exception from monitor_wait"); >> } >> >> B) The monitor waited handler does a printf: >> static void JNICALL >> monitor_waited(jvmtiEnv* jvmti, JNIEnv *env, >> jthread thread, jobject object, jboolean timed_out) { >> fprintf(stderr, "Waited!\n"); >> } >> >> B) A second thread that will be asked to wait: >> class SecondThread extends Thread { >> public void run() { >> try { >> Thread.sleep(1); >> } catch(Exception e) { >> } >> System.out.println("Hello from A"); >> } >> } >> >> C) The main thread with the wait: >> class Main extends Thread { >> public static void main(String[] args) { >> SecondThread st = new SecondThread(); >> >> synchronized (st) { >> st.start(); >> >> try { >> st.wait(); >> } catch(InterruptedException e) { >> System.out.println("Exception caught!"); >> } >> } >> >> System.out.println("Done"); >> } >> } >> >> D) If I do this, what happens is that I get: >> >> Waiting! >> Waited! >> Exception in thread "main" java.lang.IllegalArgumentException: Exception >> from monitor_wait >> at java.lang.Object.wait(Native Method) >> at java.lang.Object.wait(Object.java:502) >> at Main.main(Main.java:9) >> Hello from A >> >> - As we see, we get the print out from waiting, print out from waited and >> then the exception in the waiting. >> >> >> E) If instead, we do st.wait(-100) in the main method, we get: >> Waiting! >> Exception in thread "main" java.lang.IllegalArgumentException: Exception >> from monitor_wait >> at java.lang.Object.wait(Native Method) >> at Main.main(Main.java:9) >> Hello from A >> >> Notes: the stack is slightly different, the printout waited is no longer >> there however >> >> F) If finally, we don't throw in the waiting handler but leave the >> st.wait(-100) in place: >> Waiting! >> Exception in thread "main" java.lang.IllegalArgumentException: timeout >> value is negative >> at java.lang.Object.wait(Native Method) >> at Main.main(Main.java:9) >> Hello from A >> >> >> The question thus becomes: is this normal that there is a slight >> difference between D/E/F? >> >> Should we try to fix it to have a single behavior in the three cases, and >> if so, which would be the behavior that should be the default? >> >> Let me know if you would like to see a full code to easily replicate, I >> gave the big parts but left out the Agent_OnLoad method for example. >> >> Thanks! >> Jc >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Sep 19 18:32:52 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Sep 2017 11:32:52 -0700 Subject: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean In-Reply-To: <2954772.sIDvmWlhCn@pracovni> References: <73a34e68-19cf-e949-0057-a2e16cfca6da@oracle.com> <48a815cd-2943-d328-d955-f301d39d7b86@oracle.com> <2954772.sIDvmWlhCn@pracovni> Message-ID: Finally ;) On 9/19/17 5:56 AM, Jaroslav Tulach wrote: > On p?tek 15. z??? 2017 10:53:45 CEST mandy chung wrote: >> > http://cr.openjdk.java.net/~jtulach/8182701/webrev.05/index.html >> >> Looks good. > > Great. Unless there are further comments, then we can plan integration of my > changes. Vladimir, are you "sponsor" of my change? Will you integrate it > somewhere? Yes, I will integrate them when jdk10 repos are open again after consolidation. > > This is my first change that has a chance to get into JDK, so I don't think I > have push rights. But I am thrilled. Yes, you have to propose about 8 "significant" changes before becoming Committer and allowed to push: http://openjdk.java.net/projects/#project-committer Thanks, Vladimir > > -jt > From david.holmes at oracle.com Tue Sep 19 22:01:59 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Sep 2017 08:01:59 +1000 Subject: When does MONITOR_WAITED get thrown? In-Reply-To: References: Message-ID: <0a20173f-6f3d-7f85-6a36-1cc55cd8e9d0@oracle.com> Hi Jc, On 20/09/2017 2:26 AM, JC Beyler wrote: > Hi David, > > First off, thanks for looking at this case!? I really apologize for my > example being difficult to follow. I hope you won't mind if I try again :). > > The question is less about ordering and more on the fact that sometimes > the MONITOR_WAITED does not get emitted it seems depending on what is > happening for the MONITOR_WAIT event. Let me give a full working code at > the bottom of this that show cases my question/issue. > > Basically, there are three cases I can think of for this test: > > 1) The MONITOR_WAIT callback throws an illegal exception (or another > exception I expect would have the same issue) > 2) The actual call from Java world to the wait is illegal due to a > negative value for example: thread.wait(-100) AND the MONITOR_WAIT > callback throws an illegal exception > 3) The actual call from Java world to the wait is illegal due to a > negative value for example: thread.wait(-100) AND the MONITOR_WAIT > callback does not throw an exception > > > What I've noticed is that the behavior is slightly different depending > on the case: > > 1) In the case 1 above, we get a MONITOR_WAITED event > 2) In the case 2 above, we get exactly the same error and I believe that > probably because we check the argument to wait after doing the callback > to MONITOR_WAIT; however we get MONITOR_WAITED callback at all > 3) In the case 3 above, however, we get an illegal argument due to the > -100 for the wait call, however we do get a MONITOR_WAITED callback. First it is a bug that wait(-100) triggers any JVM TI events. The IllegalArgumentException should be thrown at the Java level - and indeed this has just been fixed. (Try using wait(-100,0) instead to see this.) That aside, for wait(-100) you will get a MONITOR_WAIT event, then the throwing of the IllegalArgumentException. You will never see MONITOR_WAITED with respect to an illegal call to wait() - we simply never hit the code that does the waiting and posts the event. (If you do see MONITOR_WAITED then it may well be for a different wait() call.) If the MONITOR_WAIT handler itself posts an exception, and the wait() call is illegal then the IllegalArgumentException will replace the exception posted by the handler. If the handler posts an exception and the call to wait is legal then it is as you describe below ... > My question is really the following: > > - Should we not have the same behavior (Whatever that may be by the way) > in all three cases? In all three cases, we do not wait due to an > exception being thrown but 2 out of 3 do not have a MONITOR_WAITED event > sent out. > > - When I look at the code, why this is happening is because the code > seems to be doing this: > > ? Do the JVM_MonitorWait in jvm.cpp > ? ?A) post the monitor wait callback > ? ?B) Do the actual wait via ObjectSynchronizer > ? ? ? i) Check the argument in ObjectSynchronizer::wait > (src/share/vm/runtime/synchronizer.cpp) > ? ? ? ? 1) All good? Go in ObjectMonitor::wait > (src/share/vm/runtime/objectMonitor.cpp) > ? ? ? ? ? ? - Check if the JNI threw, bail there after posting for waited Other than if the thread is interrupted I don't see any check for a pending exception. So the wait() happens, the MONITOR_WAITED is posted, and eventually the pending exception from the MONITOR_WAIT is detected and thrown. > ? ? ? ? ?2) Not good? bail without throwing If the timeout is illegal it posts the IllegalArgumentException and returns. The JVM TI spec says very little about exceptions and event callback handlers, other than being careful not to lose existing pending exceptions. In particular the fact there may be an exception pending, whether from the handler or other source, does not influence subsequent event handling directly - but obviously the logic in the VM that checks for pending exceptions will affect whether certain callback points can be reached if an exception is pending. Does this explain what you observe? Cheers, David ------ > > > Note: I've added the whole code below and refactored it so that the > output is more clear and you have all cases together in one code (I > augmented the sleep to 5 seconds to make it clear :)): > > Thanks for your help, > Jc > > > -------------------------------------------------------------------------------------- > > > A) Here is the agent code: > #include > #include > #include > > static void JNICALL > monitor_wait(jvmtiEnv* jvmti, JNIEnv *env, > ? ? ? ? ? ? ?jthread thread, jobject object, jlong timeout) { > ? fprintf(stderr, "Waiting!\n"); > > ? // Throw only every other time the first few times, then never again > (Works out well for the Java test :)): > ? //? ?- We want it to throw the first wait but not the first join. > ? //? ?- We want it to throw the second wait but not the second join. > ? //? ?- We want it to no longer throw at all. > ? static int cnt = 0; > ? if (cnt++ % 2 == 0 && cnt < 4) { > ? ? jclass newExcCls = > env->FindClass("java/lang/IllegalArgumentException"); > ? ? // Unable to find the new exception class, give up. > ? ? if (newExcCls == 0) { > ? ? ? return; > ? ? } > ? ? env->ThrowNew(newExcCls, "Exception from monitor_wait"); > ? } > } > > static void JNICALL > monitor_waited(jvmtiEnv* jvmti, JNIEnv *env, > ? ? ? ? ? ? ? ?jthread thread, jobject object, jboolean timed_out) { > ? fprintf(stderr, "Waited!\n"); > } > > extern "C" JNIEXPORT jint JNICALL Agent_OnLoad(JavaVM *jvm, char *options, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?void *reserved) { > ? int ernum; > > ? jvmtiEnv *jvmti; > ? if (jvm->GetEnv(reinterpret_cast(&jvmti), JVMTI_VERSION) != > JNI_OK) { > ? ? return JNI_ERR; > ? } > > ? jvmtiEventCallbacks callbacks; > ? memset(&callbacks, 0, sizeof(callbacks)); > ? callbacks.MonitorWait = &monitor_wait; > ? callbacks.MonitorWaited = &monitor_waited; > > ? jvmtiCapabilities caps; > ? memset(&caps, 0, sizeof(caps)); > ? caps.can_generate_monitor_events = 1; > > ? ernum = jvmti->AddCapabilities(&caps); > ? ernum = jvmti->SetEventCallbacks(&callbacks, > sizeof(jvmtiEventCallbacks)); > ? ernum = jvmti->SetEventNotificationMode(JVMTI_ENABLE, > JVMTI_EVENT_MONITOR_WAIT, NULL); > ? ernum = jvmti->SetEventNotificationMode(JVMTI_ENABLE, > JVMTI_EVENT_MONITOR_WAITED, NULL); > > ? return ernum; > } > > B) Here is the Java code, it's a bit long but I added comments and made > it clear (I really hope :)): > > public class Main extends Thread { > ? public static void main(String[] args) { > > ? ? for (int i = 0; i < 3; i++) { > ? ? ? SecondThread st = new SecondThread("first"); > > ? ? synchronized (st) { > ? ? ? st.start(); > > ? ? ? System.err.println("Starting with simple wait"); > ? ? ? try { > ? ? ? ? st.wait(); > ? ? ? } catch(Exception e) { > ? ? ? ? System.out.println("Here we got a monitor_waited call, the > underlying monitor_wait callback threw: " + e); > ? ? ? } > > ? ? ? System.err.println("\n\nJoining so wait/waited will show"); > ? ? ? try { > ? ? ? ? st.join(); > ? ? ? } catch(Exception e) { > ? ? ? ? System.err.println("Join exception, not intended for this test: > " + e); > ? ? ? } > ? ? } > > ? ? st = new SecondThread("second"); > > ? ? synchronized (st) { > ? ? ? st.start(); > > ? ? ? System.err.println("\n\nStarting with negative wait"); > ? ? ? try { > ? ? ? ? st.wait(-100); > ? ? ? } catch(Exception e) { > ? ? ? ? System.err.println("Here we did not get a callback to > monitor_waited though same exception as above: " + e); > ? ? ? } > > ? ? ? System.err.println("\n\nJoining so wait/waited will show"); > ? ? ? try { > ? ? ? ? st.join(); > ? ? ? } catch(Exception e) { > ? ? ? ? System.err.println("Join exception, not intended for this test: > " + e); > ? ? ? } > ? ? } > > ? ? st = new SecondThread("third"); > > ? ? synchronized (st) { > ? ? ? st.start(); > > ? ? ? System.err.println("\n\nStarting with simple wait, monitor_wait > won't throw anymore"); > ? ? ? try { > ? ? ? ? st.wait(-100); > ? ? ? } catch(Exception e) { > ? ? ? ? System.err.println("Here we did not get a callback to > monitor_waited though different exception as above: " + e); > ? ? ? } > > ? ? ? System.err.println("\n\nJoining so wait/waited will show"); > ? ? ? try { > ? ? ? ? st.join(); > ? ? ? } catch(Exception e) { > ? ? ? ? System.err.println("Join exception, not intended for this test: > " + e); > ? ? ? } > ? ? } > > ? ? System.out.println("Done"); > ? } > } > > class SecondThread extends Thread { > ? private String name; > > ? public SecondThread(String name) { > this.name = name; > ? } > > ? public void run() { > ? ? try { > ? ? ? Thread.sleep(5000); > ? ? } catch(Exception e) { > ? ? ? System.err.println(e); > ? ? } > ? ? System.err.println("Hello from " + name); > ? } > } > > C) The output I get is: > Starting with simple wait > Waiting! > Waited! > Here we got a monitor_waited call, the underlying monitor_wait callback > threw: java.lang.IllegalArgumentException: Exception from monitor_wait > > > Joining so wait/waited will show > Waiting! > Hello from first > Waited! > > > Starting with negative wait > Waiting! > Here we did not get a callback to monitor_waited though same exception > as above: java.lang.IllegalArgumentException: Exception from monitor_wait > > > Joining so wait/waited will show > Waiting! > Hello from second > Waited! > > > Starting with simple wait, monitor_wait won't throw anymore > Waiting! > Here we did not get a callback to monitor_waited though different > exception as above: java.lang.IllegalArgumentException: timeout value is > negative > > > Joining so wait/waited will show > Waiting! > Hello from third > Waited! > Done > > > On Mon, Sep 18, 2017 at 3:04 PM, David Holmes > wrote: > > Hi Jc, > > I found? your example very difficult to follow. AFAICS you will > potentially encounter monitor related events that are unrelated to > the st.wait in your test code. And there are races in the test - as > soon as st.wait releases the monitor lock then SecondThread can run, > complete the sleep and print "Hello from A". I don't think it is > specified exactly when the MONIOR_WAIT event is sent with respect to > the releasing of the monitor lock. > > David > > > On 19/09/2017 3:45 AM, JC Beyler wrote: > > Hi all, > > When looking at the documentation of > https://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#MonitorWaited > > , I see the following description: > "Sent when a thread finishes waiting on an object." > > However, there seems to be a slight issue when the MONITOR_WAIT > event handler throws an exception. > > Consider the following code: > > A) The monitor wait handler throws > > static void JNICALL > monitor_wait(jvmtiEnv* jvmti, JNIEnv *env, > ?? ? ? ? ? ? ?jthread thread, jobject object, jlong timeout) { > ?? fprintf(stderr, "Waiting!\n"); > > ?? jclass newExcCls = > env->FindClass("java/lang/IllegalArgumentException"); > ?? // Unable to find the new exception class, give up. > ?? if (newExcCls == 0) { > ?? ? return; > ?? } > ?? env->ThrowNew(newExcCls, "Exception from monitor_wait"); > } > > B) The monitor waited handler does a printf: > static void JNICALL > monitor_waited(jvmtiEnv* jvmti, JNIEnv *env, > ?? ? ? ? ? ? ? ?jthread thread, jobject object, jboolean > timed_out) { > ?? fprintf(stderr, "Waited!\n"); > } > > B) A second thread that will be asked to wait: > ??class SecondThread extends Thread { > ?? public void run() { > ?? ? try { > ?? ? ? Thread.sleep(1); > ?? ? } catch(Exception e) { > ?? ? } > ?? ? System.out.println("Hello from A"); > ?? } > } > > C) The main thread with the wait: > class Main extends Thread { > ?? public static void main(String[] args) { > ?? ? SecondThread st = new SecondThread(); > > ?? ? synchronized (st) { > ?? ? ? st.start(); > > ?? ? ? try { > ?? ? ? ? st.wait(); > ?? ? ? } catch(InterruptedException e) { > ?? ? ? ? System.out.println("Exception caught!"); > ?? ? ? } > ?? ? } > > ?? ? System.out.println("Done"); > ?? } > } > > D) If I do this, what happens is that I get: > > Waiting! > Waited! > Exception in thread "main" java.lang.IllegalArgumentException: > Exception from monitor_wait > at java.lang.Object.wait(Native Method) > at java.lang.Object.wait(Object.java:502) > at Main.main(Main.java:9) > Hello from A > > - As we see, we get the print out from waiting, print out from > waited and then the exception in the waiting. > > > E) If instead, we do st.wait(-100) in the main method, we get: > Waiting! > Exception in thread "main" java.lang.IllegalArgumentException: > Exception from monitor_wait > at java.lang.Object.wait(Native Method) > at Main.main(Main.java:9) > Hello from A > > Notes: the stack is slightly different, the printout waited is > no longer there however > > F) If finally, we don't throw in the waiting handler but leave > the st.wait(-100) in place: > Waiting! > Exception in thread "main" java.lang.IllegalArgumentException: > timeout value is negative > at java.lang.Object.wait(Native Method) > at Main.main(Main.java:9) > Hello from A > > > The question thus becomes: is this normal that there is a slight > difference between D/E/F? > > Should we try to fix it to have a single behavior in the three > cases, and if so, which would be the behavior that should be the > default? > > Let me know if you would like to see a full code to easily > replicate, I gave the big parts but left out the Agent_OnLoad > method for example. > > Thanks! > Jc > > From navy.xliu at gmail.com Sun Sep 17 08:06:59 2017 From: navy.xliu at gmail.com (Liu Xin) Date: Sun, 17 Sep 2017 16:06:59 +0800 Subject: jdk9 can not load sa.js automatically in jhsdb Message-ID: Hello, serviceability mail-list, Jdk9 refactored the CLI for hsdb. I try to catch you up. With the latest openjdk9 build, I always meet the following message when I want to use 'console' in GUI. ./jhsdb hsdb //attach pid //windows/console javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is not a function in sa.js at line number 54 Warning! JS Engine can't start, some commands will not be available I quickly look at it. It seems that it has problem to load 'sa.js'. // SA singletons are kept in 'sa' object var sa = new Object(); sa.vm = sapkg.runtime.VM.getVM(); sa.dbg = sa.vm.getDebugger(); sa.cdbg = sa.dbg.CDebugger; I strongly suspect that it didn't invoke sun.jvm.hotspot.runtime.VM.initialize before loading the sa.js. is it intentional or just wrong usage of mine? Please note that I did build nashorn and jjs works perfectly. I can reproduce this problem on linux and macosx. I took reference of the doc of clhsdb shipping with hotspot source code: hotspot/src/jdk.hotspot.agent/doc/clhsdb.html is it out of date? I found it NOT 'Few CLHSDB commands are already implemented in JavaScript.' thanks, --lx -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Wed Sep 20 22:44:46 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 21 Sep 2017 07:44:46 +0900 Subject: RFR: JDK-8187597: WrongTypeException is occurred at CLHSDB jstack after JDK-8186837 In-Reply-To: <13b177d1-e04c-dd86-7a86-b55b165d5830@oracle.com> References: <39e4a81a-0a12-1ee7-dedb-0b9853d89fce@gmail.com> <6f369ad1-ee23-32b1-37ae-3bb60629960c@gmail.com> <9bfc8e1d-8438-21f2-3c06-e53bb95afb6c@oracle.com> <0ee1ed46-5c27-8693-fb6d-396a3059335e@oracle.com> <13b177d1-e04c-dd86-7a86-b55b165d5830@oracle.com> Message-ID: <2c955c17-43b9-906f-408d-f5349d57ca13@gmail.com> Hi David, jdk10/hs has been opened [1]. Could you push this change? Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-September/000499.html On 2017/09/19 12:31, David Holmes wrote: > On 19/09/2017 1:19 PM, Yasumasa Suenaga wrote: >> Thanks David, >> >> BTW, can I push this change after jdk10/master is opened? >> I cannot access JPRT. > > I think we'd probably prefer this to go into jdk10/hs - once it is open - and for that you need a sponsor. > > Thanks, > David > >> >> Yasumasa >> >> >> 2017/09/19 ??0:08 "David Holmes" >: >> >> ??? Hi Yasumasa, >> >> ??? On 19/09/2017 12:55 PM, Yasumasa Suenaga wrote: >> >> ??????? Thanks Chris, Robbin, >> >> ??????? I'm waiting reviewer(s) for this change. >> >> >> ??? Reviewed. >> >> ??? This simply reverts the change of 8185102. >> >> ??? Thanks, >> ??? David >> ??? ----- >> >> >> ??????? Yasumasa >> >> >> ??????? 2017/09/19 ??7:14 "Chris Plummer" > ??????? >> ??????? > ??????? >>: >> >> ???????? ? ? Hi Yasumasa, >> >> ???????? ? ? Ok, I see now that CIntegerField is just an interface, so >> ??????? it's up to >> ???????? ? ? a class to implement getValue() to fetch the field. I'm a bit >> ???????? ? ? unclear on how that part works, but from responses by >> ??????? others, it >> ???????? ? ? seems this is ok. >> >> ???????? ? ? I've run all the tests I can find that use jstack or jhsdb, >> ??????? and the >> ???????? ? ? assert was not triggered. Probably need to have a NMethod >> ??????? on the >> ???????? ? ? stack to trigger the code you are fixing. >> >> ???????? ? ? thanks, >> >> ???????? ? ? Chris >> >> >> ???????? ? ? On 9/17/17 1:13 AM, Yasumasa Suenaga wrote: >> >> ???????? ? ? ? ? Hi Chris, >> >> ???????? ? ? ? ? I've tested this issue on Fedora 26 x86_64. >> ???????? ? ? ? ? I think we can sue CIntegerField at this point because >> ???????? ? ? ? ? CIntegerField is not specialized for various int size [1]. >> ???????? ? ? ? ? In fact, CIntegerField had been used at this point [2], >> ??????? and HSDB >> ???????? ? ? ? ? worked fine. >> >> >> ???????? ? ? ? ? Thanks, >> >> ???????? ? ? ? ? Yasumasa >> >> >> ???????? ? ? ? ? [1] >> ??????? http://hg.openjdk.java.net/jdk10/master/file/fd36993f7bf5/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/CIntegerField.java#l29 >> ??????? >> ??????? > ??????? > >> ???????? ? ? ? ? [2] >> ??????? http://hg.openjdk.java.net/jdk10/master/rev/cbfdbefc6ea3 >> ??????? >> ??????? > ??????? > >> >> >> ???????? ? ? ? ? On 2017/09/17 3:58, Chris Plummer wrote: >> >> ???????? ? ? ? ? ? ? Hi Yasumasa, >> >> ???????? ? ? ? ? ? ? Is this on a 32-bit system? I don't see how you could >> ???????? ? ? ? ? ? ? otherwise call getCIntegerField() on a long type. >> ??????? jlong is >> ???????? ? ? ? ? ? ? always 64-bit and long is (generally) 32-bit on 32-bit >> ???????? ? ? ? ? ? ? systems, and 64-bit on 64-bit systems, at least >> ??????? that seems >> ???????? ? ? ? ? ? ? to be the case with linux. >> >> ???????? ? ? ? ? ? ? ??From what I can see, _stack_traversal_mark is now >> ??????? the only >> ???????? ? ? ? ? ? ? long type in vmStructs.cpp. I don't know that we have a >> ???????? ? ? ? ? ? ? mechanism to safely fetch it on both 32-bit and >> ??????? 64-bit systems. >> >> ???????? ? ? ? ? ? ? _stack_traversal_mark seems to be a long because >> ??????? _traversals >> ???????? ? ? ? ? ? ? is also a long. >> >> ???????? ? ? ? ? ? ? ??? ? static long ??????? _traversals;?????????????????? // >> ???????? ? ? ? ? ? ? Stack scan count, also sweep ID. >> >> ???????? ? ? ? ? ? ? This too might be considered a bug. I'm not sure >> ??????? why you >> ???????? ? ? ? ? ? ? would want the size of this field to vary between >> ??????? 32-bit and >> ???????? ? ? ? ? ? ? 64-bit systems (adding compiler-dev to help answer >> ??????? that). >> >> ???????? ? ? ? ? ? ? So, while I would agree that your fix is generally >> ??????? in the >> ???????? ? ? ? ? ? ? right direction, I think we first need to revisit >> ??????? the use of >> ???????? ? ? ? ? ? ? long for these fields. If they can be changed to an >> ??????? int, >> ???????? ? ? ? ? ? ? then your fix is correct (pending the changes to >> ??????? int). If >> ???????? ? ? ? ? ? ? not, then maybe we need getCLongField() support. >> >> ???????? ? ? ? ? ? ? And lastly, we really should have a test to detect >> ??????? this bug. >> ???????? ? ? ? ? ? ? Maybe we already do, and it is failing but is going >> ???????? ? ? ? ? ? ? unnoticed for some reason. I'll try to look into >> ??????? that some >> ???????? ? ? ? ? ? ? more on Monday. >> >> ???????? ? ? ? ? ? ? thanks, >> >> ???????? ? ? ? ? ? ? Chris >> >> ???????? ? ? ? ? ? ? On 9/16/17 5:20 AM, Yasumasa Suenaga wrote: >> >> ???????? ? ? ? ? ? ? ? ? Hi all, >> >> ???????? ? ? ? ? ? ? ? ? I tried to get thread dump via jstack command >> ??????? on CLHSDB. >> ???????? ? ? ? ? ? ? ? ? But it was failed as below: >> >> ???????? ? ? ? ? ? ? ? ? ``` >> ???????? ? ? ? ? ? ? ? ? Caused by: >> ??????? sun.jvm.hotspot.types.WrongTypeException: >> ???????? ? ? ? ? ? ? ? ? field "_stack_traversal_mark" in type nmethod >> ??????? is not of >> ???????? ? ? ? ? ? ? ? ? type jlong, but instead of type long >> ???????? ? ? ? ? ? ? ? ? ???????? at >> ??????? jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:206) >> ???????? ? ? ? ? ? ? ? ? ???????? at >> ??????? jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:212) >> ???????? ? ? ? ? ? ? ? ? ???????? at >> ??????? jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getJLongField(BasicType.java:249) >> ???????? ? ? ? ? ? ? ? ? ???????? at >> ??????? jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.initialize(NMethod.java:108) >> ???????? ? ? ? ? ? ? ? ? ???????? at >> ??????? jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.access$000(NMethod.java:35) >> ???????? ? ? ? ? ? ? ? ? ???????? at >> ??????? jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod$1.update(NMethod.java:81) >> >> ???????? ? ? ? ? ? ? ? ? ???????? at >> ??????? jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:451) >> ???????? ? ? ? ? ? ? ? ? ???????? at >> ??????? jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.(NMethod.java:79) >> ???????? ? ? ? ? ? ? ? ? ???????? ... 23 more >> ???????? ? ? ? ? ? ? ? ? ``` >> >> ???????? ? ? ? ? ? ? ? ? I think this exception is caused by JDK-8186837. >> ???????? ? ? ? ? ? ? ? ? This changeset has changed the type of >> ???????? ? ? ? ? ? ? ? ? `nmethod::_stack_traversal_mark` to `long` from >> ??????? `jlong`. >> >> ???????? ? ? ? ? ? ? ? ? SA should follow this change. >> >> ???????? ? ? ? ? ? ? ? ? I uploaded a webrev for this issue. This webrev is >> ???????? ? ? ? ? ? ? ? ? generated from consolidated repo (jdk10/master). >> ???????? ? ? ? ? ? ? ? ? Could you review it? >> >> ??????? http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.00/ >> ??????? >> ??????? > ??????? > >> >> >> ???????? ? ? ? ? ? ? ? ? I cannot access JPRT. So I need reviewer. >> >> >> ???????? ? ? ? ? ? ? ? ? Thanks, >> >> ???????? ? ? ? ? ? ? ? ? Yasumasa >> >> >> >> >> >> From yasuenag at gmail.com Wed Sep 20 22:45:43 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 21 Sep 2017 07:45:43 +0900 Subject: PING: JDK-8151815: Could not parse core image with JSnap. In-Reply-To: <7b897b36-1824-606d-b206-df577a6afe02@gmail.com> References: <7b897b36-1824-606d-b206-df577a6afe02@gmail.com> Message-ID: PING: Have you checked this issue? >> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.03/ Yasumasa On 2017/07/01 23:43, Yasumasa Suenaga wrote: > PING: > > Have you checked this issue? > > > Yasumasa > > > On 2017/06/13 14:10, Yasumasa Suenaga wrote: >> Hi all, >> >> I want to discuss about JDK-8151815: Could not parse core image with JSnap. >> >> >> In last year, I found JSnap cannot parse coredump and I've sent review >> request for it as JDK-8151815. However it has not been reviewed yet >> [1]. >> >> We've discussed about safety implementation, but we could not get consensus. >> IMHO all SA tools should be handled java processes and core images, >> and PerfCounter value is useful. So I fix this issue. >> >> I uploaded new webrev for this issue. I think this patch is safety >> because new flag PerfMemory::_destroyed guards double free, and all >> members in PerfMemory is accessible (they are not munmap'ed) >> >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.03/ >> >> >> Can you cooperate? >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-April/019480.html >> From yasuenag at gmail.com Wed Sep 20 22:46:18 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 21 Sep 2017 07:46:18 +0900 Subject: JDK-8153333: [REDO] STW phases at Concurrent GC should count in PerfCounter In-Reply-To: References: Message-ID: <2f4e0901-1602-6276-e7fd-84e168e7b317@gmail.com> PING: Have you checked this issue? >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153333/webrev.03/hotspot/ >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153333/webrev.03/jdk/ Yasumasa On 2017/07/01 23:44, Yasumasa Suenaga wrote: > PING: > > Have you checked this issue? > > > Yasumasa > > > On 2017/06/14 13:22, Yasumasa Suenaga wrote: >> Hi all, >> >> I changed PerfCounter to show CGC STW phase in jstat in JDK-8151674. >> However, it occurred several jtreg test failure, so it was back-outed. >> >> I want to resume to work for this issue. >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153333/webrev.03/hotspot/ >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153333/webrev.03/jdk/ >> >> These changes are work fine on jtreg test as below: >> >> ?? hotspot/test/serviceability/tmtools/jstat >> ?? jdk/test/sun/tools >> >> >> Since JDK 9, default GC algorithm is set to G1. >> So I think this change is useful to watch GC behavior through jstat. >> >> I cannot access JPRT. Could you help? >> >> >> Thanks, >> >> Yasumasa >> From yasuenag at gmail.com Wed Sep 20 22:47:03 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 21 Sep 2017 07:47:03 +0900 Subject: PING: RFR: 8187401: Java Stack cannot be shown on HSDB In-Reply-To: References: Message-ID: PING: Have you checked this issue? > http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ Yasumasa On 2017/09/11 11:16, Yasumasa Suenaga wrote: > Hi all, > > This review request is a part of [1]. > > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8187401 > > webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ > > > I cannot access JPRT. So I need a sponsor. > > > Thanks, > > Yasumasa > > > [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html > From yasuenag at gmail.com Wed Sep 20 22:47:42 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 21 Sep 2017 07:47:42 +0900 Subject: PING: RFR: 8187402: UnknownOopException is occurred on Stack Memory window in HSDB In-Reply-To: References: Message-ID: PING: Have you checked this issue? > http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.00/ Yasumasa On 2017/09/11 11:17, Yasumasa Suenaga wrote: > Hi all, > > This review request is a part of [1]. > > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8187402 > > webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.00/ > > > I cannot access JPRT. So I need a sponsor. > > > Thanks, > > Yasumasa > > > [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html > From yasuenag at gmail.com Wed Sep 20 22:48:22 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 21 Sep 2017 07:48:22 +0900 Subject: PING: RFR: 8187403: [Unknown generation] is shown in Stack Memory on HSDB In-Reply-To: References: Message-ID: <2ee4d0c9-bdd5-19f3-e036-0aa096b59946@gmail.com> PING: Have you checked this issue? > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.00/ Yasumasa On 2017/09/11 11:18, Yasumasa Suenaga wrote: > Hi all, > > This review request is a part of [1]. > > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8187403 > > webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.00/ > > > I cannot access JPRT. So I need a sponsor. > > > Thanks, > > Yasumasa > > > [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html > From yasuenag at gmail.com Wed Sep 20 22:48:56 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 21 Sep 2017 07:48:56 +0900 Subject: PING: RFR: 8175816: SA: HSDB: Compute Liveness results in java.lang.IndexOutOfBoundsException In-Reply-To: <5097216b-f757-dd2b-70bc-b3a860bdebfa@gmail.com> References: <5097216b-f757-dd2b-70bc-b3a860bdebfa@gmail.com> Message-ID: <5a76ed8b-e0aa-6572-86b7-4ac149e30c3d@gmail.com> PING: Have you checked this issue? > http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.00/ Yasumasa On 2017/09/11 22:47, Yasumasa Suenaga wrote: > Hi all, > > This review request is a part of [1]. > > > JBS: > ? https://bugs.openjdk.java.net/browse/JDK-8175816 > > webrev: > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.00/ > > > I cannot access JPRT. So I need a sponsor. > > > Thanks, > > Yasumasa > > > [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html From david.holmes at oracle.com Wed Sep 20 23:35:05 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Sep 2017 09:35:05 +1000 Subject: RFR: JDK-8187597: WrongTypeException is occurred at CLHSDB jstack after JDK-8186837 In-Reply-To: <2c955c17-43b9-906f-408d-f5349d57ca13@gmail.com> References: <39e4a81a-0a12-1ee7-dedb-0b9853d89fce@gmail.com> <6f369ad1-ee23-32b1-37ae-3bb60629960c@gmail.com> <9bfc8e1d-8438-21f2-3c06-e53bb95afb6c@oracle.com> <0ee1ed46-5c27-8693-fb6d-396a3059335e@oracle.com> <13b177d1-e04c-dd86-7a86-b55b165d5830@oracle.com> <2c955c17-43b9-906f-408d-f5349d57ca13@gmail.com> Message-ID: The opening announcement was somewhat premature. They created jdk10/hs but we're not quite ready to start accepting changes yet. David On 21/09/2017 8:44 AM, Yasumasa Suenaga wrote: > Hi David, > > jdk10/hs has been opened [1]. > Could you push this change? > > > Thanks, > > Yasumasa > > > [1] > http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-September/000499.html > > > On 2017/09/19 12:31, David Holmes wrote: >> On 19/09/2017 1:19 PM, Yasumasa Suenaga wrote: >>> Thanks David, >>> >>> BTW, can I push this change after jdk10/master is opened? >>> I cannot access JPRT. >> >> I think we'd probably prefer this to go into jdk10/hs - once it is >> open - and for that you need a sponsor. >> >> Thanks, >> David >> >>> >>> Yasumasa >>> >>> >>> 2017/09/19 ??0:08 "David Holmes" >> >: >>> >>> ??? Hi Yasumasa, >>> >>> ??? On 19/09/2017 12:55 PM, Yasumasa Suenaga wrote: >>> >>> ??????? Thanks Chris, Robbin, >>> >>> ??????? I'm waiting reviewer(s) for this change. >>> >>> >>> ??? Reviewed. >>> >>> ??? This simply reverts the change of 8185102. >>> >>> ??? Thanks, >>> ??? David >>> ??? ----- >>> >>> >>> ??????? Yasumasa >>> >>> >>> ??????? 2017/09/19 ??7:14 "Chris Plummer" >> ??????? >>> ??????? >> ??????? >>: >>> >>> ???????? ? ? Hi Yasumasa, >>> >>> ???????? ? ? Ok, I see now that CIntegerField is just an interface, so >>> ??????? it's up to >>> ???????? ? ? a class to implement getValue() to fetch the field. I'm >>> a bit >>> ???????? ? ? unclear on how that part works, but from responses by >>> ??????? others, it >>> ???????? ? ? seems this is ok. >>> >>> ???????? ? ? I've run all the tests I can find that use jstack or jhsdb, >>> ??????? and the >>> ???????? ? ? assert was not triggered. Probably need to have a NMethod >>> ??????? on the >>> ???????? ? ? stack to trigger the code you are fixing. >>> >>> ???????? ? ? thanks, >>> >>> ???????? ? ? Chris >>> >>> >>> ???????? ? ? On 9/17/17 1:13 AM, Yasumasa Suenaga wrote: >>> >>> ???????? ? ? ? ? Hi Chris, >>> >>> ???????? ? ? ? ? I've tested this issue on Fedora 26 x86_64. >>> ???????? ? ? ? ? I think we can sue CIntegerField at this point because >>> ???????? ? ? ? ? CIntegerField is not specialized for various int >>> size [1]. >>> ???????? ? ? ? ? In fact, CIntegerField had been used at this point [2], >>> ??????? and HSDB >>> ???????? ? ? ? ? worked fine. >>> >>> >>> ???????? ? ? ? ? Thanks, >>> >>> ???????? ? ? ? ? Yasumasa >>> >>> >>> ???????? ? ? ? ? [1] >>> >>> http://hg.openjdk.java.net/jdk10/master/file/fd36993f7bf5/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/CIntegerField.java#l29 >>> >>> >>> >>> >>> >>> >> >>> >>> > >>> >>> ???????? ? ? ? ? [2] >>> ??????? http://hg.openjdk.java.net/jdk10/master/rev/cbfdbefc6ea3 >>> ??????? >>> ??????? >> ??????? > >>> >>> >>> ???????? ? ? ? ? On 2017/09/17 3:58, Chris Plummer wrote: >>> >>> ???????? ? ? ? ? ? ? Hi Yasumasa, >>> >>> ???????? ? ? ? ? ? ? Is this on a 32-bit system? I don't see how you >>> could >>> ???????? ? ? ? ? ? ? otherwise call getCIntegerField() on a long type. >>> ??????? jlong is >>> ???????? ? ? ? ? ? ? always 64-bit and long is (generally) 32-bit on >>> 32-bit >>> ???????? ? ? ? ? ? ? systems, and 64-bit on 64-bit systems, at least >>> ??????? that seems >>> ???????? ? ? ? ? ? ? to be the case with linux. >>> >>> ???????? ? ? ? ? ? ? ??From what I can see, _stack_traversal_mark is now >>> ??????? the only >>> ???????? ? ? ? ? ? ? long type in vmStructs.cpp. I don't know that we >>> have a >>> ???????? ? ? ? ? ? ? mechanism to safely fetch it on both 32-bit and >>> ??????? 64-bit systems. >>> >>> ???????? ? ? ? ? ? ? _stack_traversal_mark seems to be a long because >>> ??????? _traversals >>> ???????? ? ? ? ? ? ? is also a long. >>> >>> ???????? ? ? ? ? ? ? ??? ? static long >>> _traversals;?????????????????? // >>> ???????? ? ? ? ? ? ? Stack scan count, also sweep ID. >>> >>> ???????? ? ? ? ? ? ? This too might be considered a bug. I'm not sure >>> ??????? why you >>> ???????? ? ? ? ? ? ? would want the size of this field to vary between >>> ??????? 32-bit and >>> ???????? ? ? ? ? ? ? 64-bit systems (adding compiler-dev to help answer >>> ??????? that). >>> >>> ???????? ? ? ? ? ? ? So, while I would agree that your fix is generally >>> ??????? in the >>> ???????? ? ? ? ? ? ? right direction, I think we first need to revisit >>> ??????? the use of >>> ???????? ? ? ? ? ? ? long for these fields. If they can be changed to an >>> ??????? int, >>> ???????? ? ? ? ? ? ? then your fix is correct (pending the changes to >>> ??????? int). If >>> ???????? ? ? ? ? ? ? not, then maybe we need getCLongField() support. >>> >>> ???????? ? ? ? ? ? ? And lastly, we really should have a test to detect >>> ??????? this bug. >>> ???????? ? ? ? ? ? ? Maybe we already do, and it is failing but is going >>> ???????? ? ? ? ? ? ? unnoticed for some reason. I'll try to look into >>> ??????? that some >>> ???????? ? ? ? ? ? ? more on Monday. >>> >>> ???????? ? ? ? ? ? ? thanks, >>> >>> ???????? ? ? ? ? ? ? Chris >>> >>> ???????? ? ? ? ? ? ? On 9/16/17 5:20 AM, Yasumasa Suenaga wrote: >>> >>> ???????? ? ? ? ? ? ? ? ? Hi all, >>> >>> ???????? ? ? ? ? ? ? ? ? I tried to get thread dump via jstack command >>> ??????? on CLHSDB. >>> ???????? ? ? ? ? ? ? ? ? But it was failed as below: >>> >>> ???????? ? ? ? ? ? ? ? ? ``` >>> ???????? ? ? ? ? ? ? ? ? Caused by: >>> ??????? sun.jvm.hotspot.types.WrongTypeException: >>> ???????? ? ? ? ? ? ? ? ? field "_stack_traversal_mark" in type nmethod >>> ??????? is not of >>> ???????? ? ? ? ? ? ? ? ? type jlong, but instead of type long >>> ???????? ? ? ? ? ? ? ? ? ???????? at >>> >>> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:206) >>> >>> ???????? ? ? ? ? ? ? ? ? ???????? at >>> >>> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:212) >>> >>> ???????? ? ? ? ? ? ? ? ? ???????? at >>> >>> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getJLongField(BasicType.java:249) >>> >>> ???????? ? ? ? ? ? ? ? ? ???????? at >>> >>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.initialize(NMethod.java:108) >>> >>> ???????? ? ? ? ? ? ? ? ? ???????? at >>> >>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.access$000(NMethod.java:35) >>> >>> ???????? ? ? ? ? ? ? ? ? ???????? at >>> >>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod$1.update(NMethod.java:81) >>> >>> ???????? ? ? ? ? ? ? ? ? ???????? at >>> >>> jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:451) >>> >>> ???????? ? ? ? ? ? ? ? ? ???????? at >>> >>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.(NMethod.java:79) >>> ???????? ? ? ? ? ? ? ? ? ???????? ... 23 more >>> ???????? ? ? ? ? ? ? ? ? ``` >>> >>> ???????? ? ? ? ? ? ? ? ? I think this exception is caused by >>> JDK-8186837. >>> ???????? ? ? ? ? ? ? ? ? This changeset has changed the type of >>> ???????? ? ? ? ? ? ? ? ? `nmethod::_stack_traversal_mark` to `long` from >>> ??????? `jlong`. >>> >>> ???????? ? ? ? ? ? ? ? ? SA should follow this change. >>> >>> ???????? ? ? ? ? ? ? ? ? I uploaded a webrev for this issue. This >>> webrev is >>> ???????? ? ? ? ? ? ? ? ? generated from consolidated repo >>> (jdk10/master). >>> ???????? ? ? ? ? ? ? ? ? Could you review it? >>> >>> ??????? http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.00/ >>> ??????? >>> ??????? >> ??????? > >>> >>> >>> ???????? ? ? ? ? ? ? ? ? I cannot access JPRT. So I need reviewer. >>> >>> >>> ???????? ? ? ? ? ? ? ? ? Thanks, >>> >>> ???????? ? ? ? ? ? ? ? ? Yasumasa >>> >>> >>> >>> >>> >>> From yasuenag at gmail.com Wed Sep 20 23:57:57 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 21 Sep 2017 08:57:57 +0900 Subject: RFR: JDK-8187597: WrongTypeException is occurred at CLHSDB jstack after JDK-8186837 In-Reply-To: References: <39e4a81a-0a12-1ee7-dedb-0b9853d89fce@gmail.com> <6f369ad1-ee23-32b1-37ae-3bb60629960c@gmail.com> <9bfc8e1d-8438-21f2-3c06-e53bb95afb6c@oracle.com> <0ee1ed46-5c27-8693-fb6d-396a3059335e@oracle.com> <13b177d1-e04c-dd86-7a86-b55b165d5830@oracle.com> <2c955c17-43b9-906f-408d-f5349d57ca13@gmail.com> Message-ID: 2017/09/21 ??8:35 "David Holmes" : The opening announcement was somewhat premature. They created jdk10/hs but we're not quite ready to start accepting changes yet. Where can I get the opening announcement for jdk10/hs? I will send review request after that. Thanks, Yasumasa David On 21/09/2017 8:44 AM, Yasumasa Suenaga wrote: > Hi David, > > jdk10/hs has been opened [1]. > Could you push this change? > > > Thanks, > > Yasumasa > > > [1] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-Septem > ber/000499.html > > > On 2017/09/19 12:31, David Holmes wrote: > >> On 19/09/2017 1:19 PM, Yasumasa Suenaga wrote: >> >>> Thanks David, >>> >>> BTW, can I push this change after jdk10/master is opened? >>> I cannot access JPRT. >>> >> >> I think we'd probably prefer this to go into jdk10/hs - once it is open - >> and for that you need a sponsor. >> >> Thanks, >> David >> >> >>> Yasumasa >>> >>> >>> 2017/09/19 ??0:08 "David Holmes" >> david.holmes at oracle.com>>: >>> >>> Hi Yasumasa, >>> >>> On 19/09/2017 12:55 PM, Yasumasa Suenaga wrote: >>> >>> Thanks Chris, Robbin, >>> >>> I'm waiting reviewer(s) for this change. >>> >>> >>> Reviewed. >>> >>> This simply reverts the change of 8185102. >>> >>> Thanks, >>> David >>> ----- >>> >>> >>> Yasumasa >>> >>> >>> 2017/09/19 ??7:14 "Chris Plummer" >> >>> >> >>: >>> >>> Hi Yasumasa, >>> >>> Ok, I see now that CIntegerField is just an interface, so >>> it's up to >>> a class to implement getValue() to fetch the field. I'm a >>> bit >>> unclear on how that part works, but from responses by >>> others, it >>> seems this is ok. >>> >>> I've run all the tests I can find that use jstack or jhsdb, >>> and the >>> assert was not triggered. Probably need to have a NMethod >>> on the >>> stack to trigger the code you are fixing. >>> >>> thanks, >>> >>> Chris >>> >>> >>> On 9/17/17 1:13 AM, Yasumasa Suenaga wrote: >>> >>> Hi Chris, >>> >>> I've tested this issue on Fedora 26 x86_64. >>> I think we can sue CIntegerField at this point because >>> CIntegerField is not specialized for various int size >>> [1]. >>> In fact, CIntegerField had been used at this point [2], >>> and HSDB >>> worked fine. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> http://hg.openjdk.java.net/jdk10/master/file/fd36993f7bf5/ >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/ >>> CIntegerField.java#l29 >>> >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/ >>> CIntegerField.java#l29> >>> >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/ >>> CIntegerField.java#l29 >>> >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/ >>> CIntegerField.java#l29>> >>> [2] >>> http://hg.openjdk.java.net/jdk10/master/rev/cbfdbefc6ea3 >>> >>> >> > >>> >>> >>> On 2017/09/17 3:58, Chris Plummer wrote: >>> >>> Hi Yasumasa, >>> >>> Is this on a 32-bit system? I don't see how you >>> could >>> otherwise call getCIntegerField() on a long type. >>> jlong is >>> always 64-bit and long is (generally) 32-bit on >>> 32-bit >>> systems, and 64-bit on 64-bit systems, at least >>> that seems >>> to be the case with linux. >>> >>> From what I can see, _stack_traversal_mark is now >>> the only >>> long type in vmStructs.cpp. I don't know that we >>> have a >>> mechanism to safely fetch it on both 32-bit and >>> 64-bit systems. >>> >>> _stack_traversal_mark seems to be a long because >>> _traversals >>> is also a long. >>> >>> static long >>> _traversals; // >>> Stack scan count, also sweep ID. >>> >>> This too might be considered a bug. I'm not sure >>> why you >>> would want the size of this field to vary between >>> 32-bit and >>> 64-bit systems (adding compiler-dev to help answer >>> that). >>> >>> So, while I would agree that your fix is generally >>> in the >>> right direction, I think we first need to revisit >>> the use of >>> long for these fields. If they can be changed to an >>> int, >>> then your fix is correct (pending the changes to >>> int). If >>> not, then maybe we need getCLongField() support. >>> >>> And lastly, we really should have a test to detect >>> this bug. >>> Maybe we already do, and it is failing but is going >>> unnoticed for some reason. I'll try to look into >>> that some >>> more on Monday. >>> >>> thanks, >>> >>> Chris >>> >>> On 9/16/17 5:20 AM, Yasumasa Suenaga wrote: >>> >>> Hi all, >>> >>> I tried to get thread dump via jstack command >>> on CLHSDB. >>> But it was failed as below: >>> >>> ``` >>> Caused by: >>> sun.jvm.hotspot.types.WrongTypeException: >>> field "_stack_traversal_mark" in type nmethod >>> is not of >>> type jlong, but instead of type long >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:206) >>> >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:212) >>> >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getJLongField(BasicType.java:249) >>> >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.initialize(NMethod.java:108) >>> >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.access$000(NMethod.java:35) >>> >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod$1.update(NMet >>> hod.java:81) >>> >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:451) >>> >>> at >>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.(NMet >>> hod.java:79) >>> ... 23 more >>> ``` >>> >>> I think this exception is caused by JDK-8186837. >>> This changeset has changed the type of >>> `nmethod::_stack_traversal_mark` to `long` from >>> `jlong`. >>> >>> SA should follow this change. >>> >>> I uploaded a webrev for this issue. This webrev >>> is >>> generated from consolidated repo (jdk10/master). >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.00/ >>> >>> >> > >>> >>> >>> I cannot access JPRT. So I need reviewer. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> >>> >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Sep 21 00:31:47 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Sep 2017 10:31:47 +1000 Subject: RFR: JDK-8187597: WrongTypeException is occurred at CLHSDB jstack after JDK-8186837 In-Reply-To: References: <39e4a81a-0a12-1ee7-dedb-0b9853d89fce@gmail.com> <6f369ad1-ee23-32b1-37ae-3bb60629960c@gmail.com> <9bfc8e1d-8438-21f2-3c06-e53bb95afb6c@oracle.com> <0ee1ed46-5c27-8693-fb6d-396a3059335e@oracle.com> <13b177d1-e04c-dd86-7a86-b55b165d5830@oracle.com> <2c955c17-43b9-906f-408d-f5349d57ca13@gmail.com> Message-ID: On 21/09/2017 9:57 AM, Yasumasa Suenaga wrote: > 2017/09/21 ??8:35 "David Holmes" >: > > The opening announcement was somewhat premature. They created > jdk10/hs but we're not quite ready to start accepting changes yet. > > > Where can I get the opening announcement for jdk10/hs? hotspot-dev > I will send review request after that. You will need to rebase all your patches before they can be sponsored. Thanks, David > > Thanks, > > Yasumasa > > > > David > > > On 21/09/2017 8:44 AM, Yasumasa Suenaga wrote: > > Hi David, > > jdk10/hs has been opened [1]. > Could you push this change? > > > Thanks, > > Yasumasa > > > [1] > http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-September/000499.html > > > > On 2017/09/19 12:31, David Holmes wrote: > > On 19/09/2017 1:19 PM, Yasumasa Suenaga wrote: > > Thanks David, > > BTW, can I push this change after jdk10/master is opened? > I cannot access JPRT. > > > I think we'd probably prefer this to go into jdk10/hs - once > it is open - and for that you need a sponsor. > > Thanks, > David > > > Yasumasa > > > 2017/09/19 ??0:08 "David Holmes" > > >>: > > ??? Hi Yasumasa, > > ??? On 19/09/2017 12:55 PM, Yasumasa Suenaga wrote: > > ??????? Thanks Chris, Robbin, > > ??????? I'm waiting reviewer(s) for this change. > > > ??? Reviewed. > > ??? This simply reverts the change of 8185102. > > ??? Thanks, > ??? David > ??? ----- > > > ??????? Yasumasa > > > ??????? 2017/09/19 ??7:14 "Chris Plummer" > > ??????? > > ??????? > ??????? >>>: > > ???????? ? ? Hi Yasumasa, > > ???????? ? ? Ok, I see now that CIntegerField is just > an interface, so > ??????? it's up to > ???????? ? ? a class to implement getValue() to fetch > the field. I'm a bit > ???????? ? ? unclear on how that part works, but from > responses by > ??????? others, it > ???????? ? ? seems this is ok. > > ???????? ? ? I've run all the tests I can find that use > jstack or jhsdb, > ??????? and the > ???????? ? ? assert was not triggered. Probably need to > have a NMethod > ??????? on the > ???????? ? ? stack to trigger the code you are fixing. > > ???????? ? ? thanks, > > ???????? ? ? Chris > > > ???????? ? ? On 9/17/17 1:13 AM, Yasumasa Suenaga wrote: > > ???????? ? ? ? ? Hi Chris, > > ???????? ? ? ? ? I've tested this issue on Fedora 26 > x86_64. > ???????? ? ? ? ? I think we can sue CIntegerField at > this point because > ???????? ? ? ? ? CIntegerField is not specialized for > various int size [1]. > ???????? ? ? ? ? In fact, CIntegerField had been used > at this point [2], > ??????? and HSDB > ???????? ? ? ? ? worked fine. > > > ???????? ? ? ? ? Thanks, > > ???????? ? ? ? ? Yasumasa > > > ???????? ? ? ? ? [1] > http://hg.openjdk.java.net/jdk10/master/file/fd36993f7bf5/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/CIntegerField.java#l29 > > > > > > > > > > > >> > > ???????? ? ? ? ? [2] > http://hg.openjdk.java.net/jdk10/master/rev/cbfdbefc6ea3 > > > > > > > > >> > > > ???????? ? ? ? ? On 2017/09/17 3:58, Chris Plummer wrote: > > ???????? ? ? ? ? ? ? Hi Yasumasa, > > ???????? ? ? ? ? ? ? Is this on a 32-bit system? I > don't see how you could > ???????? ? ? ? ? ? ? otherwise call getCIntegerField() > on a long type. > ??????? jlong is > ???????? ? ? ? ? ? ? always 64-bit and long is > (generally) 32-bit on 32-bit > ???????? ? ? ? ? ? ? systems, and 64-bit on 64-bit > systems, at least > ??????? that seems > ???????? ? ? ? ? ? ? to be the case with linux. > > ???????? ? ? ? ? ? ? ??From what I can see, > _stack_traversal_mark is now > ??????? the only > ???????? ? ? ? ? ? ? long type in vmStructs.cpp. I > don't know that we have a > ???????? ? ? ? ? ? ? mechanism to safely fetch it on > both 32-bit and > ??????? 64-bit systems. > > ???????? ? ? ? ? ? ? _stack_traversal_mark seems to be > a long because > ??????? _traversals > ???????? ? ? ? ? ? ? is also a long. > > ???????? ? ? ? ? ? ? ??? ? static long > ?_traversals; ? // > ???????? ? ? ? ? ? ? Stack scan count, also sweep ID. > > ???????? ? ? ? ? ? ? This too might be considered a > bug. I'm not sure > ??????? why you > ???????? ? ? ? ? ? ? would want the size of this field > to vary between > ??????? 32-bit and > ???????? ? ? ? ? ? ? 64-bit systems (adding > compiler-dev to help answer > ??????? that). > > ???????? ? ? ? ? ? ? So, while I would agree that your > fix is generally > ??????? in the > ???????? ? ? ? ? ? ? right direction, I think we first > need to revisit > ??????? the use of > ???????? ? ? ? ? ? ? long for these fields. If they can > be changed to an > ??????? int, > ???????? ? ? ? ? ? ? then your fix is correct (pending > the changes to > ??????? int). If > ???????? ? ? ? ? ? ? not, then maybe we need > getCLongField() support. > > ???????? ? ? ? ? ? ? And lastly, we really should have > a test to detect > ??????? this bug. > ???????? ? ? ? ? ? ? Maybe we already do, and it is > failing but is going > ???????? ? ? ? ? ? ? unnoticed for some reason. I'll > try to look into > ??????? that some > ???????? ? ? ? ? ? ? more on Monday. > > ???????? ? ? ? ? ? ? thanks, > > ???????? ? ? ? ? ? ? Chris > > ???????? ? ? ? ? ? ? On 9/16/17 5:20 AM, Yasumasa > Suenaga wrote: > > ???????? ? ? ? ? ? ? ? ? Hi all, > > ???????? ? ? ? ? ? ? ? ? I tried to get thread dump via > jstack command > ??????? on CLHSDB. > ???????? ? ? ? ? ? ? ? ? But it was failed as below: > > ???????? ? ? ? ? ? ? ? ? ``` > ???????? ? ? ? ? ? ? ? ? Caused by: > ??????? sun.jvm.hotspot.types.WrongTypeException: > ???????? ? ? ? ? ? ? ? ? field "_stack_traversal_mark" > in type nmethod > ??????? is not of > ???????? ? ? ? ? ? ? ? ? type jlong, but instead of > type long > ???????? ? ? ? ? ? ? ? ? ???????? at > > jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:206) > > ???????? ? ? ? ? ? ? ? ? ???????? at > > jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:212) > > ???????? ? ? ? ? ? ? ? ? ???????? at > > jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getJLongField(BasicType.java:249) > > ???????? ? ? ? ? ? ? ? ? ???????? at > > jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.initialize(NMethod.java:108) > > ???????? ? ? ? ? ? ? ? ? ???????? at > > jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.access$000(NMethod.java:35) > > ???????? ? ? ? ? ? ? ? ? ???????? at > > jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod$1.update(NMethod.java:81) > > ???????? ? ? ? ? ? ? ? ? ???????? at > > jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:451) > > ???????? ? ? ? ? ? ? ? ? ???????? at > > jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.(NMethod.java:79) > ???????? ? ? ? ? ? ? ? ? ???????? ... 23 more > ???????? ? ? ? ? ? ? ? ? ``` > > ???????? ? ? ? ? ? ? ? ? I think this exception is > caused by JDK-8186837. > ???????? ? ? ? ? ? ? ? ? This changeset has changed the > type of > > `nmethod::_stack_traversal_mark` to `long` from > ??????? `jlong`. > > ???????? ? ? ? ? ? ? ? ? SA should follow this change. > > ???????? ? ? ? ? ? ? ? ? I uploaded a webrev for this > issue. This webrev is > ???????? ? ? ? ? ? ? ? ? generated from consolidated > repo (jdk10/master). > ???????? ? ? ? ? ? ? ? ? Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.00/ > > > > > > > > >> > > > ???????? ? ? ? ? ? ? ? ? I cannot access JPRT. So I > need reviewer. > > > ???????? ? ? ? ? ? ? ? ? Thanks, > > ???????? ? ? ? ? ? ? ? ? Yasumasa > > > > > > > From jini.george at oracle.com Thu Sep 21 14:36:39 2017 From: jini.george at oracle.com (Jini George) Date: Thu, 21 Sep 2017 20:06:39 +0530 Subject: jdk9 can not load sa.js automatically in jhsdb In-Reply-To: References: Message-ID: <033703fc-ac75-3569-5be4-6de48e6070fd@oracle.com> Hi Liu Xin, No, this is not a wrong usage on your part. You are facing the following issue: https://bugs.openjdk.java.net/browse/JDK-8157947 So, at this point, till this is fixed, you would face issues if you try to run commands based on the the javascript interface with jhsdb. Thanks, Jini. On 9/17/2017 1:36 PM, Liu Xin wrote: > Hello, serviceability mail-list, > > Jdk9 refactored the CLI for hsdb. I try to catch you up. With the > latest openjdk9 build, I always meet the following message when I want > to use 'console' in GUI. > > ./jhsdb hsdb > //attach pid > //windows/console > javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is not a > function in sa.js at line number 54 > Warning! JS Engine can't start, some commands will not be available > > I quickly look at it. It seems that it has problem to load 'sa.js'. > // SA singletons are kept in 'sa' object > var sa = new Object(); > sa.vm = sapkg.runtime.VM.getVM(); > sa.dbg = sa.vm.getDebugger(); > sa.cdbg = sa.dbg.CDebugger; > > I strongly suspect that it didn't invoke > sun.jvm.hotspot.runtime.VM.initialize before loading the sa.js. > is it intentional or just wrong usage of mine? > > Please note that I did build nashorn and jjs works perfectly. I can > reproduce this problem on linux and macosx. > > I took reference of the doc of clhsdb shipping with hotspot source code: > hotspot/src/jdk.hotspot.agent/doc/clhsdb.html > is it out of date? I found it NOT 'Few CLHSDB commands are already > implemented in JavaScript.' > > thanks, > --lx > From jcbeyler at google.com Fri Sep 22 03:09:55 2017 From: jcbeyler at google.com (JC Beyler) Date: Thu, 21 Sep 2017 20:09:55 -0700 Subject: When does MONITOR_WAITED get thrown? In-Reply-To: <0a20173f-6f3d-7f85-6a36-1cc55cd8e9d0@oracle.com> References: <0a20173f-6f3d-7f85-6a36-1cc55cd8e9d0@oracle.com> Message-ID: Hi David, It does explain it, thanks for your detailed explanations :) I'll come back if I have more questions but I think I'm good! Thanks again and have a great weekend! Thanks, Jc On Tue, Sep 19, 2017 at 3:01 PM, David Holmes wrote: > Hi Jc, > > On 20/09/2017 2:26 AM, JC Beyler wrote: > >> Hi David, >> >> First off, thanks for looking at this case! I really apologize for my >> example being difficult to follow. I hope you won't mind if I try again :). >> >> The question is less about ordering and more on the fact that sometimes >> the MONITOR_WAITED does not get emitted it seems depending on what is >> happening for the MONITOR_WAIT event. Let me give a full working code at >> the bottom of this that show cases my question/issue. >> >> Basically, there are three cases I can think of for this test: >> >> 1) The MONITOR_WAIT callback throws an illegal exception (or another >> exception I expect would have the same issue) >> 2) The actual call from Java world to the wait is illegal due to a >> negative value for example: thread.wait(-100) AND the MONITOR_WAIT callback >> throws an illegal exception >> 3) The actual call from Java world to the wait is illegal due to a >> negative value for example: thread.wait(-100) AND the MONITOR_WAIT callback >> does not throw an exception >> >> >> What I've noticed is that the behavior is slightly different depending on >> the case: >> >> 1) In the case 1 above, we get a MONITOR_WAITED event >> 2) In the case 2 above, we get exactly the same error and I believe that >> probably because we check the argument to wait after doing the callback to >> MONITOR_WAIT; however we get MONITOR_WAITED callback at all >> 3) In the case 3 above, however, we get an illegal argument due to the >> -100 for the wait call, however we do get a MONITOR_WAITED callback. >> > > First it is a bug that wait(-100) triggers any JVM TI events. The > IllegalArgumentException should be thrown at the Java level - and indeed > this has just been fixed. (Try using wait(-100,0) instead to see this.) > > That aside, for wait(-100) you will get a MONITOR_WAIT event, then the > throwing of the IllegalArgumentException. You will never see MONITOR_WAITED > with respect to an illegal call to wait() - we simply never hit the code > that does the waiting and posts the event. (If you do see MONITOR_WAITED > then it may well be for a different wait() call.) > > If the MONITOR_WAIT handler itself posts an exception, and the wait() call > is illegal then the IllegalArgumentException will replace the exception > posted by the handler. > > If the handler posts an exception and the call to wait is legal then it is > as you describe below ... > > My question is really the following: >> >> - Should we not have the same behavior (Whatever that may be by the way) >> in all three cases? In all three cases, we do not wait due to an exception >> being thrown but 2 out of 3 do not have a MONITOR_WAITED event sent out. >> >> - When I look at the code, why this is happening is because the code >> seems to be doing this: >> >> Do the JVM_MonitorWait in jvm.cpp >> A) post the monitor wait callback >> B) Do the actual wait via ObjectSynchronizer >> i) Check the argument in ObjectSynchronizer::wait >> (src/share/vm/runtime/synchronizer.cpp) >> 1) All good? Go in ObjectMonitor::wait >> (src/share/vm/runtime/objectMonitor.cpp) >> - Check if the JNI threw, bail there after posting for waited >> > > Other than if the thread is interrupted I don't see any check for a > pending exception. So the wait() happens, the MONITOR_WAITED is posted, and > eventually the pending exception from the MONITOR_WAIT is detected and > thrown. > > 2) Not good? bail without throwing >> > > If the timeout is illegal it posts the IllegalArgumentException and > returns. > > The JVM TI spec says very little about exceptions and event callback > handlers, other than being careful not to lose existing pending exceptions. > In particular the fact there may be an exception pending, whether from the > handler or other source, does not influence subsequent event handling > directly - but obviously the logic in the VM that checks for pending > exceptions will affect whether certain callback points can be reached if an > exception is pending. > > Does this explain what you observe? > > Cheers, > David > ------ > > >> >> Note: I've added the whole code below and refactored it so that the >> output is more clear and you have all cases together in one code (I >> augmented the sleep to 5 seconds to make it clear :)): >> >> Thanks for your help, >> Jc >> >> >> ------------------------------------------------------------ >> -------------------------- >> >> >> A) Here is the agent code: >> #include >> #include >> #include >> >> static void JNICALL >> monitor_wait(jvmtiEnv* jvmti, JNIEnv *env, >> jthread thread, jobject object, jlong timeout) { >> fprintf(stderr, "Waiting!\n"); >> >> // Throw only every other time the first few times, then never again >> (Works out well for the Java test :)): >> // - We want it to throw the first wait but not the first join. >> // - We want it to throw the second wait but not the second join. >> // - We want it to no longer throw at all. >> static int cnt = 0; >> if (cnt++ % 2 == 0 && cnt < 4) { >> jclass newExcCls = env->FindClass("java/lang/Ille >> galArgumentException"); >> // Unable to find the new exception class, give up. >> if (newExcCls == 0) { >> return; >> } >> env->ThrowNew(newExcCls, "Exception from monitor_wait"); >> } >> } >> >> static void JNICALL >> monitor_waited(jvmtiEnv* jvmti, JNIEnv *env, >> jthread thread, jobject object, jboolean timed_out) { >> fprintf(stderr, "Waited!\n"); >> } >> >> extern "C" JNIEXPORT jint JNICALL Agent_OnLoad(JavaVM *jvm, char *options, >> void *reserved) { >> int ernum; >> >> jvmtiEnv *jvmti; >> if (jvm->GetEnv(reinterpret_cast(&jvmti), JVMTI_VERSION) != >> JNI_OK) { >> return JNI_ERR; >> } >> >> jvmtiEventCallbacks callbacks; >> memset(&callbacks, 0, sizeof(callbacks)); >> callbacks.MonitorWait = &monitor_wait; >> callbacks.MonitorWaited = &monitor_waited; >> >> jvmtiCapabilities caps; >> memset(&caps, 0, sizeof(caps)); >> caps.can_generate_monitor_events = 1; >> >> ernum = jvmti->AddCapabilities(&caps); >> ernum = jvmti->SetEventCallbacks(&callbacks, >> sizeof(jvmtiEventCallbacks)); >> ernum = jvmti->SetEventNotificationMode(JVMTI_ENABLE, >> JVMTI_EVENT_MONITOR_WAIT, NULL); >> ernum = jvmti->SetEventNotificationMode(JVMTI_ENABLE, >> JVMTI_EVENT_MONITOR_WAITED, NULL); >> >> return ernum; >> } >> >> B) Here is the Java code, it's a bit long but I added comments and made >> it clear (I really hope :)): >> >> public class Main extends Thread { >> public static void main(String[] args) { >> >> for (int i = 0; i < 3; i++) { >> SecondThread st = new SecondThread("first"); >> >> synchronized (st) { >> st.start(); >> >> System.err.println("Starting with simple wait"); >> try { >> st.wait(); >> } catch(Exception e) { >> System.out.println("Here we got a monitor_waited call, the >> underlying monitor_wait callback threw: " + e); >> } >> >> System.err.println("\n\nJoining so wait/waited will show"); >> try { >> st.join(); >> } catch(Exception e) { >> System.err.println("Join exception, not intended for this test: >> " + e); >> } >> } >> >> st = new SecondThread("second"); >> >> synchronized (st) { >> st.start(); >> >> System.err.println("\n\nStarting with negative wait"); >> try { >> st.wait(-100); >> } catch(Exception e) { >> System.err.println("Here we did not get a callback to >> monitor_waited though same exception as above: " + e); >> } >> >> System.err.println("\n\nJoining so wait/waited will show"); >> try { >> st.join(); >> } catch(Exception e) { >> System.err.println("Join exception, not intended for this test: >> " + e); >> } >> } >> >> st = new SecondThread("third"); >> >> synchronized (st) { >> st.start(); >> >> System.err.println("\n\nStarting with simple wait, monitor_wait >> won't throw anymore"); >> try { >> st.wait(-100); >> } catch(Exception e) { >> System.err.println("Here we did not get a callback to >> monitor_waited though different exception as above: " + e); >> } >> >> System.err.println("\n\nJoining so wait/waited will show"); >> try { >> st.join(); >> } catch(Exception e) { >> System.err.println("Join exception, not intended for this test: >> " + e); >> } >> } >> >> System.out.println("Done"); >> } >> } >> >> class SecondThread extends Thread { >> private String name; >> >> public SecondThread(String name) { >> this.name = name; >> >> } >> >> public void run() { >> try { >> Thread.sleep(5000); >> } catch(Exception e) { >> System.err.println(e); >> } >> System.err.println("Hello from " + name); >> } >> } >> >> C) The output I get is: >> Starting with simple wait >> Waiting! >> Waited! >> Here we got a monitor_waited call, the underlying monitor_wait callback >> threw: java.lang.IllegalArgumentException: Exception from monitor_wait >> >> >> Joining so wait/waited will show >> Waiting! >> Hello from first >> Waited! >> >> >> Starting with negative wait >> Waiting! >> Here we did not get a callback to monitor_waited though same exception as >> above: java.lang.IllegalArgumentException: Exception from monitor_wait >> >> >> Joining so wait/waited will show >> Waiting! >> Hello from second >> Waited! >> >> >> Starting with simple wait, monitor_wait won't throw anymore >> Waiting! >> Here we did not get a callback to monitor_waited though different >> exception as above: java.lang.IllegalArgumentException: timeout value is >> negative >> >> >> Joining so wait/waited will show >> Waiting! >> Hello from third >> Waited! >> Done >> >> >> On Mon, Sep 18, 2017 at 3:04 PM, David Holmes > > wrote: >> >> Hi Jc, >> >> I found your example very difficult to follow. AFAICS you will >> potentially encounter monitor related events that are unrelated to >> the st.wait in your test code. And there are races in the test - as >> soon as st.wait releases the monitor lock then SecondThread can run, >> complete the sleep and print "Hello from A". I don't think it is >> specified exactly when the MONIOR_WAIT event is sent with respect to >> the releasing of the monitor lock. >> >> David >> >> >> On 19/09/2017 3:45 AM, JC Beyler wrote: >> >> Hi all, >> >> When looking at the documentation of >> https://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti. >> html#MonitorWaited >> > html#MonitorWaited> >> , I see the following description: >> "Sent when a thread finishes waiting on an object." >> >> However, there seems to be a slight issue when the MONITOR_WAIT >> event handler throws an exception. >> >> Consider the following code: >> >> A) The monitor wait handler throws >> >> static void JNICALL >> monitor_wait(jvmtiEnv* jvmti, JNIEnv *env, >> jthread thread, jobject object, jlong timeout) { >> fprintf(stderr, "Waiting!\n"); >> >> jclass newExcCls = >> env->FindClass("java/lang/IllegalArgumentException"); >> // Unable to find the new exception class, give up. >> if (newExcCls == 0) { >> return; >> } >> env->ThrowNew(newExcCls, "Exception from monitor_wait"); >> } >> >> B) The monitor waited handler does a printf: >> static void JNICALL >> monitor_waited(jvmtiEnv* jvmti, JNIEnv *env, >> jthread thread, jobject object, jboolean >> timed_out) { >> fprintf(stderr, "Waited!\n"); >> } >> >> B) A second thread that will be asked to wait: >> class SecondThread extends Thread { >> public void run() { >> try { >> Thread.sleep(1); >> } catch(Exception e) { >> } >> System.out.println("Hello from A"); >> } >> } >> >> C) The main thread with the wait: >> class Main extends Thread { >> public static void main(String[] args) { >> SecondThread st = new SecondThread(); >> >> synchronized (st) { >> st.start(); >> >> try { >> st.wait(); >> } catch(InterruptedException e) { >> System.out.println("Exception caught!"); >> } >> } >> >> System.out.println("Done"); >> } >> } >> >> D) If I do this, what happens is that I get: >> >> Waiting! >> Waited! >> Exception in thread "main" java.lang.IllegalArgumentException: >> Exception from monitor_wait >> at java.lang.Object.wait(Native Method) >> at java.lang.Object.wait(Object.java:502) >> at Main.main(Main.java:9) >> Hello from A >> >> - As we see, we get the print out from waiting, print out from >> waited and then the exception in the waiting. >> >> >> E) If instead, we do st.wait(-100) in the main method, we get: >> Waiting! >> Exception in thread "main" java.lang.IllegalArgumentException: >> Exception from monitor_wait >> at java.lang.Object.wait(Native Method) >> at Main.main(Main.java:9) >> Hello from A >> >> Notes: the stack is slightly different, the printout waited is >> no longer there however >> >> F) If finally, we don't throw in the waiting handler but leave >> the st.wait(-100) in place: >> Waiting! >> Exception in thread "main" java.lang.IllegalArgumentException: >> timeout value is negative >> at java.lang.Object.wait(Native Method) >> at Main.main(Main.java:9) >> Hello from A >> >> >> The question thus becomes: is this normal that there is a slight >> difference between D/E/F? >> >> Should we try to fix it to have a single behavior in the three >> cases, and if so, which would be the behavior that should be the >> default? >> >> Let me know if you would like to see a full code to easily >> replicate, I gave the big parts but left out the Agent_OnLoad >> method for example. >> >> Thanks! >> Jc >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Fri Sep 22 06:12:04 2017 From: jini.george at oracle.com (Jini George) Date: Fri, 22 Sep 2017 11:42:04 +0530 Subject: PING: RFR: 8175816: SA: HSDB: Compute Liveness results in java.lang.IndexOutOfBoundsException In-Reply-To: <5a76ed8b-e0aa-6572-86b7-4ac149e30c3d@gmail.com> References: <5097216b-f757-dd2b-70bc-b3a860bdebfa@gmail.com> <5a76ed8b-e0aa-6572-86b7-4ac149e30c3d@gmail.com> Message-ID: <88747c0c-01ce-efb1-c74c-5da818be72bc@oracle.com> Hi Yasumasa, Your change looks good. But please do add in a test case for this. Thanks, Jini (not a Reviewer). On 9/21/2017 4:18 AM, Yasumasa Suenaga wrote: > PING: > > Have you checked this issue? > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.00/ > > > Yasumasa > > > On 2017/09/11 22:47, Yasumasa Suenaga wrote: >> Hi all, >> >> This review request is a part of [1]. >> >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8175816 >> >> webrev: >> http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.00/ >> >> >> I cannot access JPRT. So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >> From yasuenag at gmail.com Sat Sep 23 12:13:41 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 23 Sep 2017 21:13:41 +0900 Subject: PING: RFR: 8175816: SA: HSDB: Compute Liveness results in java.lang.IndexOutOfBoundsException In-Reply-To: <88747c0c-01ce-efb1-c74c-5da818be72bc@oracle.com> References: <5097216b-f757-dd2b-70bc-b3a860bdebfa@gmail.com> <5a76ed8b-e0aa-6572-86b7-4ac149e30c3d@gmail.com> <88747c0c-01ce-efb1-c74c-5da818be72bc@oracle.com> Message-ID: <58a12433-062c-57dd-0c6e-7aba76d073cd@gmail.com> Hi Jini, I've added a test case for this in new webrev. This webrev is for consolidated jdk10/hs. http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.01/ Thanks, Yasumasa On 2017/09/22 15:12, Jini George wrote: > Hi Yasumasa, > > Your change looks good. But please do add in a test case for this. > > Thanks, > Jini (not a Reviewer). > > On 9/21/2017 4:18 AM, Yasumasa Suenaga wrote: >> PING: >> >> Have you checked this issue? >> >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.00/ >> >> >> Yasumasa >> >> >> On 2017/09/11 22:47, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> This review request is a part of [1]. >>> >>> >>> JBS: >>> ?? https://bugs.openjdk.java.net/browse/JDK-8175816 >>> >>> webrev: >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.00/ >>> >>> >>> I cannot access JPRT. So I need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >>> From jcbeyler at google.com Mon Sep 25 22:01:45 2017 From: jcbeyler at google.com (JC Beyler) Date: Mon, 25 Sep 2017 15:01:45 -0700 Subject: Low-Overhead Heap Profiling In-Reply-To: References: <2af975e6-3827-bd57-0c3d-fadd54867a67@oracle.com> <365499b6-3f4d-a4df-9e7e-e72a739fb26b@oracle.com> <102c59b8-25b6-8c21-8eef-1de7d0bbf629@oracle.com> <1497366226.2829.109.camel@oracle.com> <1498215147.2741.34.camel@oracle.com> <044f8c75-72f3-79fd-af47-7ee875c071fd@oracle.com> <23f4e6f5-c94e-01f7-ef1d-5e328d4823c8@oracle.com> Message-ID: Hi all, After a bit of a break, I am back working on this :). As before, here are two webrevs: - Full change set: http://cr.openjdk.java.net/~rasbold/8171119/webrev.09/ - Compared to version 8: http://cr.openjdk.java.net/~rasbold/8171119/webrev.08_09/ (This version is compared to version 8 I last showed but ported to the new folder hierarchy) In this version I have: - Handled Thomas' comments from his email of 07/03: - Merged the logging to be standard - Fixed up the code a bit where asked - Added some notes about the code not being thread-safe yet - Removed additional dead code from the version that modifies interpreter/c1/c2 - Fixed compiler issues so that it compiles with --disable-precompiled-header - Tested with ./configure --with-boot-jdk= --with-debug-level=slowdebug --disable-precompiled-headers Additionally, I added a test to check the sanity of the sampler: HeapMonitorStatCorrectnessTest ( http://cr.openjdk.java.net/~rasbold/8171119/webrev.08_09/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatCorrectnessTest.java.patch ) - This allocates a number of arrays and checks that we obtain the number of samples we want with an accepted error of 5%. I tested it 100 times and it passed everytime, I can test more if wanted - Not in the test are the actual numbers I got for the various array sizes, I ran the program 30 times and parsed the output; here are the averages and standard deviation: 1000: 1.28% average; 1.13% standard deviation 10000: 1.59% average; 1.25% standard deviation 100000: 1.26% average; 1.26% standard deviation What this means is that we were always at about 1~2% of the number of samples the test expected. Let me know what you think, Jc On Wed, Jul 5, 2017 at 9:31 PM, JC Beyler wrote: > Hi all, > > I apologize, I have not yet handled your remarks but thought this new > webrev would also be useful to see and comment on perhaps. > > Here is the latest webrev, it is generated slightly different than the > others since now I'm using webrev.ksh without the -N option: > http://cr.openjdk.java.net/~rasbold/8171119/webrev.08/ > > And the webrev.07 to webrev.08 diff is here: > http://cr.openjdk.java.net/~rasbold/8171119/webrev.07_08/ > > (Let me know if it works well) > > It's a small change between versions but it: > - provides a fix that makes the average sample rate correct (more on > that below). > - fixes the code to actually have it play nicely with the fast tlab > refill > - cleaned up a bit the JVMTI text and now use jvmtiFrameInfo > - moved the capability to be onload solo > > With this webrev, I've done a small study of the random number generator > we use here for the sampling rate. I took a small program and it can be > simplified to: > > for (outer loop) > for (inner loop) > int[] tmp = new int[arraySize]; > > - I've fixed the outer and inner loops to being 800 for this experiment, > meaning we allocate 640000 times an array of a given array size. > > - Each program provides the average sample size used for the whole > execution > > - Then, I ran each variation 30 times and then calculated the average of > the average sample size used for various array sizes. I selected the array > size to be one of the following: 1, 10, 100, 1000. > > - When compared to 512kb, the average sample size of 30 runs: > 1: 4.62% of error > 10: 3.09% of error > 100: 0.36% of error > 1000: 0.1% of error > 10000: 0.03% of error > > What it shows is that, depending on the number of samples, the average > does become better. This is because with an allocation of 1 element per > array, it will take longer to hit one of the thresholds. This is seen by > looking at the sample count statistic I put in. For the same number of > iterations (800 * 800), the different array sizes provoke: > 1: 62 samples > 10: 125 samples > 100: 788 samples > 1000: 6166 samples > 10000: 57721 samples > > And of course, the more samples you have, the more sample rates you pick, > which means that your average gets closer using that math. > > Thanks, > Jc > > On Thu, Jun 29, 2017 at 10:01 PM, JC Beyler wrote: > >> Thanks Robbin, >> >> This seems to have worked. When I have the next webrev ready, we will >> find out but I'm fairly confident it will work! >> >> Thanks agian! >> Jc >> >> On Wed, Jun 28, 2017 at 11:46 PM, Robbin Ehn >> wrote: >> >>> Hi JC, >>> >>> On 06/29/2017 12:15 AM, JC Beyler wrote: >>> >>>> B) Incremental changes >>>> >>> >>> I guess the most common work flow here is using mq : >>> hg qnew fix_v1 >>> edit files >>> hg qrefresh >>> hg qnew fix_v2 >>> edit files >>> hg qrefresh >>> >>> if you do hg log you will see 2 commits >>> >>> webrev.ksh -r -2 -o my_inc_v1_v2 >>> webrev.ksh -o my_full_v2 >>> >>> >>> In your .hgrc you might need: >>> [extensions] >>> mq = >>> >>> /Robbin >>> >>> >>>> Again another newbiew question here... >>>> >>>> For showing the incremental changes, is there a link that explains how >>>> to do that? I apologize for my newbie questions all the time :) >>>> >>>> Right now, I do: >>>> >>>> ksh ../webrev.ksh -m -N >>>> >>>> That generates a webrev.zip and send it to Chuck Rasbold. He then >>>> uploads it to a new webrev. >>>> >>>> I tried commiting my change and adding a small change. Then if I just >>>> do ksh ../webrev.ksh without any options, it seems to produce a similar >>>> page but now with only the changes I had (so the 06-07 comparison you were >>>> talking about) and a changeset that has it all. I imagine that is what you >>>> meant. >>>> >>>> Which means that my workflow would become: >>>> >>>> 1) Make changes >>>> 2) Make a webrev without any options to show just the differences with >>>> the tip >>>> 3) Amend my changes to my local commit so that I have it done with >>>> 4) Go to 1 >>>> >>>> Does that seem correct to you? >>>> >>>> Note that when I do this, I only see the full change of a file in the >>>> full change set (Side note here: now the page says change set and not >>>> patch, which is maybe why Serguei was having issues?). >>>> >>>> Thanks! >>>> Jc >>>> >>>> >>>> >>>> On Wed, Jun 28, 2017 at 1:12 AM, Robbin Ehn >>> > wrote: >>>> >>>> Hi, >>>> >>>> On 06/28/2017 12:04 AM, JC Beyler wrote: >>>> >>>> Dear Thomas et al, >>>> >>>> Here is the newest webrev: >>>> http://cr.openjdk.java.net/~rasbold/8171119/webrev.07/ < >>>> http://cr.openjdk.java.net/~rasbold/8171119/webrev.07/> >>>> >>>> >>>> >>>> You have some more bits to in there but generally this looks good >>>> and really nice with more tests. >>>> I'll do and deep dive and re-test this when I get back from my long >>>> vacation with whatever patch version you have then. >>>> >>>> Also I think it's time you provide incremental (v06->07 changes) as >>>> well as complete change-sets. >>>> >>>> Thanks, Robbin >>>> >>>> >>>> >>>> >>>> Thomas, I "think" I have answered all your remarks. The summary >>>> is: >>>> >>>> - The statistic system is up and provides insight on what the >>>> heap sampler is doing >>>> - I've noticed that, though the sampling rate is at the >>>> right mean, we are missing some samples, I have not yet tracked out why >>>> (details below) >>>> >>>> - I've run a tiny benchmark that is the worse case: it is a >>>> very tight loop and allocated a small array >>>> - In this case, I see no overhead when the system is off >>>> so that is a good start :) >>>> - I see right now a high overhead in this case when >>>> sampling is on. This is not a really too surprising but I'm going to see if >>>> this is consistent with our >>>> internal implementation. The benchmark is really allocation >>>> stressful so I'm not too surprised but I want to do the due diligence. >>>> >>>> - The statistic system up is up and I have a new test >>>> http://cr.openjdk.java.net/~rasbold/8171119/webrev.07/test/s >>>> erviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatTes >>>> t.java.patch >>>> >>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatTe >>>> st.java.patch> >>>> - I did a bit of a study about the random generator here, >>>> more details are below but basically it seems to work well >>>> >>>> - I added a capability but since this is the first time >>>> doing this, I was not sure I did it right >>>> - I did add a test though for it and the test seems to do >>>> what I expect (all methods are failing with the >>>> JVMTI_ERROR_MUST_POSSESS_CAPABILITY error). >>>> - http://cr.openjdk.java.net/~ra >>>> sbold/8171119/webrev.07/test/serviceability/jvmti/HeapMonito >>>> r/MyPackage/HeapMonitorNoCapabilityTest.java.patch >>>> >>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorNoCapa >>>> bilityTest.java.patch> >>>> >>>> - I still need to figure out what to do about the >>>> multi-agent vs single-agent issue >>>> >>>> - As far as measurements, it seems I still need to look at: >>>> - Why we do the 20 random calls first, are they necessary? >>>> - Look at the mean of the sampling rate that the random >>>> generator does and also what is actually sampled >>>> - What is the overhead in terms of memory/performance when >>>> on? >>>> >>>> I have inlined my answers, I think I got them all in the new >>>> webrev, let me know your thoughts. >>>> >>>> Thanks again! >>>> Jc >>>> >>>> >>>> On Fri, Jun 23, 2017 at 3:52 AM, Thomas Schatzl < >>>> thomas.schatzl at oracle.com >>> thomas.schatzl at oracle.com >>>> >>>> >> wrote: >>>> >>>> Hi, >>>> >>>> On Wed, 2017-06-21 at 13:45 -0700, JC Beyler wrote: >>>> > Hi all, >>>> > >>>> > First off: Thanks again to Robbin and Thomas for their >>>> reviews :) >>>> > >>>> > Next, I've uploaded a new webrev: >>>> > http://cr.openjdk.java.net/~rasbold/8171119/webrev.06/ < >>>> http://cr.openjdk.java.net/~rasbold/8171119/webrev.06/> >>>> >>> http://cr.openjdk.java.net/~rasbold/8171119/webrev.06/>> >>>> >>>> > >>>> > Here is an update: >>>> > >>>> > - @Robbin, I forgot to say that yes I need to look at >>>> implementing >>>> > this for the other architectures and testing it before >>>> it is all >>>> > ready to go. Is it common to have it working on all >>>> possible >>>> > combinations or is there a subset that I should be doing >>>> first and we >>>> > can do the others later? >>>> > - I've tested slowdebug, built and ran the JTreg tests I >>>> wrote with >>>> > slowdebug and fixed a few more issues >>>> > - I've refactored a bit of the code following Thomas' >>>> comments >>>> > - I think I've handled all the comments from Thomas >>>> (I put >>>> > comments inline below for the specifics) >>>> >>>> Thanks for handling all those. >>>> >>>> > - Following Thomas' comments on statistics, I want to >>>> add some >>>> > quality assurance tests and find that the easiest way >>>> would be to >>>> > have a few counters of what is happening in the sampler >>>> and expose >>>> > that to the user. >>>> > - I'll be adding that in the next version if no one >>>> sees any >>>> > objections to that. >>>> > - This will allow me to add a sanity test in JTreg >>>> about number of >>>> > samples and average of sampling rate >>>> > >>>> > @Thomas: I had a few questions that I inlined below but >>>> I will >>>> > summarize the "bigger ones" here: >>>> > - You mentioned constants are not using the right >>>> conventions, I >>>> > looked around and didn't see any convention except >>>> normal naming then >>>> > for static constants. Is that right? >>>> >>>> I looked through https://wiki.openjdk.java.net/ >>>> display/HotSpot/StyleGui >>> /display/HotSpot/StyleGui> >>>> >>> https://wiki.openjdk.java.net/display/HotSpot/StyleGui>> >>>> de and the rule is to "follow an existing pattern and must >>>> have a >>>> distinct appearance from other names". Which does not help >>>> a lot I >>>> guess :/ The GC team started using upper camel case, e.g. >>>> SomeOtherConstant, but very likely this is probably not >>>> applied >>>> consistently throughout. So I am fine with not adding >>>> another style >>>> (like kMaxStackDepth with the "k" in front with some >>>> unknown meaning) >>>> is fine. >>>> >>>> (Chances are you will find that style somewhere used >>>> anyway too, >>>> apologies if so :/) >>>> >>>> >>>> Thanks for that link, now I know where to look. I used the >>>> upper camel case in my code as well then :) I should have gotten them all. >>>> >>>> >>>> > PS: I've also inlined my answers to Thomas below: >>>> > >>>> > On Tue, Jun 13, 2017 at 8:03 AM, Thomas Schatzl >>>> >>> > e.com > wrote: >>>> > > Hi all, >>>> > > >>>> > > On Mon, 2017-06-12 at 11:11 -0700, JC Beyler wrote: >>>> > > > Dear all, >>>> > > > >>>> > > > I've continued working on this and have done the >>>> following >>>> > > webrev: >>>> > > > http://cr.openjdk.java.net/~ra >>>> sbold/8171119/webrev.05/ >>> asbold/8171119/webrev.05/> >>>> >>> http://cr.openjdk.java.net/~rasbold/8171119/webrev.05/>> >>>> >>>> > > >>>> > > [...] >>>> > > > Things I still need to do: >>>> > > > - Have to fix that TLAB case for the >>>> FastTLABRefill >>>> > > > - Have to start looking at the data to see that >>>> it is >>>> > > consistent and does gather the right samples, right >>>> frequency, etc. >>>> > > > - Have to check the GC elements and what that >>>> produces >>>> > > > - Run a slowdebug run and ensure I fixed all >>>> those issues you >>>> > > saw > Robbin >>>> > > > >>>> > > > Thanks for looking at the webrev and have a great >>>> week! >>>> > > >>>> > > scratching a bit on the surface of this change, so >>>> apologies for >>>> > > rather shallow comments: >>>> > > >>>> > > - macroAssembler_x86.cpp:5604: while this is compiler >>>> code, and I >>>> > > am not sure this is final, please avoid littering the >>>> code with >>>> > > TODO remarks :) They tend to be candidates for later >>>> wtf moments >>>> > > only. >>>> > > >>>> > > Just file a CR for that. >>>> > > >>>> > Newcomer question: what is a CR and not sure I have the >>>> rights to do >>>> > that yet ? :) >>>> >>>> Apologies. CR is a change request, this suggests to file a >>>> bug in the >>>> bug tracker. And you are right, you can't just create a >>>> new account in >>>> the OpenJDK JIRA yourselves. :( >>>> >>>> >>>> Ok good to know, I'll continue with my own todo list but I'll >>>> work hard on not letting it slip in the webrevs anymore :) >>>> >>>> >>>> I was mostly referring to the "... but it is a TODO" part >>>> of that >>>> comment in macroassembler_x86.cpp. Comments about the why >>>> of the code >>>> are appreciated. >>>> >>>> [Note that I now understand that this is to some degree >>>> still work in >>>> progress. As long as the final changeset does no contain >>>> TODO's I am >>>> fine (and it's not a hard objection, rather their use in >>>> "final" code >>>> is typically limited in my experience)] >>>> >>>> 5603 // Currently, if this happens, just set back the >>>> actual end to >>>> where it was. >>>> 5604 // We miss a chance to sample here. >>>> >>>> Would be okay, if explaining "this" and the "why" of >>>> missing a chance >>>> to sample here would be best. >>>> >>>> Like maybe: >>>> >>>> // If we needed to refill TLABs, just set the actual end >>>> point to >>>> // the end of the TLAB again. We do not sample here >>>> although we could. >>>> >>>> Done with your comment, it works well in my mind. >>>> >>>> I am not sure whether "miss a chance to sample" meant "we >>>> could, but >>>> consciously don't because it's not that useful" or "it >>>> would be >>>> necessary but don't because it's too complicated to do.". >>>> >>>> Looking at the original comment once more, I am also not >>>> sure if that >>>> comment shouldn't referring to the "end" variable (not >>>> actual_end) >>>> because that's the variable that is responsible for taking >>>> the sampling >>>> path? (Going from the member description of >>>> ThreadLocalAllocBuffer). >>>> >>>> >>>> I've moved this code and it no longer shows up here but the >>>> rationale and answer was: >>>> >>>> So.. Yes, end is the variable provoking the sampling. Actual >>>> end is the actual end of the TLAB. >>>> >>>> What was happening here is that the code is resetting _end to >>>> point towards the end of the new TLAB. Because, we now have the end for >>>> sampling and _actual_end for >>>> the actual end, we need to update the actual_end as well. >>>> >>>> Normally, were we to do the real work here, we would calculate >>>> the (end - start) offset, then do: >>>> >>>> - Set the new end to : start + (old_end - old_start) >>>> - Set the actual end like we do here now where it because it is >>>> the actual end. >>>> >>>> Why is this not done here now anymore? >>>> - I was still debating which path to take: >>>> - Do it in the fast refill code, it has its perks: >>>> - In a world where fast refills are happening all >>>> the time or a lot, we can augment there the code to do the sampling >>>> - Remember what we had as an end before leaving the >>>> slowpath and check on return >>>> - This is what I'm doing now, it removes the need to >>>> go fix up all fast refill paths but if you remain in fast refill paths, you >>>> won't get sampling. I >>>> have to think of the consequences of that, maybe a future >>>> change later on? >>>> - I have the statistics now so I'm going to study >>>> that >>>> -> By the way, though my statistics are >>>> showing I'm missing some samples, if I turn off FastTlabRefill, it is the >>>> same loss so for now, it seems >>>> this does not occur in my simple test. >>>> >>>> >>>> >>>> But maybe I am only confused and it's best to just leave >>>> the comment >>>> away. :) >>>> >>>> Thinking about it some more, doesn't this not-sampling in >>>> this case >>>> mean that sampling does not work in any collector that >>>> does inline TLAB >>>> allocation at the moment? (Or is inline TLAB alloc >>>> automatically >>>> disabled with sampling somehow?) >>>> >>>> That would indeed be a bigger TODO then :) >>>> >>>> >>>> Agreed, this remark made me think that perhaps as a first step >>>> the new way of doing it is better but I did have to: >>>> - Remove the const of the ThreadLocalBuffer remaining and >>>> hard_end methods >>>> - Move hard_end out of the header file to have a bit more >>>> logic there >>>> >>>> Please let me know what you think of that and if you prefer it >>>> this way or changing the fast refills. (I prefer this way now because it is >>>> more incremental). >>>> >>>> >>>> > > - calling HeapMonitoring::do_weak_oops() (which should >>>> probably be >>>> > > called weak_oops_do() like other similar methods) only >>>> if string >>>> > > deduplication is enabled (in g1CollectedHeap.cpp:4511) >>>> seems wrong. >>>> > >>>> > The call should be at least around 6 lines up outside >>>> the if. >>>> > >>>> > Preferentially in a method like >>>> process_weak_jni_handles(), including >>>> > additional logging. (No new (G1) gc phase without >>>> minimal logging >>>> > :)). >>>> > Done but really not sure because: >>>> > >>>> > I put for logging: >>>> > log_develop_trace(gc, freelist)("G1ConcRegionFreeing >>>> [other] : heap >>>> > monitoring"); >>>> >>>> I would think that "gc, ref" would be more appropriate log >>>> tags for >>>> this similar to jni handles. >>>> (I am als not sure what weak reference handling has to do >>>> with >>>> G1ConcRegionFreeing, so I am a bit puzzled) >>>> >>>> >>>> I was not sure what to put for the tags or really as the >>>> message. I cleaned it up a bit now to: >>>> log_develop_trace(gc, ref)("HeapSampling [other] : heap >>>> monitoring processing"); >>>> >>>> >>>> >>>> > Since weak_jni_handles didn't have logging for me to be >>>> inspired >>>> > from, I did that but unconvinced this is what should be >>>> done. >>>> >>>> The JNI handle processing does have logging, but only in >>>> ReferenceProcessor::process_discovered_references(). In >>>> process_weak_jni_handles() only overall time is measured >>>> (in a G1 >>>> specific way, since only G1 supports disabling reference >>>> procesing) :/ >>>> >>>> The code in ReferenceProcessor prints both time taken >>>> referenceProcessor.cpp:254, as well as the count, but >>>> strangely only in >>>> debug VMs. >>>> >>>> I have no idea why this logging is that unimportant to >>>> only print that >>>> in a debug VM. However there are reviews out for changing >>>> this area a >>>> bit, so it might be useful to wait for that (JDK-8173335). >>>> >>>> >>>> I cleaned it up a bit anyway and now it returns the count of >>>> objects that are in the system. >>>> >>>> >>>> > > - the change doubles the size of >>>> > > CollectedHeap::allocate_from_tlab_slow() above the >>>> "small and nice" >>>> > > threshold. Maybe it could be refactored a bit. >>>> > Done I think, it looks better to me :). >>>> >>>> In ThreadLocalAllocBuffer::handle_sample() I think the >>>> set_back_actual_end()/pick_next_sample() calls could be >>>> hoisted out of >>>> the "if" :) >>>> >>>> >>>> Done! >>>> >>>> >>>> > > - referenceProcessor.cpp:261: the change should add >>>> logging about >>>> > > the number of references encountered, maybe after the >>>> corresponding >>>> > > "JNI weak reference count" log message. >>>> > Just to double check, are you saying that you'd like to >>>> have the heap >>>> > sampler to keep in store how many sampled objects were >>>> encountered in >>>> > the HeapMonitoring::weak_oops_do? >>>> > - Would a return of the method with the number of >>>> handled >>>> > references and logging that work? >>>> >>>> Yes, it's fine if HeapMonitoring::weak_oops_do() only >>>> returned the >>>> number of processed weak oops. >>>> >>>> >>>> Done also (but I admit I have not tested the output yet) :) >>>> >>>> >>>> > - Additionally, would you prefer it in a separate >>>> block with its >>>> > GCTraceTime? >>>> >>>> Yes. Both kinds of information is interesting: while the >>>> time taken is >>>> typically more important, the next question would be why, >>>> and the >>>> number of references typically goes a long way there. >>>> >>>> See above though, it is probably best to wait a bit. >>>> >>>> >>>> Agreed that I "could" wait but, if it's ok, I'll just >>>> refactor/remove this when we get closer to something final. Either, >>>> JDK-8173335 >>>> has gone in and I will notice it now or it will soon and I can >>>> change it then. >>>> >>>> >>>> > > - threadLocalAllocBuffer.cpp:331: one more "TODO" >>>> > Removed it and added it to my personal todos to look at. >>>> > > > >>>> > > - threadLocalAllocBuffer.hpp: ThreadLocalAllocBuffer >>>> class >>>> > > documentation should be updated about the sampling >>>> additions. I >>>> > > would have no clue what the difference between >>>> "actual_end" and >>>> > > "end" would be from the given information. >>>> > If you are talking about the comments in this file, I >>>> made them more >>>> > clear I hope in the new webrev. If it was somewhere >>>> else, let me know >>>> > where to change. >>>> >>>> Thanks, that's much better. Maybe a note in the comment of >>>> the class >>>> that ThreadLocalBuffer provides some sampling facility by >>>> modifying the >>>> end() of the TLAB to cause "frequent" calls into the >>>> runtime call where >>>> actual sampling takes place. >>>> >>>> >>>> Done, I think it's better now. Added something about the >>>> slow_path_end as well. >>>> >>>> >>>> > > - in heapMonitoring.hpp: there are some random >>>> comments about some >>>> > > code that has been grabbed from >>>> "util/math/fastmath.[h|cc]". I >>>> > > can't tell whether this is code that can be used but I >>>> assume that >>>> > > Noam Shazeer is okay with that (i.e. that's all Google >>>> code). >>>> > Jeremy and I double checked and we can release that as I >>>> thought. I >>>> > removed the comment from that piece of code entirely. >>>> >>>> Thanks. >>>> >>>> > > - heapMonitoring.hpp/cpp static constant naming does >>>> not correspond >>>> > > to Hotspot's. Additionally, in Hotspot static methods >>>> are cased >>>> > > like other methods. >>>> > I think I fixed the methods to be cased the same way as >>>> all other >>>> > methods. For static constants, I was not sure. I fixed a >>>> few other >>>> > variables but I could not seem to really see a >>>> consistent trend for >>>> > constants. I made them as variables but I'm not sure now. >>>> >>>> Sorry again, style is a kind of mess. The goal of my >>>> suggestions here >>>> is only to prevent yet another style creeping in. >>>> >>>> > > - in heapMonitoring.cpp there are a few cryptic >>>> comments at the top >>>> > > that seem to refer to internal stuff that should >>>> probably be >>>> > > removed. >>>> > Sorry about that! My personal todos not cleared out. >>>> >>>> I am happy about comments, but I simply did not understand >>>> any of that >>>> and I do not know about other readers as well. >>>> >>>> If you think you will remember removing/updating them >>>> until the review >>>> proper (I misunderstood the review situation a little it >>>> seems). >>>> >>>> > > I did not think through the impact of the TLAB changes >>>> on collector >>>> > > behavior yet (if there are). Also I did not check for >>>> problems with >>>> > > concurrent mark and SATB/G1 (if there are). >>>> > I would love to know your thoughts on this, I think this >>>> is fine. I >>>> >>>> I think so too now. No objects are made live out of thin >>>> air :) >>>> >>>> > see issues with multiple threads right now hitting the >>>> stack storage >>>> > instance. Previous webrevs had a mutex lock here but we >>>> took it out >>>> > for simplificity (and only for now). >>>> >>>> :) When looking at this after some thinking I now assume >>>> for this >>>> review that this code is not MT safe at all. There seems >>>> to be more >>>> synchronization missing than just the one for the >>>> StackTraceStorage. So >>>> no comments about this here. >>>> >>>> >>>> I doubled checked a bit (quickly I admit) but it seems that >>>> synchronization in StackTraceStorage is really all you need (all methods >>>> lead to a StackTraceStorage one >>>> and can be multithreaded outside of that). >>>> There is a question about the initialization where the method >>>> HeapMonitoring::initialize_profiling is not thread safe. >>>> It would work (famous last words) and not crash if there was a >>>> race but we could add a synchronization point there as well (and therefore >>>> on the stop as well). >>>> >>>> But anyway I will really check and do this once we add back >>>> synchronization. >>>> >>>> >>>> Also, this would require some kind of specification of >>>> what is allowed >>>> to be called when and where. >>>> >>>> >>>> Would we specify this with the methods in the jvmti.xml file? >>>> We could start by specifying in each that they are not thread safe but I >>>> saw no mention of that for >>>> other methods. >>>> >>>> >>>> One potentially relevant observation about locking here: >>>> depending on >>>> sampling frequency, StackTraceStore::add_trace() may be >>>> rather >>>> frequently called. I assume that you are going to do >>>> measurements :) >>>> >>>> >>>> Though we don't have the TLAB implementation in our code, the >>>> compiler generated sampler uses 2% of overhead with a 512k sampling rate. I >>>> can do real measurements >>>> when the code settles and we can see how costly this is as a >>>> TLAB implementation. >>>> However, my theory is that if the rate is 512k, the >>>> memory/performance overhead should be minimal since it is what we saw with >>>> our code/workloads (though not called >>>> the same way, we call it essentially at the same rate). >>>> If you have a benchmark you'd like me to test, let me know! >>>> >>>> Right now, with my really small test, this does use a bit of >>>> overhead even for a 512k sample size. I don't know yet why, I'm going to >>>> see what is going on. >>>> >>>> Finally, I think it is not reasonable to suppose the overhead >>>> to be negligible if the sampling rate used is too low. The user should know >>>> that the lower the rate, >>>> the higher the overhead (documentation TODO?). >>>> >>>> >>>> I am not sure what the expected usage of the API is, but >>>> StackTraceStore::add_trace() seems to be able to grow >>>> without bounds. >>>> Only a GC truncates them to the live ones. That in itself >>>> seems to be >>>> problematic (GCs can be *wide* apart), and of course some >>>> of the API >>>> methods add to that because they duplicate that unbounded >>>> array. Do you >>>> have any concerns/measurements about this? >>>> >>>> >>>> So, the theory is that yes add_trace can be able to grow >>>> without bounds but it grows at a sample per 512k of allocated space. The >>>> stacks it gathers are currently >>>> maxed at 64 (I'd like to expand that to an option to the user >>>> though at some point). So I have no concerns because: >>>> >>>> - If really this is taking a lot of space, that means the job >>>> is keeping a lot of objects in memory as well, therefore the entire heap is >>>> getting huge >>>> - If this is the case, you will be triggering a GC at some >>>> point anyway. >>>> >>>> (I'm putting under the rug the issue of "What if we set the >>>> rate to 1 for example" because as you lower the sampling rate, we cannot >>>> guarantee low overhead; the >>>> idea behind this feature is to have a means of having >>>> meaningful allocated samples at a low overhead) >>>> >>>> I have no measurements really right now but since I now have >>>> some statistics I can poll, I will look a bit more at this question. >>>> >>>> I have the same last sentence than above: the user should >>>> expect this to happen if the sampling rate is too small. That probably can >>>> be reflected in the >>>> StartHeapSampling as a note : careful this might impact your >>>> performance. >>>> >>>> >>>> Also, these stack traces might hold on to huge arrays. Any >>>> consideration of that? Particularly it might be the cause >>>> for OOMEs in >>>> tight memory situations. >>>> >>>> >>>> There is a stack size maximum that is set to 64 so it should >>>> not hold huge arrays. I don't think this is an issue but I can double check >>>> with a test or two. >>>> >>>> >>>> - please consider adding a safepoint check in >>>> HeapMonitoring::weak_oops_do to prevent accidental misuse. >>>> >>>> - in struct StackTraceStorage, the public fields may also >>>> need >>>> underscores. At least some files in the runtime directory >>>> have structs >>>> with underscored public members (and some don't). The >>>> runtime team >>>> should probably comment on that. >>>> >>>> >>>> Agreed I did not know. I looked around and a lot of structs did >>>> not have them it seemed so I left it as is. I will happily change it if >>>> someone prefers (I was not >>>> sure if you really preferred or not, your sentence seemed to be >>>> more a note of "this might need to change but I don't know if the runtime >>>> team enforces that", let >>>> me know if I read that wrongly). >>>> >>>> >>>> - In StackTraceStorage::weak_oops_do(), when examining the >>>> StackTraceData, maybe it is useful to consider having a >>>> non-NULL >>>> reference outside of the heap's reserved space an error. >>>> There should >>>> be no oop outside of the heap's reserved space ever. >>>> >>>> Unless you allow storing random values in >>>> StackTraceData::obj, which I >>>> would not encourage. >>>> >>>> >>>> I suppose you are talking about this part: >>>> if ((value != NULL && Universe::heap()->is_in_reserved(value)) >>>> && >>>> (is_alive == NULL || is_alive->do_object_b(value))) >>>> { >>>> >>>> What you are saying is that I could have something like: >>>> if (value != my_non_null_reference && >>>> (is_alive == NULL || is_alive->do_object_b(value))) >>>> { >>>> >>>> Is that what you meant? Is there really a reason to do so? When >>>> I look at the code, is_in_reserved seems like a O(1) method call. I'm not >>>> even sure we can have a >>>> NULL value to be honest. I might have to study that to see if >>>> this was not a paranoid test to begin with. >>>> >>>> The is_alive code has now morphed due to the comment below. >>>> >>>> >>>> >>>> - HeapMonitoring::weak_oops_do() does not seem to use the >>>> passed AbstractRefProcTaskExecutor. >>>> >>>> >>>> It did use it: >>>> size_t HeapMonitoring::weak_oops_do( >>>> AbstractRefProcTaskExecutor *task_executor, >>>> BoolObjectClosure* is_alive, >>>> OopClosure *f, >>>> VoidClosure *complete_gc) { >>>> assert(SafepointSynchronize::is_at_safepoint(), "must be >>>> at safepoint"); >>>> >>>> if (task_executor != NULL) { >>>> task_executor->set_single_threaded_mode(); >>>> } >>>> return StackTraceStorage::storage()->weak_oops_do(is_alive, >>>> f, complete_gc); >>>> } >>>> >>>> But due to the comment below, I refactored this, so this is no >>>> longer here. Now I have an always true closure that is passed. >>>> >>>> >>>> - I do not understand allowing to call this method with a >>>> NULL >>>> complete_gc closure. This would mean that objects >>>> referenced from the >>>> object that is referenced by the StackTraceData are not >>>> pulled, meaning >>>> they would get stale. >>>> >>>> - same with is_alive parameter value of NULL >>>> >>>> >>>> So these questions made me look a bit closer at this code. This >>>> code I think was written this way to have a very small impact on the file >>>> but you are right, there >>>> is no reason for this here. I've simplified the code by making >>>> in referenceProcessor.cpp a process_HeapSampling method that handles >>>> everything there. >>>> >>>> The code allowed NULLs because it depended on where you were >>>> coming from and how the code was being called. >>>> >>>> - I added a static always_true variable and pass that now to be >>>> more consistent with the rest of the code. >>>> - I moved the complete_gc into process_phaseHeapSampling now >>>> (new method) and handle the task_executor and the complete_gc there >>>> - Newbie question: in our code we did a >>>> set_single_threaded_mode but I see that process_phaseJNI does it right >>>> before its call, do I need to do it for the >>>> process_phaseHeapSample? >>>> That API is much cleaner (in my mind) and is consistent with >>>> what is done around it (again in my mind). >>>> >>>> >>>> - heapMonitoring.cpp:590: I do not completely understand >>>> the purpose of >>>> this code: in the end this results in a fixed value >>>> directly dependent >>>> on the Thread address anyway? In the end this results in a >>>> fixed value >>>> directly dependent on the Thread address anyway? >>>> IOW, what is special about exactly 20 rounds? >>>> >>>> >>>> So we really want a fast random number generator that has a >>>> specific mean (512k is the default we use). The code uses the thread >>>> address as the start number of the >>>> sequence (why not, it is random enough is rationale). Then >>>> instead of just starting there, we prime the sequence and really only start >>>> at the 21st number, it is >>>> arbitrary and I have not done a study to see if we could do >>>> more or less of that. >>>> >>>> As I have the statistics of the system up and running, I'll run >>>> some experiments to see if this is needed, is 20 good, or not. >>>> >>>> >>>> - also I would consider stripping a few bits of the >>>> threads' address as >>>> initialization value for your rng. The last three bits >>>> (and probably >>>> more, check whether the Thread object is allocated on >>>> special >>>> boundaries) are always zero for them. >>>> Not sure if the given "random" value is random enough >>>> before/after, >>>> this method, so just skip that comment if you think this >>>> is not >>>> required. >>>> >>>> >>>> I don't know is the honest answer. I think what is important is >>>> that we tend towards a mean and it is random "enough" to not fall in >>>> pitfalls of only sampling a >>>> subset of objects due to their allocation order. I added that >>>> as test to do to see if it changes the mean in any way for the 512k default >>>> value and/or if the first >>>> 1000 elements look better. >>>> >>>> >>>> Some more random nits I did not find a place to put >>>> anywhere: >>>> >>>> - ThreadLocalAllocBuffer::_extra_space does not seem to >>>> be used >>>> anywhere? >>>> >>>> >>>> Good catch :). >>>> >>>> >>>> - Maybe indent the declaration of >>>> ThreadLocalAllocBuffer::_bytes_until_sample to align below the other >>>> members of that group. >>>> >>>> >>>> Done moved it up a bit to have non static members together and >>>> static separate. >>>> >>>> Thanks, >>>> Thomas >>>> >>>> >>>> Thanks for your review! >>>> Jc >>>> >>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Mon Sep 25 22:02:56 2017 From: jcbeyler at google.com (JC Beyler) Date: Mon, 25 Sep 2017 15:02:56 -0700 Subject: Low-Overhead Heap Profiling In-Reply-To: References: <2af975e6-3827-bd57-0c3d-fadd54867a67@oracle.com> <365499b6-3f4d-a4df-9e7e-e72a739fb26b@oracle.com> <102c59b8-25b6-8c21-8eef-1de7d0bbf629@oracle.com> <1497366226.2829.109.camel@oracle.com> <1498215147.2741.34.camel@oracle.com> <044f8c75-72f3-79fd-af47-7ee875c071fd@oracle.com> <23f4e6f5-c94e-01f7-ef1d-5e328d4823c8@oracle.com> Message-ID: Forgot to say that for my numbers: - Not in the test are the actual numbers I got for the various array sizes, I ran the program 30 times and parsed the output; here are the averages and standard deviation: 1000: 1.28% average; 1.13% standard deviation 10000: 1.59% average; 1.25% standard deviation 100000: 1.26% average; 1.26% standard deviation The 1000/10000/100000 are the sizes of the arrays being allocated. These are allocated 100k times and the sampling rate is 111 times the size of the array. Thanks! Jc On Mon, Sep 25, 2017 at 3:01 PM, JC Beyler wrote: > Hi all, > > After a bit of a break, I am back working on this :). As before, here are > two webrevs: > > - Full change set: http://cr.openjdk.java.net/~rasbold/8171119/webrev.09/ > - Compared to version 8: http://cr.openjdk.java.net/ > ~rasbold/8171119/webrev.08_09/ > (This version is compared to version 8 I last showed but ported to the > new folder hierarchy) > > In this version I have: > - Handled Thomas' comments from his email of 07/03: > - Merged the logging to be standard > - Fixed up the code a bit where asked > - Added some notes about the code not being thread-safe yet > - Removed additional dead code from the version that modifies > interpreter/c1/c2 > - Fixed compiler issues so that it compiles with > --disable-precompiled-header > - Tested with ./configure --with-boot-jdk= > --with-debug-level=slowdebug --disable-precompiled-headers > > Additionally, I added a test to check the sanity of the sampler: > HeapMonitorStatCorrectnessTest (http://cr.openjdk.java.net/~ > rasbold/8171119/webrev.08_09/test/hotspot/jtreg/serviceability/jvmti/ > HeapMonitor/MyPackage/HeapMonitorStatCorrectnessTest.java.patch) > - This allocates a number of arrays and checks that we obtain the > number of samples we want with an accepted error of 5%. I tested it 100 > times and it passed everytime, I can test more if wanted > - Not in the test are the actual numbers I got for the various array > sizes, I ran the program 30 times and parsed the output; here are the > averages and standard deviation: > 1000: 1.28% average; 1.13% standard deviation > 10000: 1.59% average; 1.25% standard deviation > 100000: 1.26% average; 1.26% standard deviation > > What this means is that we were always at about 1~2% of the number of > samples the test expected. > > Let me know what you think, > Jc > > > > On Wed, Jul 5, 2017 at 9:31 PM, JC Beyler wrote: > >> Hi all, >> >> I apologize, I have not yet handled your remarks but thought this new >> webrev would also be useful to see and comment on perhaps. >> >> Here is the latest webrev, it is generated slightly different than the >> others since now I'm using webrev.ksh without the -N option: >> http://cr.openjdk.java.net/~rasbold/8171119/webrev.08/ >> >> And the webrev.07 to webrev.08 diff is here: >> http://cr.openjdk.java.net/~rasbold/8171119/webrev.07_08/ >> >> (Let me know if it works well) >> >> It's a small change between versions but it: >> - provides a fix that makes the average sample rate correct (more on >> that below). >> - fixes the code to actually have it play nicely with the fast tlab >> refill >> - cleaned up a bit the JVMTI text and now use jvmtiFrameInfo >> - moved the capability to be onload solo >> >> With this webrev, I've done a small study of the random number generator >> we use here for the sampling rate. I took a small program and it can be >> simplified to: >> >> for (outer loop) >> for (inner loop) >> int[] tmp = new int[arraySize]; >> >> - I've fixed the outer and inner loops to being 800 for this experiment, >> meaning we allocate 640000 times an array of a given array size. >> >> - Each program provides the average sample size used for the whole >> execution >> >> - Then, I ran each variation 30 times and then calculated the average of >> the average sample size used for various array sizes. I selected the array >> size to be one of the following: 1, 10, 100, 1000. >> >> - When compared to 512kb, the average sample size of 30 runs: >> 1: 4.62% of error >> 10: 3.09% of error >> 100: 0.36% of error >> 1000: 0.1% of error >> 10000: 0.03% of error >> >> What it shows is that, depending on the number of samples, the average >> does become better. This is because with an allocation of 1 element per >> array, it will take longer to hit one of the thresholds. This is seen by >> looking at the sample count statistic I put in. For the same number of >> iterations (800 * 800), the different array sizes provoke: >> 1: 62 samples >> 10: 125 samples >> 100: 788 samples >> 1000: 6166 samples >> 10000: 57721 samples >> >> And of course, the more samples you have, the more sample rates you pick, >> which means that your average gets closer using that math. >> >> Thanks, >> Jc >> >> On Thu, Jun 29, 2017 at 10:01 PM, JC Beyler wrote: >> >>> Thanks Robbin, >>> >>> This seems to have worked. When I have the next webrev ready, we will >>> find out but I'm fairly confident it will work! >>> >>> Thanks agian! >>> Jc >>> >>> On Wed, Jun 28, 2017 at 11:46 PM, Robbin Ehn >>> wrote: >>> >>>> Hi JC, >>>> >>>> On 06/29/2017 12:15 AM, JC Beyler wrote: >>>> >>>>> B) Incremental changes >>>>> >>>> >>>> I guess the most common work flow here is using mq : >>>> hg qnew fix_v1 >>>> edit files >>>> hg qrefresh >>>> hg qnew fix_v2 >>>> edit files >>>> hg qrefresh >>>> >>>> if you do hg log you will see 2 commits >>>> >>>> webrev.ksh -r -2 -o my_inc_v1_v2 >>>> webrev.ksh -o my_full_v2 >>>> >>>> >>>> In your .hgrc you might need: >>>> [extensions] >>>> mq = >>>> >>>> /Robbin >>>> >>>> >>>>> Again another newbiew question here... >>>>> >>>>> For showing the incremental changes, is there a link that explains how >>>>> to do that? I apologize for my newbie questions all the time :) >>>>> >>>>> Right now, I do: >>>>> >>>>> ksh ../webrev.ksh -m -N >>>>> >>>>> That generates a webrev.zip and send it to Chuck Rasbold. He then >>>>> uploads it to a new webrev. >>>>> >>>>> I tried commiting my change and adding a small change. Then if I just >>>>> do ksh ../webrev.ksh without any options, it seems to produce a similar >>>>> page but now with only the changes I had (so the 06-07 comparison you were >>>>> talking about) and a changeset that has it all. I imagine that is what you >>>>> meant. >>>>> >>>>> Which means that my workflow would become: >>>>> >>>>> 1) Make changes >>>>> 2) Make a webrev without any options to show just the differences with >>>>> the tip >>>>> 3) Amend my changes to my local commit so that I have it done with >>>>> 4) Go to 1 >>>>> >>>>> Does that seem correct to you? >>>>> >>>>> Note that when I do this, I only see the full change of a file in the >>>>> full change set (Side note here: now the page says change set and not >>>>> patch, which is maybe why Serguei was having issues?). >>>>> >>>>> Thanks! >>>>> Jc >>>>> >>>>> >>>>> >>>>> On Wed, Jun 28, 2017 at 1:12 AM, Robbin Ehn >>>> > wrote: >>>>> >>>>> Hi, >>>>> >>>>> On 06/28/2017 12:04 AM, JC Beyler wrote: >>>>> >>>>> Dear Thomas et al, >>>>> >>>>> Here is the newest webrev: >>>>> http://cr.openjdk.java.net/~rasbold/8171119/webrev.07/ < >>>>> http://cr.openjdk.java.net/~rasbold/8171119/webrev.07/> >>>>> >>>>> >>>>> >>>>> You have some more bits to in there but generally this looks good >>>>> and really nice with more tests. >>>>> I'll do and deep dive and re-test this when I get back from my >>>>> long vacation with whatever patch version you have then. >>>>> >>>>> Also I think it's time you provide incremental (v06->07 changes) >>>>> as well as complete change-sets. >>>>> >>>>> Thanks, Robbin >>>>> >>>>> >>>>> >>>>> >>>>> Thomas, I "think" I have answered all your remarks. The >>>>> summary is: >>>>> >>>>> - The statistic system is up and provides insight on what the >>>>> heap sampler is doing >>>>> - I've noticed that, though the sampling rate is at the >>>>> right mean, we are missing some samples, I have not yet tracked out why >>>>> (details below) >>>>> >>>>> - I've run a tiny benchmark that is the worse case: it is a >>>>> very tight loop and allocated a small array >>>>> - In this case, I see no overhead when the system is off >>>>> so that is a good start :) >>>>> - I see right now a high overhead in this case when >>>>> sampling is on. This is not a really too surprising but I'm going to see if >>>>> this is consistent with our >>>>> internal implementation. The benchmark is really allocation >>>>> stressful so I'm not too surprised but I want to do the due diligence. >>>>> >>>>> - The statistic system up is up and I have a new test >>>>> http://cr.openjdk.java.net/~rasbold/8171119/webrev.07/test/s >>>>> erviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatTes >>>>> t.java.patch >>>>> >>>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatTe >>>>> st.java.patch> >>>>> - I did a bit of a study about the random generator >>>>> here, more details are below but basically it seems to work well >>>>> >>>>> - I added a capability but since this is the first time >>>>> doing this, I was not sure I did it right >>>>> - I did add a test though for it and the test seems to do >>>>> what I expect (all methods are failing with the >>>>> JVMTI_ERROR_MUST_POSSESS_CAPABILITY error). >>>>> - http://cr.openjdk.java.net/~ra >>>>> sbold/8171119/webrev.07/test/serviceability/jvmti/HeapMonito >>>>> r/MyPackage/HeapMonitorNoCapabilityTest.java.patch >>>>> >>>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorNoCapa >>>>> bilityTest.java.patch> >>>>> >>>>> - I still need to figure out what to do about the >>>>> multi-agent vs single-agent issue >>>>> >>>>> - As far as measurements, it seems I still need to look at: >>>>> - Why we do the 20 random calls first, are they necessary? >>>>> - Look at the mean of the sampling rate that the random >>>>> generator does and also what is actually sampled >>>>> - What is the overhead in terms of memory/performance >>>>> when on? >>>>> >>>>> I have inlined my answers, I think I got them all in the new >>>>> webrev, let me know your thoughts. >>>>> >>>>> Thanks again! >>>>> Jc >>>>> >>>>> >>>>> On Fri, Jun 23, 2017 at 3:52 AM, Thomas Schatzl < >>>>> thomas.schatzl at oracle.com >>>> thomas.schatzl at oracle.com >>>>> >>>>> >> wrote: >>>>> >>>>> Hi, >>>>> >>>>> On Wed, 2017-06-21 at 13:45 -0700, JC Beyler wrote: >>>>> > Hi all, >>>>> > >>>>> > First off: Thanks again to Robbin and Thomas for their >>>>> reviews :) >>>>> > >>>>> > Next, I've uploaded a new webrev: >>>>> > http://cr.openjdk.java.net/~rasbold/8171119/webrev.06/ >>>>> >>>>> >>>> http://cr.openjdk.java.net/~rasbold/8171119/webrev.06/>> >>>>> >>>>> > >>>>> > Here is an update: >>>>> > >>>>> > - @Robbin, I forgot to say that yes I need to look at >>>>> implementing >>>>> > this for the other architectures and testing it before >>>>> it is all >>>>> > ready to go. Is it common to have it working on all >>>>> possible >>>>> > combinations or is there a subset that I should be >>>>> doing first and we >>>>> > can do the others later? >>>>> > - I've tested slowdebug, built and ran the JTreg tests >>>>> I wrote with >>>>> > slowdebug and fixed a few more issues >>>>> > - I've refactored a bit of the code following Thomas' >>>>> comments >>>>> > - I think I've handled all the comments from Thomas >>>>> (I put >>>>> > comments inline below for the specifics) >>>>> >>>>> Thanks for handling all those. >>>>> >>>>> > - Following Thomas' comments on statistics, I want to >>>>> add some >>>>> > quality assurance tests and find that the easiest way >>>>> would be to >>>>> > have a few counters of what is happening in the sampler >>>>> and expose >>>>> > that to the user. >>>>> > - I'll be adding that in the next version if no one >>>>> sees any >>>>> > objections to that. >>>>> > - This will allow me to add a sanity test in JTreg >>>>> about number of >>>>> > samples and average of sampling rate >>>>> > >>>>> > @Thomas: I had a few questions that I inlined below but >>>>> I will >>>>> > summarize the "bigger ones" here: >>>>> > - You mentioned constants are not using the right >>>>> conventions, I >>>>> > looked around and didn't see any convention except >>>>> normal naming then >>>>> > for static constants. Is that right? >>>>> >>>>> I looked through https://wiki.openjdk.java.net/ >>>>> display/HotSpot/StyleGui >>>> /display/HotSpot/StyleGui> >>>>> >>>> https://wiki.openjdk.java.net/display/HotSpot/StyleGui>> >>>>> de and the rule is to "follow an existing pattern and >>>>> must have a >>>>> distinct appearance from other names". Which does not >>>>> help a lot I >>>>> guess :/ The GC team started using upper camel case, e.g. >>>>> SomeOtherConstant, but very likely this is probably not >>>>> applied >>>>> consistently throughout. So I am fine with not adding >>>>> another style >>>>> (like kMaxStackDepth with the "k" in front with some >>>>> unknown meaning) >>>>> is fine. >>>>> >>>>> (Chances are you will find that style somewhere used >>>>> anyway too, >>>>> apologies if so :/) >>>>> >>>>> >>>>> Thanks for that link, now I know where to look. I used the >>>>> upper camel case in my code as well then :) I should have gotten them all. >>>>> >>>>> >>>>> > PS: I've also inlined my answers to Thomas below: >>>>> > >>>>> > On Tue, Jun 13, 2017 at 8:03 AM, Thomas Schatzl >>>>> >>>> > e.com > wrote: >>>>> > > Hi all, >>>>> > > >>>>> > > On Mon, 2017-06-12 at 11:11 -0700, JC Beyler wrote: >>>>> > > > Dear all, >>>>> > > > >>>>> > > > I've continued working on this and have done the >>>>> following >>>>> > > webrev: >>>>> > > > http://cr.openjdk.java.net/~ra >>>>> sbold/8171119/webrev.05/ >>>> asbold/8171119/webrev.05/> >>>>> >>>> http://cr.openjdk.java.net/~rasbold/8171119/webrev.05/>> >>>>> >>>>> > > >>>>> > > [...] >>>>> > > > Things I still need to do: >>>>> > > > - Have to fix that TLAB case for the >>>>> FastTLABRefill >>>>> > > > - Have to start looking at the data to see that >>>>> it is >>>>> > > consistent and does gather the right samples, right >>>>> frequency, etc. >>>>> > > > - Have to check the GC elements and what that >>>>> produces >>>>> > > > - Run a slowdebug run and ensure I fixed all >>>>> those issues you >>>>> > > saw > Robbin >>>>> > > > >>>>> > > > Thanks for looking at the webrev and have a great >>>>> week! >>>>> > > >>>>> > > scratching a bit on the surface of this change, so >>>>> apologies for >>>>> > > rather shallow comments: >>>>> > > >>>>> > > - macroAssembler_x86.cpp:5604: while this is >>>>> compiler code, and I >>>>> > > am not sure this is final, please avoid littering >>>>> the code with >>>>> > > TODO remarks :) They tend to be candidates for later >>>>> wtf moments >>>>> > > only. >>>>> > > >>>>> > > Just file a CR for that. >>>>> > > >>>>> > Newcomer question: what is a CR and not sure I have >>>>> the rights to do >>>>> > that yet ? :) >>>>> >>>>> Apologies. CR is a change request, this suggests to file >>>>> a bug in the >>>>> bug tracker. And you are right, you can't just create a >>>>> new account in >>>>> the OpenJDK JIRA yourselves. :( >>>>> >>>>> >>>>> Ok good to know, I'll continue with my own todo list but I'll >>>>> work hard on not letting it slip in the webrevs anymore :) >>>>> >>>>> >>>>> I was mostly referring to the "... but it is a TODO" part >>>>> of that >>>>> comment in macroassembler_x86.cpp. Comments about the why >>>>> of the code >>>>> are appreciated. >>>>> >>>>> [Note that I now understand that this is to some degree >>>>> still work in >>>>> progress. As long as the final changeset does no contain >>>>> TODO's I am >>>>> fine (and it's not a hard objection, rather their use in >>>>> "final" code >>>>> is typically limited in my experience)] >>>>> >>>>> 5603 // Currently, if this happens, just set back the >>>>> actual end to >>>>> where it was. >>>>> 5604 // We miss a chance to sample here. >>>>> >>>>> Would be okay, if explaining "this" and the "why" of >>>>> missing a chance >>>>> to sample here would be best. >>>>> >>>>> Like maybe: >>>>> >>>>> // If we needed to refill TLABs, just set the actual end >>>>> point to >>>>> // the end of the TLAB again. We do not sample here >>>>> although we could. >>>>> >>>>> Done with your comment, it works well in my mind. >>>>> >>>>> I am not sure whether "miss a chance to sample" meant "we >>>>> could, but >>>>> consciously don't because it's not that useful" or "it >>>>> would be >>>>> necessary but don't because it's too complicated to do.". >>>>> >>>>> Looking at the original comment once more, I am also not >>>>> sure if that >>>>> comment shouldn't referring to the "end" variable (not >>>>> actual_end) >>>>> because that's the variable that is responsible for >>>>> taking the sampling >>>>> path? (Going from the member description of >>>>> ThreadLocalAllocBuffer). >>>>> >>>>> >>>>> I've moved this code and it no longer shows up here but the >>>>> rationale and answer was: >>>>> >>>>> So.. Yes, end is the variable provoking the sampling. Actual >>>>> end is the actual end of the TLAB. >>>>> >>>>> What was happening here is that the code is resetting _end to >>>>> point towards the end of the new TLAB. Because, we now have the end for >>>>> sampling and _actual_end for >>>>> the actual end, we need to update the actual_end as well. >>>>> >>>>> Normally, were we to do the real work here, we would calculate >>>>> the (end - start) offset, then do: >>>>> >>>>> - Set the new end to : start + (old_end - old_start) >>>>> - Set the actual end like we do here now where it because it >>>>> is the actual end. >>>>> >>>>> Why is this not done here now anymore? >>>>> - I was still debating which path to take: >>>>> - Do it in the fast refill code, it has its perks: >>>>> - In a world where fast refills are happening all >>>>> the time or a lot, we can augment there the code to do the sampling >>>>> - Remember what we had as an end before leaving the >>>>> slowpath and check on return >>>>> - This is what I'm doing now, it removes the need >>>>> to go fix up all fast refill paths but if you remain in fast refill paths, >>>>> you won't get sampling. I >>>>> have to think of the consequences of that, maybe a future >>>>> change later on? >>>>> - I have the statistics now so I'm going to >>>>> study that >>>>> -> By the way, though my statistics are >>>>> showing I'm missing some samples, if I turn off FastTlabRefill, it is the >>>>> same loss so for now, it seems >>>>> this does not occur in my simple test. >>>>> >>>>> >>>>> >>>>> But maybe I am only confused and it's best to just leave >>>>> the comment >>>>> away. :) >>>>> >>>>> Thinking about it some more, doesn't this not-sampling in >>>>> this case >>>>> mean that sampling does not work in any collector that >>>>> does inline TLAB >>>>> allocation at the moment? (Or is inline TLAB alloc >>>>> automatically >>>>> disabled with sampling somehow?) >>>>> >>>>> That would indeed be a bigger TODO then :) >>>>> >>>>> >>>>> Agreed, this remark made me think that perhaps as a first step >>>>> the new way of doing it is better but I did have to: >>>>> - Remove the const of the ThreadLocalBuffer remaining and >>>>> hard_end methods >>>>> - Move hard_end out of the header file to have a bit more >>>>> logic there >>>>> >>>>> Please let me know what you think of that and if you prefer it >>>>> this way or changing the fast refills. (I prefer this way now because it is >>>>> more incremental). >>>>> >>>>> >>>>> > > - calling HeapMonitoring::do_weak_oops() (which >>>>> should probably be >>>>> > > called weak_oops_do() like other similar methods) >>>>> only if string >>>>> > > deduplication is enabled (in >>>>> g1CollectedHeap.cpp:4511) seems wrong. >>>>> > >>>>> > The call should be at least around 6 lines up outside >>>>> the if. >>>>> > >>>>> > Preferentially in a method like >>>>> process_weak_jni_handles(), including >>>>> > additional logging. (No new (G1) gc phase without >>>>> minimal logging >>>>> > :)). >>>>> > Done but really not sure because: >>>>> > >>>>> > I put for logging: >>>>> > log_develop_trace(gc, freelist)("G1ConcRegionFreeing >>>>> [other] : heap >>>>> > monitoring"); >>>>> >>>>> I would think that "gc, ref" would be more appropriate >>>>> log tags for >>>>> this similar to jni handles. >>>>> (I am als not sure what weak reference handling has to do >>>>> with >>>>> G1ConcRegionFreeing, so I am a bit puzzled) >>>>> >>>>> >>>>> I was not sure what to put for the tags or really as the >>>>> message. I cleaned it up a bit now to: >>>>> log_develop_trace(gc, ref)("HeapSampling [other] : heap >>>>> monitoring processing"); >>>>> >>>>> >>>>> >>>>> > Since weak_jni_handles didn't have logging for me to be >>>>> inspired >>>>> > from, I did that but unconvinced this is what should be >>>>> done. >>>>> >>>>> The JNI handle processing does have logging, but only in >>>>> ReferenceProcessor::process_discovered_references(). In >>>>> process_weak_jni_handles() only overall time is measured >>>>> (in a G1 >>>>> specific way, since only G1 supports disabling reference >>>>> procesing) :/ >>>>> >>>>> The code in ReferenceProcessor prints both time taken >>>>> referenceProcessor.cpp:254, as well as the count, but >>>>> strangely only in >>>>> debug VMs. >>>>> >>>>> I have no idea why this logging is that unimportant to >>>>> only print that >>>>> in a debug VM. However there are reviews out for changing >>>>> this area a >>>>> bit, so it might be useful to wait for that (JDK-8173335). >>>>> >>>>> >>>>> I cleaned it up a bit anyway and now it returns the count of >>>>> objects that are in the system. >>>>> >>>>> >>>>> > > - the change doubles the size of >>>>> > > CollectedHeap::allocate_from_tlab_slow() above the >>>>> "small and nice" >>>>> > > threshold. Maybe it could be refactored a bit. >>>>> > Done I think, it looks better to me :). >>>>> >>>>> In ThreadLocalAllocBuffer::handle_sample() I think the >>>>> set_back_actual_end()/pick_next_sample() calls could be >>>>> hoisted out of >>>>> the "if" :) >>>>> >>>>> >>>>> Done! >>>>> >>>>> >>>>> > > - referenceProcessor.cpp:261: the change should add >>>>> logging about >>>>> > > the number of references encountered, maybe after the >>>>> corresponding >>>>> > > "JNI weak reference count" log message. >>>>> > Just to double check, are you saying that you'd like to >>>>> have the heap >>>>> > sampler to keep in store how many sampled objects were >>>>> encountered in >>>>> > the HeapMonitoring::weak_oops_do? >>>>> > - Would a return of the method with the number of >>>>> handled >>>>> > references and logging that work? >>>>> >>>>> Yes, it's fine if HeapMonitoring::weak_oops_do() only >>>>> returned the >>>>> number of processed weak oops. >>>>> >>>>> >>>>> Done also (but I admit I have not tested the output yet) :) >>>>> >>>>> >>>>> > - Additionally, would you prefer it in a separate >>>>> block with its >>>>> > GCTraceTime? >>>>> >>>>> Yes. Both kinds of information is interesting: while the >>>>> time taken is >>>>> typically more important, the next question would be why, >>>>> and the >>>>> number of references typically goes a long way there. >>>>> >>>>> See above though, it is probably best to wait a bit. >>>>> >>>>> >>>>> Agreed that I "could" wait but, if it's ok, I'll just >>>>> refactor/remove this when we get closer to something final. Either, >>>>> JDK-8173335 >>>>> has gone in and I will notice it now or it will soon and I can >>>>> change it then. >>>>> >>>>> >>>>> > > - threadLocalAllocBuffer.cpp:331: one more "TODO" >>>>> > Removed it and added it to my personal todos to look at. >>>>> > > > >>>>> > > - threadLocalAllocBuffer.hpp: ThreadLocalAllocBuffer >>>>> class >>>>> > > documentation should be updated about the sampling >>>>> additions. I >>>>> > > would have no clue what the difference between >>>>> "actual_end" and >>>>> > > "end" would be from the given information. >>>>> > If you are talking about the comments in this file, I >>>>> made them more >>>>> > clear I hope in the new webrev. If it was somewhere >>>>> else, let me know >>>>> > where to change. >>>>> >>>>> Thanks, that's much better. Maybe a note in the comment >>>>> of the class >>>>> that ThreadLocalBuffer provides some sampling facility by >>>>> modifying the >>>>> end() of the TLAB to cause "frequent" calls into the >>>>> runtime call where >>>>> actual sampling takes place. >>>>> >>>>> >>>>> Done, I think it's better now. Added something about the >>>>> slow_path_end as well. >>>>> >>>>> >>>>> > > - in heapMonitoring.hpp: there are some random >>>>> comments about some >>>>> > > code that has been grabbed from >>>>> "util/math/fastmath.[h|cc]". I >>>>> > > can't tell whether this is code that can be used but >>>>> I assume that >>>>> > > Noam Shazeer is okay with that (i.e. that's all >>>>> Google code). >>>>> > Jeremy and I double checked and we can release that as >>>>> I thought. I >>>>> > removed the comment from that piece of code entirely. >>>>> >>>>> Thanks. >>>>> >>>>> > > - heapMonitoring.hpp/cpp static constant naming does >>>>> not correspond >>>>> > > to Hotspot's. Additionally, in Hotspot static methods >>>>> are cased >>>>> > > like other methods. >>>>> > I think I fixed the methods to be cased the same way as >>>>> all other >>>>> > methods. For static constants, I was not sure. I fixed >>>>> a few other >>>>> > variables but I could not seem to really see a >>>>> consistent trend for >>>>> > constants. I made them as variables but I'm not sure >>>>> now. >>>>> >>>>> Sorry again, style is a kind of mess. The goal of my >>>>> suggestions here >>>>> is only to prevent yet another style creeping in. >>>>> >>>>> > > - in heapMonitoring.cpp there are a few cryptic >>>>> comments at the top >>>>> > > that seem to refer to internal stuff that should >>>>> probably be >>>>> > > removed. >>>>> > Sorry about that! My personal todos not cleared out. >>>>> >>>>> I am happy about comments, but I simply did not >>>>> understand any of that >>>>> and I do not know about other readers as well. >>>>> >>>>> If you think you will remember removing/updating them >>>>> until the review >>>>> proper (I misunderstood the review situation a little it >>>>> seems). >>>>> >>>>> > > I did not think through the impact of the TLAB >>>>> changes on collector >>>>> > > behavior yet (if there are). Also I did not check for >>>>> problems with >>>>> > > concurrent mark and SATB/G1 (if there are). >>>>> > I would love to know your thoughts on this, I think >>>>> this is fine. I >>>>> >>>>> I think so too now. No objects are made live out of thin >>>>> air :) >>>>> >>>>> > see issues with multiple threads right now hitting the >>>>> stack storage >>>>> > instance. Previous webrevs had a mutex lock here but we >>>>> took it out >>>>> > for simplificity (and only for now). >>>>> >>>>> :) When looking at this after some thinking I now assume >>>>> for this >>>>> review that this code is not MT safe at all. There seems >>>>> to be more >>>>> synchronization missing than just the one for the >>>>> StackTraceStorage. So >>>>> no comments about this here. >>>>> >>>>> >>>>> I doubled checked a bit (quickly I admit) but it seems that >>>>> synchronization in StackTraceStorage is really all you need (all methods >>>>> lead to a StackTraceStorage one >>>>> and can be multithreaded outside of that). >>>>> There is a question about the initialization where the method >>>>> HeapMonitoring::initialize_profiling is not thread safe. >>>>> It would work (famous last words) and not crash if there was a >>>>> race but we could add a synchronization point there as well (and therefore >>>>> on the stop as well). >>>>> >>>>> But anyway I will really check and do this once we add back >>>>> synchronization. >>>>> >>>>> >>>>> Also, this would require some kind of specification of >>>>> what is allowed >>>>> to be called when and where. >>>>> >>>>> >>>>> Would we specify this with the methods in the jvmti.xml file? >>>>> We could start by specifying in each that they are not thread safe but I >>>>> saw no mention of that for >>>>> other methods. >>>>> >>>>> >>>>> One potentially relevant observation about locking here: >>>>> depending on >>>>> sampling frequency, StackTraceStore::add_trace() may be >>>>> rather >>>>> frequently called. I assume that you are going to do >>>>> measurements :) >>>>> >>>>> >>>>> Though we don't have the TLAB implementation in our code, the >>>>> compiler generated sampler uses 2% of overhead with a 512k sampling rate. I >>>>> can do real measurements >>>>> when the code settles and we can see how costly this is as a >>>>> TLAB implementation. >>>>> However, my theory is that if the rate is 512k, the >>>>> memory/performance overhead should be minimal since it is what we saw with >>>>> our code/workloads (though not called >>>>> the same way, we call it essentially at the same rate). >>>>> If you have a benchmark you'd like me to test, let me know! >>>>> >>>>> Right now, with my really small test, this does use a bit of >>>>> overhead even for a 512k sample size. I don't know yet why, I'm going to >>>>> see what is going on. >>>>> >>>>> Finally, I think it is not reasonable to suppose the overhead >>>>> to be negligible if the sampling rate used is too low. The user should know >>>>> that the lower the rate, >>>>> the higher the overhead (documentation TODO?). >>>>> >>>>> >>>>> I am not sure what the expected usage of the API is, but >>>>> StackTraceStore::add_trace() seems to be able to grow >>>>> without bounds. >>>>> Only a GC truncates them to the live ones. That in itself >>>>> seems to be >>>>> problematic (GCs can be *wide* apart), and of course some >>>>> of the API >>>>> methods add to that because they duplicate that unbounded >>>>> array. Do you >>>>> have any concerns/measurements about this? >>>>> >>>>> >>>>> So, the theory is that yes add_trace can be able to grow >>>>> without bounds but it grows at a sample per 512k of allocated space. The >>>>> stacks it gathers are currently >>>>> maxed at 64 (I'd like to expand that to an option to the user >>>>> though at some point). So I have no concerns because: >>>>> >>>>> - If really this is taking a lot of space, that means the job >>>>> is keeping a lot of objects in memory as well, therefore the entire heap is >>>>> getting huge >>>>> - If this is the case, you will be triggering a GC at some >>>>> point anyway. >>>>> >>>>> (I'm putting under the rug the issue of "What if we set the >>>>> rate to 1 for example" because as you lower the sampling rate, we cannot >>>>> guarantee low overhead; the >>>>> idea behind this feature is to have a means of having >>>>> meaningful allocated samples at a low overhead) >>>>> >>>>> I have no measurements really right now but since I now have >>>>> some statistics I can poll, I will look a bit more at this question. >>>>> >>>>> I have the same last sentence than above: the user should >>>>> expect this to happen if the sampling rate is too small. That probably can >>>>> be reflected in the >>>>> StartHeapSampling as a note : careful this might impact your >>>>> performance. >>>>> >>>>> >>>>> Also, these stack traces might hold on to huge arrays. Any >>>>> consideration of that? Particularly it might be the cause >>>>> for OOMEs in >>>>> tight memory situations. >>>>> >>>>> >>>>> There is a stack size maximum that is set to 64 so it should >>>>> not hold huge arrays. I don't think this is an issue but I can double check >>>>> with a test or two. >>>>> >>>>> >>>>> - please consider adding a safepoint check in >>>>> HeapMonitoring::weak_oops_do to prevent accidental misuse. >>>>> >>>>> - in struct StackTraceStorage, the public fields may also >>>>> need >>>>> underscores. At least some files in the runtime directory >>>>> have structs >>>>> with underscored public members (and some don't). The >>>>> runtime team >>>>> should probably comment on that. >>>>> >>>>> >>>>> Agreed I did not know. I looked around and a lot of structs >>>>> did not have them it seemed so I left it as is. I will happily change it if >>>>> someone prefers (I was not >>>>> sure if you really preferred or not, your sentence seemed to >>>>> be more a note of "this might need to change but I don't know if the >>>>> runtime team enforces that", let >>>>> me know if I read that wrongly). >>>>> >>>>> >>>>> - In StackTraceStorage::weak_oops_do(), when examining >>>>> the >>>>> StackTraceData, maybe it is useful to consider having a >>>>> non-NULL >>>>> reference outside of the heap's reserved space an error. >>>>> There should >>>>> be no oop outside of the heap's reserved space ever. >>>>> >>>>> Unless you allow storing random values in >>>>> StackTraceData::obj, which I >>>>> would not encourage. >>>>> >>>>> >>>>> I suppose you are talking about this part: >>>>> if ((value != NULL && Universe::heap()->is_in_reserved(value)) >>>>> && >>>>> (is_alive == NULL || >>>>> is_alive->do_object_b(value))) { >>>>> >>>>> What you are saying is that I could have something like: >>>>> if (value != my_non_null_reference && >>>>> (is_alive == NULL || >>>>> is_alive->do_object_b(value))) { >>>>> >>>>> Is that what you meant? Is there really a reason to do so? >>>>> When I look at the code, is_in_reserved seems like a O(1) method call. I'm >>>>> not even sure we can have a >>>>> NULL value to be honest. I might have to study that to see if >>>>> this was not a paranoid test to begin with. >>>>> >>>>> The is_alive code has now morphed due to the comment below. >>>>> >>>>> >>>>> >>>>> - HeapMonitoring::weak_oops_do() does not seem to use the >>>>> passed AbstractRefProcTaskExecutor. >>>>> >>>>> >>>>> It did use it: >>>>> size_t HeapMonitoring::weak_oops_do( >>>>> AbstractRefProcTaskExecutor *task_executor, >>>>> BoolObjectClosure* is_alive, >>>>> OopClosure *f, >>>>> VoidClosure *complete_gc) { >>>>> assert(SafepointSynchronize::is_at_safepoint(), "must be >>>>> at safepoint"); >>>>> >>>>> if (task_executor != NULL) { >>>>> task_executor->set_single_threaded_mode(); >>>>> } >>>>> return StackTraceStorage::storage()->weak_oops_do(is_alive, >>>>> f, complete_gc); >>>>> } >>>>> >>>>> But due to the comment below, I refactored this, so this is no >>>>> longer here. Now I have an always true closure that is passed. >>>>> >>>>> >>>>> - I do not understand allowing to call this method with a >>>>> NULL >>>>> complete_gc closure. This would mean that objects >>>>> referenced from the >>>>> object that is referenced by the StackTraceData are not >>>>> pulled, meaning >>>>> they would get stale. >>>>> >>>>> - same with is_alive parameter value of NULL >>>>> >>>>> >>>>> So these questions made me look a bit closer at this code. >>>>> This code I think was written this way to have a very small impact on the >>>>> file but you are right, there >>>>> is no reason for this here. I've simplified the code by making >>>>> in referenceProcessor.cpp a process_HeapSampling method that handles >>>>> everything there. >>>>> >>>>> The code allowed NULLs because it depended on where you were >>>>> coming from and how the code was being called. >>>>> >>>>> - I added a static always_true variable and pass that now to >>>>> be more consistent with the rest of the code. >>>>> - I moved the complete_gc into process_phaseHeapSampling now >>>>> (new method) and handle the task_executor and the complete_gc there >>>>> - Newbie question: in our code we did a >>>>> set_single_threaded_mode but I see that process_phaseJNI does it right >>>>> before its call, do I need to do it for the >>>>> process_phaseHeapSample? >>>>> That API is much cleaner (in my mind) and is consistent with >>>>> what is done around it (again in my mind). >>>>> >>>>> >>>>> - heapMonitoring.cpp:590: I do not completely understand >>>>> the purpose of >>>>> this code: in the end this results in a fixed value >>>>> directly dependent >>>>> on the Thread address anyway? In the end this results in >>>>> a fixed value >>>>> directly dependent on the Thread address anyway? >>>>> IOW, what is special about exactly 20 rounds? >>>>> >>>>> >>>>> So we really want a fast random number generator that has a >>>>> specific mean (512k is the default we use). The code uses the thread >>>>> address as the start number of the >>>>> sequence (why not, it is random enough is rationale). Then >>>>> instead of just starting there, we prime the sequence and really only start >>>>> at the 21st number, it is >>>>> arbitrary and I have not done a study to see if we could do >>>>> more or less of that. >>>>> >>>>> As I have the statistics of the system up and running, I'll >>>>> run some experiments to see if this is needed, is 20 good, or not. >>>>> >>>>> >>>>> - also I would consider stripping a few bits of the >>>>> threads' address as >>>>> initialization value for your rng. The last three bits >>>>> (and probably >>>>> more, check whether the Thread object is allocated on >>>>> special >>>>> boundaries) are always zero for them. >>>>> Not sure if the given "random" value is random enough >>>>> before/after, >>>>> this method, so just skip that comment if you think this >>>>> is not >>>>> required. >>>>> >>>>> >>>>> I don't know is the honest answer. I think what is important >>>>> is that we tend towards a mean and it is random "enough" to not fall in >>>>> pitfalls of only sampling a >>>>> subset of objects due to their allocation order. I added that >>>>> as test to do to see if it changes the mean in any way for the 512k default >>>>> value and/or if the first >>>>> 1000 elements look better. >>>>> >>>>> >>>>> Some more random nits I did not find a place to put >>>>> anywhere: >>>>> >>>>> - ThreadLocalAllocBuffer::_extra_space does not seem to >>>>> be used >>>>> anywhere? >>>>> >>>>> >>>>> Good catch :). >>>>> >>>>> >>>>> - Maybe indent the declaration of >>>>> ThreadLocalAllocBuffer::_bytes_until_sample to align below the other >>>>> members of that group. >>>>> >>>>> >>>>> Done moved it up a bit to have non static members together and >>>>> static separate. >>>>> >>>>> Thanks, >>>>> Thomas >>>>> >>>>> >>>>> Thanks for your review! >>>>> Jc >>>>> >>>>> >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Sep 26 09:15:05 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Sep 2017 02:15:05 -0700 Subject: PING: RFR: 8187401: Java Stack cannot be shown on HSDB In-Reply-To: References: Message-ID: <3d25fa66-085d-11a7-74f4-eba9fa0360b5@oracle.com> Hi Yasumasa, This fix looks Ok to me but you need to add a unit test. Thanks, Serguei On 9/20/17 15:47, Yasumasa Suenaga wrote: > PING: > > Have you checked this issue? > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ > > > Yasumasa > > > On 2017/09/11 11:16, Yasumasa Suenaga wrote: >> Hi all, >> >> This review request is a part of [1]. >> >> >> JBS: >> ?? https://bugs.openjdk.java.net/browse/JDK-8187401 >> >> webrev: >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ >> >> >> I cannot access JPRT. So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >> From yasuenag at gmail.com Tue Sep 26 09:31:00 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 26 Sep 2017 18:31:00 +0900 Subject: RFR: JDK-8187597: WrongTypeException is occurred at CLHSDB jstack after JDK-8186837 In-Reply-To: References: <39e4a81a-0a12-1ee7-dedb-0b9853d89fce@gmail.com> <6f369ad1-ee23-32b1-37ae-3bb60629960c@gmail.com> <9bfc8e1d-8438-21f2-3c06-e53bb95afb6c@oracle.com> <0ee1ed46-5c27-8693-fb6d-396a3059335e@oracle.com> <13b177d1-e04c-dd86-7a86-b55b165d5830@oracle.com> <2c955c17-43b9-906f-408d-f5349d57ca13@gmail.com> Message-ID: Hi David, > You will need to rebase all your patches before they can be sponsored. I uploaded webrev for jdk10/hs: http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.01/ Could you push it? Thanks, Yasumasa 2017-09-21 9:31 GMT+09:00 David Holmes : > On 21/09/2017 9:57 AM, Yasumasa Suenaga wrote: >> >> 2017/09/21 ??8:35 "David Holmes" > >: >> >> The opening announcement was somewhat premature. They created >> jdk10/hs but we're not quite ready to start accepting changes yet. >> >> >> Where can I get the opening announcement for jdk10/hs? > > > hotspot-dev > >> I will send review request after that. > > > You will need to rebase all your patches before they can be sponsored. > > Thanks, > David > >> >> Thanks, >> >> Yasumasa >> >> >> >> David >> >> >> On 21/09/2017 8:44 AM, Yasumasa Suenaga wrote: >> >> Hi David, >> >> jdk10/hs has been opened [1]. >> Could you push this change? >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] >> >> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-September/000499.html >> >> >> >> >> On 2017/09/19 12:31, David Holmes wrote: >> >> On 19/09/2017 1:19 PM, Yasumasa Suenaga wrote: >> >> Thanks David, >> >> BTW, can I push this change after jdk10/master is opened? >> I cannot access JPRT. >> >> >> I think we'd probably prefer this to go into jdk10/hs - once >> it is open - and for that you need a sponsor. >> >> Thanks, >> David >> >> >> Yasumasa >> >> >> 2017/09/19 ??0:08 "David Holmes" >> > >> > >> >>: >> >> Hi Yasumasa, >> >> On 19/09/2017 12:55 PM, Yasumasa Suenaga wrote: >> >> Thanks Chris, Robbin, >> >> I'm waiting reviewer(s) for this change. >> >> >> Reviewed. >> >> This simply reverts the change of 8185102. >> >> Thanks, >> David >> ----- >> >> >> Yasumasa >> >> >> 2017/09/19 ??7:14 "Chris Plummer" >> > >> > > >> > >> > >>>: >> >> Hi Yasumasa, >> >> Ok, I see now that CIntegerField is just >> an interface, so >> it's up to >> a class to implement getValue() to fetch >> the field. I'm a bit >> unclear on how that part works, but from >> responses by >> others, it >> seems this is ok. >> >> I've run all the tests I can find that use >> jstack or jhsdb, >> and the >> assert was not triggered. Probably need to >> have a NMethod >> on the >> stack to trigger the code you are fixing. >> >> thanks, >> >> Chris >> >> >> On 9/17/17 1:13 AM, Yasumasa Suenaga wrote: >> >> Hi Chris, >> >> I've tested this issue on Fedora 26 >> x86_64. >> I think we can sue CIntegerField at >> this point because >> CIntegerField is not specialized for >> various int size [1]. >> In fact, CIntegerField had been used >> at this point [2], >> and HSDB >> worked fine. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] >> >> http://hg.openjdk.java.net/jdk10/master/file/fd36993f7bf5/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/CIntegerField.java#l29 >> >> >> >> >> > >> > >> >> >> > >> >> >> >> > >> >> >> >> [2] >> http://hg.openjdk.java.net/jdk10/master/rev/cbfdbefc6ea3 >> >> >> > > >> >> > >> >> > >> >> >> >> On 2017/09/17 3:58, Chris Plummer wrote: >> >> Hi Yasumasa, >> >> Is this on a 32-bit system? I >> don't see how you could >> otherwise call getCIntegerField() >> on a long type. >> jlong is >> always 64-bit and long is >> (generally) 32-bit on 32-bit >> systems, and 64-bit on 64-bit >> systems, at least >> that seems >> to be the case with linux. >> >> From what I can see, >> _stack_traversal_mark is now >> the only >> long type in vmStructs.cpp. I >> don't know that we have a >> mechanism to safely fetch it on >> both 32-bit and >> 64-bit systems. >> >> _stack_traversal_mark seems to be >> a long because >> _traversals >> is also a long. >> >> static long >> _traversals; // >> Stack scan count, also sweep ID. >> >> This too might be considered a >> bug. I'm not sure >> why you >> would want the size of this field >> to vary between >> 32-bit and >> 64-bit systems (adding >> compiler-dev to help answer >> that). >> >> So, while I would agree that your >> fix is generally >> in the >> right direction, I think we first >> need to revisit >> the use of >> long for these fields. If they can >> be changed to an >> int, >> then your fix is correct (pending >> the changes to >> int). If >> not, then maybe we need >> getCLongField() support. >> >> And lastly, we really should have >> a test to detect >> this bug. >> Maybe we already do, and it is >> failing but is going >> unnoticed for some reason. I'll >> try to look into >> that some >> more on Monday. >> >> thanks, >> >> Chris >> >> On 9/16/17 5:20 AM, Yasumasa >> Suenaga wrote: >> >> Hi all, >> >> I tried to get thread dump via >> jstack command >> on CLHSDB. >> But it was failed as below: >> >> ``` >> Caused by: >> sun.jvm.hotspot.types.WrongTypeException: >> field "_stack_traversal_mark" >> in type nmethod >> is not of >> type jlong, but instead of >> type long >> at >> >> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:206) >> >> at >> >> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:212) >> >> at >> >> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getJLongField(BasicType.java:249) >> >> at >> >> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.initialize(NMethod.java:108) >> >> at >> >> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.access$000(NMethod.java:35) >> >> at >> >> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod$1.update(NMethod.java:81) >> >> at >> >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:451) >> >> at >> >> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.(NMethod.java:79) >> ... 23 more >> ``` >> >> I think this exception is >> caused by JDK-8186837. >> This changeset has changed the >> type of >> >> `nmethod::_stack_traversal_mark` to `long` from >> `jlong`. >> >> SA should follow this change. >> >> I uploaded a webrev for this >> issue. This webrev is >> generated from consolidated >> repo (jdk10/master). >> Could you review it? >> >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.00/ >> >> >> >> > >> > >> >> > >> >> >> > >> >> >> >> >> I cannot access JPRT. So I >> need reviewer. >> >> >> Thanks, >> >> Yasumasa >> >> >> >> >> >> >> > From yasuenag at gmail.com Tue Sep 26 09:41:23 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 26 Sep 2017 18:41:23 +0900 Subject: PING: RFR: 8187401: Java Stack cannot be shown on HSDB In-Reply-To: <3d25fa66-085d-11a7-74f4-eba9fa0360b5@oracle.com> References: <3d25fa66-085d-11a7-74f4-eba9fa0360b5@oracle.com> Message-ID: Hi Serguei, Thank you for your comment! > This fix looks Ok to me but you need to add a unit test. I guess it is caused by inlined method which is generated by JIT compiler. I don't know how to reproduce it on jtreg test. Do you have any idea for it? Yasumasa 2017-09-26 18:15 GMT+09:00 serguei.spitsyn at oracle.com : > Hi Yasumasa, > > This fix looks Ok to me but you need to add a unit test. > > Thanks, > Serguei > > > > On 9/20/17 15:47, Yasumasa Suenaga wrote: >> >> PING: >> >> Have you checked this issue? >> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ >> >> >> >> Yasumasa >> >> >> On 2017/09/11 11:16, Yasumasa Suenaga wrote: >>> >>> Hi all, >>> >>> This review request is a part of [1]. >>> >>> >>> JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8187401 >>> >>> webrev: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ >>> >>> >>> I cannot access JPRT. So I need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >>> > From david.holmes at oracle.com Tue Sep 26 10:55:05 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Sep 2017 20:55:05 +1000 Subject: RFR: JDK-8187597: WrongTypeException is occurred at CLHSDB jstack after JDK-8186837 In-Reply-To: References: <39e4a81a-0a12-1ee7-dedb-0b9853d89fce@gmail.com> <6f369ad1-ee23-32b1-37ae-3bb60629960c@gmail.com> <9bfc8e1d-8438-21f2-3c06-e53bb95afb6c@oracle.com> <0ee1ed46-5c27-8693-fb6d-396a3059335e@oracle.com> <13b177d1-e04c-dd86-7a86-b55b165d5830@oracle.com> <2c955c17-43b9-906f-408d-f5349d57ca13@gmail.com> Message-ID: <21df4ebd-823b-cf13-b9f7-24b31be35f0a@oracle.com> Hi Yasumasa, On 26/09/2017 7:31 PM, Yasumasa Suenaga wrote: > Hi David, > >> You will need to rebase all your patches before they can be sponsored. > > I uploaded webrev for jdk10/hs: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.01/ > > > Could you push it? On its way, but please create the final changeset ready for your sponsor(s) to directly import in the future. Thanks, David > > Thanks, > > Yasumasa > > > 2017-09-21 9:31 GMT+09:00 David Holmes : >> On 21/09/2017 9:57 AM, Yasumasa Suenaga wrote: >>> >>> 2017/09/21 ??8:35 "David Holmes" >> >: >>> >>> The opening announcement was somewhat premature. They created >>> jdk10/hs but we're not quite ready to start accepting changes yet. >>> >>> >>> Where can I get the opening announcement for jdk10/hs? >> >> >> hotspot-dev >> >>> I will send review request after that. >> >> >> You will need to rebase all your patches before they can be sponsored. >> >> Thanks, >> David >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> >>> David >>> >>> >>> On 21/09/2017 8:44 AM, Yasumasa Suenaga wrote: >>> >>> Hi David, >>> >>> jdk10/hs has been opened [1]. >>> Could you push this change? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> >>> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-September/000499.html >>> >>> >>> >>> >>> On 2017/09/19 12:31, David Holmes wrote: >>> >>> On 19/09/2017 1:19 PM, Yasumasa Suenaga wrote: >>> >>> Thanks David, >>> >>> BTW, can I push this change after jdk10/master is opened? >>> I cannot access JPRT. >>> >>> >>> I think we'd probably prefer this to go into jdk10/hs - once >>> it is open - and for that you need a sponsor. >>> >>> Thanks, >>> David >>> >>> >>> Yasumasa >>> >>> >>> 2017/09/19 ??0:08 "David Holmes" >>> >> >>> >> >>> >>: >>> >>> Hi Yasumasa, >>> >>> On 19/09/2017 12:55 PM, Yasumasa Suenaga wrote: >>> >>> Thanks Chris, Robbin, >>> >>> I'm waiting reviewer(s) for this change. >>> >>> >>> Reviewed. >>> >>> This simply reverts the change of 8185102. >>> >>> Thanks, >>> David >>> ----- >>> >>> >>> Yasumasa >>> >>> >>> 2017/09/19 ??7:14 "Chris Plummer" >>> >> >>> >> > >>> >> >>> >> >>>: >>> >>> Hi Yasumasa, >>> >>> Ok, I see now that CIntegerField is just >>> an interface, so >>> it's up to >>> a class to implement getValue() to fetch >>> the field. I'm a bit >>> unclear on how that part works, but from >>> responses by >>> others, it >>> seems this is ok. >>> >>> I've run all the tests I can find that use >>> jstack or jhsdb, >>> and the >>> assert was not triggered. Probably need to >>> have a NMethod >>> on the >>> stack to trigger the code you are fixing. >>> >>> thanks, >>> >>> Chris >>> >>> >>> On 9/17/17 1:13 AM, Yasumasa Suenaga wrote: >>> >>> Hi Chris, >>> >>> I've tested this issue on Fedora 26 >>> x86_64. >>> I think we can sue CIntegerField at >>> this point because >>> CIntegerField is not specialized for >>> various int size [1]. >>> In fact, CIntegerField had been used >>> at this point [2], >>> and HSDB >>> worked fine. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> >>> http://hg.openjdk.java.net/jdk10/master/file/fd36993f7bf5/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/CIntegerField.java#l29 >>> >>> >>> >>> >>> >> >>> > >>> >>> >>> >> >>> >>> >>> >>> >> >>> >> >>> >>> [2] >>> http://hg.openjdk.java.net/jdk10/master/rev/cbfdbefc6ea3 >>> >>> >>> >> > >>> >>> >> >>> >>> >> >> >>> >>> >>> On 2017/09/17 3:58, Chris Plummer wrote: >>> >>> Hi Yasumasa, >>> >>> Is this on a 32-bit system? I >>> don't see how you could >>> otherwise call getCIntegerField() >>> on a long type. >>> jlong is >>> always 64-bit and long is >>> (generally) 32-bit on 32-bit >>> systems, and 64-bit on 64-bit >>> systems, at least >>> that seems >>> to be the case with linux. >>> >>> From what I can see, >>> _stack_traversal_mark is now >>> the only >>> long type in vmStructs.cpp. I >>> don't know that we have a >>> mechanism to safely fetch it on >>> both 32-bit and >>> 64-bit systems. >>> >>> _stack_traversal_mark seems to be >>> a long because >>> _traversals >>> is also a long. >>> >>> static long >>> _traversals; // >>> Stack scan count, also sweep ID. >>> >>> This too might be considered a >>> bug. I'm not sure >>> why you >>> would want the size of this field >>> to vary between >>> 32-bit and >>> 64-bit systems (adding >>> compiler-dev to help answer >>> that). >>> >>> So, while I would agree that your >>> fix is generally >>> in the >>> right direction, I think we first >>> need to revisit >>> the use of >>> long for these fields. If they can >>> be changed to an >>> int, >>> then your fix is correct (pending >>> the changes to >>> int). If >>> not, then maybe we need >>> getCLongField() support. >>> >>> And lastly, we really should have >>> a test to detect >>> this bug. >>> Maybe we already do, and it is >>> failing but is going >>> unnoticed for some reason. I'll >>> try to look into >>> that some >>> more on Monday. >>> >>> thanks, >>> >>> Chris >>> >>> On 9/16/17 5:20 AM, Yasumasa >>> Suenaga wrote: >>> >>> Hi all, >>> >>> I tried to get thread dump via >>> jstack command >>> on CLHSDB. >>> But it was failed as below: >>> >>> ``` >>> Caused by: >>> sun.jvm.hotspot.types.WrongTypeException: >>> field "_stack_traversal_mark" >>> in type nmethod >>> is not of >>> type jlong, but instead of >>> type long >>> at >>> >>> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:206) >>> >>> at >>> >>> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:212) >>> >>> at >>> >>> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getJLongField(BasicType.java:249) >>> >>> at >>> >>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.initialize(NMethod.java:108) >>> >>> at >>> >>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.access$000(NMethod.java:35) >>> >>> at >>> >>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod$1.update(NMethod.java:81) >>> >>> at >>> >>> jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:451) >>> >>> at >>> >>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.(NMethod.java:79) >>> ... 23 more >>> ``` >>> >>> I think this exception is >>> caused by JDK-8186837. >>> This changeset has changed the >>> type of >>> >>> `nmethod::_stack_traversal_mark` to `long` from >>> `jlong`. >>> >>> SA should follow this change. >>> >>> I uploaded a webrev for this >>> issue. This webrev is >>> generated from consolidated >>> repo (jdk10/master). >>> Could you review it? >>> >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.00/ >>> >>> >>> >>> >> >>> > >>> >>> >> >>> >>> >>> >> >>> >> >>> >>> >>> I cannot access JPRT. So I >>> need reviewer. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> >>> >>> >>> >>> >> From yasuenag at gmail.com Tue Sep 26 14:49:32 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 26 Sep 2017 23:49:32 +0900 Subject: RFR: 8187402: UnknownOopException is occurred on Stack Memory window in HSDB In-Reply-To: References: Message-ID: <4c8a242f-464e-297e-5779-a237691be495@gmail.com> Hi all, I uploaded new webrev to be adapted to jdk10/hs: http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.01/ Thanks, Yasumasa On 2017/09/21 7:47, Yasumasa Suenaga wrote: > PING: > > Have you checked this issue? > >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.00/ > > > Yasumasa > > > On 2017/09/11 11:17, Yasumasa Suenaga wrote: >> Hi all, >> >> This review request is a part of [1]. >> >> >> JBS: >> ?? https://bugs.openjdk.java.net/browse/JDK-8187402 >> >> webrev: >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.00/ >> >> >> I cannot access JPRT. So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >> From yasuenag at gmail.com Tue Sep 26 14:55:32 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 26 Sep 2017 23:55:32 +0900 Subject: RFR: 8187403: [Unknown generation] is shown in Stack Memory on HSDB In-Reply-To: <2ee4d0c9-bdd5-19f3-e036-0aa096b59946@gmail.com> References: <2ee4d0c9-bdd5-19f3-e036-0aa096b59946@gmail.com> Message-ID: Hi all, I uploaded new webrev to be adapted to jdk10/hs: http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/ Thanks, Yasumasa On 2017/09/21 7:48, Yasumasa Suenaga wrote: > PING: > > Have you checked this issue? > >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.00/ > > > Yasumasa > > > On 2017/09/11 11:18, Yasumasa Suenaga wrote: >> Hi all, >> >> This review request is a part of [1]. >> >> >> JBS: >> ?? https://bugs.openjdk.java.net/browse/JDK-8187403 >> >> webrev: >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.00/ >> >> >> I cannot access JPRT. So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >> From yasuenag at gmail.com Tue Sep 26 15:01:24 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 27 Sep 2017 00:01:24 +0900 Subject: RFR: JDK-8151815: Could not parse core image with JSnap. In-Reply-To: References: <7b897b36-1824-606d-b206-df577a6afe02@gmail.com> Message-ID: Hi all, I uploaded new webrev to be adapted to jdk10/hs: http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.04/ Thanks, Yasumasa On 2017/09/21 7:45, Yasumasa Suenaga wrote: > PING: > > Have you checked this issue? > >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.03/ > > > Yasumasa > > > On 2017/07/01 23:43, Yasumasa Suenaga wrote: >> PING: >> >> Have you checked this issue? >> >> >> Yasumasa >> >> >> On 2017/06/13 14:10, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I want to discuss about JDK-8151815: Could not parse core image with JSnap. >>> >>> >>> In last year, I found JSnap cannot parse coredump and I've sent review >>> request for it as JDK-8151815. However it has not been reviewed yet >>> [1]. >>> >>> We've discussed about safety implementation, but we could not get consensus. >>> IMHO all SA tools should be handled java processes and core images, >>> and PerfCounter value is useful. So I fix this issue. >>> >>> I uploaded new webrev for this issue. I think this patch is safety >>> because new flag PerfMemory::_destroyed guards double free, and all >>> members in PerfMemory is accessible (they are not munmap'ed) >>> >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.03/ >>> >>> >>> Can you cooperate? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-April/019480.html >>> From yasuenag at gmail.com Tue Sep 26 15:08:56 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 27 Sep 2017 00:08:56 +0900 Subject: RFR: JDK-8153333: [REDO] STW phases at Concurrent GC should count in PerfCounter In-Reply-To: <2f4e0901-1602-6276-e7fd-84e168e7b317@gmail.com> References: <2f4e0901-1602-6276-e7fd-84e168e7b317@gmail.com> Message-ID: Hi all, I uploaded new webrev to be adapted to jdk10/hs: http://cr.openjdk.java.net/~ysuenaga/JDK-8153333/webrev.04/ I want to check this patch via JPRT, but I cannot access it. Could you cooperate? Thanks, yasumasa On 2017/09/21 7:46, Yasumasa Suenaga wrote: > PING: > > Have you checked this issue? > >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153333/webrev.03/hotspot/ >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153333/webrev.03/jdk/ > > > Yasumasa > > > On 2017/07/01 23:44, Yasumasa Suenaga wrote: >> PING: >> >> Have you checked this issue? >> >> >> Yasumasa >> >> >> On 2017/06/14 13:22, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I changed PerfCounter to show CGC STW phase in jstat in JDK-8151674. >>> However, it occurred several jtreg test failure, so it was back-outed. >>> >>> I want to resume to work for this issue. >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153333/webrev.03/hotspot/ >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153333/webrev.03/jdk/ >>> >>> These changes are work fine on jtreg test as below: >>> >>> ?? hotspot/test/serviceability/tmtools/jstat >>> ?? jdk/test/sun/tools >>> >>> >>> Since JDK 9, default GC algorithm is set to G1. >>> So I think this change is useful to watch GC behavior through jstat. >>> >>> I cannot access JPRT. Could you help? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> From claes.redestad at oracle.com Tue Sep 26 15:12:19 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 26 Sep 2017 17:12:19 +0200 Subject: RFR: JDK-8151815: Could not parse core image with JSnap. In-Reply-To: References: <7b897b36-1824-606d-b206-df577a6afe02@gmail.com> Message-ID: <90948fe0-34dc-6c19-525c-75c9dc8bea67@oracle.com> Hi, it seems destroy() used nullness of _prologue to determine that the counter has already been destroyed, should this use _destroyed now? 165 if (_prologue == NULL) return; /Claes On 2017-09-26 17:01, Yasumasa Suenaga wrote: > Hi all, > > I uploaded new webrev to be adapted to jdk10/hs: > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.04/ > > > Thanks, > > Yasumasa > > > On 2017/09/21 7:45, Yasumasa Suenaga wrote: >> PING: >> >> Have you checked this issue? >> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.03/ >> >> >> Yasumasa >> >> >> On 2017/07/01 23:43, Yasumasa Suenaga wrote: >>> PING: >>> >>> Have you checked this issue? >>> >>> >>> Yasumasa >>> >>> >>> On 2017/06/13 14:10, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> I want to discuss about JDK-8151815: Could not parse core image >>>> with JSnap. >>>> >>>> >>>> In last year, I found JSnap cannot parse coredump and I've sent review >>>> request for it as JDK-8151815. However it has not been reviewed yet >>>> [1]. >>>> >>>> We've discussed about safety implementation, but we could not get >>>> consensus. >>>> IMHO all SA tools should be handled java processes and core images, >>>> and PerfCounter value is useful. So I fix this issue. >>>> >>>> I uploaded new webrev for this issue. I think this patch is safety >>>> because new flag PerfMemory::_destroyed guards double free, and all >>>> members in PerfMemory is accessible (they are not munmap'ed) >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.03/ >>>> >>>> >>>> Can you cooperate? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-April/019480.html >>>> From yasuenag at gmail.com Tue Sep 26 15:25:53 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 27 Sep 2017 00:25:53 +0900 Subject: RFR: JDK-8151815: Could not parse core image with JSnap. In-Reply-To: <90948fe0-34dc-6c19-525c-75c9dc8bea67@oracle.com> References: <7b897b36-1824-606d-b206-df577a6afe02@gmail.com> <90948fe0-34dc-6c19-525c-75c9dc8bea67@oracle.com> Message-ID: Hi Claes, > 165 if (_prologue == NULL) return; I keep it in case of crashing before initializing PerfMemory. PerfMemory::destroy() - function of L165 - seems to be called from perfMemory_exit(). perfMemory_exit() checks PerfMemory::is_destroyed() before calling destroy(). So I think it is safe. Thanks, Yasumasa On 2017/09/27 0:12, Claes Redestad wrote: > Hi, > > it seems destroy() used nullness of _prologue to determine that > the counter has already been destroyed, should this use _destroyed > now? > > ?165?? if (_prologue == NULL) return; > > > /Claes > > On 2017-09-26 17:01, Yasumasa Suenaga wrote: >> Hi all, >> >> I uploaded new webrev to be adapted to jdk10/hs: >> >> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.04/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2017/09/21 7:45, Yasumasa Suenaga wrote: >>> PING: >>> >>> Have you checked this issue? >>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.03/ >>> >>> >>> Yasumasa >>> >>> >>> On 2017/07/01 23:43, Yasumasa Suenaga wrote: >>>> PING: >>>> >>>> Have you checked this issue? >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> On 2017/06/13 14:10, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> I want to discuss about JDK-8151815: Could not parse core image with JSnap. >>>>> >>>>> >>>>> In last year, I found JSnap cannot parse coredump and I've sent review >>>>> request for it as JDK-8151815. However it has not been reviewed yet >>>>> [1]. >>>>> >>>>> We've discussed about safety implementation, but we could not get consensus. >>>>> IMHO all SA tools should be handled java processes and core images, >>>>> and PerfCounter value is useful. So I fix this issue. >>>>> >>>>> I uploaded new webrev for this issue. I think this patch is safety >>>>> because new flag PerfMemory::_destroyed guards double free, and all >>>>> members in PerfMemory is accessible (they are not munmap'ed) >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.03/ >>>>> >>>>> >>>>> Can you cooperate? >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-April/019480.html >>>>> > From yasuenag at gmail.com Tue Sep 26 15:31:49 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 27 Sep 2017 00:31:49 +0900 Subject: [10] RFR: 8185796: jstack and clhsdb jstack should show lock objects In-Reply-To: References: <1734e8a3-5178-2953-2b42-b443177e9cc2@gmail.com> <33bf35e5-7d8b-db21-4209-edd675c42d85@oracle.com> Message-ID: <66c16569-d7bd-3f4c-6dff-b5b27a77d38f@gmail.com> Hi all, I uploaded new webrev to be adapted to jdk10/hs: http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.02/ Thanks, Yasumasa On 2017/08/24 22:59, Yasumasa Suenaga wrote: > Thanks Jini! > > I uploaded new webrev: > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.01/ > > This webrev has been ported print_lock_info() to JavaVFrame.java, and I've added new testcase for `jhsdb jstack` and jstack command on `jhsdb clhsdb`. > > > Yasumasa > > > On 2017/08/24 18:01, Jini George wrote: >> Apologize for the late reply, Yasumasa. >> >> >>> I think so, but I guess it is difficult. >>> For example, test for CLHSDB command is provided as test/serviceability/sa/TestPrintMdo.java . >>> But target process seems to be fixed to "LingeredApp". >>> Can we change it to another program which generates lock contention? >> >> You can take a look at any of the hotspot/test/serviceability/sa/LingeredAppWith*.java files for this. The target process does not have to be be fixed to LingeredApp -- in these LingeredAppWith* cases, the targets are test-specific variations built on top of LingeredApp for ease of implementation. >> >> Thanks, >> Jini. From jini.george at oracle.com Tue Sep 26 17:36:47 2017 From: jini.george at oracle.com (Jini George) Date: Tue, 26 Sep 2017 23:06:47 +0530 Subject: RFR: 8187402: UnknownOopException is occurred on Stack Memory window in HSDB In-Reply-To: <4c8a242f-464e-297e-5779-a237691be495@gmail.com> References: <4c8a242f-464e-297e-5779-a237691be495@gmail.com> Message-ID: <6a49c097-10dc-6a47-154e-a6f5ae2e96ec@oracle.com> Hi Yasumasa, The changes look fine, but please do include the test case also for this. In general, it would be great if you could provide test cases also along with the code changes while sending for review. Thank you, Jini. On 9/26/2017 8:19 PM, Yasumasa Suenaga wrote: > Hi all, > > I uploaded new webrev to be adapted to jdk10/hs: > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.01/ > > > Thanks, > > Yasumasa > > > On 2017/09/21 7:47, Yasumasa Suenaga wrote: >> PING: >> >> Have you checked this issue? >> >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.00/ >> >> >> Yasumasa >> >> >> On 2017/09/11 11:17, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> This review request is a part of [1]. >>> >>> >>> JBS: >>> ?? https://bugs.openjdk.java.net/browse/JDK-8187402 >>> >>> webrev: >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.00/ >>> >>> >>> I cannot access JPRT. So I need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >>> >>> From serguei.spitsyn at oracle.com Tue Sep 26 17:51:11 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Sep 2017 10:51:11 -0700 Subject: PING: RFR: 8187401: Java Stack cannot be shown on HSDB In-Reply-To: References: <3d25fa66-085d-11a7-74f4-eba9fa0360b5@oracle.com> Message-ID: Hi Yasumasa, On 9/26/17 02:41, Yasumasa Suenaga wrote: > Hi Serguei, > > Thank you for your comment! > >> This fix looks Ok to me but you need to add a unit test. > I guess it is caused by inlined method which is generated by JIT > compiler. I don't know how to reproduce it on jtreg test. > Do you have any idea for it? I'm not sure what exact problem you have with jtreg. You may want to try to use other jtreg tests as examples. Thanks, Serguei > Yasumasa > > > 2017-09-26 18:15 GMT+09:00 serguei.spitsyn at oracle.com > : >> Hi Yasumasa, >> >> This fix looks Ok to me but you need to add a unit test. >> >> Thanks, >> Serguei >> >> >> >> On 9/20/17 15:47, Yasumasa Suenaga wrote: >>> PING: >>> >>> Have you checked this issue? >>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ >>> >>> >>> Yasumasa >>> >>> >>> On 2017/09/11 11:16, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> This review request is a part of [1]. >>>> >>>> >>>> JBS: >>>> https://bugs.openjdk.java.net/browse/JDK-8187401 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ >>>> >>>> >>>> I cannot access JPRT. So I need a sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >>>> From david.holmes at oracle.com Tue Sep 26 22:09:50 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Sep 2017 08:09:50 +1000 Subject: PING: RFR: 8187401: Java Stack cannot be shown on HSDB In-Reply-To: References: <3d25fa66-085d-11a7-74f4-eba9fa0360b5@oracle.com> Message-ID: <71273032-0ad5-8aed-350a-b53d0da625b3@oracle.com> Hi Sergeui, On 27/09/2017 3:51 AM, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > > On 9/26/17 02:41, Yasumasa Suenaga wrote: >> Hi Serguei, >> >> Thank you for your comment! >> >>> This fix looks Ok to me but you need to add a unit test. >> ? I guess it is caused by inlined method which is generated by JIT >> compiler. I don't know how to reproduce it on jtreg test. >> Do you have any idea for it? > > I'm not sure what exact problem you have with jtreg. > You may want to try to use other jtreg tests as examples. I see two problems: 1. hsdb is an interactive GUI tool 2. The problem seems related to JIT inlining - so how do you force that in a test? I would think this is a noreg-hard situation. As long as there is a manual reproducer that can be used to verify the fix - as per the bug report - that should be okay IMHO. Cheers, David > Thanks, > Serguei > >> Yasumasa >> >> >> 2017-09-26 18:15 GMT+09:00 serguei.spitsyn at oracle.com >> : >>> Hi Yasumasa, >>> >>> This fix looks Ok to me but you need to add a unit test. >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 9/20/17 15:47, Yasumasa Suenaga wrote: >>>> PING: >>>> >>>> Have you checked this issue? >>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> On 2017/09/11 11:16, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> This review request is a part of [1]. >>>>> >>>>> >>>>> JBS: >>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8187401 >>>>> >>>>> webrev: >>>>> ??? http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ >>>>> >>>>> >>>>> I cannot access JPRT. So I need a sponsor. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] >>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >>>>> >>>>> > From yasuenag at gmail.com Tue Sep 26 22:40:32 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 27 Sep 2017 07:40:32 +0900 Subject: RFR: 8187402: UnknownOopException is occurred on Stack Memory window in HSDB In-Reply-To: <6a49c097-10dc-6a47-154e-a6f5ae2e96ec@oracle.com> References: <4c8a242f-464e-297e-5779-a237691be495@gmail.com> <6a49c097-10dc-6a47-154e-a6f5ae2e96ec@oracle.com> Message-ID: Hi Jini, IMHO this issue (JDK-8187402) and JDK-8187403 are too difficult to crate test cases because they are problems in Stack Memory window in HSDB. Can we add noreg-hard label to JBS? Thanks, Yasumasa On 2017/09/27 2:36, Jini George wrote: > Hi Yasumasa, > > The changes look fine, but please do include the test case also for > this. In general, it would be great if you could provide test cases also > along with the code changes while sending for review. > > Thank you, > Jini. > > On 9/26/2017 8:19 PM, Yasumasa Suenaga wrote: >> Hi all, >> >> I uploaded new webrev to be adapted to jdk10/hs: >> >> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.01/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2017/09/21 7:47, Yasumasa Suenaga wrote: >>> PING: >>> >>> Have you checked this issue? >>> >>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.00/ >>> >>> >>> Yasumasa >>> >>> >>> On 2017/09/11 11:17, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> This review request is a part of [1]. >>>> >>>> >>>> JBS: >>>> ?? https://bugs.openjdk.java.net/browse/JDK-8187402 >>>> >>>> webrev: >>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.00/ >>>> >>>> >>>> I cannot access JPRT. So I need a sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >>>> >>>> > From serguei.spitsyn at oracle.com Tue Sep 26 22:52:48 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Sep 2017 15:52:48 -0700 Subject: PING: RFR: 8187401: Java Stack cannot be shown on HSDB In-Reply-To: <71273032-0ad5-8aed-350a-b53d0da625b3@oracle.com> References: <3d25fa66-085d-11a7-74f4-eba9fa0360b5@oracle.com> <71273032-0ad5-8aed-350a-b53d0da625b3@oracle.com> Message-ID: <05acbfe2-5d8a-b492-8f30-6180568ad26d@oracle.com> Hi David, On 9/26/17 15:09, David Holmes wrote: > Hi Sergeui, > > On 27/09/2017 3:51 AM, serguei.spitsyn at oracle.com wrote: >> Hi Yasumasa, >> >> >> On 9/26/17 02:41, Yasumasa Suenaga wrote: >>> Hi Serguei, >>> >>> Thank you for your comment! >>> >>>> This fix looks Ok to me but you need to add a unit test. >>> ? I guess it is caused by inlined method which is generated by JIT >>> compiler. I don't know how to reproduce it on jtreg test. >>> Do you have any idea for it? >> >> I'm not sure what exact problem you have with jtreg. >> You may want to try to use other jtreg tests as examples. > > I see two problems: > > 1. hsdb is an interactive GUI tool There is already at least one jtreg hsdb test: ? open/test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java Not sure, if this example would help in this case though. > 2. The problem seems related to JIT inlining - so how do you force > that in a test? Then I wonder how was it forced in the manual reproducer? The fact it is fixed has to be verified anyway. > I would think this is a noreg-hard situation. As long as there is a > manual reproducer that can be used to verify the fix - as per the bug > report - that should be okay IMHO. I'm Ok with adding noreg-hard label if it is hard to develop. Thanks, Serguei > Cheers, > David > >> Thanks, >> Serguei >> >>> Yasumasa >>> >>> >>> 2017-09-26 18:15 GMT+09:00 serguei.spitsyn at oracle.com >>> : >>>> Hi Yasumasa, >>>> >>>> This fix looks Ok to me but you need to add a unit test. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 9/20/17 15:47, Yasumasa Suenaga wrote: >>>>> PING: >>>>> >>>>> Have you checked this issue? >>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2017/09/11 11:16, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> This review request is a part of [1]. >>>>>> >>>>>> >>>>>> JBS: >>>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8187401 >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ >>>>>> >>>>>> >>>>>> I cannot access JPRT. So I need a sponsor. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] >>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >>>>>> >>>>>> >> From serguei.spitsyn at oracle.com Tue Sep 26 23:02:25 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Sep 2017 16:02:25 -0700 Subject: PING: RFR: 8187401: Java Stack cannot be shown on HSDB In-Reply-To: <05acbfe2-5d8a-b492-8f30-6180568ad26d@oracle.com> References: <3d25fa66-085d-11a7-74f4-eba9fa0360b5@oracle.com> <71273032-0ad5-8aed-350a-b53d0da625b3@oracle.com> <05acbfe2-5d8a-b492-8f30-6180568ad26d@oracle.com> Message-ID: <92d46b66-29e8-95f2-ce89-0feb5eef61fe@oracle.com> On 9/26/17 15:52, serguei.spitsyn at oracle.com wrote: > Hi David, > > > On 9/26/17 15:09, David Holmes wrote: >> Hi Sergeui, >> >> On 27/09/2017 3:51 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Yasumasa, >>> >>> >>> On 9/26/17 02:41, Yasumasa Suenaga wrote: >>>> Hi Serguei, >>>> >>>> Thank you for your comment! >>>> >>>>> This fix looks Ok to me but you need to add a unit test. >>>> ? I guess it is caused by inlined method which is generated by JIT >>>> compiler. I don't know how to reproduce it on jtreg test. >>>> Do you have any idea for it? >>> >>> I'm not sure what exact problem you have with jtreg. >>> You may want to try to use other jtreg tests as examples. >> >> I see two problems: >> >> 1. hsdb is an interactive GUI tool > > There is already at least one jtreg hsdb test: > open/test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java > > Not sure, if this example would help in this case though. It seems, this test example won't help much as it is too simple. Thanks, Serguei > >> 2. The problem seems related to JIT inlining - so how do you force >> that in a test? > > Then I wonder how was it forced in the manual reproducer? > The fact it is fixed has to be verified anyway. > > >> I would think this is a noreg-hard situation. As long as there is a >> manual reproducer that can be used to verify the fix - as per the bug >> report - that should be okay IMHO. > > I'm Ok with adding noreg-hard label if it is hard to develop. > > Thanks, > Serguei > >> Cheers, >> David >> >>> Thanks, >>> Serguei >>> >>>> Yasumasa >>>> >>>> >>>> 2017-09-26 18:15 GMT+09:00 serguei.spitsyn at oracle.com >>>> : >>>>> Hi Yasumasa, >>>>> >>>>> This fix looks Ok to me but you need to add a unit test. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> On 9/20/17 15:47, Yasumasa Suenaga wrote: >>>>>> PING: >>>>>> >>>>>> Have you checked this issue? >>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2017/09/11 11:16, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> This review request is a part of [1]. >>>>>>> >>>>>>> >>>>>>> JBS: >>>>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8187401 >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ >>>>>>> >>>>>>> >>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >>>>>>> >>>>>>> >>> > From david.holmes at oracle.com Tue Sep 26 23:22:12 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Sep 2017 09:22:12 +1000 Subject: PING: RFR: 8187401: Java Stack cannot be shown on HSDB In-Reply-To: <05acbfe2-5d8a-b492-8f30-6180568ad26d@oracle.com> References: <3d25fa66-085d-11a7-74f4-eba9fa0360b5@oracle.com> <71273032-0ad5-8aed-350a-b53d0da625b3@oracle.com> <05acbfe2-5d8a-b492-8f30-6180568ad26d@oracle.com> Message-ID: On 27/09/2017 8:52 AM, serguei.spitsyn at oracle.com wrote: > Hi David, > > > On 9/26/17 15:09, David Holmes wrote: >> Hi Sergeui, >> >> On 27/09/2017 3:51 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Yasumasa, >>> >>> >>> On 9/26/17 02:41, Yasumasa Suenaga wrote: >>>> Hi Serguei, >>>> >>>> Thank you for your comment! >>>> >>>>> This fix looks Ok to me but you need to add a unit test. >>>> ? I guess it is caused by inlined method which is generated by JIT >>>> compiler. I don't know how to reproduce it on jtreg test. >>>> Do you have any idea for it? >>> >>> I'm not sure what exact problem you have with jtreg. >>> You may want to try to use other jtreg tests as examples. >> >> I see two problems: >> >> 1. hsdb is an interactive GUI tool > > There is already at least one jtreg hsdb test: > ? open/test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java > > Not sure, if this example would help in this case though. > >> 2. The problem seems related to JIT inlining - so how do you force >> that in a test? > > Then I wonder how was it forced in the manual reproducer? > The fact it is fixed has to be verified anyway. Well the reproducer happens to hit the issue, so we can use it to manually verify. >> I would think this is a noreg-hard situation. As long as there is a >> manual reproducer that can be used to verify the fix - as per the bug >> report - that should be okay IMHO. > > I'm Ok with adding noreg-hard label if it is hard to develop. Sounds good to me. The manual verification steps should be very clearly spelt out in the bug report so that even someone unfamiliar with hsdb (like me!) can follow them easily. Cheers, David > Thanks, > Serguei > >> Cheers, >> David >> >>> Thanks, >>> Serguei >>> >>>> Yasumasa >>>> >>>> >>>> 2017-09-26 18:15 GMT+09:00 serguei.spitsyn at oracle.com >>>> : >>>>> Hi Yasumasa, >>>>> >>>>> This fix looks Ok to me but you need to add a unit test. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> On 9/20/17 15:47, Yasumasa Suenaga wrote: >>>>>> PING: >>>>>> >>>>>> Have you checked this issue? >>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2017/09/11 11:16, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> This review request is a part of [1]. >>>>>>> >>>>>>> >>>>>>> JBS: >>>>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8187401 >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ >>>>>>> >>>>>>> >>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >>>>>>> >>>>>>> >>> > From serguei.spitsyn at oracle.com Tue Sep 26 23:25:51 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Sep 2017 16:25:51 -0700 Subject: PING: RFR: 8187401: Java Stack cannot be shown on HSDB In-Reply-To: References: <3d25fa66-085d-11a7-74f4-eba9fa0360b5@oracle.com> <71273032-0ad5-8aed-350a-b53d0da625b3@oracle.com> <05acbfe2-5d8a-b492-8f30-6180568ad26d@oracle.com> Message-ID: <4457260a-a6e3-57a4-ef40-5b83db09f3b4@oracle.com> On 9/26/17 16:22, David Holmes wrote: > On 27/09/2017 8:52 AM, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> >> On 9/26/17 15:09, David Holmes wrote: >>> Hi Sergeui, >>> >>> On 27/09/2017 3:51 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi Yasumasa, >>>> >>>> >>>> On 9/26/17 02:41, Yasumasa Suenaga wrote: >>>>> Hi Serguei, >>>>> >>>>> Thank you for your comment! >>>>> >>>>>> This fix looks Ok to me but you need to add a unit test. >>>>> ? I guess it is caused by inlined method which is generated by JIT >>>>> compiler. I don't know how to reproduce it on jtreg test. >>>>> Do you have any idea for it? >>>> >>>> I'm not sure what exact problem you have with jtreg. >>>> You may want to try to use other jtreg tests as examples. >>> >>> I see two problems: >>> >>> 1. hsdb is an interactive GUI tool >> >> There is already at least one jtreg hsdb test: >> open/test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java >> >> Not sure, if this example would help in this case though. >> >>> 2. The problem seems related to JIT inlining - so how do you force >>> that in a test? >> >> Then I wonder how was it forced in the manual reproducer? >> The fact it is fixed has to be verified anyway. > > Well the reproducer happens to hit the issue, so we can use it to > manually verify. > >>> I would think this is a noreg-hard situation. As long as there is a >>> manual reproducer that can be used to verify the fix - as per the >>> bug report - that should be okay IMHO. >> >> I'm Ok with adding noreg-hard label if it is hard to develop. > > Sounds good to me. The manual verification steps should be very > clearly spelt out in the bug report so that even someone unfamiliar > with hsdb (like me!) can follow them easily. Sounds good, thanks. Serguei > > Cheers, > David > >> Thanks, >> Serguei >> >>> Cheers, >>> David >>> >>>> Thanks, >>>> Serguei >>>> >>>>> Yasumasa >>>>> >>>>> >>>>> 2017-09-26 18:15 GMT+09:00 serguei.spitsyn at oracle.com >>>>> : >>>>>> Hi Yasumasa, >>>>>> >>>>>> This fix looks Ok to me but you need to add a unit test. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> On 9/20/17 15:47, Yasumasa Suenaga wrote: >>>>>>> PING: >>>>>>> >>>>>>> Have you checked this issue? >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2017/09/11 11:16, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> This review request is a part of [1]. >>>>>>>> >>>>>>>> >>>>>>>> JBS: >>>>>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8187401 >>>>>>>> >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >>>>>>>> >>>>>>>> >>>> >> From serguei.spitsyn at oracle.com Tue Sep 26 23:31:34 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Sep 2017 16:31:34 -0700 Subject: PING: RFR: 8187402: UnknownOopException is occurred on Stack Memory window in HSDB In-Reply-To: References: Message-ID: <14edd183-f9f7-107c-c50a-87708a1eacf2@oracle.com> Hi Yasumasa, The fix looks Ok to me. Could you, please, add the noreg-hard label and a good description how to run the hsdb and reproduce it? Thanks, Serguei On 9/20/17 15:47, Yasumasa Suenaga wrote: > PING: > > Have you checked this issue? > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.00/ > > > Yasumasa > > > On 2017/09/11 11:17, Yasumasa Suenaga wrote: >> Hi all, >> >> This review request is a part of [1]. >> >> >> JBS: >> ?? https://bugs.openjdk.java.net/browse/JDK-8187402 >> >> webrev: >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.00/ >> >> >> I cannot access JPRT. So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >> From yasuenag at gmail.com Wed Sep 27 00:48:46 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 27 Sep 2017 09:48:46 +0900 Subject: PING: RFR: 8187402: UnknownOopException is occurred on Stack Memory window in HSDB In-Reply-To: <14edd183-f9f7-107c-c50a-87708a1eacf2@oracle.com> References: <14edd183-f9f7-107c-c50a-87708a1eacf2@oracle.com> Message-ID: Hi Serguei, I added noreg-hard label and details how to reproduce to JBS. https://bugs.openjdk.java.net/browse/JDK-8187402 Thanks, Yasumasa 2017-09-27 8:31 GMT+09:00 serguei.spitsyn at oracle.com : > Hi Yasumasa, > > The fix looks Ok to me. > Could you, please, add the noreg-hard label and a good description how to > run the hsdb and reproduce it? > > Thanks, > Serguei > > > > On 9/20/17 15:47, Yasumasa Suenaga wrote: >> >> PING: >> >> Have you checked this issue? >> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.00/ >> >> >> >> Yasumasa >> >> >> On 2017/09/11 11:17, Yasumasa Suenaga wrote: >>> >>> Hi all, >>> >>> This review request is a part of [1]. >>> >>> >>> JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8187402 >>> >>> webrev: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.00/ >>> >>> >>> I cannot access JPRT. So I need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >>> > From yasuenag at gmail.com Wed Sep 27 00:49:54 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 27 Sep 2017 09:49:54 +0900 Subject: PING: RFR: 8187401: Java Stack cannot be shown on HSDB In-Reply-To: <4457260a-a6e3-57a4-ef40-5b83db09f3b4@oracle.com> References: <3d25fa66-085d-11a7-74f4-eba9fa0360b5@oracle.com> <71273032-0ad5-8aed-350a-b53d0da625b3@oracle.com> <05acbfe2-5d8a-b492-8f30-6180568ad26d@oracle.com> <4457260a-a6e3-57a4-ef40-5b83db09f3b4@oracle.com> Message-ID: Hi David, Serguei, I added noreg-hard label and how to reproduce to JBS: https://bugs.openjdk.java.net/browse/JDK-8187401 Also I uploaded new webrev for jdk10/hs: http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.01/ Thanks, Yasumasa 2017-09-27 8:25 GMT+09:00 serguei.spitsyn at oracle.com : > On 9/26/17 16:22, David Holmes wrote: >> >> On 27/09/2017 8:52 AM, serguei.spitsyn at oracle.com wrote: >>> >>> Hi David, >>> >>> >>> On 9/26/17 15:09, David Holmes wrote: >>>> >>>> Hi Sergeui, >>>> >>>> On 27/09/2017 3:51 AM, serguei.spitsyn at oracle.com wrote: >>>>> >>>>> Hi Yasumasa, >>>>> >>>>> >>>>> On 9/26/17 02:41, Yasumasa Suenaga wrote: >>>>>> >>>>>> Hi Serguei, >>>>>> >>>>>> Thank you for your comment! >>>>>> >>>>>>> This fix looks Ok to me but you need to add a unit test. >>>>>> >>>>>> I guess it is caused by inlined method which is generated by JIT >>>>>> compiler. I don't know how to reproduce it on jtreg test. >>>>>> Do you have any idea for it? >>>>> >>>>> >>>>> I'm not sure what exact problem you have with jtreg. >>>>> You may want to try to use other jtreg tests as examples. >>>> >>>> >>>> I see two problems: >>>> >>>> 1. hsdb is an interactive GUI tool >>> >>> >>> There is already at least one jtreg hsdb test: >>> open/test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java >>> >>> Not sure, if this example would help in this case though. >>> >>>> 2. The problem seems related to JIT inlining - so how do you force that >>>> in a test? >>> >>> >>> Then I wonder how was it forced in the manual reproducer? >>> The fact it is fixed has to be verified anyway. >> >> >> Well the reproducer happens to hit the issue, so we can use it to manually >> verify. >> >>>> I would think this is a noreg-hard situation. As long as there is a >>>> manual reproducer that can be used to verify the fix - as per the bug report >>>> - that should be okay IMHO. >>> >>> >>> I'm Ok with adding noreg-hard label if it is hard to develop. >> >> >> Sounds good to me. The manual verification steps should be very clearly >> spelt out in the bug report so that even someone unfamiliar with hsdb (like >> me!) can follow them easily. > > > Sounds good, thanks. > > Serguei > >> >> Cheers, >> David >> >>> Thanks, >>> Serguei >>> >>>> Cheers, >>>> David >>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> 2017-09-26 18:15 GMT+09:00 serguei.spitsyn at oracle.com >>>>>> : >>>>>>> >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> This fix looks Ok to me but you need to add a unit test. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 9/20/17 15:47, Yasumasa Suenaga wrote: >>>>>>>> >>>>>>>> PING: >>>>>>>> >>>>>>>> Have you checked this issue? >>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2017/09/11 11:16, Yasumasa Suenaga wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> This review request is a part of [1]. >>>>>>>>> >>>>>>>>> >>>>>>>>> JBS: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8187401 >>>>>>>>> >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> >>>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >>>>>>>>> >>>>> >>> > From yasuenag at gmail.com Wed Sep 27 01:10:12 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 27 Sep 2017 10:10:12 +0900 Subject: RFR: 8187403: [Unknown generation] is shown in Stack Memory on HSDB In-Reply-To: References: <2ee4d0c9-bdd5-19f3-e036-0aa096b59946@gmail.com> Message-ID: Hi all, I added noreg-hard label to JBS because this issue appears Stack Memory window on HSDB (GUI application). So it is hard to test. https://bugs.openjdk.java.net/browse/JDK-8187403 Thanks, Yasumasa 2017-09-26 23:55 GMT+09:00 Yasumasa Suenaga : > Hi all, > > I uploaded new webrev to be adapted to jdk10/hs: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/ > > > Thanks, > > Yasumasa > > > On 2017/09/21 7:48, Yasumasa Suenaga wrote: >> >> PING: >> >> Have you checked this issue? >> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.00/ >> >> >> >> Yasumasa >> >> >> >> On 2017/09/11 11:18, Yasumasa Suenaga wrote: >>> >>> Hi all, >>> >>> This review request is a part of [1]. >>> >>> >>> JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8187403 >>> >>> webrev: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.00/ >>> >>> >>> I cannot access JPRT. So I need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >>> > From sharath.ballal at oracle.com Wed Sep 27 15:12:49 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Wed, 27 Sep 2017 15:12:49 +0000 (UTC) Subject: RFR: 8187402: UnknownOopException is occurred on Stack Memory window in HSDB In-Reply-To: References: <4c8a242f-464e-297e-5779-a237691be495@gmail.com> <6a49c097-10dc-6a47-154e-a6f5ae2e96ec@oracle.com> Message-ID: Hi Yasumasa, We don't have any tests for HSDB (because it is gui). If the problem recreates in CLHSDB you can write a testcase, if not you can add noreg-hard label. Thanks, Sharath -----Original Message----- From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] Sent: Wednesday, September 27, 2017 4:11 AM To: Jini George Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR: 8187402: UnknownOopException is occurred on Stack Memory window in HSDB Hi Jini, IMHO this issue (JDK-8187402) and JDK-8187403 are too difficult to crate test cases because they are problems in Stack Memory window in HSDB. Can we add noreg-hard label to JBS? Thanks, Yasumasa On 2017/09/27 2:36, Jini George wrote: > Hi Yasumasa, > > The changes look fine, but please do include the test case also for > this. In general, it would be great if you could provide test cases > also along with the code changes while sending for review. > > Thank you, > Jini. > > On 9/26/2017 8:19 PM, Yasumasa Suenaga wrote: >> Hi all, >> >> I uploaded new webrev to be adapted to jdk10/hs: >> >> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.01/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2017/09/21 7:47, Yasumasa Suenaga wrote: >>> PING: >>> >>> Have you checked this issue? >>> >>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.00/ >>> >>> >>> Yasumasa >>> >>> >>> On 2017/09/11 11:17, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> This review request is a part of [1]. >>>> >>>> >>>> JBS: >>>> ?? https://bugs.openjdk.java.net/browse/JDK-8187402 >>>> >>>> webrev: >>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.00/ >>>> >>>> >>>> I cannot access JPRT. So I need a sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-Sept >>>> ember/021821.html >>>> >>>> > From yasuenag at gmail.com Wed Sep 27 23:10:14 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 28 Sep 2017 08:10:14 +0900 Subject: RFR: 8187402: UnknownOopException is occurred on Stack Memory window in HSDB In-Reply-To: References: <4c8a242f-464e-297e-5779-a237691be495@gmail.com> <6a49c097-10dc-6a47-154e-a6f5ae2e96ec@oracle.com> Message-ID: <6653d591-d878-964a-e1c7-b43457151029@gmail.com> Hi Sharath, I've reported 4 issues of HSDB. I added noreg-hard to 8187401, 8187402, 8187403. But 8175816 is testable so I've included testcase in webrev. Thanks, Yasumasa On 2017/09/28 0:12, Sharath Ballal wrote: > Hi Yasumasa, > We don't have any tests for HSDB (because it is gui). > If the problem recreates in CLHSDB you can write a testcase, if not you can add noreg-hard label. > > > Thanks, > Sharath > > > -----Original Message----- > From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] > Sent: Wednesday, September 27, 2017 4:11 AM > To: Jini George > Cc: serviceability-dev at openjdk.java.net > Subject: Re: RFR: 8187402: UnknownOopException is occurred on Stack Memory window in HSDB > > Hi Jini, > > IMHO this issue (JDK-8187402) and JDK-8187403 are too difficult to crate test cases because they are problems in Stack Memory window in HSDB. > Can we add noreg-hard label to JBS? > > > Thanks, > > Yasumasa > > > On 2017/09/27 2:36, Jini George wrote: >> Hi Yasumasa, >> >> The changes look fine, but please do include the test case also for >> this. In general, it would be great if you could provide test cases >> also along with the code changes while sending for review. >> >> Thank you, >> Jini. >> >> On 9/26/2017 8:19 PM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I uploaded new webrev to be adapted to jdk10/hs: >>> >>> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.01/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2017/09/21 7:47, Yasumasa Suenaga wrote: >>>> PING: >>>> >>>> Have you checked this issue? >>>> >>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.00/ >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> On 2017/09/11 11:17, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> This review request is a part of [1]. >>>>> >>>>> >>>>> JBS: >>>>> ?? https://bugs.openjdk.java.net/browse/JDK-8187402 >>>>> >>>>> webrev: >>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8187402/webrev.00/ >>>>> >>>>> >>>>> I cannot access JPRT. So I need a sponsor. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] >>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-Sept >>>>> ember/021821.html >>>>> >>>>> >> From serguei.spitsyn at oracle.com Thu Sep 28 23:22:09 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 28 Sep 2017 16:22:09 -0700 Subject: PING: RFR: 8175816: SA: HSDB: Compute Liveness results in java.lang.IndexOutOfBoundsException In-Reply-To: <58a12433-062c-57dd-0c6e-7aba76d073cd@gmail.com> References: <5097216b-f757-dd2b-70bc-b3a860bdebfa@gmail.com> <5a76ed8b-e0aa-6572-86b7-4ac149e30c3d@gmail.com> <88747c0c-01ce-efb1-c74c-5da818be72bc@oracle.com> <58a12433-062c-57dd-0c6e-7aba76d073cd@gmail.com> Message-ID: <442a573a-9dea-909c-2aae-1d867b49c7bf@oracle.com> Hi Yasumasa, The fix looks good to me. One minor comment: ? Not all imports in the test are ordered correctly. Thanks, Serguei On 9/23/17 05:13, Yasumasa Suenaga wrote: > Hi Jini, > > I've added a test case for this in new webrev. > This webrev is for consolidated jdk10/hs. > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.01/ > > > Thanks, > > Yasumasa > > > On 2017/09/22 15:12, Jini George wrote: >> Hi Yasumasa, >> >> Your change looks good. But please do add in a test case for this. >> >> Thanks, >> Jini (not a Reviewer). >> >> On 9/21/2017 4:18 AM, Yasumasa Suenaga wrote: >>> PING: >>> >>> Have you checked this issue? >>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.00/ >>> >>> >>> Yasumasa >>> >>> >>> On 2017/09/11 22:47, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> This review request is a part of [1]. >>>> >>>> >>>> JBS: >>>> ?? https://bugs.openjdk.java.net/browse/JDK-8175816 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.00/ >>>> >>>> >>>> I cannot access JPRT. So I need a sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >>>> >>>> From serguei.spitsyn at oracle.com Thu Sep 28 23:27:06 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 28 Sep 2017 16:27:06 -0700 Subject: RFR: 8187403: [Unknown generation] is shown in Stack Memory on HSDB In-Reply-To: References: <2ee4d0c9-bdd5-19f3-e036-0aa096b59946@gmail.com> Message-ID: Hi Yasumasa, Could you, please, also add some evaluation to the bug report about what is the root cause and how do you fix it? Thanks, Serguei On 9/26/17 18:10, Yasumasa Suenaga wrote: > Hi all, > > I added noreg-hard label to JBS because this issue appears Stack > Memory window on HSDB (GUI application). So it is hard to test. > > https://bugs.openjdk.java.net/browse/JDK-8187403 > > > Thanks, > > Yasumasa > > > > 2017-09-26 23:55 GMT+09:00 Yasumasa Suenaga : >> Hi all, >> >> I uploaded new webrev to be adapted to jdk10/hs: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2017/09/21 7:48, Yasumasa Suenaga wrote: >>> PING: >>> >>> Have you checked this issue? >>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.00/ >>> >>> >>> Yasumasa >>> >>> >>> >>> On 2017/09/11 11:18, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> This review request is a part of [1]. >>>> >>>> >>>> JBS: >>>> https://bugs.openjdk.java.net/browse/JDK-8187403 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.00/ >>>> >>>> >>>> I cannot access JPRT. So I need a sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >>>> From yasuenag at gmail.com Fri Sep 29 01:04:49 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 29 Sep 2017 10:04:49 +0900 Subject: PING: RFR: 8175816: SA: HSDB: Compute Liveness results in java.lang.IndexOutOfBoundsException In-Reply-To: <442a573a-9dea-909c-2aae-1d867b49c7bf@oracle.com> References: <5097216b-f757-dd2b-70bc-b3a860bdebfa@gmail.com> <5a76ed8b-e0aa-6572-86b7-4ac149e30c3d@gmail.com> <88747c0c-01ce-efb1-c74c-5da818be72bc@oracle.com> <58a12433-062c-57dd-0c6e-7aba76d073cd@gmail.com> <442a573a-9dea-909c-2aae-1d867b49c7bf@oracle.com> Message-ID: Hi Serguei, > One minor comment: > Not all imports in the test are ordered correctly. I changed import order about jdk.test.lib in testcase: http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.02/ I will send a changeset to you if you will be a sponsor :-) Thanks, Yasumasa 2017-09-29 8:22 GMT+09:00 serguei.spitsyn at oracle.com : > Hi Yasumasa, > > The fix looks good to me. > One minor comment: > Not all imports in the test are ordered correctly. > > Thanks, > Serguei > > > > On 9/23/17 05:13, Yasumasa Suenaga wrote: >> >> Hi Jini, >> >> I've added a test case for this in new webrev. >> This webrev is for consolidated jdk10/hs. >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.01/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2017/09/22 15:12, Jini George wrote: >>> >>> Hi Yasumasa, >>> >>> Your change looks good. But please do add in a test case for this. >>> >>> Thanks, >>> Jini (not a Reviewer). >>> >>> On 9/21/2017 4:18 AM, Yasumasa Suenaga wrote: >>>> >>>> PING: >>>> >>>> Have you checked this issue? >>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.00/ >>>> >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> On 2017/09/11 22:47, Yasumasa Suenaga wrote: >>>>> >>>>> Hi all, >>>>> >>>>> This review request is a part of [1]. >>>>> >>>>> >>>>> JBS: >>>>> https://bugs.openjdk.java.net/browse/JDK-8175816 >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.00/ >>>>> >>>>> >>>>> I cannot access JPRT. So I need a sponsor. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] >>>>> >>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >>>>> > From yasuenag at gmail.com Fri Sep 29 01:20:55 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 29 Sep 2017 10:20:55 +0900 Subject: RFR: 8187403: [Unknown generation] is shown in Stack Memory on HSDB In-Reply-To: References: <2ee4d0c9-bdd5-19f3-e036-0aa096b59946@gmail.com> Message-ID: Hi Serguei, I added it to JBS: https://bugs.openjdk.java.net/browse/JDK-8187403?focusedCommentId=14119248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14119248 Sorry for my English. I'm not good at English... Yasumasa 2017-09-29 8:27 GMT+09:00 serguei.spitsyn at oracle.com : > Hi Yasumasa, > > Could you, please, also add some evaluation to the bug report about what is > the root cause and how do you fix it? > > Thanks, > Serguei > > > > On 9/26/17 18:10, Yasumasa Suenaga wrote: >> >> Hi all, >> >> I added noreg-hard label to JBS because this issue appears Stack >> Memory window on HSDB (GUI application). So it is hard to test. >> >> https://bugs.openjdk.java.net/browse/JDK-8187403 >> >> >> Thanks, >> >> Yasumasa >> >> >> >> 2017-09-26 23:55 GMT+09:00 Yasumasa Suenaga : >>> >>> Hi all, >>> >>> I uploaded new webrev to be adapted to jdk10/hs: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2017/09/21 7:48, Yasumasa Suenaga wrote: >>>> >>>> PING: >>>> >>>> Have you checked this issue? >>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.00/ >>>> >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> >>>> On 2017/09/11 11:18, Yasumasa Suenaga wrote: >>>>> >>>>> Hi all, >>>>> >>>>> This review request is a part of [1]. >>>>> >>>>> >>>>> JBS: >>>>> https://bugs.openjdk.java.net/browse/JDK-8187403 >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.00/ >>>>> >>>>> >>>>> I cannot access JPRT. So I need a sponsor. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] >>>>> >>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >>>>> > From yasuenag at gmail.com Fri Sep 29 04:24:16 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 29 Sep 2017 13:24:16 +0900 Subject: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached Message-ID: Hi all, If we try to attach invalid JVMTI agent via JVMTI.agent_load dcmd, we will get "Command executed successfully". However, it implies error in JVMTIAgentLoadDCmd. This message is from JCmd.java when jcmd does not receive any output from target VM. I think HotSopt/jcmd should return useful error message to users to understand the cause of failure. I uploaded webrev for this issue. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ This change is work fine on Fedora 26 x86_64 as following jtreg testcases: - hotspot/jtreg/serviceability/attach - hotspot/jtreg/serviceability/dcmd/jvmti - jdk/com/sun/tools/attach I cannot access JPRT. So I need a sponsor. (I cannot test it on other platforms.) Thanks, Yasumasa From serguei.spitsyn at oracle.com Fri Sep 29 05:35:54 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 28 Sep 2017 22:35:54 -0700 Subject: RFR: 8187403: [Unknown generation] is shown in Stack Memory on HSDB In-Reply-To: References: <2ee4d0c9-bdd5-19f3-e036-0aa096b59946@gmail.com> Message-ID: <1869b689-d6ba-bfcd-6bc2-a4a5e0ca6695@oracle.com> An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Fri Sep 29 06:21:42 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 29 Sep 2017 15:21:42 +0900 Subject: RFR: 8187403: [Unknown generation] is shown in Stack Memory on HSDB In-Reply-To: <1869b689-d6ba-bfcd-6bc2-a4a5e0ca6695@oracle.com> References: <2ee4d0c9-bdd5-19f3-e036-0aa096b59946@gmail.com> <1869b689-d6ba-bfcd-6bc2-a4a5e0ca6695@oracle.com> Message-ID: Hi Serguet, Thank you for your comment. > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegion.java.frames.html > > It seems, there is no reason for renaming 'type' to 't' in the > initialize() method. I added new private member "type" as HeapRegionType. http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegion.java.udiff.html So I renamed to "t" to avoid conflict. > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionManager.java.frames.html > > 89 public HeapRegion addrToRegion(Address addr) { > 90 return regions().getByAddress(addr); > 91 } > > A suggestion: replace 'addrToRegion' with 'getByAddress'. > It will look similar to the 'heapRegionIterator.' I've implemented it to follow HotSpot implementation. http://hg.openjdk.java.net/jdk10/hs/file/3a45532a1854/src/hotspot/share/gc/g1/heapRegionManager.inline.hpp#l32 I think current proposal is easy to understand if other people check this with HotSpot. Should I rename to "getByAddress" ? Other your comment will be fixed in new webrev later. Thanks, Yasumasa 2017-09-29 14:35 GMT+09:00 serguei.spitsyn at oracle.com : > Hi Yasumasa, > > Just some minor comments. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionTable.java.frames.html > > I'd suggest to make the lines 144-145 a one-liner. > It won't be that big. Otherwise, the indent is not right. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegion.java.frames.html > > The same as above for lines 85-86. > It seems, there is no reason for renaming 'type' to 't' in the > initialize() method. > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionManager.java.frames.html > > 89 public HeapRegion addrToRegion(Address addr) { > 90 return regions().getByAddress(addr); > 91 } > > A suggestion: replace 'addrToRegion' with 'getByAddress'. > It will look similar to the 'heapRegionIterator.' > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionType.java.html > > 41 private static int freeTag; > 42 > 43 private static int youngMask; > 44 > 45 private static int humongousMask; > 46 > 47 private static int pinnedMask; > 48 > 49 private static int oldMask; > 50 > 51 private static CIntegerField tagField; > > Unneeded empty lines. > > Also, it looks like the fields 'freeTag' and 'pinnedMask' are never > initialized. > Not sure, if it is intentional. > > Otherwise, the fix looks good to me. > > Thanks, > Serguei > > > On 9/28/17 18:20, Yasumasa Suenaga wrote: > > Hi Serguei, > > I added it to JBS: > > https://bugs.openjdk.java.net/browse/JDK-8187403?focusedCommentId=14119248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14119248 > > Sorry for my English. I'm not good at English... > > > Please, don't worry about your English. > Your description looks good. > Thank you for the bug report update! > > Thanks, > Serguei > > > Yasumasa > > > > 2017-09-29 8:27 GMT+09:00 serguei.spitsyn at oracle.com > : > > Hi Yasumasa, > > Could you, please, also add some evaluation to the bug report about what is > the root cause and how do you fix it? > > Thanks, > Serguei > > > > On 9/26/17 18:10, Yasumasa Suenaga wrote: > > Hi all, > > I added noreg-hard label to JBS because this issue appears Stack > Memory window on HSDB (GUI application). So it is hard to test. > > https://bugs.openjdk.java.net/browse/JDK-8187403 > > > Thanks, > > Yasumasa > > > > 2017-09-26 23:55 GMT+09:00 Yasumasa Suenaga : > > Hi all, > > I uploaded new webrev to be adapted to jdk10/hs: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/ > > > Thanks, > > Yasumasa > > > On 2017/09/21 7:48, Yasumasa Suenaga wrote: > > PING: > > Have you checked this issue? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.00/ > > > Yasumasa > > > > On 2017/09/11 11:18, Yasumasa Suenaga wrote: > > Hi all, > > This review request is a part of [1]. > > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8187403 > > webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.00/ > > > I cannot access JPRT. So I need a sponsor. > > > Thanks, > > Yasumasa > > > [1] > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html > > From serguei.spitsyn at oracle.com Fri Sep 29 07:49:43 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 29 Sep 2017 00:49:43 -0700 Subject: RFR: 8187403: [Unknown generation] is shown in Stack Memory on HSDB In-Reply-To: References: <2ee4d0c9-bdd5-19f3-e036-0aa096b59946@gmail.com> <1869b689-d6ba-bfcd-6bc2-a4a5e0ca6695@oracle.com> Message-ID: <481be3d6-d19d-8fd0-6446-c8aea02488a6@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Sep 29 08:21:36 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 29 Sep 2017 01:21:36 -0700 Subject: PING: RFR: 8175816: SA: HSDB: Compute Liveness results in java.lang.IndexOutOfBoundsException In-Reply-To: References: <5097216b-f757-dd2b-70bc-b3a860bdebfa@gmail.com> <5a76ed8b-e0aa-6572-86b7-4ac149e30c3d@gmail.com> <88747c0c-01ce-efb1-c74c-5da818be72bc@oracle.com> <58a12433-062c-57dd-0c6e-7aba76d073cd@gmail.com> <442a573a-9dea-909c-2aae-1d867b49c7bf@oracle.com> Message-ID: Hi Yasumasa, On 9/28/17 18:04, Yasumasa Suenaga wrote: > Hi Serguei, > >> One minor comment: >> Not all imports in the test are ordered correctly. > I changed import order about jdk.test.lib in testcase: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.02/ > > I will send a changeset to you if you will be a sponsor :-) Ok, I'll push it. No need to send a patch as you have it in your webrev. Thanks, Serguei > Thanks, > > Yasumasa > > > 2017-09-29 8:22 GMT+09:00 serguei.spitsyn at oracle.com > : >> Hi Yasumasa, >> >> The fix looks good to me. >> One minor comment: >> Not all imports in the test are ordered correctly. >> >> Thanks, >> Serguei >> >> >> >> On 9/23/17 05:13, Yasumasa Suenaga wrote: >>> Hi Jini, >>> >>> I've added a test case for this in new webrev. >>> This webrev is for consolidated jdk10/hs. >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.01/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2017/09/22 15:12, Jini George wrote: >>>> Hi Yasumasa, >>>> >>>> Your change looks good. But please do add in a test case for this. >>>> >>>> Thanks, >>>> Jini (not a Reviewer). >>>> >>>> On 9/21/2017 4:18 AM, Yasumasa Suenaga wrote: >>>>> PING: >>>>> >>>>> Have you checked this issue? >>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.00/ >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2017/09/11 22:47, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> This review request is a part of [1]. >>>>>> >>>>>> >>>>>> JBS: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8175816 >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.00/ >>>>>> >>>>>> >>>>>> I cannot access JPRT. So I need a sponsor. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >>>>>> From yasuenag at gmail.com Fri Sep 29 08:25:08 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 29 Sep 2017 17:25:08 +0900 Subject: RFR: 8187403: [Unknown generation] is shown in Stack Memory on HSDB In-Reply-To: <481be3d6-d19d-8fd0-6446-c8aea02488a6@oracle.com> References: <2ee4d0c9-bdd5-19f3-e036-0aa096b59946@gmail.com> <1869b689-d6ba-bfcd-6bc2-a4a5e0ca6695@oracle.com> <481be3d6-d19d-8fd0-6446-c8aea02488a6@oracle.com> Message-ID: Thanks Serguei, I've uploaded new webrev. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.02/ Yasumasa 2017-09-29 16:49 GMT+09:00 serguei.spitsyn at oracle.com : > Hi Yasumasa, > > > On 9/28/17 23:21, Yasumasa Suenaga wrote: > > Hi Serguet, > > Thank you for your comment. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegion.java.frames.html > > It seems, there is no reason for renaming 'type' to 't' in the > initialize() method. > > I added new private member "type" as HeapRegionType. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegion.java.udiff.html > > So I renamed to "t" to avoid conflict. > > > There is no conflict. > Only local is used in the initialize() method. > Also, the initialize() method is static so that the instance field 'type' is > not in its scope. > Otherwise, you could use this.type to avoid such a conflict. > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionManager.java.frames.html > > 89 public HeapRegion addrToRegion(Address addr) { > 90 return regions().getByAddress(addr); > 91 } > > A suggestion: replace 'addrToRegion' with 'getByAddress'. > It will look similar to the 'heapRegionIterator.' > > I've implemented it to follow HotSpot implementation. > > http://hg.openjdk.java.net/jdk10/hs/file/3a45532a1854/src/hotspot/share/gc/g1/heapRegionManager.inline.hpp#l32 > > I think current proposal is easy to understand if other people check > this with HotSpot. > Should I rename to "getByAddress" ? > > > 81 public Iterator heapRegionIterator() { > 82 return regions().heapRegionIterator(length()); > 83 } > . . . > 89 public HeapRegion addrToRegion(Address addr) { > 90 return regions().getByAddress(addr); > 91 } > > > There is already regions().getByAddress(addr), so I'm suggesting to follow > this local pattern. > Renaming 'addrToRegion' to 'getByAddress' will unify it with the > 'heapRegionIterator()'. > Otherwise, you would need to rename 'getByAddress' to 'addrToRegion' > everywhere. > But I guess, it is better to avoid. > > Thanks, > Serguei > > > > Other your comment will be fixed in new webrev later. > > Thanks, > > Yasumasa > > > 2017-09-29 14:35 GMT+09:00 serguei.spitsyn at oracle.com > : > > Hi Yasumasa, > > Just some minor comments. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionTable.java.frames.html > > I'd suggest to make the lines 144-145 a one-liner. > It won't be that big. Otherwise, the indent is not right. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegion.java.frames.html > > The same as above for lines 85-86. > It seems, there is no reason for renaming 'type' to 't' in the > initialize() method. > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionManager.java.frames.html > > 89 public HeapRegion addrToRegion(Address addr) { > 90 return regions().getByAddress(addr); > 91 } > > A suggestion: replace 'addrToRegion' with 'getByAddress'. > It will look similar to the 'heapRegionIterator.' > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionType.java.html > > 41 private static int freeTag; > 42 > 43 private static int youngMask; > 44 > 45 private static int humongousMask; > 46 > 47 private static int pinnedMask; > 48 > 49 private static int oldMask; > 50 > 51 private static CIntegerField tagField; > > Unneeded empty lines. > > Also, it looks like the fields 'freeTag' and 'pinnedMask' are never > initialized. > Not sure, if it is intentional. > > Otherwise, the fix looks good to me. > > Thanks, > Serguei > > > On 9/28/17 18:20, Yasumasa Suenaga wrote: > > Hi Serguei, > > I added it to JBS: > > https://bugs.openjdk.java.net/browse/JDK-8187403?focusedCommentId=14119248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14119248 > > Sorry for my English. I'm not good at English... > > > Please, don't worry about your English. > Your description looks good. > Thank you for the bug report update! > > Thanks, > Serguei > > > Yasumasa > > > > 2017-09-29 8:27 GMT+09:00 serguei.spitsyn at oracle.com > : > > Hi Yasumasa, > > Could you, please, also add some evaluation to the bug report about what is > the root cause and how do you fix it? > > Thanks, > Serguei > > > > On 9/26/17 18:10, Yasumasa Suenaga wrote: > > Hi all, > > I added noreg-hard label to JBS because this issue appears Stack > Memory window on HSDB (GUI application). So it is hard to test. > > https://bugs.openjdk.java.net/browse/JDK-8187403 > > > Thanks, > > Yasumasa > > > > 2017-09-26 23:55 GMT+09:00 Yasumasa Suenaga : > > Hi all, > > I uploaded new webrev to be adapted to jdk10/hs: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/ > > > Thanks, > > Yasumasa > > > On 2017/09/21 7:48, Yasumasa Suenaga wrote: > > PING: > > Have you checked this issue? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.00/ > > > Yasumasa > > > > On 2017/09/11 11:18, Yasumasa Suenaga wrote: > > Hi all, > > This review request is a part of [1]. > > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8187403 > > webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.00/ > > > I cannot access JPRT. So I need a sponsor. > > > Thanks, > > Yasumasa > > > [1] > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html > > > From serguei.spitsyn at oracle.com Fri Sep 29 09:00:12 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 29 Sep 2017 02:00:12 -0700 Subject: RFR: 8187403: [Unknown generation] is shown in Stack Memory on HSDB In-Reply-To: References: <2ee4d0c9-bdd5-19f3-e036-0aa096b59946@gmail.com> <1869b689-d6ba-bfcd-6bc2-a4a5e0ca6695@oracle.com> <481be3d6-d19d-8fd0-6446-c8aea02488a6@oracle.com> Message-ID: On 9/29/17 01:25, Yasumasa Suenaga wrote: > Thanks Serguei, > > I've uploaded new webrev. Could you review again? > http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.02/ Looks good. I can sponsor it, but you probably need another review. Thanks, Serguei > Yasumasa > > > > 2017-09-29 16:49 GMT+09:00 serguei.spitsyn at oracle.com > : >> Hi Yasumasa, >> >> >> On 9/28/17 23:21, Yasumasa Suenaga wrote: >> >> Hi Serguet, >> >> Thank you for your comment. >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegion.java.frames.html >> >> It seems, there is no reason for renaming 'type' to 't' in the >> initialize() method. >> >> I added new private member "type" as HeapRegionType. >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegion.java.udiff.html >> >> So I renamed to "t" to avoid conflict. >> >> >> There is no conflict. >> Only local is used in the initialize() method. >> Also, the initialize() method is static so that the instance field 'type' is >> not in its scope. >> Otherwise, you could use this.type to avoid such a conflict. >> >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionManager.java.frames.html >> >> 89 public HeapRegion addrToRegion(Address addr) { >> 90 return regions().getByAddress(addr); >> 91 } >> >> A suggestion: replace 'addrToRegion' with 'getByAddress'. >> It will look similar to the 'heapRegionIterator.' >> >> I've implemented it to follow HotSpot implementation. >> >> http://hg.openjdk.java.net/jdk10/hs/file/3a45532a1854/src/hotspot/share/gc/g1/heapRegionManager.inline.hpp#l32 >> >> I think current proposal is easy to understand if other people check >> this with HotSpot. >> Should I rename to "getByAddress" ? >> >> >> 81 public Iterator heapRegionIterator() { >> 82 return regions().heapRegionIterator(length()); >> 83 } >> . . . >> 89 public HeapRegion addrToRegion(Address addr) { >> 90 return regions().getByAddress(addr); >> 91 } >> >> >> There is already regions().getByAddress(addr), so I'm suggesting to follow >> this local pattern. >> Renaming 'addrToRegion' to 'getByAddress' will unify it with the >> 'heapRegionIterator()'. >> Otherwise, you would need to rename 'getByAddress' to 'addrToRegion' >> everywhere. >> But I guess, it is better to avoid. >> >> Thanks, >> Serguei >> >> >> >> Other your comment will be fixed in new webrev later. >> >> Thanks, >> >> Yasumasa >> >> >> 2017-09-29 14:35 GMT+09:00 serguei.spitsyn at oracle.com >> : >> >> Hi Yasumasa, >> >> Just some minor comments. >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionTable.java.frames.html >> >> I'd suggest to make the lines 144-145 a one-liner. >> It won't be that big. Otherwise, the indent is not right. >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegion.java.frames.html >> >> The same as above for lines 85-86. >> It seems, there is no reason for renaming 'type' to 't' in the >> initialize() method. >> >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionManager.java.frames.html >> >> 89 public HeapRegion addrToRegion(Address addr) { >> 90 return regions().getByAddress(addr); >> 91 } >> >> A suggestion: replace 'addrToRegion' with 'getByAddress'. >> It will look similar to the 'heapRegionIterator.' >> >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionType.java.html >> >> 41 private static int freeTag; >> 42 >> 43 private static int youngMask; >> 44 >> 45 private static int humongousMask; >> 46 >> 47 private static int pinnedMask; >> 48 >> 49 private static int oldMask; >> 50 >> 51 private static CIntegerField tagField; >> >> Unneeded empty lines. >> >> Also, it looks like the fields 'freeTag' and 'pinnedMask' are never >> initialized. >> Not sure, if it is intentional. >> >> Otherwise, the fix looks good to me. >> >> Thanks, >> Serguei >> >> >> On 9/28/17 18:20, Yasumasa Suenaga wrote: >> >> Hi Serguei, >> >> I added it to JBS: >> >> https://bugs.openjdk.java.net/browse/JDK-8187403?focusedCommentId=14119248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14119248 >> >> Sorry for my English. I'm not good at English... >> >> >> Please, don't worry about your English. >> Your description looks good. >> Thank you for the bug report update! >> >> Thanks, >> Serguei >> >> >> Yasumasa >> >> >> >> 2017-09-29 8:27 GMT+09:00 serguei.spitsyn at oracle.com >> : >> >> Hi Yasumasa, >> >> Could you, please, also add some evaluation to the bug report about what is >> the root cause and how do you fix it? >> >> Thanks, >> Serguei >> >> >> >> On 9/26/17 18:10, Yasumasa Suenaga wrote: >> >> Hi all, >> >> I added noreg-hard label to JBS because this issue appears Stack >> Memory window on HSDB (GUI application). So it is hard to test. >> >> https://bugs.openjdk.java.net/browse/JDK-8187403 >> >> >> Thanks, >> >> Yasumasa >> >> >> >> 2017-09-26 23:55 GMT+09:00 Yasumasa Suenaga : >> >> Hi all, >> >> I uploaded new webrev to be adapted to jdk10/hs: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2017/09/21 7:48, Yasumasa Suenaga wrote: >> >> PING: >> >> Have you checked this issue? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.00/ >> >> >> Yasumasa >> >> >> >> On 2017/09/11 11:18, Yasumasa Suenaga wrote: >> >> Hi all, >> >> This review request is a part of [1]. >> >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8187403 >> >> webrev: >> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.00/ >> >> >> I cannot access JPRT. So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] >> >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >> >> >> From serguei.spitsyn at oracle.com Fri Sep 29 09:08:02 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 29 Sep 2017 02:08:02 -0700 Subject: PING: RFR: 8175816: SA: HSDB: Compute Liveness results in java.lang.IndexOutOfBoundsException In-Reply-To: References: <5097216b-f757-dd2b-70bc-b3a860bdebfa@gmail.com> <5a76ed8b-e0aa-6572-86b7-4ac149e30c3d@gmail.com> <88747c0c-01ce-efb1-c74c-5da818be72bc@oracle.com> <58a12433-062c-57dd-0c6e-7aba76d073cd@gmail.com> <442a573a-9dea-909c-2aae-1d867b49c7bf@oracle.com> Message-ID: <4558128e-696b-832d-b648-0f3ac487886b@oracle.com> On 9/29/17 01:21, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > > On 9/28/17 18:04, Yasumasa Suenaga wrote: >> Hi Serguei, >> >>> One minor comment: >>> ?? Not all imports in the test are ordered correctly. >> I changed import order about jdk.test.lib in testcase: >> >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.02/ >> >> I will send a changeset to you if you will be a sponsor :-) > > Ok, I'll push it. > No need to send a patch as you have it in your webrev. Ok. Please, send me a changeset for push. Thanks, Serguei > Thanks, > Serguei > > >> Thanks, >> >> Yasumasa >> >> >> 2017-09-29 8:22 GMT+09:00 serguei.spitsyn at oracle.com >> : >>> Hi Yasumasa, >>> >>> The fix looks good to me. >>> One minor comment: >>> ?? Not all imports in the test are ordered correctly. >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 9/23/17 05:13, Yasumasa Suenaga wrote: >>>> Hi Jini, >>>> >>>> I've added a test case for this in new webrev. >>>> This webrev is for consolidated jdk10/hs. >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.01/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2017/09/22 15:12, Jini George wrote: >>>>> Hi Yasumasa, >>>>> >>>>> Your change looks good. But please do add in a test case for this. >>>>> >>>>> Thanks, >>>>> Jini (not a Reviewer). >>>>> >>>>> On 9/21/2017 4:18 AM, Yasumasa Suenaga wrote: >>>>>> PING: >>>>>> >>>>>> Have you checked this issue? >>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.00/ >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2017/09/11 22:47, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> This review request is a part of [1]. >>>>>>> >>>>>>> >>>>>>> JBS: >>>>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8175816 >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8175816/webrev.00/ >>>>>>> >>>>>>> >>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-September/021821.html >>>>>>> >>>>>>> > From yasuenag at gmail.com Fri Sep 29 09:19:25 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 29 Sep 2017 18:19:25 +0900 Subject: RFR: 8187403: [Unknown generation] is shown in Stack Memory on HSDB In-Reply-To: References: <2ee4d0c9-bdd5-19f3-e036-0aa096b59946@gmail.com> <1869b689-d6ba-bfcd-6bc2-a4a5e0ca6695@oracle.com> <481be3d6-d19d-8fd0-6446-c8aea02488a6@oracle.com> Message-ID: Thanks Serguei, I'm waiting another reviewer. Yasumasa 2017/09/29 ??6:00 "serguei.spitsyn at oracle.com" : > > > On 9/29/17 01:25, Yasumasa Suenaga wrote: > >> Thanks Serguei, >> >> I've uploaded new webrev. Could you review again? >> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.02/ >> > > Looks good. > I can sponsor it, but you probably need another review. > > Thanks, > Serguei > > > Yasumasa >> >> >> >> 2017-09-29 16:49 GMT+09:00 serguei.spitsyn at oracle.com >> : >> >>> Hi Yasumasa, >>> >>> >>> On 9/28/17 23:21, Yasumasa Suenaga wrote: >>> >>> Hi Serguet, >>> >>> Thank you for your comment. >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/ >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/ >>> HeapRegion.java.frames.html >>> >>> It seems, there is no reason for renaming 'type' to 't' in the >>> initialize() method. >>> >>> I added new private member "type" as HeapRegionType. >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/ >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/ >>> HeapRegion.java.udiff.html >>> >>> So I renamed to "t" to avoid conflict. >>> >>> >>> There is no conflict. >>> Only local is used in the initialize() method. >>> Also, the initialize() method is static so that the instance field >>> 'type' is >>> not in its scope. >>> Otherwise, you could use this.type to avoid such a conflict. >>> >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/ >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/ >>> HeapRegionManager.java.frames.html >>> >>> 89 public HeapRegion addrToRegion(Address addr) { >>> 90 return regions().getByAddress(addr); >>> 91 } >>> >>> A suggestion: replace 'addrToRegion' with 'getByAddress'. >>> It will look similar to the 'heapRegionIterator.' >>> >>> I've implemented it to follow HotSpot implementation. >>> >>> http://hg.openjdk.java.net/jdk10/hs/file/3a45532a1854/src/ >>> hotspot/share/gc/g1/heapRegionManager.inline.hpp#l32 >>> >>> I think current proposal is easy to understand if other people check >>> this with HotSpot. >>> Should I rename to "getByAddress" ? >>> >>> >>> 81 public Iterator heapRegionIterator() { >>> 82 return regions().heapRegionIterator(length()); >>> 83 } >>> . . . >>> 89 public HeapRegion addrToRegion(Address addr) { >>> 90 return regions().getByAddress(addr); >>> 91 } >>> >>> >>> There is already regions().getByAddress(addr), so I'm suggesting to >>> follow >>> this local pattern. >>> Renaming 'addrToRegion' to 'getByAddress' will unify it with the >>> 'heapRegionIterator()'. >>> Otherwise, you would need to rename 'getByAddress' to 'addrToRegion' >>> everywhere. >>> But I guess, it is better to avoid. >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> Other your comment will be fixed in new webrev later. >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> 2017-09-29 14:35 GMT+09:00 serguei.spitsyn at oracle.com >>> : >>> >>> Hi Yasumasa, >>> >>> Just some minor comments. >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/ >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/ >>> G1HeapRegionTable.java.frames.html >>> >>> I'd suggest to make the lines 144-145 a one-liner. >>> It won't be that big. Otherwise, the indent is not right. >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/ >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/ >>> HeapRegion.java.frames.html >>> >>> The same as above for lines 85-86. >>> It seems, there is no reason for renaming 'type' to 't' in the >>> initialize() method. >>> >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/ >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/ >>> HeapRegionManager.java.frames.html >>> >>> 89 public HeapRegion addrToRegion(Address addr) { >>> 90 return regions().getByAddress(addr); >>> 91 } >>> >>> A suggestion: replace 'addrToRegion' with 'getByAddress'. >>> It will look similar to the 'heapRegionIterator.' >>> >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/ >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/ >>> HeapRegionType.java.html >>> >>> 41 private static int freeTag; >>> 42 >>> 43 private static int youngMask; >>> 44 >>> 45 private static int humongousMask; >>> 46 >>> 47 private static int pinnedMask; >>> 48 >>> 49 private static int oldMask; >>> 50 >>> 51 private static CIntegerField tagField; >>> >>> Unneeded empty lines. >>> >>> Also, it looks like the fields 'freeTag' and 'pinnedMask' are never >>> initialized. >>> Not sure, if it is intentional. >>> >>> Otherwise, the fix looks good to me. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 9/28/17 18:20, Yasumasa Suenaga wrote: >>> >>> Hi Serguei, >>> >>> I added it to JBS: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8187403?focusedComm >>> entId=14119248&page=com.atlassian.jira.plugin.system. >>> issuetabpanels:comment-tabpanel#comment-14119248 >>> >>> Sorry for my English. I'm not good at English... >>> >>> >>> Please, don't worry about your English. >>> Your description looks good. >>> Thank you for the bug report update! >>> >>> Thanks, >>> Serguei >>> >>> >>> Yasumasa >>> >>> >>> >>> 2017-09-29 8:27 GMT+09:00 serguei.spitsyn at oracle.com >>> : >>> >>> Hi Yasumasa, >>> >>> Could you, please, also add some evaluation to the bug report about what >>> is >>> the root cause and how do you fix it? >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 9/26/17 18:10, Yasumasa Suenaga wrote: >>> >>> Hi all, >>> >>> I added noreg-hard label to JBS because this issue appears Stack >>> Memory window on HSDB (GUI application). So it is hard to test. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8187403 >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> >>> 2017-09-26 23:55 GMT+09:00 Yasumasa Suenaga : >>> >>> Hi all, >>> >>> I uploaded new webrev to be adapted to jdk10/hs: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.01/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2017/09/21 7:48, Yasumasa Suenaga wrote: >>> >>> PING: >>> >>> Have you checked this issue? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.00/ >>> >>> >>> Yasumasa >>> >>> >>> >>> On 2017/09/11 11:18, Yasumasa Suenaga wrote: >>> >>> Hi all, >>> >>> This review request is a part of [1]. >>> >>> >>> JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8187403 >>> >>> webrev: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187403/webrev.00/ >>> >>> >>> I cannot access JPRT. So I need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/20 >>> 17-September/021821.html >>> >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Fri Sep 29 09:28:17 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 29 Sep 2017 18:28:17 +0900 Subject: PING: RFR: 8187401: Java Stack cannot be shown on HSDB In-Reply-To: References: <3d25fa66-085d-11a7-74f4-eba9fa0360b5@oracle.com> <71273032-0ad5-8aed-350a-b53d0da625b3@oracle.com> <05acbfe2-5d8a-b492-8f30-6180568ad26d@oracle.com> <4457260a-a6e3-57a4-ef40-5b83db09f3b4@oracle.com> Message-ID: Hi all, This change has been reviewed by Serguei. I'm waiting for another reviewer. Thanks, Yasumasa 2017/09/27 ??9:49 "Yasumasa Suenaga" : > Hi David, Serguei, > > I added noreg-hard label and how to reproduce to JBS: > > https://bugs.openjdk.java.net/browse/JDK-8187401 > > > Also I uploaded new webrev for jdk10/hs: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.01/ > > > Thanks, > > Yasumasa > > > > 2017-09-27 8:25 GMT+09:00 serguei.spitsyn at oracle.com > : > > On 9/26/17 16:22, David Holmes wrote: > >> > >> On 27/09/2017 8:52 AM, serguei.spitsyn at oracle.com wrote: > >>> > >>> Hi David, > >>> > >>> > >>> On 9/26/17 15:09, David Holmes wrote: > >>>> > >>>> Hi Sergeui, > >>>> > >>>> On 27/09/2017 3:51 AM, serguei.spitsyn at oracle.com wrote: > >>>>> > >>>>> Hi Yasumasa, > >>>>> > >>>>> > >>>>> On 9/26/17 02:41, Yasumasa Suenaga wrote: > >>>>>> > >>>>>> Hi Serguei, > >>>>>> > >>>>>> Thank you for your comment! > >>>>>> > >>>>>>> This fix looks Ok to me but you need to add a unit test. > >>>>>> > >>>>>> I guess it is caused by inlined method which is generated by JIT > >>>>>> compiler. I don't know how to reproduce it on jtreg test. > >>>>>> Do you have any idea for it? > >>>>> > >>>>> > >>>>> I'm not sure what exact problem you have with jtreg. > >>>>> You may want to try to use other jtreg tests as examples. > >>>> > >>>> > >>>> I see two problems: > >>>> > >>>> 1. hsdb is an interactive GUI tool > >>> > >>> > >>> There is already at least one jtreg hsdb test: > >>> open/test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java > >>> > >>> Not sure, if this example would help in this case though. > >>> > >>>> 2. The problem seems related to JIT inlining - so how do you force > that > >>>> in a test? > >>> > >>> > >>> Then I wonder how was it forced in the manual reproducer? > >>> The fact it is fixed has to be verified anyway. > >> > >> > >> Well the reproducer happens to hit the issue, so we can use it to > manually > >> verify. > >> > >>>> I would think this is a noreg-hard situation. As long as there is a > >>>> manual reproducer that can be used to verify the fix - as per the bug > report > >>>> - that should be okay IMHO. > >>> > >>> > >>> I'm Ok with adding noreg-hard label if it is hard to develop. > >> > >> > >> Sounds good to me. The manual verification steps should be very clearly > >> spelt out in the bug report so that even someone unfamiliar with hsdb > (like > >> me!) can follow them easily. > > > > > > Sounds good, thanks. > > > > Serguei > > > >> > >> Cheers, > >> David > >> > >>> Thanks, > >>> Serguei > >>> > >>>> Cheers, > >>>> David > >>>> > >>>>> Thanks, > >>>>> Serguei > >>>>> > >>>>>> Yasumasa > >>>>>> > >>>>>> > >>>>>> 2017-09-26 18:15 GMT+09:00 serguei.spitsyn at oracle.com > >>>>>> : > >>>>>>> > >>>>>>> Hi Yasumasa, > >>>>>>> > >>>>>>> This fix looks Ok to me but you need to add a unit test. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Serguei > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 9/20/17 15:47, Yasumasa Suenaga wrote: > >>>>>>>> > >>>>>>>> PING: > >>>>>>>> > >>>>>>>> Have you checked this issue? > >>>>>>>> > >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Yasumasa > >>>>>>>> > >>>>>>>> > >>>>>>>> On 2017/09/11 11:16, Yasumasa Suenaga wrote: > >>>>>>>>> > >>>>>>>>> Hi all, > >>>>>>>>> > >>>>>>>>> This review request is a part of [1]. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> JBS: > >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8187401 > >>>>>>>>> > >>>>>>>>> webrev: > >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187401/webrev.00/ > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I cannot access JPRT. So I need a sponsor. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> > >>>>>>>>> Yasumasa > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> [1] > >>>>>>>>> > >>>>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/ > 2017-September/021821.html > >>>>>>>>> > >>>>> > >>> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: