Re: RFR JDK-8232222: Set state to 'linked' when an archived class is restored at runtime

Hi Jiangli,  I'm sorry I didn't see the whole thread because I filtered it to serviceability-dev.  I see you have answered some of these questions, there. Still reading. Coleen On 6/8/20 10:46 PM, coleen.phillim...@oracle.com wrote: Hi Jiangi, I apologize for jumping in at this late stag

Re: RFR JDK-8232222: Set state to 'linked' when an archived class is restored at runtime

(Posting on the right thread and list now...) On 6/9/20 2:26 AM, David Holmes wrote: Hi Jiangli, >    http://cr.openjdk.java.net/~jiangli/823/webrev.03/ I'm having trouble keeping track of all the issues, so let me walk through the changes as I see them: - InstanceKlass::restore_unshare

RFR: 8243290: Improve diagnostic messages for class verification and redefinition failures

Hello, Please review this simple change for improving diagnostics around class verification and linking failures: Bug: https://bugs.openjdk.java.net/browse/JDK-8243290 Webrev: http://cr.openjdk.java.net/~poonam/8243290/webrev.00/ Problem: During the class redefinition process, if a class veri

Re: RFR: 8243290: Improve diagnostic messages for class verification and redefinition failures

This change looks good  to me. Coleen On 6/9/20 10:46 AM, Poonam Parhar wrote: Hello, Please review this simple change for improving diagnostics around class verification and linking failures: Bug: https://bugs.openjdk.java.net/browse/JDK-8243290 Webrev: http://cr.openjdk.java.net/~poonam/8

RFR(s): 8247248: JVM TI might create JNI locals in another thread when using handshakes.

Hi all, If the direct handshake is executed by the target thread, the JNI local(s) are created in that thread but returned in the handshaking thread. They thus are not safe to use. (thread might even have exited by this point) Code: http://cr.openjdk.java.net/~rehn/8247248/v1/webrev/ Unfortunat

Re: RFR: 8243290: Improve diagnostic messages for class verification and redefinition failures

Hi, For some reason, my message filters are dropping messages. But I think Harold pointed out that if ex_msg is NULL then the logging will crash with %s in the change for both files. Coleen On 6/9/20 10:46 AM, Poonam Parhar wrote: Hello, Please review this simple change for improving diagn

Re: RFR: 8243290: Improve diagnostic messages for class verification and redefinition failures

Hi Poonam, Thank you for taking care about this! It looks good besides the comment from Harold and Coleen about ex_msg can be equal to NULL. Thanks, Serguei On 6/9/20 07:46, Poonam Parhar wrote: Hello, Please

Re: RFR(s): 8247248: JVM TI might create JNI locals in another thread when using handshakes.

Hi Robbin, Nice catch! The fix looks good in general. I'd be nice to add comments to explain why these global refs are created. Thanks, Serguei On 6/9/20 09:15, Robbin Ehn wrote: Hi all, If the direct handshake is executed by the target thread, the JNI local(s) are created in that thread bu

Re: RFR: 8243290: Improve diagnostic messages for class verification and redefinition failures

Thanks Serguei! regards, Poonam On 6/9/20 10:56 AM, serguei.spit...@oracle.com wrote: Hi Poonam, Thank you for taking care about this! It looks good besides the comment from Harold and Coleen about ex_msg can be equal to NULL. Thanks, Serguei On 6/9/20 07:46, Poonam Parhar wrote: Hello,

Re: RFR: 8243290: Improve diagnostic messages for class verification and redefinition failures

Thanks Coleen! I will fix the null string issue. regards, Poonam On 6/9/20 9:59 AM, coleen.phillim...@oracle.com wrote: Hi, For some reason, my message filters are dropping messages. But I think Harold pointed out that if ex_msg is NULL then the logging will crash with %s in the change for b

Re: RFR: 8242891: vmTestbase/nsk/jvmti/ test should be fixed to fail early if JVMTI function return error

Hi Leonid, Thank you for taking care about this! It looks good in general. However, I think, a similar return is needed in more cases. One example: http://cr.openjdk.java.net/~lmesnik/8242891/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/E

Re: RFR(s): 8243451: nsk.share.jdi.Debugee.isJFR_active() is incorrect and corresponsing logic seems to be broken

http://cr.openjdk.java.net/~fmatte/8243451/webrev.09/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/TestDebuggerType2.java.udiff.html I see that isJFRActive() depends on "nsk.share.jdi.HeapwalkingDebuggee". It is not going to work of debugee is not "nsk.share.jdi.HeapwalkingDebuggee". Shouldn't

Re: RFR: 8242891: vmTestbase/nsk/jvmti/ test should be fixed to fail early if JVMTI function return error

Hi On 6/9/20 12:34 PM, serguei.spit...@oracle.com wrote: Hi Leonid, Thank you for taking care about this! It looks good in general. However, I think, a similar return is needed in more cases. One example: http://cr.openjdk.java.net/~lmesnik/8242891/webrev.00/test/hotspot/jtreg/vmTestbase/nsk

RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump

Hi Ralf, I finally managed to fully read through your change. Very nice piece of work. I only found a few minor nits which would be nice if you could address them before pushing. But no need for further webrev. Here we go: workgroup.cpp - update copyright year L111: little spelling issue: forer

RFR(S) : 8183040 : update jdk/test/lib/Platform.java to use NIO file API

