Re: RFR: JDK-8245660: Try to recover from "Windbg Error: WaitForEvent failed" error

Hi Chris, On 05/22/2020 17:12, Chris Plummer wrote: Hi Alex, I think this is a good experiment, but I don't really see a reason to push the change and wait for a failure to pop up in CI testing. I think you should be able to get the data you are looking for with adhoc runs. I find it pretty

Re: RFR: JDK-8244703: "platform encoding not initialized" exceptions with debugger, JNI

Hi Serguei, thanks for the review. On 05/22/2020 12:47, serguei.spit...@oracle.com wrote: Hi Alex, The fix looks good. > And I'm not sure why len+len/2+2 is used there. > In my fix I allocated len*4+1 (for the worst case - each symbol requires 4 bytes to encode plus 1 byte for terminal 0).

Re: RFR: JDK-8245660: Try to recover from "Windbg Error: WaitForEvent failed" error

Hi Alex, I think this is a good experiment, but I don't really see a reason to push the change and wait for a failure to pop up in CI testing. I think you should be able to get the data you are looking for with adhoc runs. I find it pretty easy to reproduce by just running all the SA tests ab

RFR: JDK-8245660: Try to recover from "Windbg Error: WaitForEvent failed" error

Hi all, Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8245660 webrev: http://cr.openjdk.java.net/~amenkov/jdk15/windbg_waitForEvent_try/webrev/ This is temporary change to try different approaches to fix https://bugs.openjdk.java.net/browse/JDK-8204994 (SA might fail to att

Re: RFR: JDK-8244703: "platform encoding not initialized" exceptions with debugger, JNI

Hi Alex, The fix looks good. > And I'm not sure why len+len/2+2 is used there. > In my fix I allocated len*4+1 (for the worst case - each symbol requires 4 bytes to encode plus 1 byte for terminal 0). I agree, the size len+len/2+2 looks very strange. Most likely, we get error messages truncat

Re: RFR: 8131745: java/lang/management/ThreadMXBean/AllThreadIds.java still fails intermittently

I was thinking in a similar direction. It is better to count only tested threads instead of the unreliable and expensive retries. Thanks, Serguei On 5/22/20 10:26, Alex Menkov wrote: Hi Daniil, I'm not sure all this retry logic is a good way. As mentioned in jira the most important part of t

Re: PING: Re: RFR (XS): 8244571: assert(!_thread->is_pending_jni_exception_check()) failed: Pending JNI Exception Check during class loading

Thank you for the review, Chris! Serguei On 5/22/20 11:57, Chris Plummer wrote: Hi Serguei, Looks good, and I agree with David's comments. I was thinking the same thing when I first looked at your original changes. thanks, Chris On 5/22/20 2:32 AM, serguei.spit...@oracle.com wrote: Hi

Re: PING: Re: RFR (XS): 8244571: assert(!_thread->is_pending_jni_exception_check()) failed: Pending JNI Exception Check during class loading

Hi Serguei, Looks good, and I agree with David's comments. I was thinking the same thing when I first looked at your original changes. thanks, Chris On 5/22/20 2:32 AM, serguei.spit...@oracle.com wrote: Hi David, The updated webrev is with your comments addressed: http://cr.openjdk.java.ne

Re: RFR: 8244993: Revert changes to OutputAnalyzer stderrShouldBeEmptyIgnoreVMWarnings() that allow version strings

