Re: RFR : JDK-8044122 MBean access to the PID

s the attributes of a vm.  Perhaps MXBeanInteropTest1.java I will make changes as suggested. Roger On 10/10/2017 1:20 PM, mandy chung wrote: On 10/10/17 4:47 AM, Ujwal Vangapally wrote: Kindly review the changes made. https://bugs.openjdk.java.net/browse/JDK-8044122 webrev : http://cr.o

Re: RFR : JDK-8044122 MBean access to the PID

using the MBean, is that intentional? (Besides it is already available as the JMVID) Gruss Bernd -- http://bernd.eckenfels.net *From:* serviceability-dev on behalf of mandy chung *Sent:* Friday, October 20, 2017 4:42

Re: RFR : JDK-8044122 MBean access to the PID

t ensure not leaking ProcessHandle. Mandy Gruss Bernd -- http://bernd.eckenfels.net *From:* serviceability-dev on behalf of mandy chung *Sent:* Tuesday, October 24, 2017 7:20:27 PM *To:* serviceability-dev@openjdk.java.net *Sub

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

oved the link to the documentation. At least this should point to JDK 9 docs rather than JDK 7. Mandy -Harsha On Thursday 12 October 2017 09:22 PM, Harsha Wardhana B wrote: Sure. I will send out a modified webrev soon. -Harsha On Thursday 12 October 2017 08:52 PM, mandy chung wrote: On 10/1

Re: [Proposal/Question] Provide mechanism to monitor thread states more efficiently

serviceability-dev is the mailing list for discussing java.lang.management APIs. Getting the stack trace is expensive. ThreadMXBean.getThreadInfos(ids) does not get the stack trace and locks information and is less expensive. A typical lightweight monitoring application does BCI and call Thr

Re: RFR : JDK-8044122 MBean access to the PID

PM, mandy chung wrote: The permission check should be done separately, if needed. Otherwise, the frames in the stack when this method is called must have the security permission granted. Mandy On 10/23/17 1:00 PM, Bernd Eckenfels wrote: Hello, When running this privileged it means one can

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

http://cr.openjdk.java.net/~hb/5016517/webrev.05/ Looks okay in general.   Daniel is closer to the FileLoginModule implementation that I will count on his review. FileLoginModule.java 225 if(hashPwdMgr == null) { 226 hashPwdMgr = new HashedPasswordManager(passwordFile, hashPasswords); 227 }

Re: RFR : JDK-8044122 MBean access to the PID

On 10/30/17 9:50 AM, Ujwal Vangapally wrote: Hi Mandy, yes, this makes it more clear. kindly take a look at new webrev. webrev : http://cr.openjdk.java.net/~uvangapally/webrev/2017/8044122/webrev.04/ Looks good. thanks Mandy

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

On 10/31/17 8:55 AM, Harsha Wardhana B wrote: Hi Mandy, Below is the new webrev incorporating below review comments. http://cr.openjdk.java.net/~hb/5016517/webrev.06/ Looks okay in general except this: 286 // Check if header needs to be inserted 287 if (sbuf.indexOf("# T

Re: RFR : JDK-8044122 MBean access to the PID

wrote: Thanks for the Review Roger, Mandy. Ujwal. On 10/31/2017 4:09 AM, mandy chung wrote: On 10/30/17 9:50 AM, Ujwal Vangapally wrote: Hi Mandy, yes, this makes it more clear. kindly take a look at new webrev. webrev : http://cr.openjdk.java.net/~uvangapally/webrev/2017/8044122/webrev

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

On 11/7/17 8:26 AM, Harsha Wardhana B wrote: Hi, Please find below the webrev addressing Daniel and Mandy's comments. http://cr.openjdk.java.net/~hb/5016517/webrev.07/ Can you summarize the change? I thought we agree to only replace the clear passwords with the hashes and not to alter any

Re: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent

On 11/7/17 9:04 AM, Harsha Wardhana B wrote: Hi Mandy, To summarize the changes, 1. The header will not contain the file modification timestamp. Instead when the password file is modified, a debug log will be printed. The log will contain the timestamp. 2. The password file is now protec

Re: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact"

On 11/9/17 2:40 AM, Ujwal Vangapally wrote: Thanks for the Review Daniel, made changes as suggested. webrev : http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.03/ Looks good. Minor comment: in the new test, it can fold some of the println together e.g. line 81 can be m

Re: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact"

