Re: RFR(S): 8192978: Missing checks and small fixes in jdwp library

Fixed. Dan On 12/11/17 2:53 AM, Chris Plummer wrote: Hi Christoph, I was just guilty of the same thing on Friday. Dan cleaned it up for me. See JDK-8191229. I believe the process is to change the Fix Version in the backport from 10 to 11, re-open it, and then close as resolved "No an

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

On 12/8/17 4:28 AM, Alan Bateman wrote: On 07/12/2017 16:55, Daniel D. Daugherty wrote: : Greetings, I have a small fix for a very intermittent ServerSocket related test failure:     JDK-8182307: Error during JRMP connection establishment     https://bugs.openjdk.java.net/browse/JDK-8182307

Re: RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError

I would not do the JVM/TI SetEventNotificationMode() call i JNI_OnLoad(). Dan On 12/7/17 8:38 PM, Chris Plummer wrote: Hi Yasumasa, That would work, but let me see what David and Serguei think. I believe normally we enable events in Agent_Initialize(), so don't want to switch around

Re: URGENT RFR(XXS): 8193225 - [BACKOUT] fix for 8182307 Error during JRMP connection

no RMI test failures... I cannot explain what happened (yet)... Dan Thanks, Serguei On 12/7/17 16:57, Igor Ignatyev wrote: Reviewed. -- Igor On Dec 7, 2017, at 4:46 PM, Daniel D. Daugherty <daniel.daughe...@oracle.com> wrote: Resending with the correct subject line! Greetings,

Re: URGENT RFR(XXS): 8193225 - [BACKOUT] fix for 8182307 Error during JRMP connection

Thanks Igor! Dan On 12/7/17 7:57 PM, Igor Ignatyev wrote: Reviewed. -- Igor On Dec 7, 2017, at 4:46 PM, Daniel D. Daugherty <daniel.daughe...@oracle.com> wrote: Resending with the correct subject line! Greetings, My fix for the following bug: JDK-8182307: Error durin

URGENT RFR(XXS): 8193225 - [BACKOUT] fix for 8182307 Error during JRMP connection

Error during JRMP connection establishment     https://bugs.openjdk.java.net/browse/JDK-8193225 Here's the webrev:     http://cr.openjdk.java.net/~dcubed/8193225-webrev/jdk10-0/ This is a simple "hg backout". I need a single (R)eviewer. Thanks! Dan On 12/7/17 11:38 AM, Daniel D.

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

establishment     https://bugs.openjdk.java.net/browse/JDK-8193225 Here's the webrev:     http://cr.openjdk.java.net/~dcubed/8193225-webrev/jdk10-0/ This is a simple "hg backout". I need a single (R)eviewer. Thanks! Dan On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: Greetings, I have a

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

DK 10 enters Rampdown Phase One in one week". In short, the RDP1 deadline applies to jdk/jdk, jdk/hs and jdk/client all at the same time. Dan Thanks, Serguei On 12/7/17 09:09, Daniel D. Daugherty wrote: Roger, Thanks for the review! Dan P.S. I'm planning to push this fix to jd

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

/7/17 11:38 AM, Daniel D. Daugherty wrote: Greetings, I have a small fix for a very intermittent ServerSocket related test failure:     JDK-8182307: Error during JRMP connection establishment https://bugs.openjdk.java.net/browse/JDK-8182307 The fix is copied from Jerry's work on the following

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

. This is one of the few times that reply-to-all is the right thing to do... Dan On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: Greetings, I have a small fix for a very intermittent ServerSocket related test failure:     JDK-8182307: Error during JRMP connection establishment     https

Re: RFR(XXS): 8182307 - Error during JRMP connection establishment

Adding core-libs-dev@... since this is RMI code. Thanks Alan! Folks, this review spans three OpenJDK aliases so Thunderbird's reply-to-list feature won't get it right. This is one of the few times that reply-to-all is the right thing to do... Dan On 12/7/17 11:38 AM, Daniel D. Daugherty wrote

RFR(XXS): 8182307 - Error during JRMP connection establishment

Greetings, I have a small fix for a very intermittent ServerSocket related test failure:     JDK-8182307: Error during JRMP connection establishment     https://bugs.openjdk.java.net/browse/JDK-8182307 The fix is copied from Jerry's work on the following bugs:     JDK-8182757 JDWP: Socket

Re: RFR(XS): 8192840: serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java failing on Windows

On 11/30/17 4:50 PM, Chris Plummer wrote: Hello, Please review the changes below. I'll push once I get two reviews since this is an integration block and would be best if it makes it into today's nightly build. test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java    

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

