Endless loops in computation code (1.6.0_22).

Dawid Weiss dawid.weiss at gmail.com
Thu Mar 3 13:39:27 PST 2011

> Inserting the breakpoint would deopt the code and you'll resume in the
> interpreter so you'll end up avoiding the JITed code which presumably is
> where the bug is.

Yep, I realize this is the case, I even mentioned it in my original post.
Let me double check that we're not doing something non-deterministic first
though... but if you'd like to try then...

> I agree.  It sounds like we're screwing up the bounds somehow.  Is there a
> jar file I can grab to run this test easily?

Mind this is happening infrequently (but on different machines, different
OSs, etc.).  Here's the procedure:

git clone git at github.com:carrotsearch/jsuffixarrays.git
cd jsuffixarrays
# while (true)? {
mvn test
# }

I've just done the above and it hung on the first execution... the next one
it didn't, the third one it did again. So maybe it is happening more
frequently than less. The JRE I did it on is:

java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)

But it applies to newer versions as well.

The particular class that is causing this is DivSufSort (DivSufSortTest),
but I don't know what causes this to happen, so I'd run all of them (these
are parallel testng tests).

I also didn't check with the trunk HotSpot, so it may be something that's
already been fixed.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110303/561776df/attachment.html 

More information about the hotspot-compiler-dev mailing list