RFR(XXS): 8213902: com/sun/jdi/SetLocalWhileThreadInNative.java times out
JC Beyler
jcbeyler at google.com
Fri Nov 16 16:04:16 UTC 2018
Hi David,
Thanks for the explanation :) That makes sense to me,
Jc
On Thu, Nov 15, 2018 at 8:40 PM David Holmes <david.holmes at oracle.com>
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
>
--
Thanks,
Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20181116/cd6f19ff/attachment.html>
More information about the serviceability-dev
mailing list