time error or something... I really wish I had saved that JPRT build log... :-( Dan /Robbin On 2017-11-23 03:16, Daniel D. Daugherty wrote: Greetings, I've made minor tweaks to the Thread-SMR project based on the remaining code review comments over the last couple of days. I've also rebased the proj

Re: RFR: XS: SA: JDK-8191919: Include TestJhsdbJstackLock.java in ProblemList.txt

On 11/27/17 12:21 PM, Jini George wrote: Hello, Could I please get quick reviews for excluding TestJhsdbJstackLock.java since it causes timeouts on windows ? ID: https://bugs.openjdk.java.net/browse/JDK-8191919 Webrev: http://cr.openjdk.java.net/~jgeorge/8191919/webrev.00/

Re: RFR (S): 8191894: Refactor weak references in JvmtiTagHashmap to use the Access API

Adding serviceability-dev@... since this is JVM/TI related... Dan On 11/27/17 6:28 AM, Erik Österlund wrote: Hi, The JVMTI tag hashmap has weak oop references that are handled using raw oop accesses and a G1-specific SATB enqueue call when leaking out objects from the tag map, requiring

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

there either. Obviously I'll be keeping an eye on testing for the next several days, but so far everything looks good!! Dan On 11/22/17 9:16 PM, Daniel D. Daugherty wrote: Greetings, I've made minor tweaks to the Thread-SMR project based on the remaining code review comments over the last

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

://bugs.openjdk.java.net/browse/JDK-8191809 Nice follow-up! Thanks for filing it. Dan /Robbin On 2017-11-23 03:16, Daniel D. Daugherty wrote: Greetings, I've made minor tweaks to the Thread-SMR project based on the remaining code review comments over the last couple of days. I've also rebased the project

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

nument, CO. Dan On 11/21/17 7:12 PM, Daniel D. Daugherty wrote: Greetings, *** We are wrapping up code review on this project so it is time *** *** for the various code reviewers to chime in one last time. *** In this latest round, we had three different reviewers chime in so we're doing delta w

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

Thanks Jerry! Dan On 11/22/17 3:21 PM, Gerald Thornbrugh wrote: Hi Dan, Your changes look good. Jerry On Nov 21, 2017, at 5:12 PM, Daniel D. Daugherty <daniel.daughe...@oracle.com> wrote: Greetings, *** We are wrapping up code review on this project so it i

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

On 11/22/17 8:02 AM, coleen.phillim...@oracle.com wrote: On 11/22/17 7:54 AM, Daniel D. Daugherty wrote: On 11/22/17 4:48 AM, Erik Österlund wrote: Hi, Some replies... On 2017-11-21 18:36, Daniel D. Daugherty wrote: Thanks for keeping all the OpenJDK aliases! On 11/21/17 12:24 PM

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

On 11/22/17 8:06 AM, Erik Österlund wrote: Hi Dan, On 2017-11-22 13:53, Daniel D. Daugherty wrote: On 11/22/17 4:07 AM, Erik Österlund wrote: Hi, Some replies... On 2017-11-21 17:28, Daniel D. Daugherty wrote: Hi Coleen! Thanks for making time to review the Thread-SMR stuff again!! I

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

Adding back the other OpenJDK aliases... On 11/22/17 8:01 AM, coleen.phillim...@oracle.com wrote: On 11/22/17 7:51 AM, Daniel D. Daugherty wrote: On 11/21/17 11:26 PM, David Holmes wrote: Hi Dan, On 22/11/2017 10:12 AM, Daniel D. Daugherty wrote: Greetings, *** We are wrapping up code

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

On 11/22/17 4:48 AM, Erik Österlund wrote: Hi, Some replies... On 2017-11-21 18:36, Daniel D. Daugherty wrote: Thanks for keeping all the OpenJDK aliases! On 11/21/17 12:24 PM, coleen.phillim...@oracle.com wrote: On 11/21/17 11:28 AM, Daniel D. Daugherty wrote: On 11/20/17 3:12 PM

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

On 11/22/17 4:07 AM, Erik Österlund wrote: Hi, Some replies... On 2017-11-21 17:28, Daniel D. Daugherty wrote: Hi Coleen! Thanks for making time to review the Thread-SMR stuff again!! I have added back the other three OpenJDK aliases... This review is being done on _four_ different OpenJDK

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

On 11/21/17 11:26 PM, David Holmes wrote: Hi Dan, On 22/11/2017 10:12 AM, Daniel D. Daugherty wrote: Greetings, *** We are wrapping up code review on this project so it is time *** *** for the various code reviewers to chime in one last time. *** In this latest round, we had three different

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

project is currently baselined on Jesper's 2017-11-17 PIT snapshot so there will be some catching up to do before integration... We welcome comments, suggestions and feedback. Dan, Erik and Robbin On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: Greetings, Testing of the last round of changes reveale

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

Thanks for keeping all the OpenJDK aliases! On 11/21/17 12:24 PM, coleen.phillim...@oracle.com wrote: On 11/21/17 11:28 AM, Daniel D. Daugherty wrote: Hi Coleen! Thanks for making time to review the Thread-SMR stuff again!! I have added back the other three OpenJDK aliases... This review

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

Adding back the missing OpenJDK aliases... On 11/21/17 11:14 AM, coleen.phillim...@oracle.com wrote: On 11/20/17 8:50 PM, Daniel D. Daugherty wrote: On 11/20/17 12:51 AM, David Holmes wrote: Hi Dan, Figured I'd better cast an eye over this again before it gets pushed :) Thanks

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

I don't have any in-depth comments.  This looks really good from my day of reading it. Thanks for taking the time to review it again! Dan Thanks, Coleen On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: Greetings, Testing of the last round of changes revealed a hang in one of the new TLH

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

ts, suggestions and feedback. Dan, Erik and Robbin On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: Greetings, Robbin rebased the project last night/this morning to merge with Thread Local Handshakes (TLH) and also picked up additional changesets up thru: Changeset: fa736014cf28 Author:cjp

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

comments... Dan Thanks, David On 21/11/2017 11:50 AM, Daniel D. Daugherty wrote: On 11/20/17 12:51 AM, David Holmes wrote: Hi Dan, Figured I'd better cast an eye over this again before it gets pushed :) Thanks for reviewing again!! Only one thing (repeated many times) jumped out at me

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

  // Impl note: See _smr_to_delete_list_cnt note. uint  Threads::_smr_to_delete_list_max = 0; Yikes! With the additional comments, the additions to thread.hpp and thread.cpp grew by a bunch... I've done a test build build on my Mac with these changes and I'm about

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

und to be a little noisier than usual because we did not rebase on a PIT snapshot so the new baseline has not been through Jesper's usual care-and-feeding of integration_blockers, etc. We welcome comments, suggestions and feedback. Dan, Erik and Robbin On 11/14/17 4:48 PM, Daniel D. Daugherty wr

Re: CSR review request for: 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled

Also reviewed the CSR. Added a comment about one typo/grammar change, but it's finalized so I did not actually make the change. Dan On 11/16/17 8:01 PM, serguei.spit...@oracle.com wrote: Chris, I've also moved the statements about compatibility risk from the "Description" section to the

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

ier than usual because we did not rebase on a PIT snapshot so the new baseline has not been through Jesper's usual care-and-feeding of integration_blockers, etc. We welcome comments, suggestions and feedback. Dan, Erik and Robbin On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: Greetings, I reba

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

the rebased bits to build so there is no delta webrev. These bits have been run through JPRT and I've submitted the usual Mach5 tier[1-5] test run... We welcome comments, suggestions and feedback. Dan, Erik and Robbin On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: Greetings, I rebased

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: Greetings, Resolving one of the code review comments (from both Stefan K and Coleen) on jdk10-04-full required quite a few changes so it is being done as a standalone patch and corresponding webrevs: Here's the mq comment for the change

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

The jdk10-05-full bits have passed JPRT testing (hs-tier1 testing) and hs-tier[2-5] testing via Mach 5. No unexpected test failures. Dan On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: Greetings, Resolving one of the code review comments (from both Stefan K and Coleen) on jdk10-04-full

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

and Robbin On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: Greetings, We have a (eXtra Large) fix for the following bug: 8167108 inconsistent handling of SR_lock can lead to crashes https://bugs.openjdk.java.net/browse/JDK-8167108 This fix adds a Safe Memory Reclamation (SMR) mechanism based

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

JavaThreadsListIterator {     ThreadsListHandle _tlh; ... } This issue has been addressed as part of my response to Stefan K's code review comments. I quoted the above comment in that reply so it should be easy to find that resolution... Dan Thanks, Coleen On 10/9/17 3:41 PM, Daniel D. Daugherty wrote

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

Greetings, This code review from Stefan Karlsson was originally posted on an Oracle internal alias that we use for discussing HotSpot SMR development issues. That subject was: "Thread-SMR (8167108)(JDK10): CR round 0 changes". I did not have time to address Stefan's review before I went on

Re: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout

On 11/6/17 1:56 PM, Chris Plummer wrote: Hi Dean, It looks like ciEnv::jvmti_state_changed() is used to support the JVMTI AddCapabilities() interface, which I believe typically a JVMTI agent uses to setup the available capabilities when the agent is first loaded (although capabilities can by

Re: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout

On 11/3/17 8:25 PM, Chris Plummer wrote: Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8059334 Wow! This bug was quite the adventure... http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/

Re: RFR (S): 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled

up! Dan On 11/2/17 4:59 PM, serguei.spit...@oracle.com wrote: Hi Dan, Thank you a lot for doing this review! I was waiting for you for a couple of weeks. :) On 11/2/17 10:13, Daniel D. Daugherty wrote: On 10/13/17 12:58 AM, serguei.spit...@oracle.com wrote: Please, review a fix for: ht

Re: RFR (S): 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled

On 10/13/17 12:58 AM, serguei.spit...@oracle.com wrote: Please, review a fix for: https://bugs.openjdk.java.net/browse/JDK-8187289 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.1/ Summary:   The issue is that the FRAME_POP event request is not

Re: RFR(XL): 8167108 - SMR and JavaThread Lifecycle

been reviewing (and arguing over) each other's code. It has been an adventure! Dan, Erik, and Robbin On 10/9/17 1:41 PM, Daniel D. Daugherty wrote: Greetings, We have a (eXtra Large) fix for the following bug: 8167108 inconsistent handling of SR_lock can lead to crashes https

RFR(XL): 8167108 - SMR and JavaThread Lifecycle

Greetings, We have a (eXtra Large) fix for the following bug: 8167108 inconsistent handling of SR_lock can lead to crashes https://bugs.openjdk.java.net/browse/JDK-8167108 This fix adds a Safe Memory Reclamation (SMR) mechanism based on Hazard Pointers to manage JavaThread lifecycle. Here's a

Re: RFR(S) 8177901: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface

of it as insurance against someone changing the code in the future. :-) Dan So thumbs up. Thank you a lot, David! Serguei Cheers, David Just a sanity check is needed. Thanks, Serguei On 9/14/17 14:53, Daniel D. Daugherty wrote: On 9/4/17 11:23 PM, serguei.spit...@oracle.com wrote

