[GR-53397] Apparent compiler bug in GraalVM

[vlofgren]

Describe the issue

A intermittent error appears in the code used by the Marginalia search engine to construct its index that after some investigation appears to be a logical contradiction, a situation equivalent to the code below:

val = read-only mmapped file 
      not subject to change
counts = zeroed mmap:ed file 

long offset = 0;
for (int i = 0; i < length; i++) {
  counts[i] = val[i];
  offset += val[i];
}

long size = 0;
for (int i = 0; i < length; i++) {
   size += counts[i];
}

assert (size == offset); // this fails

The problem goes away on openjdk. For a full account of the investigation see the Deep Bug blog entry on marginalia.nu.

Steps to reproduce the issue:

The problem appears while construcing a search engine index in the Marginalia search engine. A modified version of the sources is available here that makes the process accessible without setting up a full search engine: https://github.com/MarginaliaSearch/MarginaliaSearch/tree/jvm-bug-replicator ; along with a link to ~10 GB of test data that is the smallest set discovered that reproduces the issue.

Ensure you check out the jvm-bug-replicator branch! The readme on the branch contains full instructions for reproducing the error.

The code has been modified to throw an exception 'java.lang.IllegalStateException: Impossible state' when the situation described above appears.

Describe GraalVM and your environment:

• GraalVM version:: Java(TM) SE Runtime Environment Oracle GraalVM 22+36.1 (build 22+36-jvmci-b02); also seen o the JDK 21 version of the same.
• JDK major version: 22
• OS: Debian 12 Linux
• Architecture: x86_64 (seen on a Ryzen 9 3900X and an Epyc 7543)

More details

To help comprehend the code, I've extracted only the code that fails in this repo. This does not reproduce the error, but it might help navigate the code of the marginalia search engine.

[gergo-]

Thanks again for this reproducer @vlofgren . I can reproduce the issue locally. The best workaround at the moment is to add -Dgraal.StripMineCountedLoops=false to your GraalVM command line. We will target a fix for GraalVM 22.0.2, which will be released in July.

[gergo-]

After some joint detective work, @davleopo figured out the issue, and we have merged his fix internally. It will be present in GraalVM for JDK 22.0.2, to be released on July 16. I will close this issue to signal that it is resolved from our side. @vlofgren please test that version when it comes out and reopen this or report any other problems as needed.

We have also determined that the same underlying problem was the reason for some other failures we had observed internally that were almost impossible to reproduce and to debug. So having this reproducer was very helpful for understanding these failures. Thank you again for the report, and please don't hesitate to report further problems you encounter even if they seem hard to pin down.

As an aside, since there are interesting computationally demanding operations involved in the search engine, we were wondering if individual parts could be split out as self-contained compiler benchmarks. Certainly we would be interested if you find tasks that are slower when run with GraalVM vs. other JDKs.

[vlofgren]

Excellent. Will get back to you if there are any issues.

I've actually seen a pretty significant performance boost from switching to GraalVM, but I might see if I can extract some benchmarks later. I do, as noted, do some rather unusual computational gymnastics, so there's probably room for optimizations ;-)