Re: RFR: 8227269: Slow class loading when running JVM in debug mode

Sorry, forgot to complete my comments at the end (see below). On 3/15/20 23:57, serguei.spit...@oracle.com wrote: Hi Roman, Thank you for the update and sorry for the latency in review. Some comments are below.

Re: RFR: 8240956: SEGV in DwarfParser::process_dwarf after JDK-8234624

Sorry it is still crashing. # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x7f98ec01e94e, pid=13702, tid=13704 # # JRE version: Java(TM) SE Runtime Environment (15.0) (fastdebug build 15-internal+0-2020-03-16-0640217.suenaga.source) # Java VM:

Re: RFR: 8196751: Add jhsdb option to specify debug server RMI connector port

Hi Daniil, The update looks pretty good to me so far. I'll make another pass tomorrow. Thanks, Serguei On 3/13/20 15:05, Daniil Titov wrote: Hi Yasumasa, Serguei and Alex, Please review a new version of the webrev that includes the changes Yasumasa suggested. Shutdown hook is already regi

Re: RFR(L): 8215624: add parallel heap inspection support for jmap histo(G1)

Just update a new path, my preliminary measure show about 3.5x speedup of jmap histo on a nearly full 4GB G1 heap (8-core platform with parallel thread number set to 4). webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_02/ bug: https://bugs.openjdk.java.net/browse/JDK-821562

Re: RFR: 8240956: SEGV in DwarfParser::process_dwarf after JDK-8234624

Hi David, I missed loop condition, so I fixed it and pushed to submit repo. Could you try again? http://hg.openjdk.java.net/jdk/submit/rev/9c148df17f23 webrev is here: http://cr.openjdk.java.net/~ysuenaga/JDK-8240956/webrev.02/ Thanks a lot! Yasumasa On 2020/03/16 16:17, David Holmes

Re: RFR: 8240956: SEGV in DwarfParser::process_dwarf after JDK-8234624

On 16/03/2020 7:20 pm, Yasumasa Suenaga wrote: Hi David, I missed loop condition, so I fixed it and pushed to submit repo. Could you try again?   http://hg.openjdk.java.net/jdk/submit/rev/9c148df17f23 webrev is here:   http://cr.openjdk.java.net/~ysuenaga/JDK-8240956/webrev.02/ Test job r

Re: RFR: 8240956: SEGV in DwarfParser::process_dwarf after JDK-8234624

Thank you so much, David! Yasumasa On 2020/03/16 21:01, David Holmes wrote: On 16/03/2020 9:46 pm, David Holmes wrote: On 16/03/2020 7:20 pm, Yasumasa Suenaga wrote: Hi David, I missed loop condition, so I fixed it and pushed to submit repo. Could you try again?    http://hg.openjdk.java.n

Re: RFR: 8240956: SEGV in DwarfParser::process_dwarf after JDK-8234624

On 16/03/2020 9:46 pm, David Holmes wrote: On 16/03/2020 7:20 pm, Yasumasa Suenaga wrote: Hi David, I missed loop condition, so I fixed it and pushed to submit repo. Could you try again?    http://hg.openjdk.java.net/jdk/submit/rev/9c148df17f23 webrev is here:    http://cr.openjdk.java.net/~

Re: RFR: 8240956: SEGV in DwarfParser::process_dwarf after JDK-8234624

Hi all, This webrev has passed submit repo (mach5-one-ysuenaga-JDK-8240956-20200316-0924-9487169) and additional tests. So please review it: JBS: https://bugs.openjdk.java.net/browse/JDK-8240956 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8240956/webrev.02/ Thanks, Yasumasa On

Re: RFR(L) 8238268: Many SA tests are not running on OSX because they do not attempt to use sudo when available

I had to make another change. TestMutuallyExclusivePlatformPredicates.java failed when I ran tier 3. I had fixed it a long while back due to Platform.shouldSAAttach() being removed, but there were more changes to Platform.java after that that I didn't

Re: RFR(L) 8238268: Many SA tests are not running on OSX because they do not attempt to use sudo when available