Re: RFR(S) 8177901: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface

a sanity check is needed. Thanks, Serguei On 9/14/17 14:53, Daniel D. Daugherty wrote: On 9/4/17 11:23 PM, serguei.spit...@oracle.com wrote: Hi David, On 9/4/17 21:43, David Holmes wrote: Hi Serguei, This looks good to me. One not below. On 2/09/2017 6:30 PM, serguei.spit...@oracle.com wrote

Re: RFR: SA: MacOS X: 8184042: several serviceability/sa tests timed out on MacOS X

On 8/18/17 4:00 AM, Jini George wrote: Hi all, Requesting reviews for: https://bugs.openjdk.java.net/browse/JDK-8184042 Webrev: http://cr.openjdk.java.net/~jgeorge/8184042/webrev.00/ hotspot/src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m     L832:   result =

Re: RFR(S) 8177901: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface

On 9/4/17 11:23 PM, serguei.spit...@oracle.com wrote: Hi David, On 9/4/17 21:43, David Holmes wrote: Hi Serguei, This looks good to me. One not below. On 2/09/2017 6:30 PM, serguei.spit...@oracle.com wrote: Please, review a fix for: https://bugs.openjdk.java.net/browse/JDK-8177901 Webrev:

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

the 'jdk_management' and 'jdk_jmx' test groups... that should also pick up any closed side tests... Dan On 9/5/17 10:44 AM, Shafi Ahmad wrote: Thank you Daniel. I will run and update it with the result. Regards, Shafi On Tue, Sep 5, 2017 at 9:44 PM +0530, "Daniel D. Daugherty" <

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

