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

[Daniel D. Daugherty]

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


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


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


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