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

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Reingruber, Richard
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 | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

David Holmes
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
> <[hidden email] <mailto:[hidden email]>> 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
Reply | Threaded
Open this post in threaded view
|

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

David Holmes
In reply to this post by Reingruber, Richard
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 | Threaded
Open this post in threaded view
|

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

Chris Plummer
In reply to this post by David Holmes
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
>> <[hidden email] <mailto:[hidden email]>> 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



Reply | Threaded
Open this post in threaded view
|

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

Reingruber, Richard
In reply to this post by David Holmes
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 <[hidden email]>
Sent: Freitag, 16. November 2018 05:43
To: Reingruber, Richard <[hidden email]>; [hidden email]
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 | Threaded
Open this post in threaded view
|

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

Reingruber, Richard
In reply to this post by Chris Plummer
Hi Jc, David, Chris,

  >> Is this not a test that's failing due to a real bug?

I would not consider this a bug, but rather a limitation. I don't see a way to
work around it in the TestScaffold, though (looking at [1]).

So an enhancement would have to happen in the jdi implementation. To me it does
not seem worth the effort. I'd say the tracing is not necessary for regression
testing. In the case of a test error where all that output is required, I'd
start the debuggee in a shell and do the debugging manually.

Regarding -Xcomp: makes a lot of sense for tests that are indifferent about the
execution mode. The test at hand triggers compilation of the central test
method. It does not help that much, to compile everything else, too.

Anyway, here is another webrev without excluding -Xcomp:

http://cr.openjdk.java.net/~rrich/webrevs/2018/8213902/webrev.02/

I'd prefer the original webrev, because it's greener ;)

I would need a sponsor, too. Please take either one of the patches.

Thanks for reviewing,
Richard.

[1] Debugger stack

java.lang.Object.wait(long) line: not available [native method]
com.sun.tools.jdi.AbstractLauncher$Helper(java.lang.Object).wait() line: 328
com.sun.tools.jdi.AbstractLauncher$Helper.launchAndAccept() line: 197
com.sun.tools.jdi.SunCommandLineLauncher(com.sun.tools.jdi.AbstractLauncher).launch(java.lang.String[], java.lang.String, com.sun.jdi.connect.spi.TransportService$ListenKey, com.sun.jdi.connect.spi.TransportService) line: 140
com.sun.tools.jdi.SunCommandLineLauncher.launch(java.util.Map<java.lang.String,? extends com.sun.jdi.connect.Connector.Argument>) line: 229
VMConnection.launchTarget() line: 314
VMConnection.open() line: 149
SetLocalWhileThreadInNative(TestScaffold).connect(java.lang.String[]) line: 637
SetLocalWhileThreadInNative(TestScaffold).startUp(java.lang.String) line: 364
SetLocalWhileThreadInNative(TestScaffold).startTo(java.lang.String, java.lang.String, java.lang.String) line: 374
SetLocalWhileThreadInNative(TestScaffold).startToMain(java.lang.String) line: 369
SetLocalWhileThreadInNative.runTests() line: 132
SetLocalWhileThreadInNative(TestScaffold).startTests() line: 431
SetLocalWhileThreadInNative.main(java.lang.String[]) line: 120

-----Original Message-----
From: Chris Plummer <[hidden email]>
Sent: Freitag, 16. November 2018 06:23
To: David Holmes <[hidden email]>; JC Beyler <[hidden email]>; Reingruber, Richard <[hidden email]>
Cc: [hidden email]
Subject: Re: RFR(XXS): 8213902: com/sun/jdi/SetLocalWhileThreadInNative.java times out

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
>> <[hidden email] <mailto:[hidden email]>> 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



Reply | Threaded
Open this post in threaded view
|

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

JC Beyler
In reply to this post by David Holmes
Hi David,

Thanks for the explanation :) That makes sense to me,
Jc

On Thu, Nov 15, 2018 at 8:40 PM David Holmes <[hidden email]> 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
> <[hidden email] <mailto:[hidden email]>> 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


--

Thanks,
Jc
Reply | Threaded
Open this post in threaded view
|

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

David Holmes
In reply to this post by Reingruber, Richard
On 17/11/2018 1:32 am, Reingruber, Richard wrote:
> 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.

