Endless loops in computation code (1.6.0_22).

[Dawid Weiss]

Hi Tom.

Apologies for not providing a broader context, it follows.

> Is it hanging, as in making no progress, or not terminating?

It is hanging as in: it consumes 100% of a single core, never terminates
(when executed without debugging), in the debugging mode it does not
terminate until a JVM breakpoint is set inside the loop below, then it
breaks out to the debugger and you can step-by-step execute the code or
re-run it and, magically, it will terminate.

> Does it terminate if given a lot more time?  It's not GC bound?  By
debugger do you mean gdb or a Java debugger?

No, it never terminates... at least not in a reasonable time. Normally this
loop ends in 2-3 seconds and when hung it does not terminate after 30
minutes or so (the longest we waited to kill it on the build server).

To me It looks like it JITs into something that causes an endless loop. I
also checked with jrockit and J9 and these never hung, so it's probably
hotspot.

Talking about the debugger, that was a Java debugger, I didn't inspect JIT
dumps of what this method compiles to yet, didn't have the time and wanted
to check if it's a known issue first.

I'll try to reproduce it with JIT code dumps, I'll let you know if I
succeed.

Dawid

On Thu, Mar 3, 2011 at 9:37 PM, Tom Rodriguez <tom.rodriguez at oracle.com>wrote:

>
> On Mar 3, 2011, at 4:39 AM, Dawid Weiss wrote:
>
> > Hi. We see an infrequent, but very annoying VM hangups in purely
> > computational code, as in here:
> >
> >
> http://builds.carrot2.org/build/result/viewBuildResultsFailedTests.action?buildKey=JSA-JSAHEAD-JOB1&buildNumber=8
> >
> > The loop in question is like this:
> >
> >            for (c0 = ALPHABET_SIZE - 2, j = m; 0 < j; --c0)
> >            {
> >                for (c1 = ALPHABET_SIZE - 1; c0 < c1; j = i, --c1)
> >                {
> >                    i = bucket_B[(c0) * ALPHABET_SIZE + (c1)];
> >                    if (1 < (j - i))
> >                    {
> >                        ssSort(PAb, i, j, buf, bufsize, 2, n, SA[i] == (m
> - 1));
> >                    }
> >                }
> >            }
> >
> > Unfortunately I cannot provide an always-halting example, but the bug
> > seems to be JVM-related because:
> >
> > 1) once the VM hangs in debugging mode, breaking out to the debugger
> > and stepping through the code terminates normally (so a deopt. I
> > assume),
>
> Is it hanging, as in making no progress, or not terminating?  Does it
> terminate if given a lot more time?  It's not GC bound?  By debugger do you
> mean gdb or a Java debugger?
>
> tom
>
> >
> > 2) the freeze is non-deterministic, while the test is (regardless of
> > the 'randomness', it always starts from the same seed),
> >
> > 3) we could reproduce this occasionally under different VMs and
> > different OSs (64-bit linux, 64-bit Windows).
> >
> > Has there been any bug in the JIT that might be causing this? Thanks
> > for pointers if you recognize an evil code pattern above.
> >
> > Dawid
> >
> > P.S. The above code is a translation from another person's C snippet,
> > so I can't easily explain why the loop is built this way or why c0 is
> > passed between the inner and outer loop :).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110303/2168ff20/attachment.html