On 3/16/20 11:26, Chris Plummer wrote: I had to make another change. TestMutuallyExclusivePlatformPredicates.java failed when I ran tier 3. I had fixed it a long while back due to Platform.shouldSAAttach() being removed, but there were mo

RFR: 8240711: TestJstatdPort.java failed due to "ExportException: Port already in use:"

Please review the change [1] that fixes the intermittent failure of the test. The problem here is that if the RMI port is in use than the test keep waiting for "jstatd started (bound to " to appear in the process output and in this case It doesn't happen. at java.util.concurrent.CountDo

Re: RFR(L) 8238268: Many SA tests are not running on OSX because they do not attempt to use sudo when available

> On Mar 16, 2020, at 11:43 AM, "serguei.spit...@oracle.com" > wrote: > >  >> On 3/16/20 11:26, Chris Plummer wrote: >> I had to make another change. TestMutuallyExclusivePlatformPredicates.java >> failed when I ran tier 3. I had fixed it a long while back due to >> Platform.shouldSAAttach(

Re: RFR: 8240711: TestJstatdPort.java failed due to "ExportException: Port already in use:"

Hi Daniil, Looks like the test is supposed to handle "port in use" issue (see lines 103-114). I suppose in case "port in use" jstatd exits, but ProcessTools.startProcess() continue to wait for "jstatd started" message. --alex On 03/16/2020 12:00, Daniil Titov wrote: Please review the change

Re: 8240711: TestJstatdPort.java failed due to "ExportException: Port already in use:"

Hi Alex, Yes, you are right, class JstatdTest has the code that is supposed to handle the "port in use" case but at least for this specific test sun/tools/jstatd/TestJstatdPort.java is doesn't work. Since there are multiple tests in sun/tools/jstatd/* folder that use this class and different

Re: RFR: 8240711: TestJstatdPort.java failed due to "ExportException: Port already in use:"

Resending with the corrected subject ... Hi Alex, Yes, you are right, class JstatdTest has the code that is supposed to handle the "port in use" case but at least for this specific test (sun/tools/jstatd/TestJstatdPort.java) it doesn't work. Since there are multiple tests in sun/tools/jstatd/

Re: RFR: 8240711: TestJstatdPort.java failed due to "ExportException: Port already in use:"

I don't agree. The code handles exact the same "port in use" case for the same tool. So it either works or doesn't. And have 2 code blocks which suppose to do the same makes the code messy. BTW did you tested the change (I mean craft the test to get "port in use" error)? --alex On 03/16/2020 1

Re: RFR(L) 8238268: Many SA tests are not running on OSX because they do not attempt to use sudo when available

Hi Serguei and Igor, New webrev: http://cr.openjdk.java.net/~cjplummer/8238268/webrev.02/index.html Only files changed were Platform.java and SATestUtils.java. -Moved canPtraceAttachLinux() from Platform.java to SATestUtils.java

Re: RFR(L) 8238268: Many SA tests are not running on OSX because they do not attempt to use sudo when available

Hi Chris, does canPtraceAttachLinux have to be public? otherwise, looks good to me. -- Igor > On Mar 16, 2020, at 5:11 PM, Chris Plummer wrote: > > Hi Serguei and Igor, > > New webrev: > > http://cr.openjdk.java.net/~cjplummer/8238268/webrev.02/index.html >

Re: RFR(L) 8238268: Many SA tests are not running on OSX because they do not attempt to use sudo when available

Hi Chris, +1 No need in another webrev. Thanks, Serguei On 3/16/20 17:14, Igor Ignatyev wrote: Hi Chris, does canPtraceAttachLinux have to be public? otherwise, looks good to

Re: RFR: 8240711: TestJstatdPort.java failed due to "ExportException: Port already in use:"

Hi Alex, Yes, I did test the change by modifying the test to use the RMI port that is already in use ( the stack trace in the original email was exact from this changed test) and then ensured that with the fix the such issue is properly handled. I will send a new version of the webrev that r

Re: RFR(L) 8238268: Many SA tests are not running on OSX because they do not attempt to use sudo when available

No it doesn't. I'll change that. thanks, Chris On 3/16/20 5:14 PM, Igor Ignatyev wrote: Hi Chris, does canPtraceAttachLinux have to be public? otherwise, looks good to me.