Seems like you should also run: nsk.monitoring.testlist Dan On 9/4/17 4:11 AM, Shafi Ahmad wrote: Hi, Please review the fix for ‘JDK-8170299: Debugger does not stop inside the low memory notifications code’ to jdk10. With the current implementation ‘debugger does not stop inside the low

Re: RFR(M): 8061228 Allow JDWP socket connector to accept connections from certain ip addresses only

On 8/31/17 4:06 PM, serguei.spit...@oracle.com wrote: On 8/31/17 14:51, Daniel D. Daugherty wrote: I compared the .2 and .3 patches. Everything good except for this whitespace change that didn't show up in the webrev (IIRC): - /* +  /*    * Start the transport loop

Re: RFR(M): 8061228 Allow JDWP socket connector to accept connections from certain ip addresses only

sue before giving the official thumbs up! Dan On 8/31/17 3:35 PM, serguei.spit...@oracle.com wrote: On 8/31/17 11:54, Daniel D. Daugherty wrote: On 8/29/17 2:44 AM, serguei.spit...@oracle.com wrote: Hi Dan, Please, find the updated webrev's here: http://cr.openjdk.java.net/~sspitsyn/we

Re: RFR(M): 8061228 Allow JDWP socket connector to accept connections from certain ip addresses only

sport in the bag. The intended error exit point for startTransport is L733. Dan On 8/31/17 12:54 PM, Daniel D. Daugherty wrote: On 8/29/17 2:44 AM, serguei.spit...@oracle.com wrote: Hi Dan, Please, find the updated webrev's here: http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8061228-jd