Sorry Richard I misread the driver line and didn't notice that these are
actually "application" args that the test then uses for its internal
launch of the debuggee.

Thanks,
David

> Do you think this is a misuse?
>
> Thanks for looking at the patch,
> Richard.
>
> -----Original Message-----
> From: David Holmes <[hidden email]>
> Sent: Freitag, 16. November 2018 05:43
> To: Reingruber, Richard <[hidden email]>; [hidden email]
> 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 | Threaded
Open this post in threaded view
|

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

David Holmes
In reply to this post by Reingruber, Richard
Hi Richard,

I'll sponsor this over the weekend.

Thanks,
David

On 17/11/2018 1:37 am, Reingruber, Richard wrote:

> Hi Jc, David, Chris,
>
>    >> Is this not a test that's failing due to a real bug?
>
> I would not consider this a bug, but rather a limitation. I don't see a way to
> work around it in the TestScaffold, though (looking at [1]).
>
> So an enhancement would have to happen in the jdi implementation. To me it does
> not seem worth the effort. I'd say the tracing is not necessary for regression
> testing. In the case of a test error where all that output is required, I'd
> start the debuggee in a shell and do the debugging manually.
>
> Regarding -Xcomp: makes a lot of sense for tests that are indifferent about the
> execution mode. The test at hand triggers compilation of the central test
> method. It does not help that much, to compile everything else, too.
>
> Anyway, here is another webrev without excluding -Xcomp:
>
> http://cr.openjdk.java.net/~rrich/webrevs/2018/8213902/webrev.02/
>
> I'd prefer the original webrev, because it's greener ;)
>
> I would need a sponsor, too. Please take either one of the patches.
>
> Thanks for reviewing,
> Richard.
>
> [1] Debugger stack
>
> java.lang.Object.wait(long) line: not available [native method]
> com.sun.tools.jdi.AbstractLauncher$Helper(java.lang.Object).wait() line: 328
> com.sun.tools.jdi.AbstractLauncher$Helper.launchAndAccept() line: 197
> com.sun.tools.jdi.SunCommandLineLauncher(com.sun.tools.jdi.AbstractLauncher).launch(java.lang.String[], java.lang.String, com.sun.jdi.connect.spi.TransportService$ListenKey, com.sun.jdi.connect.spi.TransportService) line: 140
> com.sun.tools.jdi.SunCommandLineLauncher.launch(java.util.Map<java.lang.String,? extends com.sun.jdi.connect.Connector.Argument>) line: 229
> VMConnection.launchTarget() line: 314
> VMConnection.open() line: 149
> SetLocalWhileThreadInNative(TestScaffold).connect(java.lang.String[]) line: 637
> SetLocalWhileThreadInNative(TestScaffold).startUp(java.lang.String) line: 364
> SetLocalWhileThreadInNative(TestScaffold).startTo(java.lang.String, java.lang.String, java.lang.String) line: 374
> SetLocalWhileThreadInNative(TestScaffold).startToMain(java.lang.String) line: 369
> SetLocalWhileThreadInNative.runTests() line: 132
> SetLocalWhileThreadInNative(TestScaffold).startTests() line: 431
> SetLocalWhileThreadInNative.main(java.lang.String[]) line: 120
>
> -----Original Message-----
> From: Chris Plummer <[hidden email]>
> Sent: Freitag, 16. November 2018 06:23
> To: David Holmes <[hidden email]>; JC Beyler <[hidden email]>; Reingruber, Richard <[hidden email]>
> Cc: [hidden email]
> Subject: Re: RFR(XXS): 8213902: com/sun/jdi/SetLocalWhileThreadInNative.java times out
>
> 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
>>> <[hidden email] <mailto:[hidden email]>> 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
>
>
>
Reply | Threaded
Open this post in threaded view
|

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

David Holmes
Version 2 pushed.

Richard: I'm unclear about your Author status as you are somehow only
listed as a JDK 9 Author ? And I thought all existing Authors were
automatically added to the JDK project.

Cheers,
David

On 17/11/2018 8:34 am, David Holmes wrote:

