Potential bug in hotspot occasionally resulting in non-termination of parallel stream execution

[Daniel D. Daugherty]

On 4/23/15 6:28 AM, Paul Sandoz wrote:
> On Apr 23, 2015, at 2:16 PM, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>
>> On 4/23/15 1:45 AM, Paul Sandoz wrote:
>>> Hi Dan,
>>>
>>> On Apr 22, 2015, at 10:43 PM, "Daniel D. Daugherty" <daniel.daugherty at oracle.com> wrote:
>>>
>>>> Paul,
>>>>
>>>> Thanks for letting me know about this potential issue with JDK-8061553.
>>>>
>>>> Is there an open JBS for this issue?
>>> See:
>>>
>>>    https://bugs.openjdk.java.net/browse/JDK-8077392
>> Thanks for the bug ref. I'm planning to assign the bug to myself
>> and move it to 'hotspot/runtime'. Please let me know if that
>> messes up the way your team manages bugs...
>>
> It won't mess anything up, by all means take it :-)

Done. I'm going to start copying the e-mail messages from
this thread into the bug report so we have all the context
and data in one place.


>
>
>>>> If not can you file one with
>>>> a reproducible test case and some instructions on how to run it?
>>> See Amy's email on this thread for details. It does not appear hard to reproduce but it is time consuming to do so.
>> That's pretty typical for Java monitor races so I'm
>> rather used to that.
>>
> Ok.
>
>
>>> It takes many executions of a parallel stream pipeline for a failure to be observed. So far i have tried and failed to reproduce reliably with a simpler test case that runs in a shorter time frame.
>> The other Fork/Join hang that you mentioned:
>>
>> http://cs.oswego.edu/pipermail/concurrency-interest/2015-April/014240.html
>>
>> Do you know if there is a stack trace for it?
>>
> You can track that one here:
>
>    https://bugs.openjdk.java.net/browse/JDK-8078490
>
> The circumstances where this can arise are not the those of which stream f/j tasks are executed. So i am still reasonably confident they are separate. A stack trace from the test case will show no F/J thread nor the main thread waiting in java.util.concurrent.ForkJoinTask.externalAwaitDone. Instead it just spins waiting for a condition, which should be triggered by the executing f/j task, but that task never gets executed.

Thanks for the pointer. I've added a watch to that bug,
but I concur that they are different.


>>> Alexey suggests two things:
>>>
>>> 1) running the tests with a fast debug build and see if an assert fails; and
>> Yup. That's in the plan...
>>
>>
>>> 2) developing some jcstress test for wait/notify.
>> Don't know what 'jcstress' is, but I'm guessing we have a new
>> stress test harness...
> Yes, see:
>
>    http://openjdk.java.net/projects/code-tools/jcstress/

Thanks for the pointer. I think Aleksey S. might have told me
about that one before. Or it might have been Claes...

Dan


>
> Paul.
>
>> We have a Doug Lea program called CallTimerGrid
>> that we use for stress testing and I've been using it to stress
>> test each of the Contended Locking buckets as they get ready for
>> review. JDK-8061553 passed those runs (2-3 hours for product bits
>> and 60-72 hours for fastdebug bits) so I'm guessing that CallTimerGrid
>> does not easily tickle this issue.
>>
>> Dan
>>
>>> Paul.
>