Re: RFR : 8182485 - JMX connections should have configurable ObjectInputFilter
Thanks for the review Daniel,Roger. -Harsha On Tuesday 20 June 2017 11:30 PM, Roger Riggs wrote: +1 Roger On 6/20/2017 1:24 PM, Daniel Fuchs wrote: The fix looks good to me Harsha. best regards, -- daniel On 20/06/2017 07:10, Harsha Wardhana B wrote: Hi, Please review the below RFE, JDK-8182485 : JMX connections should have configurable ObjectInputFilter having webrev at http://cr.openjdk.java.net/~hb/8182485/webrev.00/ The enhancement adds ObjectInputFilter to JMX connections to configure filters during deserialization. -Harsha
Remove METHOD_ENTRY and METHOD_EXIT events from needed_capabilities in JDWP Agent
Looking at the Agent_OnLoad() code in debuginit.c of libjdwp, I see that both the METHOD_ENTRY and METHOD_EXIT are listed as required, but I don't see where they are ever enabled in the agent. In the J9 JVM making it possible to enable these events has severe performance penalties. Since the events are not enabled in the JDWP agent, simply reserved, we were hoping you'd be open to removing the reservation of the capabilities. -- Ron
Re: RFR : 8182485 - JMX connections should have configurable ObjectInputFilter
+1 Roger On 6/20/2017 1:24 PM, Daniel Fuchs wrote: The fix looks good to me Harsha. best regards, -- daniel On 20/06/2017 07:10, Harsha Wardhana B wrote: Hi, Please review the below RFE, JDK-8182485 : JMX connections should have configurable ObjectInputFilter having webrev at http://cr.openjdk.java.net/~hb/8182485/webrev.00/ The enhancement adds ObjectInputFilter to JMX connections to configure filters during deserialization. -Harsha
Re: RFR : 8182485 - JMX connections should have configurable ObjectInputFilter
The fix looks good to me Harsha. best regards, -- daniel On 20/06/2017 07:10, Harsha Wardhana B wrote: Hi, Please review the below RFE, JDK-8182485 : JMX connections should have configurable ObjectInputFilter having webrev at http://cr.openjdk.java.net/~hb/8182485/webrev.00/ The enhancement adds ObjectInputFilter to JMX connections to configure filters during deserialization. -Harsha
Re: Review Request JDK-8182596: Fix broken links in com.sun.tools.attach.VirtualMachine
Looks good.
Thanks,
Serguei
On 6/20/17 08:37, Mandy Chung wrote:
diff --git
a/src/jdk.attach/share/classes/com/sun/tools/attach/VirtualMachine.java
b/src/jdk.attach/share/classes/com/sun/tools/attach/VirtualMachine.java
--- a/src/jdk.attach/share/classes/com/sun/tools/attach/VirtualMachine.java
+++ b/src/jdk.attach/share/classes/com/sun/tools/attach/VirtualMachine.java
@@ -59,9 +59,9 @@
* {@link java.lang.instrument} for a detailed description on how these agents
* are loaded and started). The {@link #loadAgentLibrary loadAgentLibrary} and
* {@link #loadAgentPath loadAgentPath} methods are used to load agents that
- * are deployed either in a dynamic library or statically linked into the VM and
make use of the JVM Tools
- * Interface.
+ * are deployed either in a dynamic library or statically linked into the VM
and
+ * make use of the JVM Tools
Interface.
+ *
*
* In addition to loading agents a VirtualMachine provides read access to
the
* {@link java.lang.System#getProperties() system properties} in the target
VM.
@@ -289,8 +289,8 @@
/**
* Loads an agent library.
*
- * A JVM
- * TI client is called an agent. It is developed in a native
language.
+ * A JVM TI
+ * client is called an agent. It is developed in a native language.
* A JVM TI agent is deployed in a platform specific manner but it is
typically the
* platform equivalent of a dynamic library. Alternatively, it may be
statically linked into the VM.
* This method causes the given agent library to be loaded into the target
@@ -298,8 +298,8 @@
* It then causes the target VM to invoke the {@code Agent_OnAttach}
function
* or, for a statically linked agent named 'L', the {@code
Agent_OnAttach_L} function
* as specified in the
- *
JVM Tools
- * Interface specification. Note that the {@code Agent_OnAttach[_L]}
+ * JVM Tools Interface
specification.
+ * Note that the {@code Agent_OnAttach[_L]}
* function is invoked even if the agent library was loaded prior to
invoking
* this method.
*
@@ -380,8 +380,8 @@
/**
* Load a native agent library by full pathname.
*
- * A JVM
- * TI client is called an agent. It is developed in a native
language.
+ * A JVM TI
+ * client is called an agent. It is developed in a native language.
* A JVM TI agent is deployed in a platform specific manner but it is
typically the
* platform equivalent of a dynamic library. Alternatively, the native
* library specified by the agentPath parameter may be statically
@@ -397,8 +397,7 @@
* It then causes the target VM to invoke the {@code Agent_OnAttach}
* function or, for a statically linked agent named 'L', the
* {@code Agent_OnAttach_L} function as specified in the
- *
JVM Tools
- * Interface specification.
+ * JVM Tools Interface
specification.
* Note that the {@code Agent_OnAttach[_L]}
* function is invoked even if the agent library was loaded prior to
invoking
* this method.
@@ -611,9 +610,9 @@
* way as on the command line, you need to specify at least the
* {@code com.sun.management.jmxremote.port} property.
*
- * See the online documentation for
- * Monitoring and Management Using JMX Technology for further details.
+ * See the online documentation for
+ * {@extLink monitoring_and_management_using_jmx_technology
+ * Monitoring and Management Using JMX Technology} for further details.
*
* @param agentProperties
* A Properties object containing the configuration properties
@@ -642,9 +641,9 @@
/**
* Starts the local JMX management agent in the target virtual machine.
*
- * See the online documentation for
- * Monitoring and Management Using JMX Technology for further details.
+ * See the online documentation for
+ * {@extLink monitoring_and_management_using_jmx_technology
+ * Monitoring and Management Using JMX Technology} for further details.
*
* @return The String representation of the local connector's service
address.
* The value can be parsed by the
Re: Review Request JDK-8182596: Fix broken links in com.sun.tools.attach.VirtualMachine
Looks good.
On 20/06/2017 16:37, Mandy Chung wrote:
diff --git
a/src/jdk.attach/share/classes/com/sun/tools/attach/VirtualMachine.java
b/src/jdk.attach/share/classes/com/sun/tools/attach/VirtualMachine.java
--- a/src/jdk.attach/share/classes/com/sun/tools/attach/VirtualMachine.java
+++ b/src/jdk.attach/share/classes/com/sun/tools/attach/VirtualMachine.java
@@ -59,9 +59,9 @@
* {@link java.lang.instrument} for a detailed description on how these agents
* are loaded and started). The {@link #loadAgentLibrary loadAgentLibrary} and
* {@link #loadAgentPath loadAgentPath} methods are used to load agents that
- * are deployed either in a dynamic library or statically linked into the VM and
make use of the JVM Tools
- * Interface.
+ * are deployed either in a dynamic library or statically linked into the VM
and
+ * make use of the JVM Tools
Interface.
+ *
*
* In addition to loading agents a VirtualMachine provides read access to
the
* {@link java.lang.System#getProperties() system properties} in the target
VM.
@@ -289,8 +289,8 @@
/**
* Loads an agent library.
*
- * A JVM
- * TI client is called an agent. It is developed in a native
language.
+ * A JVM TI
+ * client is called an agent. It is developed in a native language.
* A JVM TI agent is deployed in a platform specific manner but it is
typically the
* platform equivalent of a dynamic library. Alternatively, it may be
statically linked into the VM.
* This method causes the given agent library to be loaded into the target
@@ -298,8 +298,8 @@
* It then causes the target VM to invoke the {@code Agent_OnAttach}
function
* or, for a statically linked agent named 'L', the {@code
Agent_OnAttach_L} function
* as specified in the
- *
JVM Tools
- * Interface specification. Note that the {@code Agent_OnAttach[_L]}
+ * JVM Tools Interface
specification.
+ * Note that the {@code Agent_OnAttach[_L]}
* function is invoked even if the agent library was loaded prior to
invoking
* this method.
*
@@ -380,8 +380,8 @@
/**
* Load a native agent library by full pathname.
*
- * A JVM
- * TI client is called an agent. It is developed in a native
language.
+ * A JVM TI
+ * client is called an agent. It is developed in a native language.
* A JVM TI agent is deployed in a platform specific manner but it is
typically the
* platform equivalent of a dynamic library. Alternatively, the native
* library specified by the agentPath parameter may be statically
@@ -397,8 +397,7 @@
* It then causes the target VM to invoke the {@code Agent_OnAttach}
* function or, for a statically linked agent named 'L', the
* {@code Agent_OnAttach_L} function as specified in the
- *
JVM Tools
- * Interface specification.
+ * JVM Tools Interface
specification.
* Note that the {@code Agent_OnAttach[_L]}
* function is invoked even if the agent library was loaded prior to
invoking
* this method.
@@ -611,9 +610,9 @@
* way as on the command line, you need to specify at least the
* {@code com.sun.management.jmxremote.port} property.
*
- * See the online documentation for
- * Monitoring and Management Using JMX Technology for further details.
+ * See the online documentation for
+ * {@extLink monitoring_and_management_using_jmx_technology
+ * Monitoring and Management Using JMX Technology} for further details.
*
* @param agentProperties
* A Properties object containing the configuration properties
@@ -642,9 +641,9 @@
/**
* Starts the local JMX management agent in the target virtual machine.
*
- * See the online documentation for
- * Monitoring and Management Using JMX Technology for further details.
+ * See the online documentation for
+ * {@extLink monitoring_and_management_using_jmx_technology
+ * Monitoring and Management Using JMX Technology} for further details.
*
* @return The String representation of the local connector's service
address.
* The value can be parsed by the
Review Request JDK-8182596: Fix broken links in com.sun.tools.attach.VirtualMachine
diff --git
a/src/jdk.attach/share/classes/com/sun/tools/attach/VirtualMachine.java
b/src/jdk.attach/share/classes/com/sun/tools/attach/VirtualMachine.java
--- a/src/jdk.attach/share/classes/com/sun/tools/attach/VirtualMachine.java
+++ b/src/jdk.attach/share/classes/com/sun/tools/attach/VirtualMachine.java
@@ -59,9 +59,9 @@
* {@link java.lang.instrument} for a detailed description on how these agents
* are loaded and started). The {@link #loadAgentLibrary loadAgentLibrary} and
* {@link #loadAgentPath loadAgentPath} methods are used to load agents that
- * are deployed either in a dynamic library or statically linked into the VM
and make use of the JVM Tools
- * Interface.
+ * are deployed either in a dynamic library or statically linked into the VM
and
+ * make use of the JVM Tools
Interface.
+ *
*
* In addition to loading agents a VirtualMachine provides read access to
the
* {@link java.lang.System#getProperties() system properties} in the target VM.
@@ -289,8 +289,8 @@
/**
* Loads an agent library.
*
- * A JVM
- * TI client is called an agent. It is developed in a native
language.
+ * A JVM TI
+ * client is called an agent. It is developed in a native language.
* A JVM TI agent is deployed in a platform specific manner but it is
typically the
* platform equivalent of a dynamic library. Alternatively, it may be
statically linked into the VM.
* This method causes the given agent library to be loaded into the target
@@ -298,8 +298,8 @@
* It then causes the target VM to invoke the {@code Agent_OnAttach}
function
* or, for a statically linked agent named 'L', the {@code
Agent_OnAttach_L} function
* as specified in the
- *
JVM Tools
- * Interface specification. Note that the {@code Agent_OnAttach[_L]}
+ * JVM Tools Interface
specification.
+ * Note that the {@code Agent_OnAttach[_L]}
* function is invoked even if the agent library was loaded prior to
invoking
* this method.
*
@@ -380,8 +380,8 @@
/**
* Load a native agent library by full pathname.
*
- * A JVM
- * TI client is called an agent. It is developed in a native
language.
+ * A JVM TI
+ * client is called an agent. It is developed in a native language.
* A JVM TI agent is deployed in a platform specific manner but it is
typically the
* platform equivalent of a dynamic library. Alternatively, the native
* library specified by the agentPath parameter may be statically
@@ -397,8 +397,7 @@
* It then causes the target VM to invoke the {@code Agent_OnAttach}
* function or, for a statically linked agent named 'L', the
* {@code Agent_OnAttach_L} function as specified in the
- *
JVM Tools
- * Interface specification.
+ * JVM Tools Interface
specification.
* Note that the {@code Agent_OnAttach[_L]}
* function is invoked even if the agent library was loaded prior to
invoking
* this method.
@@ -611,9 +610,9 @@
* way as on the command line, you need to specify at least the
* {@code com.sun.management.jmxremote.port} property.
*
- * See the online documentation for
- * Monitoring and Management Using JMX Technology for further details.
+ * See the online documentation for
+ * {@extLink monitoring_and_management_using_jmx_technology
+ * Monitoring and Management Using JMX Technology} for further details.
*
* @param agentProperties
* A Properties object containing the configuration properties
@@ -642,9 +641,9 @@
/**
* Starts the local JMX management agent in the target virtual machine.
*
- * See the online documentation for
- * Monitoring and Management Using JMX Technology for further details.
+ * See the online documentation for
+ * {@extLink monitoring_and_management_using_jmx_technology
+ * Monitoring and Management Using JMX Technology} for further details.
*
* @return The String representation of the local connector's service
address.
* The value can be parsed by the
Re: RFR: JDK-8173180 VirtualMachine.startLocalManagementAgent() returns URI with unreliable IP address
Hi Daniel, On Tuesday 20 June 2017 06:39 PM, Daniel Fuchs wrote: On 20/06/2017 12:42, Ujwal Vangapally wrote: Thanks for the Review Daniel, Harsha. Yes with this fix JConsole running on JDK 8 won't be able to connect to a process running on higher version of Java containing this change. I think even Harsha is agreeing this, his point is that the use case where a client running on JDK 8 trying to connect to a process running on latest releases is rare. As mostly for Local Management both client and server will be running on same machine using same JDK for starting both client and server . please correct me if this is not the case. Well - I believe it could be quite common to use VisualVM running on JDK 8 to connect to JDK 9 processes. JMX is all about interoperability so I'd be very reluctant to break this 'by default'. Agreed. can we have this fix with interoperability issue between versions ? Maybe you could make the fix conditional to a system property being defined? Also are you sure what you are proposing is the correct fix for this issue? It's more of a workaround than a fix as we don't see any other way to fix this issue. Note that - if I'm not mistaken - you can work around the original issue by specifying -Djava.rmi.server.hostname= on the command line. http://docs.oracle.com/javase/8/docs/technotes/guides/rmi/javarmiproperties.html This will instruct RMI to put the specified inside its stubs. The inconvenience is that this is global (for all RMI stubs, just not only those used by JMX) - but would that be an issue for the use case mentioned in the bug? We had the same consideration that setting the RMI property will change the Interface address for all the stubs which may not be an acceptable fix in this case. One possible fix (enhancement) would be to define a JMX system property that will control the Interface address that goes into RMI stubs. If that seems like too much work, we can close this issue as 'won't fix' as we don't have any acceptable fix. best regards, -- daniel -Harsha Thanks, Ujwal. On 6/20/2017 2:40 PM, Daniel Fuchs wrote: Hi Harsha, Maybe I'm missing something. How is the local agent started? If it's started when you connect jconsole to a process by specifying the process ID - then I suspect this will prevent e.g. jconsole or jvisualvm running on JDK 8 to connect to your process. Can you verify that it's not the case? best regards, -- daniel On 20/06/2017 09:11, Harsha Wardhana B wrote: Hi Daniel, The fix is applicable only to local JMX agent and the most common use case would be client and server running from same JVM. It is highly unlikely that local JMX agent will be started to cater for out-of-jvm clients. I don't see how introducing this fix can cause new interoperability problems. Can you please elaborate? -Harsha On Monday 19 June 2017 10:23 PM, Daniel Fuchs wrote: Hi, If I'm not mistaken then this will make it impossible for earlier release to interoperate with newer releases as the LocalRMIClientSocketFactory class will not be present the client tries to deserialize the stub. best regards, -- daniel On 19/06/2017 11:52, Ujwal Vangapally wrote: Hi, Kindly review the fix for bug below https://bugs.openjdk.java.net/browse/JDK-8173180 webrev: http://cr.openjdk.java.net/~uvangapally/webrev/2017/8173180/webrev.00/ Thanks, Ujwal
Re: [10] RFR 8181647: jhsdb jstack could not output thread name
Thank you for checking.
However, a few days ago, I have changed the output to be more similar to
jstack.
Could you possibly check for latest one?
Best regards,
Chihiro
On 2017/06/20 21:16, Jini George wrote:
Your changes look good overall, Chihiro. A few points on the test
case, though.
* The test case checks for the existence of the compiler threads and
the sweeper thread which would not exist when the test case is run
with options like -Xint. You might want to remove those.
* You might have to skip the test on OSX due to jstack issues on OSX.
* Please correct the alignment on lines 74 and 81 for the test case.
Thank you,
Jini. (Not a (R)eviewer)
On 6/14/2017 12:47 PM, chihiro ito wrote:
Hi all,
I added a test case and modified previous patch including fix the
copyright year to 2017.
I changed to output Java thread name next the separator lines in
"jhsdb jstack --mixed" case as following.
- 32117 -
"main"
0x7f6c8feafa82__pthread_cond_timedwait + 0x132
Could you possibly review for this following small change? If review
is ok, please commit this as cito.
Source:
diff --git
a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java
b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java
---
a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java
+++
b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All
rights reserved.
+ * Copyright (c) 2003, 2017, Oracle and/or its affiliates. All
rights reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -88,6 +88,12 @@
out.print("- ");
out.print(th);
out.println(" -");
+ JavaThread jthread = (JavaThread) proxyToThread.get(th);
+ if (jthread != null) {
+ out.print("\"");
+ out.print(jthread.getThreadName());
+ out.println("\"");
+ }
while (f != null) {
ClosestSymbol sym = f.closestSymbolToPC();
Address pc = f.pc();
diff --git
a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java
b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java
---
a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java
+++
b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2002, 2013, Oracle and/or its affiliates. All
rights reserved.
+ * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All
rights reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -75,7 +75,9 @@
for (JavaThread cur = threads.first(); cur != null; cur
= cur.next(), i++) {
if (cur.isJavaThread()) {
Address sp = cur.getLastJavaSP();
-tty.print("Thread ");
+tty.print("\"");
+tty.print(cur.getThreadName());
+tty.print("\" nid=");
cur.printThreadIDOn(tty);
tty.print(": (state = " + cur.getThreadState());
if (verbose) {
diff --git a/test/serviceability/sa/JhsdbThreadNameTest.java
b/test/serviceability/sa/JhsdbThreadNameTest.java
new file mode 100644
--- /dev/null
+++ b/test/serviceability/sa/JhsdbThreadNameTest.java
@@ -0,0 +1,107 @@
+/*
+ * Copyright (c) 2017, Oracle and/or its affiliates. All rights
reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License
+ * version 2 for more details (a copy is included in the LICENSE
file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License
version
+ * 2 along with this work; if not, write to the Free Software
Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA
94065 USA
+ * or visit www.oracle.com if you need additional information or
have any
+ * questions.
+ */
+
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.List;
+import java.util.function.Consumer;
+
+import jdk.test.lib.apps.LingeredApp;
Re: RFR: JDK-8173180 VirtualMachine.startLocalManagementAgent() returns URI with unreliable IP address
On 20/06/2017 12:42, Ujwal Vangapally wrote: Thanks for the Review Daniel, Harsha. Yes with this fix JConsole running on JDK 8 won't be able to connect to a process running on higher version of Java containing this change. I think even Harsha is agreeing this, his point is that the use case where a client running on JDK 8 trying to connect to a process running on latest releases is rare. As mostly for Local Management both client and server will be running on same machine using same JDK for starting both client and server . please correct me if this is not the case. Well - I believe it could be quite common to use VisualVM running on JDK 8 to connect to JDK 9 processes. JMX is all about interoperability so I'd be very reluctant to break this 'by default'. can we have this fix with interoperability issue between versions ? Maybe you could make the fix conditional to a system property being defined? Also are you sure what you are proposing is the correct fix for this issue? Note that - if I'm not mistaken - you can work around the original issue by specifying -Djava.rmi.server.hostname= on the command line. http://docs.oracle.com/javase/8/docs/technotes/guides/rmi/javarmiproperties.html This will instruct RMI to put the specified inside its stubs. The inconvenience is that this is global (for all RMI stubs, just not only those used by JMX) - but would that be an issue for the use case mentioned in the bug? best regards, -- daniel Thanks, Ujwal. On 6/20/2017 2:40 PM, Daniel Fuchs wrote: Hi Harsha, Maybe I'm missing something. How is the local agent started? If it's started when you connect jconsole to a process by specifying the process ID - then I suspect this will prevent e.g. jconsole or jvisualvm running on JDK 8 to connect to your process. Can you verify that it's not the case? best regards, -- daniel On 20/06/2017 09:11, Harsha Wardhana B wrote: Hi Daniel, The fix is applicable only to local JMX agent and the most common use case would be client and server running from same JVM. It is highly unlikely that local JMX agent will be started to cater for out-of-jvm clients. I don't see how introducing this fix can cause new interoperability problems. Can you please elaborate? -Harsha On Monday 19 June 2017 10:23 PM, Daniel Fuchs wrote: Hi, If I'm not mistaken then this will make it impossible for earlier release to interoperate with newer releases as the LocalRMIClientSocketFactory class will not be present the client tries to deserialize the stub. best regards, -- daniel On 19/06/2017 11:52, Ujwal Vangapally wrote: Hi, Kindly review the fix for bug below https://bugs.openjdk.java.net/browse/JDK-8173180 webrev: http://cr.openjdk.java.net/~uvangapally/webrev/2017/8173180/webrev.00/ Thanks, Ujwal
Re: RFR: JDK-8173180 VirtualMachine.startLocalManagementAgent() returns URI with unreliable IP address
Hi, I would expect to see a mix of versions in many operational cases. For example, in a large deployment there will be a mix of versions active and the folks monitoring it should not have to change their management tools unnecessarily. The usual rule for interoperability between versions is that it should work between the previous and next versions. (+/- 1). If there is any issue with compatibility between versions, you'll need to file a CCC to make sure it gets adequate review. Roger On 6/20/17 7:42 AM, Ujwal Vangapally wrote: Thanks for the Review Daniel, Harsha. Yes with this fix JConsole running on JDK 8 won't be able to connect to a process running on higher version of Java containing this change. I think even Harsha is agreeing this, his point is that the use case where a client running on JDK 8 trying to connect to a process running on latest releases is rare. As mostly for Local Management both client and server will be running on same machine using same JDK for starting both client and server . please correct me if this is not the case. can we have this fix with interoperability issue between versions ? Thanks, Ujwal. On 6/20/2017 2:40 PM, Daniel Fuchs wrote: Hi Harsha, Maybe I'm missing something. How is the local agent started? If it's started when you connect jconsole to a process by specifying the process ID - then I suspect this will prevent e.g. jconsole or jvisualvm running on JDK 8 to connect to your process. Can you verify that it's not the case? best regards, -- daniel On 20/06/2017 09:11, Harsha Wardhana B wrote: Hi Daniel, The fix is applicable only to local JMX agent and the most common use case would be client and server running from same JVM. It is highly unlikely that local JMX agent will be started to cater for out-of-jvm clients. I don't see how introducing this fix can cause new interoperability problems. Can you please elaborate? -Harsha On Monday 19 June 2017 10:23 PM, Daniel Fuchs wrote: Hi, If I'm not mistaken then this will make it impossible for earlier release to interoperate with newer releases as the LocalRMIClientSocketFactory class will not be present the client tries to deserialize the stub. best regards, -- daniel On 19/06/2017 11:52, Ujwal Vangapally wrote: Hi, Kindly review the fix for bug below https://bugs.openjdk.java.net/browse/JDK-8173180 webrev: http://cr.openjdk.java.net/~uvangapally/webrev/2017/8173180/webrev.00/ Thanks, Ujwal
Re: [10] RFR 8181647: jhsdb jstack could not output thread name
Your changes look good overall, Chihiro. A few points on the test case,
though.
* The test case checks for the existence of the compiler threads and the
sweeper thread which would not exist when the test case is run with
options like -Xint. You might want to remove those.
* You might have to skip the test on OSX due to jstack issues on OSX.
* Please correct the alignment on lines 74 and 81 for the test case.
Thank you,
Jini. (Not a (R)eviewer)
On 6/14/2017 12:47 PM, chihiro ito wrote:
Hi all,
I added a test case and modified previous patch including fix the
copyright year to 2017.
I changed to output Java thread name next the separator lines in
"jhsdb jstack --mixed" case as following.
- 32117 -
"main"
0x7f6c8feafa82__pthread_cond_timedwait + 0x132
Could you possibly review for this following small change? If review
is ok, please commit this as cito.
Source:
diff --git
a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java
b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java
---
a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java
+++
b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2003, 2017, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -88,6 +88,12 @@
out.print("- ");
out.print(th);
out.println(" -");
+ JavaThread jthread = (JavaThread) proxyToThread.get(th);
+ if (jthread != null) {
+ out.print("\"");
+ out.print(jthread.getThreadName());
+ out.println("\"");
+ }
while (f != null) {
ClosestSymbol sym = f.closestSymbolToPC();
Address pc = f.pc();
diff --git
a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java
b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java
---
a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java
+++
b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2002, 2013, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -75,7 +75,9 @@
for (JavaThread cur = threads.first(); cur != null; cur =
cur.next(), i++) {
if (cur.isJavaThread()) {
Address sp = cur.getLastJavaSP();
-tty.print("Thread ");
+tty.print("\"");
+tty.print(cur.getThreadName());
+tty.print("\" nid=");
cur.printThreadIDOn(tty);
tty.print(": (state = " + cur.getThreadState());
if (verbose) {
diff --git a/test/serviceability/sa/JhsdbThreadNameTest.java
b/test/serviceability/sa/JhsdbThreadNameTest.java
new file mode 100644
--- /dev/null
+++ b/test/serviceability/sa/JhsdbThreadNameTest.java
@@ -0,0 +1,107 @@
+/*
+ * Copyright (c) 2017, Oracle and/or its affiliates. All rights
reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file
that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License
version
+ * 2 along with this work; if not, write to the Free Software
Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA
94065 USA
+ * or visit www.oracle.com if you need additional information or have
any
+ * questions.
+ */
+
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.List;
+import java.util.function.Consumer;
+
+import jdk.test.lib.apps.LingeredApp;
+import jdk.test.lib.JDKToolLauncher;
+import jdk.test.lib.Platform;
+import jdk.test.lib.process.OutputAnalyzer;
+import jdk.test.lib.Utils;
+
+/*
+ * @test
+ * @library /test/lib
+ * @run main/othervm
Re: RFR: JDK-8173180 VirtualMachine.startLocalManagementAgent() returns URI with unreliable IP address
Thanks for the Review Daniel, Harsha. Yes with this fix JConsole running on JDK 8 won't be able to connect to a process running on higher version of Java containing this change. I think even Harsha is agreeing this, his point is that the use case where a client running on JDK 8 trying to connect to a process running on latest releases is rare. As mostly for Local Management both client and server will be running on same machine using same JDK for starting both client and server . please correct me if this is not the case. can we have this fix with interoperability issue between versions ? Thanks, Ujwal. On 6/20/2017 2:40 PM, Daniel Fuchs wrote: Hi Harsha, Maybe I'm missing something. How is the local agent started? If it's started when you connect jconsole to a process by specifying the process ID - then I suspect this will prevent e.g. jconsole or jvisualvm running on JDK 8 to connect to your process. Can you verify that it's not the case? best regards, -- daniel On 20/06/2017 09:11, Harsha Wardhana B wrote: Hi Daniel, The fix is applicable only to local JMX agent and the most common use case would be client and server running from same JVM. It is highly unlikely that local JMX agent will be started to cater for out-of-jvm clients. I don't see how introducing this fix can cause new interoperability problems. Can you please elaborate? -Harsha On Monday 19 June 2017 10:23 PM, Daniel Fuchs wrote: Hi, If I'm not mistaken then this will make it impossible for earlier release to interoperate with newer releases as the LocalRMIClientSocketFactory class will not be present the client tries to deserialize the stub. best regards, -- daniel On 19/06/2017 11:52, Ujwal Vangapally wrote: Hi, Kindly review the fix for bug below https://bugs.openjdk.java.net/browse/JDK-8173180 webrev: http://cr.openjdk.java.net/~uvangapally/webrev/2017/8173180/webrev.00/ Thanks, Ujwal
Re: RFR: JDK-8173180 VirtualMachine.startLocalManagementAgent() returns URI with unreliable IP address
Hi Harsha, Maybe I'm missing something. How is the local agent started? If it's started when you connect jconsole to a process by specifying the process ID - then I suspect this will prevent e.g. jconsole or jvisualvm running on JDK 8 to connect to your process. Can you verify that it's not the case? best regards, -- daniel On 20/06/2017 09:11, Harsha Wardhana B wrote: Hi Daniel, The fix is applicable only to local JMX agent and the most common use case would be client and server running from same JVM. It is highly unlikely that local JMX agent will be started to cater for out-of-jvm clients. I don't see how introducing this fix can cause new interoperability problems. Can you please elaborate? -Harsha On Monday 19 June 2017 10:23 PM, Daniel Fuchs wrote: Hi, If I'm not mistaken then this will make it impossible for earlier release to interoperate with newer releases as the LocalRMIClientSocketFactory class will not be present the client tries to deserialize the stub. best regards, -- daniel On 19/06/2017 11:52, Ujwal Vangapally wrote: Hi, Kindly review the fix for bug below https://bugs.openjdk.java.net/browse/JDK-8173180 webrev: http://cr.openjdk.java.net/~uvangapally/webrev/2017/8173180/webrev.00/ Thanks, Ujwal
Re: RFR: JDK-8173180 VirtualMachine.startLocalManagementAgent() returns URI with unreliable IP address
Hi Daniel, The fix is applicable only to local JMX agent and the most common use case would be client and server running from same JVM. It is highly unlikely that local JMX agent will be started to cater for out-of-jvm clients. I don't see how introducing this fix can cause new interoperability problems. Can you please elaborate? -Harsha On Monday 19 June 2017 10:23 PM, Daniel Fuchs wrote: Hi, If I'm not mistaken then this will make it impossible for earlier release to interoperate with newer releases as the LocalRMIClientSocketFactory class will not be present the client tries to deserialize the stub. best regards, -- daniel On 19/06/2017 11:52, Ujwal Vangapally wrote: Hi, Kindly review the fix for bug below https://bugs.openjdk.java.net/browse/JDK-8173180 webrev: http://cr.openjdk.java.net/~uvangapally/webrev/2017/8173180/webrev.00/ Thanks, Ujwal
RFR : 8182485 - JMX connections should have configurable ObjectInputFilter
Hi, Please review the below RFE, JDK-8182485 : JMX connections should have configurable ObjectInputFilter having webrev at http://cr.openjdk.java.net/~hb/8182485/webrev.00/ The enhancement adds ObjectInputFilter to JMX connections to configure filters during deserialization. -Harsha
