Hi David, I would like to pass -XX args mainly to the debuggee which is launched by SetLocalWhileThreadInNative. There's no need to run SetLocalWhileThreadInNative in another vm.
Do you think this is a misuse? Thanks for looking at the patch, Richard. -----Original Message----- From: David Holmes <david.hol...@oracle.com> Sent: Freitag, 16. November 2018 05:43 To: Reingruber, Richard <richard.reingru...@sap.com>; serviceability-dev@openjdk.java.net Subject: Re: RFR(XXS): 8213902: com/sun/jdi/SetLocalWhileThreadInNative.java times out Hi Richard, I think your test is misusing @driver. If you want to pass -XX args you should be using "@run main/othervm" Otherwise turning off the Print* flags seems reasonable, but removing Xcomp as well seems unnecessary. Cheers, David On 16/11/2018 8:32 am, Reingruber, Richard wrote: > Hi, > > could I please get reviews for the following small patch? It fixes a bug in > the test > com/sun/jdi/SetLocalWhileThreadInNative.java that causes a deadlock when > executed with > -vmoption:-Xcomp. > > Deadlock: > > Debuggee (SetLocalWhileThreadInNativeTarget): > - running with -Xcomp > - still in early start-up > - printed a lot on tty already, because -XX:+PrintCompilation > -XX:+PrintInlining are given > - java thread waits for compiler thread to finish compile task > - compiler thread is blocked in write on tty. tty buffer is full, because > debugger is not yet > reading debuggee's output > > Debugger > - waiting until connection to debugger is established > > The fix is to remove -XX:+PrintCompilation -XX:+PrintInlining. In addition it > excludes the test if > running with -Xcomp, because that mode does not add a lot of value, as the > test actually only needs > dontinline_testMethod() to be compiled. Running with -Xcomp just wastes > energy. > > Webrev: http://cr.openjdk.java.net/~rrich/webrevs/2018/8213902/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8213902 > > The contribution needs to be sponsored as well, please. > > Thanks, Richard. >