Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties
Hi Erik, The minimal command line would be, "-Xmanagement", that will start only the local management server. "-Xmanagement:local=true,port=" will start the remote management server without SSL or authentication. On Wednesday 24 January 2018 06:13 PM, Erik Gahlin wrote: Hi Harsha, Very nice to see progress on this! Before reviewing, the minimal command line to start up the default management server now becomes -Xmanagement:ssl=false,authenticate=false No. Please refer above for minimal options. and if you use a property that doesn't exist, or that is mandatory, you will get an error message stating what is wrong? If we use property, that doesn't exist, we get invalid option error. As said before, no options are mandatory. /// //./java -Xmanagement:ssl=true,authenticate=false,rmiregistry_ssl=true HelloWorld// //Error: Invalid option specified: rmiregistry_ssl// /// Could we reduce the command line further, so only a single property is needed: -Xmanagement:secure=false or perhaps: -Xmanagement:unsecure which would set ssl=false,authenticate=false, because that is what you want 99% of the time. Thanks Erik Thanks Harsha Hi, Please review the changes for above enhancement having webrev at, http://cr.openjdk.java.net/~hb/8187498/webrev.00/ Thanks Harsha
Re: RFR: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes
Hi Jini, On 25/01/2018 3:43 AM, Jini George wrote: Hello, Requesting reviews for the issue: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes ID: https://bugs.openjdk.java.net/browse/JDK-8175384 Webrev: http://cr.openjdk.java.net/~jgeorge/8175384/webrev.01/ The issue was seen while printing out the details of the invokevirtual bytecode of the java.lang.Enum.values() method. The fix is to avoid a ClassCastException by returning the bottom klass in the case of an object array klass, while printing out the details. I'm a bit confused as to what getFieldOrMethodKlassRefAt is supposed to be returning - should it really be instanceKlass? It's not at all clear to me that returning the array component type is the right thing to do. That aside a couple of minor nits: src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! k = (k.isObjArrayKlass())?((ObjArrayKlass)k).getBottomKlass():k; No () needed around k.isObjArrayKlass() Spaces needed around the ? and : operators test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java Copyright year should now be "2017, 2018," Thanks, David Tests run: The SA tests pass with Mach5 and jprt. Thanks, Jini.
Re: RFR: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes
Hi Jini, It looks good to me. Thanks, Serguei On 1/24/18 09:43, Jini George wrote: Hello, Requesting reviews for the issue: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes ID: https://bugs.openjdk.java.net/browse/JDK-8175384 Webrev: http://cr.openjdk.java.net/~jgeorge/8175384/webrev.01/ The issue was seen while printing out the details of the invokevirtual bytecode of the java.lang.Enum.values() method. The fix is to avoid a ClassCastException by returning the bottom klass in the case of an object array klass, while printing out the details. Tests run: The SA tests pass with Mach5 and jprt. Thanks, Jini.
RFR: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes
Hello, Requesting reviews for the issue: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes ID: https://bugs.openjdk.java.net/browse/JDK-8175384 Webrev: http://cr.openjdk.java.net/~jgeorge/8175384/webrev.01/ The issue was seen while printing out the details of the invokevirtual bytecode of the java.lang.Enum.values() method. The fix is to avoid a ClassCastException by returning the bottom klass in the case of an object array klass, while printing out the details. Tests run: The SA tests pass with Mach5 and jprt. Thanks, Jini.
Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties
Hi Harsha, Very nice to see progress on this! Before reviewing, the minimal command line to start up the default management server now becomes -Xmanagement:ssl=false,authenticate=false and if you use a property that doesn't exist, or that is mandatory, you will get an error message stating what is wrong? Could we reduce the command line further, so only a single property is needed: -Xmanagement:secure=false or perhaps: -Xmanagement:unsecure which would set ssl=false,authenticate=false, because that is what you want 99% of the time. Thanks Erik Hi, Please review the changes for above enhancement having webrev at, http://cr.openjdk.java.net/~hb/8187498/webrev.00/ Thanks Harsha
Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties
On 24/01/2018 11:18, Harsha Wardhana B wrote: Hi, Please review the changes for above enhancement having webrev at, http://cr.openjdk.java.net/~hb/8187498/webrev.00/ One of the guidelines in JEP 293 [1] is to not introduce new options with -X as a prefix. I think a related discussion point is whether it should be a java launcher or VM option. -Alan [1] http://openjdk.java.net/jeps/293
RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties
Hi, Please review the changes for above enhancement having webrev at, http://cr.openjdk.java.net/~hb/8187498/webrev.00/ Thanks Harsha