> Hi Richard,
>
> I'll sponsor this over the weekend.
>
> Thanks,
> David
>
> On 17/11/2018 1:37 am, Reingruber, Richard wrote:
>> Hi Jc, David, Chris,
>>
>>    >> Is this not a test that's failing due to a real bug?
>>
>> I would not consider this a bug, but rather a limitation. I don't see
>> a way to
>> work around it in the TestScaffold, though (looking at [1]).
>>
>> So an enhancement would have to happen in the jdi implementation. To
>> me it does
>> not seem worth the effort. I'd say the tracing is not necessary for
>> regression
>> testing. In the case of a test error where all that output is
>> required, I'd
>> start the debuggee in a shell and do the debugging manually.
>>
>> Regarding -Xcomp: makes a lot of sense for tests that are indifferent
>> about the
>> execution mode. The test at hand triggers compilation of the central test
>> method. It does not help that much, to compile everything else, too.
>>
>> Anyway, here is another webrev without excluding -Xcomp:
>>
>> http://cr.openjdk.java.net/~rrich/webrevs/2018/8213902/webrev.02/
>>
>> I'd prefer the original webrev, because it's greener ;)
>>
>> I would need a sponsor, too. Please take either one of the patches.
>>
>> Thanks for reviewing,
>> Richard.
>>
>> [1] Debugger stack
>>
>> java.lang.Object.wait(long) line: not available [native method]
>> com.sun.tools.jdi.AbstractLauncher$Helper(java.lang.Object).wait()
>> line: 328
>> com.sun.tools.jdi.AbstractLauncher$Helper.launchAndAccept() line: 197
>> com.sun.tools.jdi.SunCommandLineLauncher(com.sun.tools.jdi.AbstractLauncher).launch(java.lang.String[],
>> java.lang.String, com.sun.jdi.connect.spi.TransportService$ListenKey,
>> com.sun.jdi.connect.spi.TransportService) line: 140
>> com.sun.tools.jdi.SunCommandLineLauncher.launch(java.util.Map<java.lang.String,?
>> extends com.sun.jdi.connect.Connector.Argument>) line: 229
>> VMConnection.launchTarget() line: 314
>> VMConnection.open() line: 149
>> SetLocalWhileThreadInNative(TestScaffold).connect(java.lang.String[])
>> line: 637
>> SetLocalWhileThreadInNative(TestScaffold).startUp(java.lang.String)
>> line: 364
>> SetLocalWhileThreadInNative(TestScaffold).startTo(java.lang.String,
>> java.lang.String, java.lang.String) line: 374
>> SetLocalWhileThreadInNative(TestScaffold).startToMain(java.lang.String) line:
>> 369
>> SetLocalWhileThreadInNative.runTests() line: 132
>> SetLocalWhileThreadInNative(TestScaffold).startTests() line: 431
>> SetLocalWhileThreadInNative.main(java.lang.String[]) line: 120
>>
>> -----Original Message-----
>> From: Chris Plummer <[hidden email]>
>> Sent: Freitag, 16. November 2018 06:23
>> To: David Holmes <[hidden email]>; JC Beyler
>> <[hidden email]>; Reingruber, Richard <[hidden email]>
>> Cc: [hidden email]
>> Subject: Re: RFR(XXS): 8213902:
>> com/sun/jdi/SetLocalWhileThreadInNative.java times out
>>
>> 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
>>>> <[hidden email] <mailto:[hidden email]>> 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
>>
>>
>>
Reply | Threaded
Open this post in threaded view
|

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

Reingruber, Richard
Thank you David.

Regarding my status: you're right. I noticed it, too, but wasn't sure what to do. Can you tell me?

Thanks again, Richard.

-----Original Message-----
From: David Holmes <[hidden email]>
Sent: Sonntag, 18. November 2018 00:07
To: Reingruber, Richard <[hidden email]>; JC Beyler <[hidden email]>
Cc: [hidden email]
Subject: Re: RFR(XXS): 8213902: com/sun/jdi/SetLocalWhileThreadInNative.java times out

Version 2 pushed.

Richard: I'm unclear about your Author status as you are somehow only
listed as a JDK 9 Author ? And I thought all existing Authors were
automatically added to the JDK project.