Re: RFR(M): 8061228 Allow JDWP socket connector to accept connections from certain ip addresses only

On 8/28/17 1:37 PM, serguei.spit...@oracle.com wrote: On 8/28/17 12:17, Daniel D. Daugherty wrote: On 8/22/17 5:22 PM, serguei.spit...@oracle.com wrote: Please, review another revision of the fix for the enhancement: https://bugs.openjdk.java.net/browse/JDK-8061228 CSR: https

Re: RFR(M): 8061228 Allow JDWP socket connector to accept connections from certain ip addresses only

On 8/22/17 5:22 PM, serguei.spit...@oracle.com wrote: Please, review another revision of the fix for the enhancement: https://bugs.openjdk.java.net/browse/JDK-8061228 CSR: https://bugs.openjdk.java.net/browse/CCC-8061228   The SCR is in the DRAFT state.   Joe suggested to consider this CSR

Re: RFR(M): 8061228 Allow JDWP socket connector to accept connections from certain ip addresses only

Resending with Dmitry's e-mail address included. Please delete the previous version. On 8/22/17 5:22 PM, serguei.spit...@oracle.com wrote: Please, review another revision of the fix for the enhancement: https://bugs.openjdk.java.net/browse/JDK-8061228 CSR:

Re: RFR(M): 8061228 Allow JDWP socket connector to accept connections from certain ip addresses only

On 8/22/17 5:22 PM, serguei.spit...@oracle.com wrote: Please, review another revision of the fix for the enhancement: https://bugs.openjdk.java.net/browse/JDK-8061228 CSR: https://bugs.openjdk.java.net/browse/CCC-8061228   The SCR is in the DRAFT state.   Joe suggested to consider this CSR

Re: RFR (S) 8185687: Fix minor bugs in jvmti specification

On 8/17/17 12:53 PM, serguei.spit...@oracle.com wrote: Please, review a fix for the bug: https://bugs.openjdk.java.net/browse/JDK-8185687 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8185687-jvmti-spec.1/ src/share/vm/prims/jvmti.xml     No comments.

Re: RFR(XXS): quarantine sun/management/jdp/JdpOffTest.java (8186152)

Thanks Serguei! Dan On 8/11/17 1:41 PM, serguei.spit...@oracle.com wrote: Looks good. Thanks, Serguei On 8/11/17 10:55, Daniel D. Daugherty wrote: Greetings, I'm quarantining sun/management/jdp/JdpOffTest.java as it continues to fail in the JDK10-hs nightly. 8186152 quarantine sun

RFR(XXS): quarantine sun/management/jdp/JdpOffTest.java (8186152)

Greetings, I'm quarantining sun/management/jdp/JdpOffTest.java as it continues to fail in the JDK10-hs nightly. 8186152 quarantine sun/management/jdp/JdpOffTest.java https://bugs.openjdk.java.net/browse/JDK-8186152 $ hg diff test/ProblemList.txt diff -r 5ebbdc94be6d test/ProblemList.txt ---

Re: [8u] RFR: 8185164: GetOwnedMonitorInfo() returns incorrect owned monitor

On 8/11/17 2:04 AM, Yasumasa Suenaga wrote: Hi all, I want to backport JDK-8185164 change to 8u because this issue will affect JVMTI users who want to check owned monitors in MonitorContendedEnter JVMTI event. Could you review it?

Re: [10] RFR: 8186018: SA: Monitor Cache Dump in HSDB does not work

On 8/9/17 3:14 AM, David Holmes wrote: On 9/08/2017 5:52 PM, Yasumasa Suenaga wrote: Hi David, Copyright format is just two years: first and last, so should be: * Copyright (c) 2001, 2017, Oracle and/or its affiliates. All rights reserved. Sorry, I've fixed:

Re: [10] RFR for JDK-8169961: Memory leak after debugging session

On 8/9/17 3:05 AM, Shafi Ahmad wrote: May I get it reviewed by serviceability team. I don't count as being on the Serviceability team anymore, but I've pinged Serguei Spitsyn who is back from his vacation... More below... Regards, Shafi -Original Message- From: Shafi Ahmad

Re: [10] RFR: 8185164: GetOwnedMonitorInfo() returns incorrect owned monitor

On 8/7/17 2:54 AM, Yasumasa Suenaga wrote: Thanks Serguei, David, I uploaded webrev which includes @summary update and 4 indent: http://cr.openjdk.java.net/~ysuenaga/JDK-8185164/webrev.05/ make/test/JtregNative.gmk No comments. src/share/vm/runtime/objectMonitor.cpp No comments.

Re: [10] RFR: 8185164: GetOwnedMonitorInfo() returns incorrect owned monitor

-8185164/webrev.03/ Thanks, Yasumasa 2017-08-06 23:54 GMT+09:00 Daniel D. Daugherty <daniel.daughe...@oracle.com>: On 8/6/17 1:28 AM, Yasumasa Suenaga wrote: Hi Dan, Serguei, Thanks Serguei! I can run new testcase on my environment. Dan, I modified your patch and uploaded as webrev:

Re: [10] RFR: 8185164: GetOwnedMonitorInfo() returns incorrect owned monitor

le. Sorry I missed that one. - I moved "event_has_posted = JNI_TRUE" to each before return statement. Good catch. My original setting of event_has_posted had a narrow race. I'm good on the changes. I'll have test results later today. Dan Yasumasa On 2017/08/06 11:33,

Re: [10] RFR: 8185164: GetOwnedMonitorInfo() returns incorrect owned monitor

...@oracle.com wrote: On 8/4/17 14:26, Daniel D. Daugherty wrote: On 8/4/17 3:17 PM, serguei.spit...@oracle.com wrote: The patch is attached. It may need some tweaks though. I was not able to make it fail yet. I don't think the original test had "failure" detection. You were jus

Re: RFR(XXS): quarantine tests named in JDK-8184042 on MacOS X (8185872)

an! - Ioi On 8/4/17 2:24 PM, Daniel D. Daugherty wrote: Greetings, I'm quarantining the tests named in JDK-8184042 on MacOS X. Webrev URL: http://cr.openjdk.java.net/~dcubed/8185872-webrev/0/ This fix is targeted to JDK10/hs. Dan

Re: [10] RFR: 8185164: GetOwnedMonitorInfo() returns incorrect owned monitor

list. Dan On 8/4/17 12:45, Daniel D. Daugherty wrote: Thanks Serguei! I happen to be doing a test run this weekend that includes most of the JPDA stack of tests so I'll include the following in my experiment: $ hg log -v -r tip changeset: 12872:bb66cd7c61b1 tag: 8185164

RFR(XXS): quarantine tests named in JDK-8184042 on MacOS X (8185872)

Greetings, I'm quarantining the tests named in JDK-8184042 on MacOS X. Webrev URL: http://cr.openjdk.java.net/~dcubed/8185872-webrev/0/ This fix is targeted to JDK10/hs. Dan

Re: [10] RFR: 8185164: GetOwnedMonitorInfo() returns incorrect owned monitor

, Thank you for letting me know about this discussion. I'll try to convert the attached test case to the JTreg format. Thanks, Serguei On 8/4/17 11:16, Daniel D. Daugherty wrote: Adding Serguei to this thread directly since he's back from vacation! On 7/31/17 10:14 PM, David Holmes wrote: Hi Dan

Re: [10] RFR: 8185164: GetOwnedMonitorInfo() returns incorrect owned monitor

Adding Serguei to this thread directly since he's back from vacation! On 7/31/17 10:14 PM, David Holmes wrote: Hi Dan, On 26/07/2017 11:52 PM, Daniel D. Daugherty wrote: On 7/26/17 12:11 AM, David Holmes wrote: On 26/07/2017 10:27 AM, Yasumasa Suenaga wrote: Hi Dan, I've added some

Re: RFR 8182757: JDWP: Socket Transport handshake hangs on Solaris

On 8/2/17 9:16 AM, Gerald Thornbrugh wrote: Hi, Please review this JDK-10 fix for JDK-8182757. The bug: https://bugs.openjdk.java.net/browse/JDK-8182757 The webrev: http://cr.openjdk.java.net/~gthornbr/8182757/webrev.00

Re: [10] RFR: 8185164: GetOwnedMonitorInfo() returns incorrect owned monitor

in the bug yesterday, but you should look at that when you're officially back! Dan Thanks, David Did you run the jdk repo's com/sun/jdi tests with your fix? I have not done yet. I have a trip until 28 July JST. So I will run it after that. Yasumasa On 2017/07/26 7:05, Daniel D. Daugherty wrote

Re: [10] RFR: 8185164: GetOwnedMonitorInfo() returns incorrect owned monitor

On 7/24/17 8:40 PM, Yasumasa Suenaga wrote: Hi all, I tried to get owned monitors in MonitorContendedEnter JVMTI event handler. However GetOwnedMonitorInfo JVMTI function returns a monitor which is not yet owned. I attached reproducer to JBS. Please read README.md. I think

Re: [10] RFR for JDK-8169961: Memory leak after debugging session

DK-8169961: Memory leak after debugging session Hi Daniel, Thank you for the review. -Original Message----- From: Daniel D. Daugherty Sent: Friday, July 14, 2017 6:46 AM To: Shafi Ahmad <shafi.s.ah...@oracle.com>; serviceability- d...@openjdk.java.net Subject: Re: [10] RFR for JDK-81

Re: RFR 8183123 : JDP packets have no processId context set

rationException, so I have also handled that. I have a new webrev, which I will ask Christoph to upload... Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leon...@uk.ibm.com <m

Re: [10] RFR for JDK-8169961: Memory leak after debugging session

On 7/13/17 10:19 AM, Shafi Ahmad wrote: Hi Daniel, Thank you for the review. -Original Message- From: Daniel D. Daugherty Sent: Thursday, July 13, 2017 7:40 PM To: Shafi Ahmad <shafi.s.ah...@oracle.com>; serviceability- d...@openjdk.java.net Subject: Re: [10] RFR for JDK-8

Re: [10] RFR for JDK-8169961: Memory leak after debugging session

On 7/13/17 2:45 AM, Shafi Ahmad wrote: Hi, Please review the code change for the fix of bug 'JDK-8169961: Memory leak after debugging session' Summary: 1. It seems that the thread created for com.sun.tools.jdi.TargetVM.EventController is never stopped and keeps a hard reference to the

Re: [9] RFA: 8181419: Race in jdwp invoker handling may lead to crashes or invalid results

Severin, OpenJDK9 has reached the Release Candidate phase. I attached the most recent e-mail on that topic. At this point in the release, only _critical_ P1 bugs can be fixed. Dan On 7/7/17 7:42 AM, Severin Gehwolf wrote: Hi, Could somebody please approve 8181419 for JDK 9. As mentioned in

Re: RFR 8183123 : JDP packets have no processId context set

On 6/29/17 7:57 AM, Andrew Leonard wrote: Hi All, Please can I get some review feedback for my changes for this issue: _https://bugs.openjdk.java.net/browse/JDK-8183123_ The webrev patch has been uploaded here: _http://cr.openjdk.java.net/~clanger/webrevs/8183123.0/_

Re: [Urgent JDK 9] RFR: 8182844: Fix broken links in the generated jvmti.html

On 6/24/17 4:14 PM, Mandy Chung wrote: On Jun 25, 2017, at 1:26 AM, serguei.spit...@oracle.com wrote: If you want this fixed in JDK9, the priority has to be raised to P1. I don't think JDK9 should go out the door with broken doc links. That gives a bad

Re: [Urgent JDK 9] RFR: 8182844: Fix broken links in the generated jvmti.html

On 6/24/17 11:27 AM, serguei.spit...@oracle.com wrote: On 6/24/17 10:26, serguei.spit...@oracle.com wrote: On 6/24/17 06:40, Daniel D. Daugherty wrote: On 6/23/17 10:06 PM, serguei.spit...@oracle.com wrote: Please, review this urgent JDK 9 review request for the bug: https

Re: [Urgent JDK 9] RFR: 8182844: Fix broken links in the generated jvmti.html

On 6/23/17 10:06 PM, serguei.spit...@oracle.com wrote: Please, review this urgent JDK 9 review request for the bug: https://bugs.openjdk.java.net/browse/JDK-8182844 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8182844-jvmti-spec-links/ src/share/vm/prims/jvmti.xml No

Re: RFR(10): JDK-8178536: OOM ERRORS + SERVICE-THREAD TAKES A PROCESSOR TO 100%

