Re: JDK-8185003 JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

They are both supported API. So one is not any easier than the other. Mandy On 8/3/17 8:08 PM, Hohensee, Paul wrote: Thought it would be an easier path, but I didn’t know for sure, hence my question. Thanks, Paul *From: *Mandy Chung *Date: *Thursday, August 3,

Re: JDK-8185003 JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

Thought it would be an easier path, but I didn’t know for sure, hence my question. Thanks, Paul From: Mandy Chung Date: Thursday, August 3, 2017 at 5:10 PM To: "Hohensee, Paul" Cc: Ujwal Vangapally , serviceability-dev

Re: RFR: JDK-8185003 JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

> On Aug 3, 2017, at 2:10 PM, Daniel Fuchs wrote: > > Hi Mandy, > > On 03/08/17 21:04, Mandy Chung wrote: >>> Adding a public method to an interface is an incompatible source change >>> unless there is a default body. On the other hand I am not sure how MXBean >>>

Re: JDK-8185003 JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

Why? There is a reasonable request to java.lang.management.ThreadMXBean. dumpAllThreads and getThreadInfos methods should have taken the maxDepth parameter when it was introduced. Unfortunately they didn’t and need to add two new methods to it. Mandy > On Aug 3, 2017, at 1:42 PM, Hohensee,

Re: RFR: JDK-8185003 JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

> On Aug 3, 2017, at 2:10 PM, Daniel Fuchs wrote: > > Hi Mandy, > > On 03/08/17 21:04, Mandy Chung wrote: >>> Adding a public method to an interface is an incompatible source change >>> unless there is a default body. On the other hand I am not sure how MXBean >>>

Re: RFR: JDK-8185003 JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

Hi Mandy, On 03/08/17 21:04, Mandy Chung wrote: Adding a public method to an interface is an incompatible source change unless there is a default body. On the other hand I am not sure how MXBean proxies will work when proxying an interface containing a default body. It would be interesting to

Re: JDK-8185003 JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

Add it to com.sun.management.ThreadMXBean rather than java.lang.management.ThreadMXBean? Paul From: serviceability-dev on behalf of Mandy Chung Date: Thursday, August 3, 2017 at 1:04 PM To: Ujwal Vangapally

Re: RFR: JDK-8185003 JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

> On Aug 3, 2017, at 8:24 AM, Ujwal Vangapally > wrote: > > Thanks for the review Erik, > I will investigate more considering Daniel's comment. > Adding a public method to an interface is an incompatible source change > unless there is a default body. On the

Re: RFR 8185806: Quarantine test JdbExprTest.sh on 32-bit Windows

On 8/3/17 12:45, harold seigel wrote: Hi Serguei, Dan pointed out that the test failed on both 64-bit and 32-bit Windows platforms so I'll be sending out a new webrev without a "(sun.arch.data.model != "32")" clause in the

Re: RFR 8185806: Quarantine test JdbExprTest.sh on 32-bit Windows

Hi Serguei, Dan pointed out that the test failed on both 64-bit and 32-bit Windows platforms so I'll be sending out a new webrev without a "(sun.arch.data.model != "32")" clause in the @requires statement. Thanks, Harold On 8/3/2017 3:15 PM, serguei.spit...@oracle.com wrote: Hi Harold,

Re: RFR: JDK-8185003 JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

Hi Ujwal, On 8/3/2017 12:44 PM, Ujwal Vangapally wrote: Thanks for the review Roger, please see my comments inline. On 8/3/2017 8:23 PM, Roger Riggs wrote: Hi Ujwal, (Reviewer, but not specifically servicability). Comments, java/lang/management/ThreadMXBean.java: 809: It may be useful

Re: JDK-8185003 JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

What do people think of the idea of extending this RFE to include adding versions of dumpAllThreads that are duals of the existing getThreadInfo(long[], …) methods? And also add getThreadInfo(long[] ids, boolean lockedMonitors, boolean lockedSynchronizers, int maxDepth) as the dual of the

Re: RFR: JDK-8185003 JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

Thanks for the review Roger, please see my comments inline. On 8/3/2017 8:23 PM, Roger Riggs wrote: Hi Ujwal, (Reviewer, but not specifically servicability). Comments, java/lang/management/ThreadMXBean.java: 809: It may be useful to state that the behavior is the same as {@link

Re: RFR: JDK-8185003 JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

Thanks for the review Erik, I will investigate more considering Daniel's comment. Adding a public method to an interface is an incompatible source change unless there is a default body. On the other hand I am not sure how MXBean proxies will work when proxying an interface containing a

Re: RFR: JDK-8185003 JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

Hi Ujwal, (Reviewer, but not specifically servicability). Comments, java/lang/management/ThreadMXBean.java: 809: It may be useful to state that the behavior is the same as {@link #dumpAllThreads} except that the depth is limited. 828: Do not duplicate specification of the meaning of

[10] RFR: 8185796: jstack and clhsdb jstack should show lock objects

Hi all, Thread dump shows lock objects, however jstack jhsdb and jstack in CLHSDB are not show them. They are very useful for checking monitors. So jstack mode should show them. I uploaded webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.00/ This change

Re: RFR: JDK-8185003 JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

Looks good, not a reviewer. Nit, saw that spaces before commas were missing in some method calls, i.e. ",-1" instead of ", -1" Erik Hi, kindly review the changes made. https://bugs.openjdk.java.net/browse/JDK-8185003 webrev:

Re: RFR: JDK-8185003 JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

kindly use the below link for accessing webrev http://cr.openjdk.java.net/~uvangapally/webrev/2017/8185003/webrev.01/ previously shared link is no longer accessible hence providing this new link. Thanks, Ujwal. On 8/3/2017 3:08 PM, Ujwal Vangapally wrote: Hi, kindly review the changes

Re: [10] RFR: 8185164: GetOwnedMonitorInfo() returns incorrect owned monitor

Hi, I think the fix is sound and prevents anyone from observing the case where the monitor will be seen in the stack-frame, but has not yet been set as the "pending monitor". As far as I can tell it is only this case (GetOwnedMonitorInfo from the contended-monitor event callback in the

RFR: JDK-8185003 JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

Hi, kindly review the changes made. https://bugs.openjdk.java.net/browse/JDK-8185003 webrev: http://cr.openjdk.java.net/~uvangapally/webrev/2017/8185003/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8185705 Thanks, Ujwal.

RE: RFR(XS): 8185112: [TESTBUG] Servicability tests cannot parse float if non US locale.

Hi Volker, > OK, I don't want to unnecessarily block this change but IMO if we > don't need the integer parsing function at all we should remove it or > otherwise change it to use NumberFormat as well. We need the integer parsing function. But the intergers parsed are not printed with