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

David Holmes david.holmes at oracle.com
Sun Nov 18 21:58:04 UTC 2018 

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 <david.holmes at oracle.com>
> Sent: Sonntag, 18. November 2018 00:07
> To: Reingruber, Richard <richard.reingruber at sap.com>; JC Beyler <jcbeyler at google.com>
> Cc: serviceability-dev at openjdk.java.net
> 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 <chris.plummer at oracle.com>
>>> Sent: Freitag, 16. November 2018 06:23
>>> To: David Holmes <david.holmes at oracle.com>; JC Beyler
>>> <jcbeyler at google.com>; Reingruber, Richard <richard.reingruber at sap.com>
>>> Cc: serviceability-dev at openjdk.java.net
>>> 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
>>>>> <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