RE: RFR[9u-dev]: 8150900: Implement diagnostic_pd

ahead with this fix and need not a new review. I have tested this change and its working fine as before.   Webrev link: http://cr.openjdk.java.net/~csahu/8150900/webrev.01/   Regards, Cheleswer   From: Cheleswer Sahu Sent: Wednesday, May 11, 2016 2:29 PM To: Christian Thalinger Cc: Kevin

RE: RFR[9u-dev]: 8150900: Implement diagnostic_pd

Thanks Christian for review. I will correct the alignment.   Regards, Cheleswer   From: Christian Thalinger Sent: Wednesday, May 11, 2016 1:00 AM To: Cheleswer Sahu Cc: Kevin Walls; Gerard Ziemski; serviceability-dev@openjdk.java.net; hotspot-runtime-...@openjdk.java.net Subject: Re: RFR[9u

RE: RFR[9u-dev]: 8150900: Implement diagnostic_pd

Hi, I need one reviewer (R) to review these changes before pushing in JDK9. Can somebody please review the changes. Regards, Cheleswer > -Original Message- > From: Kevin Walls > Sent: Friday, May 06, 2016 3:53 PM > To: Cheleswer Sahu; Gerard Ziemski > Cc: ser

RE: RFR[9u-dev]: 8150900: Implement diagnostic_pd

Hi Gerard, > -Original Message- > From: Gerard Ziemski > Sent: Monday, May 02, 2016 9:07 PM > To: Cheleswer Sahu > Cc: hotspot-runtime-...@openjdk.java.net; serviceability- > d...@openjdk.java.net > Subject: Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd > &g

RFR[9u-dev]: 8150900: Implement diagnostic_pd

Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8150900. Webrev Link: http://cr.openjdk.java.net/~csahu/8150900/webrev.00/ Enhancement Brief: A new variant of flag "diagnostic_pd" is implemented. All flags which are diagnostic in nature and platform de

RE: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails

Thanks Dmitry and Leonid for review. Thanks Dan for information, I will do the needful before pushing this fix. Regards, Cheleswer -Original Message- From: Daniel D. Daugherty Sent: Thursday, April 07, 2016 7:52 PM To: Dmitry Samersoff; Cheleswer Sahu; Leonid Mesnik; hotspot-runtime

RE: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails

link http://cr.openjdk.java.net/~csahu/8153319/webrev.01/ Regards, Cheleswer -Original Message- From: Leonid Mesnik Sent: Tuesday, April 05, 2016 7:00 PM To: Cheleswer Sahu; hotspot-runtime-...@openjdk.java.net; serviceability-dev@openjdk.java.net Subject: Re: RFR[9u-dev]: 8153319: new

RE: RFR[9u-dev]: 8054326: Confusing message in "Current rem set statistics"

Hi, This fix is waiting for review, can somebody please review this change. Regards, Cheleswer From: Cheleswer Sahu Sent: Friday, April 01, 2016 6:01 PM To: hotspot-runtime-...@openjdk.java.net; serviceability-dev@openjdk.java.net Cc: Mattis Castegren Subject: RFR[9u-dev]: 8054326

RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails

Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8153319. Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ Bug Brief: Test is failing on some platforms. Problem Identified: Newly created child thread (NamedThread) is finished its execution

RFR[9u-dev]: 8054326: Confusing message in "Current rem set statistics"

Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8054326. Webrev Link: http://cr.openjdk.java.net/~csahu/8054326/ Bug Brief: In output of remset statistics "Max" is printing as 0k, which is confusing for user. Problem Identified : "Max" value is rou

RE: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters

Thanks Dmitry, Kevin for review. Regards, Cheleswer -Original Message- From: Kevin Walls Sent: Friday, April 01, 2016 1:02 AM To: Dmitry Samersoff; Cheleswer Sahu; Mattis Castegren; David Holmes; Daniel Daugherty; hotspot-runtime-...@openjdk.java.net; serviceability-dev

RE: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters

Cheleswer -Original Message- From: Mattis Castegren Sent: Wednesday, March 30, 2016 10:42 PM To: Kevin Walls; David Holmes; Daniel Daugherty; Dmitry Samersoff; Cheleswer Sahu; hotspot-runtime-...@openjdk.java.net; serviceability-dev@openjdk.java.net Cc: Mattis Castegren Subject: RE:

RE: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters

Hi David, -Original Message- From: David Holmes Sent: Friday, March 18, 2016 2:42 PM To: Cheleswer Sahu; hotspot-runtime-...@openjdk.java.net; serviceability-dev@openjdk.java.net Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' na

RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters

Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8151442. Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/ Bug Brief: In jstack thread dumps , thread name greater than 1996 characters doesn't close quotation marks properly. Problem Identifi

RE: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters

Thanks Dmitry for review. I will file CR and let you know once done. Cheleswer -Original Message- From: Dmitry Samersoff Sent: Friday, March 18, 2016 2:35 PM To: Cheleswer Sahu; hotspot-runtime-...@openjdk.java.net; serviceability-dev@openjdk.java.net Subject: Re: RFR[9u-dev

RE: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly

-Original Message- From: David Holmes Sent: Monday, March 14, 2016 7:19 AM To: Cheleswer Sahu; Dmitry Dmitriev; Thomas Stüfe Cc: serviceability-dev@openjdk.java.net; hotspot-runtime-...@openjdk.java.net Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly

RE: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly

Thanks Dmitry and Thomas for reviews. After adding space I will  request for the push.   Regards, Cheleswer   From: Dmitry Dmitriev Sent: Friday, March 11, 2016 5:00 PM To: Cheleswer Sahu; Thomas Stüfe Cc: serviceability-dev@openjdk.java.net; hotspot-runtime-...@openjdk.java.net Subject: Re

RE: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly

@gmail.com] Sent: Thursday, March 10, 2016 7:39 PM To: Dmitry Dmitriev Cc: Cheleswer Sahu; serviceability-dev@openjdk.java.net; hotspot-runtime-...@openjdk.java.net Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly   (Sorry, pressed Send button

RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly

Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8151509. Webrev link: http://cr.openjdk.java.net/~csahu/8151509/ Bug Brief: In check_addr0(), pointer "p" is not updated correctly, because of this it was reading only first two entries from buffer.

RE: RFR[9u-dev]: 8146683: check_addr0 should be more efficient

Hi Thomas,   Thanks for identifying the issue. I will file a new bug for this and correct the issue.     Regards, Cheleswer     From: Thomas Stüfe [mailto:thomas.stu...@gmail.com] Sent: Wednesday, March 09, 2016 4:44 PM To: David Holmes Cc: Kevin Walls; Cheleswer Sahu; Daniel Daugherty

RE: RFR[9u-dev]: 8146683: check_addr0 should be more efficient

hu/8146683/webrev.01/ Regards, Cheleswer -Original Message- From: Dean Long Sent: Wednesday, February 24, 2016 7:44 AM To: Daniel Daugherty; Thomas Stüfe; Cheleswer Sahu Cc: serviceability-dev@openjdk.java.net; hotspot-runtime-...@openjdk.java.net Subject: Re: RFR[9u-dev]: 8146683: check_

RFR[9u-dev]: 8146683: check_addr0 should be more efficient

Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8146683 . Webrev link: http://cr.openjdk.java.net/~csahu/8146683/ JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683 Bug Brief: While investigating bug https://bugs.openjdk.java.net/browse/JDK-8

Re: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata

the potential for many reaper threads, I at least wanted to keep the memory waste low. On Wed, Jan 13, 2016 at 2:25 AM, cheleswer sahu wrote: + Thread t = null; + if (Boolean.getBoolean("processReaperUseDefaultStackSize")) { +

Re: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata

Adding core-libs-dev and hotspot-runtime-dev team . On 1/14/2016 12:24 AM, Martin Buchholz wrote: You should include core-libs-dev (and perhaps hotspot-runtime-dev) in this thread. You're changing core library code. On Wed, Jan 13, 2016 at 2:25 AM, cheleswer sahu wrote: Hi, Please r

RFR[9u-dev] 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata

Hi, Please review the code changes for "https://bugs.openjdk.java.net/browse/JDK-8130425";. Problem summary: When a large TLS (Thread Local Storage) size is set for threads, JVM is throwing StackOverflow exception. Problem Identified: As per investigation and a discussion we came to the co

Re: RFR[ 9u-dev] JDK-8138745: Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot

Hi David, Please review the code changes in updated webrev http://cr.openjdk.java.net/~kevinw/8138745/webrev.02/ Regards, Cheleswer On 12/8/2015 4:36 AM, David Holmes wrote: Hi Cheleswer, Thanks. Just a few minor updates ... On 3/12/2015 4:58 PM, cheleswer sahu wrote: Hi, Thanks David and

Re: RFR[ 9u-dev] JDK-8138745: Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot

e: Hi, On 25/11/2015 10:40 PM, cheleswer sahu wrote: Hi, Please review the code changes for "https://bugs.openjdk.java.net/browse/JDK-8138745";. Web review link: <http://cr.openjdk.java.net/%7Ekevinw/8138745/webrev.00/>http://cr.openjdk.java.net/~kevinw/8138745/webrev.00/

RFR[ 9u-dev] JDK-8138745: Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot

Hi, Please review the code changes for "https://bugs.openjdk.java.net/browse/JDK-8138745";. Web review link: http://cr.openjdk.java.net/~kevinw/8138745/webrev.00/ Enhancement Brief: ExitOnOutOfMemoryError: When user enable this option,

RFR[ 9u-dev] JDK-8129348: Debugger hangs in trace mode with TRACE_SENDS

Hi, Please review the code changes for "https://bugs.openjdk.java.net/browse/JDK-8129348";. Web review link: http://cr.openjdk.java.net/~kevinw/8129348/webrev.01/ Bug Brief: Debugger hangs in trace mode when TRACE_SENDS flag is enabled. To print the argument information, it does a remote call

[8u60] request for approval: 8075773 : jps running as root fails after the fix of JDK-8050807

Hi! May I please have approval to backport this fix from JDK9 to JDK8. I have built the JDK-8 hotspot and tested already. JDK9 fix applies cleanly to JDK8. As I do not have an account for OPENJDK, Kevin Walls will push the fix into jdk8u/hs-dev/hotspot. BUGURL: https://bugs.openjdk.java.net/br

Re: RFR[ 9u-dev] JDK-8075773 - jps running as root fails with 7u75, works fine with 7u72

Hi, I have fixed the code and tested. It's working fine. Please review the changes. Web review link: http://cr.openjdk.java.net/~dbuck/8075773/webrev.02/ Regards, Cheleswer On 5/15/2015 12:26 PM, cheleswer sahu wrote: Dear Dan & Dmitry, Thanks for pointing out the security vulnera

Re: RFR[ 9u-dev] JDK-8075773 - jps running as root fails with 7u75, works fine with 7u72

Dear Dan & Dmitry, Thanks for pointing out the security vulnerability in the fix and for your precise review. I am also agree with Dmitry's fix. I will fix the code and resend the review request. Regards, Cheleswer On 5/14/2015 9:46 PM, Gerald Thornbrugh wrote: Hi Dan, When Cheleswer and I

RFR[ 9u-dev] JDK-8075773 - jps running as root fails with 7u75, works fine with 7u72

Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8075773. I have built and tested JDK9 with fix successfully. As I do not have an account for OpenJDK, David Buck will push the fix into jdk9/hs-rt/. Web review link: http://cr.openjdk.java.net/~dbuck/8075773/webrev.

RFR[ 9u-dev] JDK-8075773 - jps running as root fails with 7u75, works fine with 7u72

Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8075773. I have built and tested JDK9 with fix successfully. As I do not have an account for OpenJDK, David Buck will push the fix into jdk9/hs-rt/. Web review link: http://cr.openjdk.java.net/~dbuck/8075773/webrev.

[8u60] request for approval: 8072863: Replace fatal() with vm_exit_during_initialization() when an incorrect class is found on the bootclasspath

Hi! May I please have approval to backport this fix from JDK9 to JDK8. I have built the JDK-8 hotspot and tested already. JDK9 fix applies cleanly to JDK8. As I do not have an account for OPENJDK, David Buck will push the fix into jdk8u/hs-dev/hotspot. BUGURL: https://bugs.openjdk.java.net/br

RFR[ 9u-dev] JDK-8072863 - Replace fatal() with vm_exit_during_initialization() when an incorrect class is found on the bootclasspath

/webrev.02/ Regards, Cheleswer On 3/30/2015 2:14 AM, David Holmes wrote: On 27/03/2015 5:36 PM, cheleswer sahu wrote: Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8072863. I have built the JDK9 with fix successfully. As I do not have account for OpenJDK, David

RFR[ 9u-dev] JDK-8072863 - Replace fatal() with vm_exit_during_initialization() when an incorrect class is found on the bootclasspath

Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8072863. I have built the JDK9 with fix successfully. As I do not have account for OpenJDK, David Buck will push the fix into jdk9/hs-rt/. Web review link: http://cr.openjdk.java.net/~dbuck/8072863/webrev.00/ Regar