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.
> 

Reply via email to