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

[Paul Sandoz]

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 :-)


> 
>>> 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.


> 
>> 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/

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.
>