<div dir="ltr">Hi, I've come across an assertion tripping in JDK debug builds (24, latest, not 23) in combination with new foreign memory apis. Product builds seem to be functioning ok:<div><div class="gmail-snippet-clipboard-content gmail-notranslate gmail-position-relative gmail-overflow-auto" style="box-sizing:border-box;display:flex;color:rgb(31,35,40);font-family:-apple-system,"system-ui","Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:16px;overflow:auto"><pre class="gmail-notranslate" style="box-sizing:border-box;font-size:13.6px;margin-top:0px;margin-bottom:0px;overflow:auto;line-height:1.45;border-radius:6px"><code style="box-sizing:border-box;padding:0px;margin:0px;background:transparent;border-radius:6px;word-break:normal;border:0px;display:inline;overflow:visible;line-height:inherit"># Internal Error (src/hotspot/share/opto/loopnode.cpp:3196), pid=27, tid=44
# Error: assert(!loop->_body.contains(in)) failed
</code></pre><div class="gmail-zeroclipboard-container" style="box-sizing:border-box"><span aria-label="Copy" class="gmail-ClipboardButton gmail-btn gmail-btn-invisible gmail-js-clipboard-copy gmail-m-2 gmail-p-0 gmail-d-flex gmail-flex-justify-center gmail-flex-items-center" value="% javac Repro.java
% java -Xbatch -XX:-TieredCompilation Repro
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (src/hotspot/share/opto/loopnode.cpp:3196), pid=27, tid=44
# Error: assert(!loop->_body.contains(in)) failed" tabindex="0" role="button" style="box-sizing:border-box;font-size:14px;line-height:20px;vertical-align:middle;border:0px;border-radius:6px;background-color:transparent;display:flex;padding:0px"></span></div></div><br class="gmail-Apple-interchange-newline"></div><div>I've been able to narrow it down somewhat, repro code/data as well as crash logs can be found here: <a href="https://github.com/mernst-github/repro/tree/main/loopnode-assertion">https://github.com/mernst-github/repro/tree/main/loopnode-assertion</a> (this was originally a standard `quicksort` on top of a MemorySegment).</div><div><br></div><div>I have not been able to discover anything more systematic. Small changes to the input data, or using a heap array instead of a MemorySegment make the issue go away.</div><div><br></div><div>Cheers</div><div>Matthias</div><div>(PS: lmk if this is not an opportune place to report such an issue)</div><div><br></div></div>