RFR(XXS): 8213902: com/sun/jdi/SetLocalWhileThreadInNative.java times out

[JC Beyler]

Hi Richard,

Is this not a test that's failing due to a real bug? Ie: if someone were to
really be running the program in this configuration (with printcompilation
and printinlining) and attaching a debugger, would they not reach the same
issue?

Should that not be fixed in some way instead? Or is this such an improbable
case that we just consider it ludicrous?

Thanks,
Jc

On Thu, Nov 15, 2018 at 2:32 PM Reingruber, Richard <
richard.reingruber at sap.com> 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.



-- 

Thanks,
Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20181115/24c076a9/attachment.html>