<div dir="ltr">You're welcome -- thanks all for taking the time to reply. I want to ensure that this issue isn't lost in the shuffle and can be triaged/tracked appropriately. Is this the right place for the mentioned folks to comment, or might I better off taking this to somewhere like hotspot-compiler-dev? This is my first time attempting to report an issue directly to OpenJDK and would value any advice.<div><br></div><div>Best,</div><div>Joel</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 4, 2023 at 3:44 PM Paul Sandoz <<a href="mailto:paul.sandoz@oracle.com">paul.sandoz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Joel,<br>
<br>
Thank you for the detailed report, it's very helpful. I’ll let Intel folks more knowledgable than I on HotSpot+AVX-512 comment on the specifics. I am presuming a simpler reproducing test case needs to induce just enough register pressure, which may be tricky to do so reliably. <br>
<br>
Paul.<br>
<br>
> On Oct 4, 2023, at 12:07 PM, Joel Knighton <<a href="mailto:joel.knighton@datastax.com" target="_blank">joel.knighton@datastax.com</a>> wrote:<br>
> <br>
> Hello,<br>
> I have a very repeatable JVM crash when using the Panama Vector API that appears to be due to improper assembly emitted when compiling FloatVector.fromArray in certain circumstances. This crash occurs on (at least) OpenJDK 20 (OpenJDK Runtime Environment Temurin-20.0.2+9 (build 20.0.2+9)), OpenJDK 21 (OpenJDK Runtime Environment Temurin-21+35-202309042127 (build 21-beta+35-ea)<br>
> ), and OpenJDK 22-internal-adhoc built from the latest in source control. I haven't yet been able to produce the compilation conditions necessary in a neatly isolated JMH benchmark, but I hope to sufficiently illustrate the conditions such that inspection of the relevant code can confirm or deny whether I'm diagnosing the problem correctly.<br>
> <br>
> The crash can occur when using `FloatVector.fromArray(VectorSpecies<Float> species, float[] a, int offset, int[] indexMap, int mapOffset)` on a machine with AVX-512 extensions. hsdis on the crash dump shows the crash occurs at an instruction of the form `vgatherdps (%rsi,%zmm27,4),%zmm0{%k7}`. In particular, when using VSIB addressing, I noticed the index register was used nowhere else in the disassembly and seemed incorrect, as earlier assembly preparing the indexMap used a different destination register. Preceding the referenced `vgatherdps ...` instruction, the preparation of the indexMap was using destination %zmm19. Instrumenting assembler_x86 confirms that the code generating the `vgatherdps` intended the index register encoding to be 19. The crash never occurs when `vgatherdps` is emitted using index registers available prior to AVX-512.<br>
> <br>
> With the addressing used here, I expect the index register encoding to be split across EVEX.V’, EVEX.X, and SIB.index. Since the register encoding is always off by 8 when the crash occurs, I suspect EVEX.X, the fourth bit. Inspection of `Assembler::evgatherdps` shows that `Assembler::vex_prefix` is responsible for choosing the value of EVEX.X. vex_prefix defers this responsibility to `adr.xmmindex_needs_rex()` for the source address `adr`, which checks that the encoding of xmmindex is greater than or equal to 8. This check appears insufficient for AVX-512 extensions, where we wouldn't expect the fourth bit (EVEX.X) to be set for registers 16-23.<br>
> <br>
> On an OpenJDK build I produced with patched `xmmindex_needs_rex` to not set EVEX.X for index registers zmm16-23, I was able to run the code without crashing. I'm not sure if this is a correct or comprehensive fix, but it seems to further confirm my understanding of the cause of the crash.<br>
> <br>
> Here are gists of the patch I used (<a href="https://gist.github.com/jkni/d81262034917c4039c6f3a217dc5c04b" rel="noreferrer" target="_blank">https://gist.github.com/jkni/d81262034917c4039c6f3a217dc5c04b</a>) and an excerpt of the crash dump (<a href="https://gist.github.com/jkni/5854501cce6ce23e15d93eae1f7c2da2" rel="noreferrer" target="_blank">https://gist.github.com/jkni/5854501cce6ce23e15d93eae1f7c2da2</a>).<br>
> <br>
> Please let me know whether additional information would be helpful in diagnosing this issue. I would appreciate any insight.<br>
> <br>
> Thanks,<br>
> Joel<br>
<br>
</blockquote></div>