On 11/9/17 9:03 AM, Ujwal Vangapally wrote: Thanks for the review Mandy, kindly check if this version is better. webrev : http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.04/ Looks okay. Mandy

Re: RFR: 8191564: Refactor GC related servicability code into GC specific subclasses

On 11/30/17 6:22 AM, Roman Kennke wrote: Hi David, I added the tag as you proposed: Differential: http://cr.openjdk.java.net/~rkennke/8191564/webrev.08.diff/ Full: http://cr.openjdk.java.net/~rkennke/8191564/webrev.08/ This looks really good.  This version looks much better than an early

Re: RFR: 8191564: Refactor GC related servicability code into GC specific subclasses

On 11/30/17 10:26 AM, Roman Kennke wrote: Hi Mandy, thanks for reviewing! I think Erik Ö. already pushed it for me. A minor comment that GCMemoryManager could take an enum to indicate the type of this  GC action (major vs minor).   This can be a future cleanup. This may be overly restrict

Re: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code [internal]

On 12/11/17 2:31 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. This is a spec change.  Is

Re: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code [internal]

orporating the review comment. Regards, Shafi *From:*mandy chung *Sent:* Tuesday, December 12, 2017 2:35 AM *To:* Shafi Ahmad *Cc:* serviceability-dev@openjdk.java.net *Subject:* Re: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code [internal] On 12/11/17

Re: [10] RFR for JDK-8170299: Debugger does not stop inside the low memory notifications code [internal]

On 12/13/17 2:23 AM, Shafi Ahmad wrote: Thank you Mandy and David for review comments. Please find updated webrev: http://cr.openjdk.java.net/~shshahma/8170299/webrev.03/ I have modify the code to use Emitter class rather than Br

Re: [8u] RFR(S) 8059036: Implement Diagnostic Commands for heap and finalizerinfo

On 12/14/17 9:42 PM, David Buck wrote: Hi! May I please get a review of the following very simple backport of this serviceability improvement to JDK 8? : JDK 8 backport webrevs for review: http://cr.openjdk.java.net/~dbuck/8059036.0_jdk8/ This patch looks okay to me. Mandy

Re: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers

Hi Bob, I think the new methods in VMSupport and probablywith VMSupport.getVMTemporaryDirectory should belong to jdk.internal.jvmstat as they are specific for jvmstat and attach API to use. W.r.t VMSupportImpl, the implementation is the same for all platforms except Linux.  One option is to

Re: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers

On 1/17/18 11:08 AM, Bob Vandette wrote: I put these new methods in VMSupport since this was the class containg the getVMTemporaryDirectory and the intention of this class was document as: /* * Support class used by JVMTI and VM attach mechanism. */ class VMSupport { I looked at the hist

Re: RFR: 8193710 - jcmd -l and jps commands do not list Java processes running in Docker containers

On 1/22/18 9:20 AM, Bob Vandette wrote: : Webrev: http://cr.openjdk.java.net/~bobv/8193710/webrev.02/ Thanks for the update.  Looks good to me. It would be good to add a comment in PlatformSupport::getInstance to explain that PlatformSupport provides the default implementation that can b

Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

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

Re: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results

Hi Erik, The proposal you outline below is reasonable. The API was designed to allow any number of memory pools managed by a memory manager that can represent different phases of a garbage collector or other resource manager to expose various metrics. How G1 exposes these monitoring metrics is

Re: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results

On 1/25/18 1:04 PM, Hohensee, Paul wrote: The JMX API spec doesn’t specify what the memory pool or garbage > collector names are, but the current names are de-facto part of the > API, so if we change the existing ones, imo a CSR should be filed. The names are implementation details but I ca

Re: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results

  Are you seeing issue/bug with the sum result? Mandy That said, imo there will always be a demand for the ability to get collector and memory pool specific details, so I don’t see a way to get around providing named entities. Paul *From: *mandy chung *Organization: *Oracle Corporation *Dat

Re: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results

On 1/29/18 10:35 AM, mandy chung wrote: Thanks for the reply Paul.   Try to understand a little more on the specific from gc-specific memory pool you depend on. On 1/29/18 8:27 AM, Hohensee, Paul wrote: A name change would affect Amazon’s heap monitoring, and thus I expect it would affect

Re: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results

.01/ <http://cr.openjdk.java.net/%7Ephh/8195115/webrev.hs.01/> Waiting on the submit repo to come back with a result on it. Thanks, Paul *From: *mandy chung *Organization: *Oracle Corporation *Date: *Monday, January 29, 2018 at 10:52 AM *To: *"Hohensee, Paul" , Erik Helin , D

Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

On 2/7/18 1:19 AM, Harsha Wardhana B wrote: --start-management-agent will not be recognized in the current format and hence will not default to --start-management-agent=local=true. `--start-local-management-server` is one option as Alan suggests. Another option is to make `--start-management-a

Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

On 2/13/18 1:30 AM, Harsha Wardhana B wrote: Hi, Please find below the revised webrev. http://cr.openjdk.java.net/~hb/8187498/webrev.02/ On Friday 09 February 2018 05:07 AM, mandy chung wrote: On 2/7/18 1:19 AM, Harsha Wardhana B wrote: > > --start-management-agent will not be reco

Re: RFR: 8041626: [Event Request] Shutdown reason

Hi Robin, Do you want a shutdown event for every call to Runtime::exit regardless where it is in the shutdown sequence?  or do you expect to get an event of the first thread calling JVM_Halt?  or the first thread starting the shutdown sequence but it may not be the thread halting? Mandy On

Re: RFR JDK-8198253: ThreadInfo.from(CompositeData) assigning fields incorrectly in JDK 9

ption should be thrown. Does this help? Mandy On 2/15/18 4:46 PM, Jeremy Manson wrote: Hi folks, Been a long time!  I'd like someone to do a code review. This is in code I wrote a few years ago, and got wrong.  At the time, David Holmes, Staffan Larsen, and Mandy Chung reviewed it.  It does

Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

The code review and CSR review can be in parallel. For this case, I agree with Kumar to have CSR written that would help the code review. Please specify the behavior and its relationship with jcmd and other relevant diagnosability tools. On 2/20/18 6:41 AM, Kumar Srinivasan wrote: What is the

Re: RFR JDK-8198253: ThreadInfo.from(CompositeData) assigning fields incorrectly in JDK 9

01/ <http://cr.openjdk.java.net/%7Ejmanson/8198253/webrev.01/> On Fri, Feb 16, 2018 at 6:20 PM, mandy chung <mailto:mandy.ch...@oracle.com>> wrote: Hi Jeremy, lockedMonitors and lockedSynchronizers attribute are not optional if that's the issue you try to resolve. I thi

Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

On 2/20/18 9:55 PM, Harsha Wardhana B wrote: We cannot get rid of specifying options via -D. We have plenty of -D flags but very few have short-hand alternative via --start-management-agent. If management properties are specified by --start-management-agent, the options specified by -D are

Re: RFR JDK-8198253: ThreadInfo.from(CompositeData) assigning fields incorrectly in JDK 9

instead.  I will take any pass on the spec and how it can tie with @since in the getter methods. I will look at it later today. Mandy Jeremy On Tue, Feb 20, 2018 at 6:41 PM, mandy chung <mailto:mandy.ch...@oracle.com>> wrote: Hi Jeremy, Another approach is to

Re: Thread Native ID Access

I'm not comfortable for ThreadInfo to expose the implementation details.  What should we specify w.r.t. Java Thread mapping to native thread which is platform dependent.  Also how does it relate to the future fibers [1]? Another alternative is for JDK specific diagnostic tools to do that mapp

Re: Thread Native ID Access

e to do is not > to cache it in the Thread object. You wouldn't want to do that > anyway, because it would be a waste of space for something that's > only needed occasionally. > > Is there another way of doing the right thing here? > > Jeremy > > > >

Re: RFR JDK-8198253: ThreadInfo.from(CompositeData) assigning fields incorrectly in JDK 9

Hi Jeremy, I have revised the spec of ThreadInfo::from to include "since" column: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198253/api/java/lang/management/ThreadInfo.html#from(javax.management.openmbean.CompositeData) I caught a few other issues like mix-n-match older version of Sta

Re: RFR JDK-8198253: ThreadInfo.from(CompositeData) assigning fields incorrectly in JDK 9

Webrev at: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198253/webrev.01 This patch updates the spec to clarify what attributes are required since which release. There is a spec bug that "classLoaderName" added in JDK 9 is missing in the CompositeData for StackTraceElement but the impleme

Re: RFR JDK-8198253: ThreadInfo.from(CompositeData) assigning fields incorrectly in JDK 9

a comment when calling StackTraceElementCompositeData.v5CompositeType() to say that nothing changed in StackTraceElementCompositeData between 6 and 5. Will fix this.   I will file a CSR for you to review. thanks Mandy best regards, -- daniel On 24/02/2018 00:50, mandy chung wrote: Webrev at: http

Re: RFR JDK-8198253: ThreadInfo.from(CompositeData) assigning fields incorrectly in JDK 9

nd send another webrev.  I am tempted to improve and provide an automated way for the versioning support. Mandy On Fri, Feb 23, 2018 at 4:50 PM, mandy chung <mailto:mandy.ch...@oracle.com>> wrote: Webrev at: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198253/webrev.01

Re: RFR JDK-8198253: ThreadInfo.from(CompositeData) assigning fields incorrectly in JDK 9

CSR: https://bugs.openjdk.java.net/browse/JDK-8198732 Can you please review? Mandy On 2/23/18 4:50 PM, mandy chung wrote: Webrev at: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198253/webrev.01 This patch updates the spec to clarify what attributes are required since which release

Re: RFR JDK-8198253: ThreadInfo.from(CompositeData) assigning fields incorrectly in JDK 9

Good point, Jeremy. I notice some strange-ness when I wrote it but wasn't able to pin point the error. Daniel also suggests to clarify MonitorInfo as well. Does this version look better? * Returns a {@code ThreadInfo} object represented by the * given {@code CompositeData}. *

Re: RFR JDK-8198253: ThreadInfo.from(CompositeData) assigning fields incorrectly in JDK 9

/8198253/api/java/lang/management/ Webrev: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198253/webrev.02/ Mandy On 2/27/18 10:55 AM, mandy chung wrote: Good point, Jeremy. I notice some strange-ness when I wrote it but wasn't able to pin point the error. Daniel also suggests to cl

Re: RFR JDK-8198253: ThreadInfo.from(CompositeData) assigning fields incorrectly in JDK 9

On 2/27/18 9:44 AM, Jeremy Manson wrote: On Mon, Feb 26, 2018 at 4:53 PM, mandy chung <mailto:mandy.ch...@oracle.com>> wrote: On 2/26/18 4:23 PM, Jeremy Manson wrote: Hi Mandy, Thanks for taking this on!  I'm happy to see that you are happy to do clea

Re: RFR JDK-8198253: ThreadInfo.from(CompositeData) assigning fields incorrectly in JDK 9

On 2/27/18 10:05 PM, Jeremy Manson wrote: Yup, that's better.  I'd probably say "The same rule" instead of "Same rule". Thanks. Will fix it before I push. Mandy Jeremy On Tue, Feb 27, 2018 at 10:55 AM, mandy chung <mailto:mandy.ch...@oracle.com>&

Re: RFR JDK-8198253: ThreadInfo.from(CompositeData) assigning fields incorrectly in JDK 9

, or is a CompositeData representing a StackTraceElement of version N.``` What do you think? best regards, -- danie On 27/02/2018 20:31, mandy chung wrote: I made further edits to the javadoc and I am happy with this version (move out the attributes for StackTraceElement as a separate t

Re: RFR : JDK-8071367 - JMX: Remove SNMP support

On 3/7/18 11:46 PM, Alan Bateman wrote: On 08/03/2018 07:27, Amit Sapre wrote: Hello, Please review the changes for removing SNMP support. Bug ID : https://bugs.openjdk.java.net/browse/JDK-8071367 Webrev : http://cr.openjdk.java.net/~asapre/webrev/2018/JDK-8071367/webrev.00

Re: RFR : JDK-8071367 - JMX: Remove SNMP support

On 3/22/18 6:12 AM, Alan Bateman wrote: On 22/03/2018 10:03, Amit Sapre wrote: Thanks Alan and Mandy for inputs. This webrev : http://cr.openjdk.java.net/~asapre/webrev/2018/JDK-8071367/webrev.01/ addresses your c

Re: RFR : JDK-8071367 - JMX: Remove SNMP support

On 3/22/18 5:36 PM, Martin Buchholz wrote: On Wed, Mar 7, 2018 at 11:27 PM, Amit Sapre > wrote: Bug ID : https://bugs.openjdk.java.net/browse/JDK-8071367 Is there a reason this bug is not visible?

Re: RFR : JDK-8071367 - JMX: Remove SNMP support

On 3/23/18 3:43 AM, Amit Sapre wrote: Thanks all for the inputs. This webrev addresses the inputs : http://cr.openjdk.java.net/~asapre/webrev/2018/JDK-8071367/webrev.02/ Looks good. Mandy

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

This is a very good change and no more mapfile to maintain!! Please do file JBS issues for the component teams to clean up their exports. Mandy On 3/23/18 7:30 AM, Erik Joelsson wrote: I have looked at the build changes and they look good. Will you file followups for each component team to

Re: RFR: 8187490: HotSpotRuntimeMBean should be moved to Graal management module

On 4/13/18 2:24 AM, Doug Simon wrote: Please review this change that removes the existing Graal service provider for hooking into the Platform MBean Server and makes jdk.internal.vm.compiler.management an upgradeable module. Please refer to https://bugs.openjdk.java.net/browse/JDK-8187490?f

Review Request JDK-8200559: Java agents doing instrumentation need a means to define auxiliary classes

Background: Java agents support both load time and dynamic instrumentation. At load time, the agent's ClassFileTransformer is invoked to transform class bytes.  There is no Class objects at this time.  Dynamic instrumentation is when redefineClasses or retransformClasses is used to redefine a

Re: Review Request JDK-8200559: Java agents doing instrumentation need a means to define auxiliary classes

a agent can be started by -javaagent option at startup or be put on the classpath such that the java agent can be dynamically loaded via the attach mechansim. Mandy Thanks, David On 15/04/2018 4:23 PM, mandy chung wrote: Background: Java agents support both load time and dynamic instrumentation. A

Re: Review Request JDK-8200559: Java agents doing instrumentation need a means to define auxiliary classes

case! Best regards, Rafael 2018-04-15 8:23 GMT+02:00 mandy chung <mailto:mandy.ch...@oracle.com>>: Background: Java agents support both load time and dynamic instrumentation.   At load time, the agent's ClassFileTransformer is invoked to transform class bytes

Re: RFR: 81820709 - Container Awareness JEP

On 4/3/18 10:09 PM, Bob Vandette wrote: WEBREV: http://cr.openjdk.java.net/~bobv/8182070/v01/webrev I reviewed the webrev and look okay in general. I will look through the javadoc next. Metrics.java 37 * 1. All processes, including the current process within a container. includes

Re: Review Request JDK-8200559: Java agents doing instrumentation need a means to define auxiliary classes

not help me much, unfortunately. Also, I could not resolve this lookup as the class in question is not necessarily loaded at this point. Best regards, Rafael 2018-04-17 9:28 GMT+02:00 mandy chung <mailto:mandy.ch...@oracle.com>>: Hi Rafael, I see that mocking/proxying/testi

Re: RFR: 8196325: GarbageCollectionNotificationInfo has same information for before and after

Hi Sangheon, On 4/18/18 12:41 PM, sangheon.kim wrote: CR: https://bugs.openjdk.java.net/browse/JDK-8196325 webrev: http://cr.openjdk.java.net/~sangheki/8196325/webrev.0/ This is indeed a regression.  GcInfoBuilder depends on the order of the pool name array. The change looks okay.  I woul

Re: RFR: 8196325: GarbageCollectionNotificationInfo has same information for before and after

On 4/19/18 4:52 AM, sangheon.kim wrote: Webrev: http://cr.openjdk.java.net/~sangheki/8196325/webrev.1 (full) http://cr.openjdk.java.net/~sangheki/8196325/webrev.1_to_0/ (inc) Looks good. Mandy

Re: Review Request JDK-8200559: Java agents doing instrumentation need a means to define auxiliary classes

https://bugs.openjdk.java.net/browse/JDK-8201784 This is the correct JBS issue (Sorry I cut-n-paste the wrong link). Mandy On 4/18/18 3:46 PM, mandy chung wrote: Hi Rafael, I think it's best to separate the testing requirement from java agents doing instrumentation that may r

Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

On 4/23/18 1:20 PM, Harsha Wardhana B wrote: Hi All, After internal discussions, many of the concerns below were addressed and final spec is published at, https://bugs.openjdk.java.net/browse/JDK-8199584 Below is the implementation of the above spec. http://cr.openjdk.java.net/~hb/8187498

Re: RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

On 4/27/18 3:43 PM, Harsha Wardhana B wrote: On Thursday 26 April 2018 09:09 PM, mandy chung wrote: src/java.base/share/classes/sun/launcher/resources/launcher.properties 112 \ --start-management-agent option=value[:option=value:]\n\ option and value should be and to represent user

Re: [svc] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control

On 5/14/18 5:52 PM, David Holmes wrote: This review is being spread across four groups: langtools, core-libs, hotspot and serviceability. This is the specific review thread for serviceability - webrev: http://cr.openjdk.java.net/~dholmes/8010319-JEP181/webrev.serviceability.v1/ Just a pa

Re: RFR (S): 8203500: Fix broken links to Specification in "specs" directory

The fix looks fine. Mandy On 5/21/18 3:54 PM, Iris Clark wrote: Hi. Please review this small change to fix a few broken links to Specification in the “specs” directory from the JavaDoc API. The incorrect references either not include "{@docRoot}" or include the non-existent "{@docRootParen

Re: RFR: 81820709 - Container Awareness JEP

On 5/23/18 7:39 AM, Bob Vandette wrote: Should this be an instance method? like cpuacct.getLongValue("cpuacct.usage”); > I did it this way in order to provide a centralized place to check for missing subsystems. The getLongValue method does the checking for all subsystems 137 if

Re: RFR: 81820709 - Container Awareness JEP

On 5/24/18 12:31 PM, Bob Vandette wrote: Yes, I saw that but wasn’t sure how new text that’s added to the launcher.properties file would get localized. Is there a process for getting this done? No action should be needed. Changes to .properties files are tracked and localized version will be

Re: Review Request JDK-8200559: Java agents doing instrumentation need a means to define auxiliary classes

Thanks for considering my suggestion and your feedback! Best regards, Rafael 2018-04-15 8:23 GMT+02:00 mandy chung <mailto:mandy.ch...@oracle.com>>: Background: Java agents support both load time and dynamic instrumentation. At load time, the agent's ClassFileTr

Re: RFR: 8204173: Lower the minimum number of heap memory pools in MemoryTest.java

Hi Stefan, This change looks okay. Can you add a comment to describe the expected memory pools for ZGC so that it explains why the min number of heap memory pools is 1. I think this test and possibly other memory pool tests should be re-examined and determine what proper verification should

Re: RFR: 8204170: MXBeanException.java assumes the existence of a pool that doesn't support usage threshold

Hi Stefan, I think a better fix is to find another operation that will throw an exception. ThreadMXBean::getThreadInfo throws IAE and it can be a candidate. Mandy On 5/31/18 6:38 AM, Stefan Karlsson wrote: Hi all, Please review this patch to deal with the case when all available MemoryPo

Re: RFR: 8204170: MXBeanException.java assumes the existence of a pool that doesn't support usage threshold

On 5/31/18 10:01 AM, Stefan Karlsson wrote: Hi Mandy, On 2018-05-31 18:44, mandy chung wrote: Hi Stefan, I think a better fix is to find another operation that will throw an exception.  ThreadMXBean::getThreadInfo throws IAE and it can be a candidate. Thanks for taking a look at this

Re: RFR: 8204173: Lower the minimum number of heap memory pools in MemoryTest.java

On 5/31/18 10:36 AM, Stefan Karlsson wrote: Hi Mandy, On 2018-05-31 18:19, mandy chung wrote: Hi Stefan, This change looks okay.  Can you add a comment to describe the expected memory pools for ZGC so that it explains why the min number of heap memory pools is 1. I think this test and

Re: RFR: 8204173: Lower the minimum number of heap memory pools in MemoryTest.java

On 5/31/18 11:14 AM, Stefan Karlsson wrote: Right. The ZGC patch has a @requires vm.gc != "Z" row in MemoryTest.java. Ah. This change is fine then. Mandy

Re: RFR: 8203357 Container Metrics

Hi Bob, On 5/30/18 12:45 PM, Bob Vandette wrote:> RFE: Container Metrics https://bugs.openjdk.java.net/browse/JDK-8203357 WEBREV: http://cr.openjdk.java.net/~bobv/8203357/webrev.00 Looks fine in general. It's good to have this internal API ready for JFR and other library code to use. I sk

Re: RFR: 8203357 Container Metrics

On 6/1/18 8:52 AM, Bob Vandette wrote: I filed a CSR for this a few days ago. > https://bugs.openjdk.java.net/browse/JDK-8204107 Typo: s/-XshowSetting/-XshowSettings In the specification section, you can include the new lines adding to java --extra-help output (that's the spec) and drop t

Re: Ping!! Re: RFR: 8203357 Container Metrics

On 6/11/18 10:12 PM, David Holmes wrote: For the Java code ... methods that return arrays should return zero-length arrays when something is not available rather than null. All methods do return zero length arrays except I missed the getPerCpuUsage.  I’ll fix that one and correct the javado

Re: Ping!! Re: RFR: 8203357 Container Metrics

On 6/11/18 10:43 PM, David Holmes wrote: On 12/06/2018 3:31 PM, mandy chung wrote: On 6/11/18 10:12 PM, David Holmes wrote: For the Java code ... methods that return arrays should return zero-length arrays when something is not available rather than null. All methods do return zero length

Re: RFR (S): 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results

Looks fine to me. Mandy On 6/16/18 12:00 PM, Hohensee, Paul wrote: Thanks for the re-review, Erik. New webrev with your fixes: http://cr.openjdk.java.net/~phh/8195115/webrev.04/ Need another reviewer, please. Thanks, Paul

Re: RFR : JDK-8204661 - Show error 'Port already in use' in HashedPasswordFileTest.java

On 6/20/18 1:14 AM, Harsha Wardhana B wrote: Hi, Please find the fix below for the bug JDK-8204661 : Show error 'Port already in use' in HashedPasswordFileTest.java having webrev at, http://cr.openjdk.java.net/~hb/8204661/webrev.00/ The problem root-cause is discussed in the comments se

Re: RFR : JDK-8192953 - sun/management/jmxremote/bootstrap/*.sh tests fail with error : revokeall.exe: Permission denied

I would suggest to take the time and replace it with java.nio.file API and remove revokeall.exe sooner rather than later. Mandy On 6/26/18 7:09 AM, Harsha Wardhana B wrote: Hi All, Please find the fix for the bug, https://bugs.openjdk.java.net/browse/JDK-8192953 having webrev at, http://cr

Re: RFR : JDK-8192953 - sun/management/jmxremote/bootstrap/*.sh tests fail with error : revokeall.exe: Permission denied

27;t you think pushing this fix is better than quarantining the tests? Harsha On Wednesday 27 June 2018 08:50 PM, mandy chung wrote: I would suggest to take the time and replace it with java.nio.file API and remove revokeall.exe sooner rather than later. Mandy On 6/26/18 7:09 AM, Harsha Wardha

Re: RFR : JDK-8192953 - sun/management/jmxremote/bootstrap/*.sh tests fail with error : revokeall.exe: Permission denied

ss pushing this fix is the right thing to do now. Harsha On Wednesday 27 June 2018 09:52 PM, mandy chung wrote: I think the right thing to do is to bite the bullet and fix the test properly. In addition, this fix does not seem to work if there is no "open" directory. Mandy On 6/2

Re: Review Request JDK-8200559: Java agents doing instrumentation need a means to define auxiliary classes

ks for the information, best regards, Rafael mandy chung mailto:mandy.ch...@oracle.com>> schrieb am So., 15. Apr. 2018, 08:23: Background: Java agents support both load time and dynamic instrumentation. At load time, the agent's ClassFileTransformer is invoked to transform cl

Re: committed > max in MemoryMXBean#getHeapMemoryUsage()

It's indeed strange that no one reports this issue. I created: https://bugs.openjdk.java.net/browse/JDK-8207200 Mandy On 7/12/18 6:35 AM, Daniel Mitterdorfer wrote: Hi, while working on a change in Elasticsearch, I discovered an interesting situation related to the implementation of jmm_ge

Re: committed > max in MemoryMXBean#getHeapMemoryUsage()

Great! Thanks Erik. Mandy On 7/13/18 1:34 AM, Erik Helin wrote: On 07/12/2018 10:34 PM, mandy chung wrote: It's indeed strange that no one reports this issue.  I created:     https://bugs.openjdk.java.net/browse/JDK-8207200 Mandy: I moved the bug over to hotspot/gc, this is much more l

Re: RFR: 8206456 - [TESTBUG] docker jtreg tests fail on systems without cpuset.effective_cpus / cpuset.effective_mem

On 7/17/18 7:00 AM, Bob Vandette wrote: Please review this fix which eliminates some docker/cgroup test failures when running on older Linux kernels with missing cgroup metric files. BUGS: https://bugs.openjdk.java.net/browse/JDK-8206456 WEBREV: http://cr.openjdk.java.net/~bobv/8206456/webr

Re: RFR : JDK-8170299 - Debugger does not stop inside the low memory notifications code

On 8/24/18 7:06 AM, Daniel Fuchs wrote: Hi Harsha, On 23/08/2018 17:35, Daniel Fuchs wrote: So all in all - maybe this is worth fixing but better early in the release than late. I also wonder whether such a behavior change should deserve a release note (or a switch to revert to the old behavi

Re: RFR (S) 8210775: JVM TI Spec missing copyright

On 9/14/18 3:01 PM, Iris Clark wrote: Hi. Please review the following changes to add a copyright line to the end of the generated jvmti.html file: 8210775: JVM TI Spec missing copyright bug: https://bugs.openjdk.java.net/browse/JDK-8210775 webrev: http://cr.openjdk.java.net/

Re: RFR (S) 8048215: [TESTBUG] java/lang/management/ManagementFactory/ThreadMXBeanProxy.java Expected non-null LockInfo

On 10/14/18 9:23 PM, David Holmes wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8048215 webrev: http://cr.openjdk.java.net/~dholmes/8048215/webrev/ Simple race condition in the test. The main thread does checks that are only valid once the target thread has called o.wait() but there's

Re: Probable bug within sun.management.StackTraceElementCompositeData

Hi Sven, It's indeed a bug in the order of names and values when constructing CompositeData for StackTraceElement.  I created https://bugs.openjdk.java.net/browse/JDK-8212197 for this issue. Mandy On 10/14/18 3:52 PM, David Holmes wrote: Hi Sven, Moving to serviceability-dev mailing list.

RFR JDK-8212197: OpenDataException thrown when constructing CompositeData for StackTraceElement

Webrev: http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8212197/webrev.00/ This simple patch fixes the issue Sven reports [1] where the order of names and values when creating CompositeData for StackTraceElement is mismatched.  I keep names/values in the order of the attributes defined from old

Re: Probable bug within sun.management.StackTraceElementCompositeData

I plan to request the backport to 11u. Mandy On 10/16/18 11:16 PM, Sven Reimers wrote: Hi, thanks for fixing. What about a backport to 11? Thanks -Sven Mandy Chung mailto:mandy.ch...@oracle.com>> schrieb am Mo., 15. Okt. 2018, 19:50: Hi Sven, It's indeed a bug in t

Re: Probable bug within sun.management.StackTraceElementCompositeData

:51 AM, Mandy Chung wrote: Hi Sven, It's indeed a bug in the order of names and values when constructing CompositeData for StackTraceElement.  I created https://bugs.openjdk.java.net/browse/JDK-8212197 for this issue. Mandy On 10/14/18 3:52 PM, David Holmes wrote: Hi Sven, Movi

Re: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

On 10/16/18 7:33 PM, David Holmes wrote: Hi Dean, Thanks for tackling this. I'm still struggling to fully grasp why we need both the PerfCounters and the regular counters. I get that we have to decrement the live counts before ensure_join() has allowed Thread.join() to return, to ensure th

Re: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

On 10/17/18 2:13 PM, dean.l...@oracle.com wrote: On 10/17/18 1:41 PM, Mandy Chung wrote: On 10/16/18 7:33 PM, David Holmes wrote: Hi Dean, Thanks for tackling this. I'm still struggling to fully grasp why we need both the PerfCounters and the regular counters. I get that we ha

Re: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

On 10/17/18 3:18 PM, dean.l...@oracle.com wrote: New webrevs, full and incremental: http://cr.openjdk.java.net/~dlong/8021335/webrev.6/ http://cr.openjdk.java.net/~dlong/8021335/webrev.6.diff/ I like it better without all the asserts too. Looks good to me. Mandy

Re: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count

On 10/18/18 12:27 AM, David Holmes wrote: Hi Dean, On 18/10/2018 2:06 PM, dean.l...@oracle.com wrote: You're right, I missed that.  I think the right thing to do is call current_thread_exiting while holding the Threads_lock. Then we can get rid of the parallel atomic counters.  So, here's o

Re: OpenDataException thrown when constructing CompositeData for ThreadInfo

Hi Sven, Do you have a sample ThreadInfo to reproduce this issue?   That will be helpful.  JMX monitoring is not impacted as far as I can tell. NB profiling is using this internal API `sun.management.ThreadInfoCompositeData::toCompositeData` which may be unused since JMX supports MXBean. Ma

  1   2   3   4   5   6   7   8   >