http://cr.openjdk.java.net/~iignatyev//8183040/webrev.00 > > 38 lines changed: 8 ins; 16 del; 14 mod; Hi all, could you please review this small clean up of testlibrary classes which updates j.t.lib.Platform and j.t.l.SA.SATestUtils (as it now contains the methods which 8183040 was about) to

Re: RFR(S) : 8183040 : update jdk/test/lib/Platform.java to use NIO file API

Hi Igor, > On Jun 9, 2020, at 4:47 PM, Igor Ignatyev wrote: > > could you please review this small clean up of testlibrary classes which > updates j.t.lib.Platform and j.t.l.SA.SATestUtils (as it now contains the > methods which 8183040 was about) to use NIO file API? > > testing: test/hotspo

Re: RFR(S) : 8183040 : update jdk/test/lib/Platform.java to use NIO file API

Hi Igor, In SATestUtils.java you do var bb = ... Files.readAllBytes(...) ... and then use bb[0] if the file has 0 length, old code throws EOFException and new one will throw IndexOutOfBoundsException. And looks like the caller doesn't expect it (it catches IOException). --alex On 06/09/2020

Re: RFR: 8242891: vmTestbase/nsk/jvmti/ test should be fixed to fail early if JVMTI function return error

On 6/9/20 12:58, Leonid Mesnik wrote: Hi On 6/9/20 12:34 PM, serguei.spit...@oracle.com wrote: Hi Leonid, Thank you for taking care about this! It looks good in general. However, I think, a simila

Re: RFR(s): 8247248: JVM TI might create JNI locals in another thread when using handshakes.

Hi Robbin, On 10/06/2020 2:15 am, Robbin Ehn wrote: Hi all, If the direct handshake is executed by the target thread, the JNI local(s) are created in that thread but returned in the handshaking thread. They thus are not safe to use. (thread might even have exited by this point) Code: http://cr

Re: RFR(S) : 8183040 : update jdk/test/lib/Platform.java to use NIO file API

Hi Alex, as far as I can see, the caller just rethrows IOException as RuntimeException, so I don't think throwing IndexOutOfBoundsException would be much different, albeit it will be a bit more cryptic. yet given the content of /proc/sys/kernel/yama/ptrace_scope and /sys/fs/selinux/booleans/den

Re: RFR(S) : 8183040 : update jdk/test/lib/Platform.java to use NIO file API

Hi Brian, thank you for your review. Cheers, -- Igor > On Jun 9, 2020, at 5:18 PM, Brian Burkhalter > wrote: > > Hi Igor, > >> On Jun 9, 2020, at 4:47 PM, Igor Ignatyev > > wrote: >> >> could you please review this small clean up of testlibrary classes whic

Retroactive CSR review request(XS): 8246811: Update JDWP, JDI and Instrumentation specs for Record attribute

Please, review a retroactive CSR for fix integrated to 14:   https://bugs.openjdk.java.net/browse/JDK-8235360 CSR:   https://bugs.openjdk.java.net/browse/JDK-8246811 Summary:   It is formal public request.   The CSR was alrea

Re: Retroactive CSR review request(XS): 8246811: Update JDWP, JDI and Instrumentation specs for Record attribute

Thanks, David! Serguei On 6/9/20 22:29, David Holmes wrote: Hi Serguei, I've added my review as well. The request can be Finalized. Thanks, David On 10/06/2020 3:08 pm, serguei.spit...@oracle.com wrote: Please, review a retroactive CSR for fix integrated to 14: https://bugs.openjdk.java.net

Re: Retroactive CSR review request(XS): 8246811: Update JDWP, JDI and Instrumentation specs for Record attribute

Hi Serguei, I've added my review as well. The request can be Finalized. Thanks, David On 10/06/2020 3:08 pm, serguei.spit...@oracle.com wrote: Please, review a retroactive CSR for fix integrated to 14: https://bugs.openjdk.java.net/browse/JDK-8235360 CSR: https://bugs.openjdk.java.net/browse/

RE: RFR(s): 8243451: nsk.share.jdi.Debugee.isJFR_active() is incorrect and corresponsing logic seems to be broken

Hi Leonid, The call isJFRActive() need to be executed on HeapwalkingDebuggee side. This is what my understanding is. Thanks, Fairoz > -Original Message- > From: Leonid Mesnik > Sent: Wednesday, June 10, 2020 1:16 AM > To: Serguei Spitsyn ; Fairoz Matte > ; Erik Gahlin > Cc: serviceabil

Re: RFR(s): 8243451: nsk.share.jdi.Debugee.isJFR_active() is incorrect and corresponsing logic seems to be broken

Hi Fairoz, It is confusing there is methods with the same name isJFRActive on both debuggee and debugger side. Leonid is talking about the isJFRActive that belongs to the debugger. He suggests to move this method from the TestDebuggerType2 to HeapWalkingDebugger. The reason is the HeapWalking

RE: RFR(s): 8243451: nsk.share.jdi.Debugee.isJFR_active() is incorrect and corresponsing logic seems to be broken

Hi Serguei, Thanks for the clarification. I will work on to move isJFRActive () method from the TestDebuggerType2 to HeapWalkingDebugger Thanks, Fairoz > -Original Message- > From: Serguei Spitsyn > Sent: Wednesday, June 10, 2020 11:42 AM > To: Fairoz Matte ; Leonid Mesnik > ; Erik Gah

RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump

Hi Christoph, thanks for your review. I've incorporated your changes. I will run the relevant tests again and if no problems show up, I will submit the change later this day. Best regards, Ralf -Original Message- From: Langer, Christoph Sent: Tuesday, 9 June 2020 22:23 To: Schmelter