> Hotspot changes: > > http://cr.openjdk.java.net/~poonam/8178536/webrev.hotspot/ src/share/vm/services/lowMemoryDetector.cpp nit - please update the copyright year before pushing. L307: // call Sensor::trigger(int, MemoryUsage) to send notification to listeners. nit -

Re: RFR(10)(M): JDK-8164563: Test nsk/jvmti/CompiledMethodUnload/compmethunload001 keeps reporting: PRODUCT BUG: class was not unloaded in 5

On 5/4/17 4:38 PM, Chris Plummer wrote: Hello, Please review the following changes: http://cr.openjdk.java.net/~cjplummer/8164563/webrev.00/webrev.hotspot/ https://bugs.openjdk.java.net/browse/JDK-8164563 src/share/vm/prims/jvmtiImpl.hpp No comments. src/share/vm/prims/jvmtiImpl.cpp

Re: RFR(M): 8172970: TESTBUG: need test coverage for the JVMTI functions allowed in the start phase

s\'\n", name); L137: printf("Class source file name: \'%s\'\n", name); You don't need to escape the single-quotes with backslash here. Thumbs up! Dan Thanks, Serguei On 5/2/17 11:09, Daniel D. Daugherty wrote: > New webrev version is: > http://cr.

Re: RFR(M): 8172970: TESTBUG: need test coverage for the JVMTI functions allowed in the start phase

> New webrev version is: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.3/ make/test/JtregNative.gmk No comments. test/serviceability/jvmti/StartPhase/AllowedFunctions/AllowedFunctions.java L27: * @summary Verify the functions that allowed to operate

Re: Result: New Serviceability Group Lead: Serguei Spitsyn

Resending... this time I'm including regist...@openjdk.java.net. Dan On 4/19/17 10:13 AM, Daniel D. Daugherty wrote: The vote for Serguei Spitsyn [1] is now closed. Yes: 5 No: 0 Abstain: 0 According to the Bylaws definition of Simple Majority[2], this is sufficient to approve the new Group

Result: New Serviceability Group Lead: Serguei Spitsyn

The vote for Serguei Spitsyn [1] is now closed. Yes: 5 No: 0 Abstain: 0 According to the Bylaws definition of Simple Majority[2], this is sufficient to approve the new Group Lead. The OpenJDK Lead will ask the Governing Board to ratify this nomination. Daniel Daugherty [1]

Re: CFV: New Serviceability Group Lead: Serguei Spitsyn

Vote: yes Dan On 4/4/17 7:46 AM, Daniel D. Daugherty wrote: I hereby nominate Serguei Spitsyn to Serviceability Group Lead [1]. Serguei is a Reviewer in the jdk10 and jdk9 projects, a Committer in the jdk8u project, a member of the OpenJDK Serviceability Group, and has so far committed >

CFV: New Serviceability Group Lead: Serguei Spitsyn

I hereby nominate Serguei Spitsyn to Serviceability Group Lead [1]. Serguei is a Reviewer in the jdk10 and jdk9 projects, a Committer in the jdk8u project, a member of the OpenJDK Serviceability Group, and has so far committed > 70 changesets spread across multiple repos in JDK9 alone. Serguei

Re: RFR(S): 8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface

On 3/2/17 3:19 PM, serguei.spit...@oracle.com wrote: On 3/2/17 14:06, Daniel D. Daugherty wrote: On 3/2/17 2:24 PM, serguei.spit...@oracle.com wrote: The updated webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.2/ The change at L152-L153 has been

Re: RFR(S): 8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface

roduce the problem? Dan Thanks, Serguei On 3/2/17 11:21, serguei.spit...@oracle.com wrote: Dan, Thank you for reviewing! I was waiting for your comments. On 3/2/17 06:59, Daniel D. Daugherty wrote: On 3/1/17 8:49 PM, serguei.spit...@oracle.com wrote: Please, review the JDK 10 fix for:

Re: RFR(S): 8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface

On 3/1/17 8:49 PM, serguei.spit...@oracle.com wrote: Please, review the JDK 10 fix for: https://bugs.openjdk.java.net/browse/JDK-8134103 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8134103-jdi-wrong-phase.1/ src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c

Re: RFR (XXS): 8172969: JVMTI spec: GetCurrentThread may return NULL in the early start phase

On 2/13/17 12:33 AM, serguei.spit...@oracle.com wrote: Please, review a JDK 9 fix for the bug: https://bugs.openjdk.java.net/browse/JDK-8172969 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172969-jvmti-spec.hs1/ src/share/vm/prims/jvmti.xml No comments. Thumbs

<    5   6   7   8   9   10   11   12   13   14   >