Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties
Hi Mandy,Alan, Thanks for your inputs. If I keep it as launcher option, it may need to know JMX agent flags which may need to be extended in future. I would prefer making it a VM option. I will make the required changes and send out an updated webrev. -Harsha On Thursday 25 January 2018 09:31 PM, mandy chung wrote: Hi Harsha, JEP 293 [1] describes the guidelines for JDK command-line options. As Alan points out, new options should move away from -X prefix but use `--` GNU-style long form option. The guideline says: The use of |-X| as a prefix to indicate "non-standard" options will be discontinued for new options, although command-line help may continue to draw a distinction between more commonly used options and those for advanced use. You can consider `--management` as an alternative. Should this be a launcher option that converts it to the corresponding `-Dcom.sun.management.jmxremote.` rather than a VM option? Mandy [1] http://openjdk.java.net/jeps/293 On 1/24/18 11:21 PM, Harsha Wardhana B wrote: 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
PING: RFR: 8194249: SA: G1HeapRegionTable#getByAddress() returns incorrect HeapRegion
PING: Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.01/ This webrev has been reviewed by Jini. I need a Reviewer and sponsor. Yasumasa On 2018/01/22 19:53, Yasumasa Suenaga wrote: Hi Jini, Thank you for your review! I will update the copyright year in this changeset. I'm waiting for Reviewer and sponsor. Yasumasa On 2018/01/22 13:14, Jini George wrote: Hi Yasumasa, The changes look good to me. Please do update the copyright year to 2018. Thanks! Jini (Not a Reviewer). On 12/31/2017 10:03 AM, Yasumasa Suenaga wrote: Hi David, How did you submit to mach5 ??? I'm using Submit Repo for testing: https://wiki.openjdk.java.net/display/Build/Submit+Repo Anyway the failure is with: Thanks! I've fixed them in new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.01/ This webrev has passed Mach 5 tier 1 tests in Submit Repo: http://java.se.oracle.com:10065/mdash/jobs/mach5-one-ysuenaga-JDK-8194249-20171231-0202-8291 Yasumasa On 2017/12/30 10:31, David Holmes wrote: Hi Yasumasa, Not a review ... On 29/12/2017 11:16 PM, Yasumasa Suenaga wrote: Hi all, G1HeapRegionTable#getByAddress() returns incorrect HeapRegion which contains incorrect address. We can see it in Stack Memory window on HSDB. Some oop addresses are shown as Free Region (attached image). G1HeapRegion#getByAddress() should create HeapRegion instance from the address in _biased_base array. I uploaded webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8194249/webrev.00/ I've tested this change with test/hotspot/jtreg/serviceability/sa, it works fine. But I received some failure from Mach 5. I also tested this change via submit repos. http://java.se.oracle.com:10065/mdash/jobs/mach5-one-ysuenaga-JDK-8194249-20171228-0605-8272 I cannot access this URL. Could you share the result? How did you submit to mach5 ??? Anyway the failure is with: test/hotspot/jtreg/serviceability/sa/TestG1HeapRegion.java On linux and OS X: stderr: [Exception in thread "main" java.lang.NullPointerException at TestG1HeapRegion$G1HeapRegionTestClosure.doSpace(TestG1HeapRegion.java:70) at jdk.hotspot.agent/sun.jvm.hotspot.gc.g1.G1CollectedHeap.heapRegionIterate(G1CollectedHeap.java:121) at TestG1HeapRegion.scanHeapRegion(TestG1HeapRegion.java:81) at TestG1HeapRegion.main(TestG1HeapRegion.java:129) On Solaris sparcv9: stderr: [Exception in thread "main" java.lang.RuntimeException: Address of HeapRegion does not match.: expected 0x0007afb0 to equal 0x0007afc0 at jdk.test.lib.Asserts.fail(Asserts.java:594) at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) at TestG1HeapRegion$G1HeapRegionTestClosure.doSpace(TestG1HeapRegion.java:70) at jdk.hotspot.agent/sun.jvm.hotspot.gc.g1.G1CollectedHeap.heapRegionIterate(G1CollectedHeap.java:121) at TestG1HeapRegion.scanHeapRegion(TestG1HeapRegion.java:81) at TestG1HeapRegion.main(TestG1HeapRegion.java:129) ] David - Also I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa
