Re: RFR: JDK-8210984: [TESTBUG] hs203t003 fails with "# ERROR: hs203t003.cpp, 218: NSK_CPP_STUB2 ( ResumeThread, jvmti, thread)"

Patch attached. Ran another 1000 clean testruns with the sleep(1) pauses. Restored the sleep(100) for the final patch. On 9/26/18, 2:12 PM, Chris Plummer wrote: On 9/26/18 11:07 AM, Gary Adams wrote: On 9/26/18, 1:40 PM, Chris Plummer wrote: Hi Gary, Should the following comment come first,

nsk/jvmti/scenarios/hotswap bugs on the ProblemList

While looking at some other hotswap tests, I noticed 2 tests on the ProblemList. I'm attempting some runs with the tests removed from the list to try and reproduce the errors locally. Issues: https://bugs.openjdk.java.net/browse/JDK-6813266 hs204t001 https://bugs.openjdk.java.net/bro

JDK-8203350: Crash in vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/TestDescription.java

I've been unsuccessful trying to reproduce the failure in hs201t002. Issue: https://bugs.openjdk.java.net/browse/JDK-8203350 Colleen made a comment on the bug that the reference from hs201t002a to class hs201t002 might be an issue for the redefined class. I found in test hs201t001 that an int

Re: RFR (M) 8211036 : Remove the NSK_STUB macros from vmTestbase for non jvmti

LGTM :) Thanks, David On 26/09/2018 11:51 PM, JC Beyler wrote: Hi all, Anybody on the hotspot-dev list have any comments or a LGTM? Thanks! Jc On Tue, Sep 25, 2018 at 10:56 AM Alex Menkov wrote: +1 --alex On 09/24/2018 11:40, Igor Ignatyev wrote: (cc-ing hotspot-dev alias) Hi Jc, the

Re: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp

Sorry Jc, I thought my LGTM was implicit. :) Thanks, David On 26/09/2018 11:52 PM, JC Beyler wrote: Ping on this, anybody have time to do a review and give a LGTM? Or David if you have time and will to provide an explicit LGTM :) Thanks, Jc On Mon, Sep 24, 2018 at 9:18 AM JC Beyler

Re: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file

LGTM. Thanks, David On 27/09/2018 1:16 AM, Sharath Ballal wrote: Can I get one more review from a (R)eviewer please ? Thanks, Sharath -Original Message- From: Sharath Ballal Sent: Wednesday, September 26, 2018 9:57 AM To: Jini Susan George; serviceability-dev Subject: RE: RFR (XS) JD

Re: RFR 8163083: SocketListeningConnector does not allow invocations with port 0

Hi Serguei, Thank you for reviewing this change. Initially I understood the whole fragment below  (from the Javadoc for com.sun.jdi.connect.ListeningConnector.startListening() method) as a direction for the user how to obtain and prepare the argument map before passing it in startListening(

Re: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp

Hi Jc, This seems fine to me. I'll leave it to you and Mikael to wrestle out the naming. Thanks, David On 27/09/2018 1:45 PM, JC Beyler wrote: Hi Mikael and David, @David: I thought it was implicit but did not want to presume on this one because my goal is to start propagating this new cla

Re: RFR 8163083: SocketListeningConnector does not allow invocations with port 0

Hi Daniil, It looks great, thank you for the update. I have a couple of more minor comments on the test. 56 testWithDefaultArgs(connector); 57 testWithDefaultArgs2(connector); 58 testWithWildcardPort1(connector); 59 testWithWildcardPort2(connector);   Pl

Re: RFR 8163083: SocketListeningConnector does not allow invocations with port 0

Just noticed one more minor issue: +import java.util.Collection; +import java.util.Iterator; +import java.util.LinkedHashMap;  It seems the above imports are not really used and can be removed. Thanks, Serguei On 9/27/18 11:22 AM, serguei.spit...@oracle.com wrote: Hi Daniil, It looks great,

Re: JDK-8203350: Crash in vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002/TestDescription.java

Hi Gary, Aren't you just hiding a potential jvmti bug with this change? If you think this is a test bug and this is a proper fix, I'd like to see an explanation of how the test is causing the crash. The explanation would need to involve native code, since pure java should never crash. thanks

Re: RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again

Speaking of not being bullet proof, during testing of the fix to wait for a specific prompt an intermittent failure was observed. ... Sending command: trace methods 0x2a9 reply[0]: MyThread-0[1] Sending command: cont WARNING: message not recieved: MyThread-0[1] Remaining debugger output follows:

Re: RFR 8163083: SocketListeningConnector does not allow invocations with port 0

Hi Serguei, The webrev was updated to address all these comments. Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.08 Bug: https://bugs.openjdk.java.net/browse/JDK-8163083 Thanks! --Daniil From: Organization: Oracle Corporation Date: Thursday, September 27, 2018 a

Re: RFR 8163083: SocketListeningConnector does not allow invocations with port 0

It looks good to me. Thanks! Serguei On 9/27/18 11:50 AM, Daniil Titov wrote: Hi Serguei, The webrev was updated to address all these comments. Webrev: http://cr.openjdk.java.net/~dtitov/8163083/webrev.08 Bug: https://bugs.openjdk.j

Re: RFR: JDK-8208473: [TESTBUG] nsk/jdb/exclude/exclude001/exclude001.java is timing out on solaris-sparc again

The extra check after timing out doesn't seem like it should help. You've already called findMessage() 2100 times at 200ms intervals. Why would one more call after that help? I think it might be the receiveReply() call that is fixing it. It does a waitForPrompt(), so this probably gives us anot

RFR JDK-8203928: [Test] Convert non-JDB scaffolding serviceability shell script tests to java

Hi all, please review a fix for https://bugs.openjdk.java.net/browse/JDK-8203928 webrev: http://cr.openjdk.java.net/~amenkov/sh2java/non-jdb/webrev.01/ Some details: ImmutableResourceTest.java - required compile/run args are specified by using jtreg tag options; JITDebug.java - was not abl

Re: RFR (S) 8210842: Handle JNIGlobalRefLocker.cpp

Some of us have lobbied to make openjdk source C++11, but it's not yet. If you're brave, you can try to change that flag to -std=gnu++11 On Thu, Sep 27, 2018 at 2:33 PM, JC Beyler wrote: > Hi all, > > Sorry to come back to this so late in the game, but somehow when I synced my > hg clone (or the

Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core

This looks good to me, Fairoz. Thanks, Jini. On 9/26/2018 1:37 PM, Fairoz Matte wrote: Hi Jini, Thanks for pointing out that, yes we cannot make that cleanup for JDK8. Keeping it very simple and taking only changes required to fix JDK-8164383 http://cr.openjdk.java.net/~fmatte/8164383/webrev.0

RE: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core

Hi Jini, thanks for the review. May I get one more review for this? Thanks, Fairoz > -Original Message- > From: Jini George > Sent: Friday, September 28, 2018 10:37 AM > To: Fairoz Matte ; serviceability- > d...@openjdk.java.net > Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps