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

[Chris Plummer]

See https://bugs.openjdk.java.net/browse/JDK-8173304 and also 
https://bugs.openjdk.java.net/browse/JDK-4368399, which dates back to 2000.

Chris

On 11/15/18 8:40 PM, David Holmes wrote:
> 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