Cheers,
David

On 17/11/2018 8:34 am, David Holmes wrote:

> Hi Richard,
>
> I'll sponsor this over the weekend.
>
> Thanks,
> David
>
> On 17/11/2018 1:37 am, Reingruber, Richard wrote:
>> Hi Jc, David, Chris,
>>
>>    >> Is this not a test that's failing due to a real bug?
>>
>> I would not consider this a bug, but rather a limitation. I don't see
>> a way to
>> work around it in the TestScaffold, though (looking at [1]).
>>
>> So an enhancement would have to happen in the jdi implementation. To
>> me it does
>> not seem worth the effort. I'd say the tracing is not necessary for
>> regression
>> testing. In the case of a test error where all that output is
>> required, I'd
>> start the debuggee in a shell and do the debugging manually.
>>
>> Regarding -Xcomp: makes a lot of sense for tests that are indifferent
>> about the
>> execution mode. The test at hand triggers compilation of the central test
>> method. It does not help that much, to compile everything else, too.
>>
>> Anyway, here is another webrev without excluding -Xcomp:
>>
>> http://cr.openjdk.java.net/~rrich/webrevs/2018/8213902/webrev.02/
>>
>> I'd prefer the original webrev, because it's greener ;)
>>
>> I would need a sponsor, too. Please take either one of the patches.
>>
>> Thanks for reviewing,
>> Richard.
>>
>> [1] Debugger stack
>>
>> java.lang.Object.wait(long) line: not available [native method]
>> com.sun.tools.jdi.AbstractLauncher$Helper(java.lang.Object).wait()
>> line: 328
>> com.sun.tools.jdi.AbstractLauncher$Helper.launchAndAccept() line: 197
>> com.sun.tools.jdi.SunCommandLineLauncher(com.sun.tools.jdi.AbstractLauncher).launch(java.lang.String[],
>> java.lang.String, com.sun.jdi.connect.spi.TransportService$ListenKey,
>> com.sun.jdi.connect.spi.TransportService) line: 140
>> com.sun.tools.jdi.SunCommandLineLauncher.launch(java.util.Map<java.lang.String,?
>> extends com.sun.jdi.connect.Connector.Argument>) line: 229
>> VMConnection.launchTarget() line: 314
>> VMConnection.open() line: 149
>> SetLocalWhileThreadInNative(TestScaffold).connect(java.lang.String[])
>> line: 637
>> SetLocalWhileThreadInNative(TestScaffold).startUp(java.lang.String)
>> line: 364
>> SetLocalWhileThreadInNative(TestScaffold).startTo(java.lang.String,
>> java.lang.String, java.lang.String) line: 374
>> SetLocalWhileThreadInNative(TestScaffold).startToMain(java.lang.String) line:
>> 369
>> SetLocalWhileThreadInNative.runTests() line: 132
>> SetLocalWhileThreadInNative(TestScaffold).startTests() line: 431
>> SetLocalWhileThreadInNative.main(java.lang.String[]) line: 120
>>
>> -----Original Message-----
>> From: Chris Plummer <[hidden email]>
>> Sent: Freitag, 16. November 2018 06:23
>> To: David Holmes <[hidden email]>; JC Beyler
>> <[hidden email]>; Reingruber, Richard <[hidden email]>
>> Cc: [hidden email]
>> Subject: Re: RFR(XXS): 8213902:
>> com/sun/jdi/SetLocalWhileThreadInNative.java times out
>>
>> 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
>>>> <[hidden email] <mailto:[hidden email]>> 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
>>
>>
>>
Reply | Threaded
Open this post in threaded view
|

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

David Holmes
Hi Richard,

On 19/11/2018 6:57 am, Reingruber, Richard wrote:
> Thank you David.
>
> Regarding my status: you're right. I noticed it, too, but wasn't sure what to do. Can you tell me?

You'll need to contact the JDK Project lead (Mark Reinhold) , as you
would have done when you got your JDK 9 Author role.

Cheers,
David

