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

David Holmes david.holmes at oracle.com
Fri Nov 16 04:40:09 UTC 2018


Hi Jc,

If I may put in my 2c ...

On 16/11/2018 2:13 pm, JC Beyler wrote:
> 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?

This is just a limitation of connecting process streams via finite 
pipes. If the pipe can fill before the target process reaches the point 
where it communicates back to the initial process (which would trigger 
the initial process to start draining the pipe) then you effectively 
deadlock.

So you either structure the tests so that they work correctly with the 
finite pipes provided by the test scaffold, or you modify the test 
scaffold to either provide a bigger pipe or else rework it to ensure 
pipes can't fill and cause indefinite blocking.

For the case at hand fixing the test to not be so verbose is reasonable 
in my opinion, though I'm not sure I'd remove Xcomp altogether as Xcomp 
likes a range of programs to put it through its paces.

But it wouldn't be unreasonable to file a RFE to make the TestScaffold 
handle this better.

Cheers,
David

> 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 <mailto: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


More information about the serviceability-dev mailing list