The following test periodically hangs when run with -server.  If you run a debug might you might need to increase the time it was before it considers it to be hung.  I'm still trying to narrow which release it appeared it.  6u14 is currently the first release where I've seen it hang.

import java.net.*;
import org.jsuffixarrays.*;

public class test extends Thread {
    public static void main(String[] args) throws Exception {
        int hung = 0;
        for (int i = 0; i < 10000; i++) {
            URLClassLoader apploader = (URLClassLoader)test.class.getClassLoader();
            URLClassLoader ucl = new URLClassLoader(apploader.getURLs(), apploader.getParent());
            Class c = ucl.loadClass("test");
            Thread t = (Thread)c.newInstance();
            t.start();
            for (int s = 0; s < 10; s++) {
                Thread.sleep(500);
                if (!t.isAlive()) {
                    break;
                }
            }
            if (t.isAlive()) {
                hung++;
            }
            System.out.println("ok " + (i + 1 - hung) + " hung " + hung);
        }
    }
    public void run() {
        DivSufSortTest t = new DivSufSortTest();
        t.setupForConstraints();
        t.invariantsOnRandomLargeAlphabet();
        t.sameResultWithArraySlice();
        t.invariantsOnRandomSmallAlphabet();
    }
}
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 <###@###.###> 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 :).