> Thanks again, Richard.
>
> -----Original Message-----
> From: David Holmes <[hidden email]>
> Sent: Sonntag, 18. November 2018 00:07
> To: Reingruber, Richard <[hidden email]>; JC Beyler <[hidden email]>
> Cc: [hidden email]
> Subject: Re: RFR(XXS): 8213902: com/sun/jdi/SetLocalWhileThreadInNative.java times out
>
> Version 2 pushed.
>
> Richard: I'm unclear about your Author status as you are somehow only
> listed as a JDK 9 Author ? And I thought all existing Authors were
> automatically added to the JDK project.
>
> Cheers,
> David
>
> On 17/11/2018 8:34 am, David Holmes wrote:
>> Hi Richard,
>>
>> I'll sponsor this over the weekend.
>>
>> Thanks,
>> David
>>
>> On 17/11/2018 1:37 am, Reingruber, Richard wrote:
>>> Hi Jc, David, Chris,
>>>
>>>     >> Is this not a test that's failing due to a real bug?
>>>
>>> I would not consider this a bug, but rather a limitation. I don't see
>>> a way to
>>> work around it in the TestScaffold, though (looking at [1]).
>>>
>>> So an enhancement would have to happen in the jdi implementation. To
>>> me it does
>>> not seem worth the effort. I'd say the tracing is not necessary for
>>> regression
>>> testing. In the case of a test error where all that output is
>>> required, I'd
>>> start the debuggee in a shell and do the debugging manually.
>>>
>>> Regarding -Xcomp: makes a lot of sense for tests that are indifferent
>>> about the
>>> execution mode. The test at hand triggers compilation of the central test
>>> method. It does not help that much, to compile everything else, too.
>>>
>>> Anyway, here is another webrev without excluding -Xcomp:
>>>
>>> http://cr.openjdk.java.net/~rrich/webrevs/2018/8213902/webrev.02/
>>>
>>> I'd prefer the original webrev, because it's greener ;)
>>>
>>> I would need a sponsor, too. Please take either one of the patches.
>>>
>>> Thanks for reviewing,
>>> Richard.
>>>
>>> [1] Debugger stack
>>>
>>> java.lang.Object.wait(long) line: not available [native method]
>>> com.sun.tools.jdi.AbstractLauncher$Helper(java.lang.Object).wait()
>>> line: 328
>>> com.sun.tools.jdi.AbstractLauncher$Helper.launchAndAccept() line: 197
>>> com.sun.tools.jdi.SunCommandLineLauncher(com.sun.tools.jdi.AbstractLauncher).launch(java.lang.String[],
>>> java.lang.String, com.sun.jdi.connect.spi.TransportService$ListenKey,
>>> com.sun.jdi.connect.spi.TransportService) line: 140
>>> com.sun.tools.jdi.SunCommandLineLauncher.launch(java.util.Map<java.lang.String,?
>>> extends com.sun.jdi.connect.Connector.Argument>) line: 229
>>> VMConnection.launchTarget() line: 314
>>> VMConnection.open() line: 149
>>> SetLocalWhileThreadInNative(TestScaffold).connect(java.lang.String[])
>>> line: 637
>>> SetLocalWhileThreadInNative(TestScaffold).startUp(java.lang.String)
>>> line: 364
>>> SetLocalWhileThreadInNative(TestScaffold).startTo(java.lang.String,
>>> java.lang.String, java.lang.String) line: 374
>>> SetLocalWhileThreadInNative(TestScaffold).startToMain(java.lang.String) line:
>>> 369
>>> SetLocalWhileThreadInNative.runTests() line: 132
>>> SetLocalWhileThreadInNative(TestScaffold).startTests() line: 431
>>> SetLocalWhileThreadInNative.main(java.lang.String[]) line: 120
>>>
>>> -----Original Message-----
>>> From: Chris Plummer <[hidden email]>
>>> Sent: Freitag, 16. November 2018 06:23
>>> To: David Holmes <[hidden email]>; JC Beyler
>>> <[hidden email]>; Reingruber, Richard <[hidden email]>
>>> Cc: [hidden email]
>>> Subject: Re: RFR(XXS): 8213902:
>>> com/sun/jdi/SetLocalWhileThreadInNative.java times out
>>>
>>> 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
>>>>> <[hidden email] <mailto:[hidden email]>> 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
>>>
>>>
>>>