Hi Daniil, There is one reference to "jvmwarningmsg" that occurs before it is declared while all the rest all come after. It probably would make sense to move its declaration up near the top of the file.   92 private static void matchListedProcesses(OutputAnalyzer output) {   93 o

Re: RFR (XS): 8245392: Remove duplication in class redefinition and retransformation specs

Hi Chris, Thank you for the review! I'll make it consistent. Thanks, Serguei On 5/22/20 11:33, Chris Plummer wrote: Hi Serguei, Just one very minor editing suggestion. Where you have "If canUnrestrictedlyRedefineClasses() is false," there is a comma placed here, but the previous two bullet

Re: RFR: JDK-8244703: "platform encoding not initialized" exceptions with debugger, JNI

Hi Alan, thank you for the review. On 05/22/2020 11:16, Alan Bateman wrote: On 22/05/2020 18:50, Alex Menkov wrote: Hi all, please review the fix for https://bugs.openjdk.java.net/browse/JDK-8244703 webrev: http://cr.openjdk.java.net/~amenkov/jdk15/jdwp_javalib_dep/webrev/ The issue is a reg

Re: RFR (XS): 8245392: Remove duplication in class redefinition and retransformation specs

Hi Serguei, Just one very minor editing suggestion. Where you have "If canUnrestrictedlyRedefineClasses() is false," there is a comma placed here, but the previous two bullet items are of a similar form, yet have no comma. I suggest you make all 3 consisten

Re: RFR: JDK-8244703: "platform encoding not initialized" exceptions with debugger, JNI

On 22/05/2020 18:50, Alex Menkov wrote: Hi all, please review the fix for https://bugs.openjdk.java.net/browse/JDK-8244703 webrev: http://cr.openjdk.java.net/~amenkov/jdk15/jdwp_javalib_dep/webrev/ The issue is a regression from JDK-8222529 which introduced dependency jdwp lib of java lib. The

Re: RFR: 8131745: java/lang/management/ThreadMXBean/AllThreadIds.java still fails intermittently

I don't think this approach adds any value to test coverage. We have other tests which are targeted to test the methods. IMO the test can still test the methods, but with relaxed conditions. maybe something like 1. at the beginning: getTotalStartedThreadCount() >= 1, getThreadCount() >= 1 ge

Re: RFR: 8131745: java/lang/management/ThreadMXBean/AllThreadIds.java still fails intermittently

Hi Alex, I was thinking about it as well. But the test also indirectly tests getTotalStartedThreadCount(), getThreadCount(), and getPeakThreadCount() methods of ThreadMXBean. So I tried to not reduce the test coverage. Best regards, Daniil On 5/22/20, 10:26 AM, "Alex Menkov" wrote: Hi

RFR: JDK-8244703: "platform encoding not initialized" exceptions with debugger, JNI

Hi all, please review the fix for https://bugs.openjdk.java.net/browse/JDK-8244703 webrev: http://cr.openjdk.java.net/~amenkov/jdk15/jdwp_javalib_dep/webrev/ The issue is a regression from JDK-8222529 which introduced dependency jdwp lib of java lib. The fix removes the dependency and implement

Re: RFR: 8131745: java/lang/management/ThreadMXBean/AllThreadIds.java still fails intermittently

Hi Daniil, I'm not sure all this retry logic is a good way. As mentioned in jira the most important part of the testing is ensuring that you find all the created threads when they are alive, and you don't find them when they are dead. The actual thread count checking is not that important. I a

Re: RFR: JDK-8225056 VM support for sealed classes

Thanks Lois! I'll add the two ResourceMarks before the changes get pushed. Harold On 5/22/2020 11:07 AM, Lois Foltan wrote: On 5/21/2020 2:33 PM, Harold Seigel wrote: Hi David, Thanks for looking at this!  Please review this new webrev:    http://cr.openjdk.java.net/~hseigel/webrev.01/webre

Re: RFR: JDK-8225056 VM support for sealed classes

On 5/21/2020 2:33 PM, Harold Seigel wrote: Hi David, Thanks for looking at this!  Please review this new webrev:    http://cr.openjdk.java.net/~hseigel/webrev.01/webrev/ Hi Harold, I think this webrev looks good!  A couple of minor comments: - oops/instanceKlass.cpp:   line #236, do you nee

Re: PING: Re: RFR (XS): 8244571: assert(!_thread->is_pending_jni_exception_check()) failed: Pending JNI Exception Check during class loading

Hi David, The updated webrev is with your comments addressed: http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/8244571-jvmti-test-jnicheck.2/ Thanks, Serguei On 5/22/20 00:43, serguei.spit...@oracle.com wrote: Hi David, Thank you for the comments! On 5/21/20 23:58, David Holmes wrote: Hi

Re: PING: Re: RFR (XS): 8244571: assert(!_thread->is_pending_jni_exception_check()) failed: Pending JNI Exception Check during class loading

Hi David, Thank you for the comments! On 5/21/20 23:58, David Holmes wrote: Hi Serguei, On 22/05/2020 4:17 pm, serguei.spit...@oracle.com wrote: PING: This is pretty small and easy to review fix. Thanks! Serguei On 5/19/20 09:28, serguei.spit...@oracle.com wrote: Please, review fix for:

Re: RFR: 8244993: Revert changes to OutputAnalyzer stderrShouldBeEmptyIgnoreVMWarnings() that allow version strings

Hi Daniil, On 22/05/2020 5:24 pm, Daniil Titov wrote: Hi David, Some tiers in Mach5 are configured to run tests with '-showversion' VM options. In JDK-8242009 [3] we started forwarding test VM options to j-*tools Okay. Filtering it out seems fine then. Thanks, David and some tests that l

Re: RFR: 8244993: Revert changes to OutputAnalyzer stderrShouldBeEmptyIgnoreVMWarnings() that allow version strings

Hi David, Some tiers in Mach5 are configured to run tests with '-showversion' VM options. In JDK-8242009 [3] we started forwarding test VM options to j-*tools and some tests that launch them and expect an empty stderr (apart from VM warnings) need to be corrected to either ignore version messa

Re: PING: Re: RFR (XS): 8244571: assert(!_thread->is_pending_jni_exception_check()) failed: Pending JNI Exception Check during class loading

Hi Serguei, On 22/05/2020 4:17 pm, serguei.spit...@oracle.com wrote: PING: This is pretty small and easy to review fix. Thanks! Serguei On 5/19/20 09:28, serguei.spit...@oracle.com wrote: Please, review fix for: https://bugs.openjdk.java.net/browse/JDK-8244571 Webrev: http://cr.openjdk.java