<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div style="background-color: rgb(255, 255, 255); color: rgb(8, 8, 8);"><span>Hi all,</span></div><div style="background-color: rgb(255, 255, 255); color: rgb(8, 8, 8);"><span><br></span></div><div style="background-color: rgb(255, 255, 255); color: rgb(8, 8, 8);"><span>With the latest changes I got the following error </span></div><div style="background-color: rgb(255, 255, 255); color: rgb(8, 8, 8);"><span><br></span></div><div style="background-color: rgb(255, 255, 255); color: rgb(8, 8, 8);"><span>=======================8<----------------------</span></div><span>./src/hotspot/share/ci/ciMethodData.cpp:477:1: error: non-void function does not return a value in all control paths [-Werror,-Wreturn-type]<br>}<br>^<br>1 error generated.<br>make[3]: *** [/opt/teamcity-agent/work/602288ed8ca22f30/build/macosx-aarch64-server-release/hotspot/variant-server/libjvm/objs/ciMethodData.o] Error 1<br>make[3]: *** Waiting for unfinished jobs....<br>make[2]: *** [hotspot-server-libs] Error 2<br>make[2]: *** Waiting for unfinished jobs….</span><div><span style="caret-color: rgb(8, 8, 8); color: rgb(8, 8, 8); background-color: rgb(255, 255, 255);">=======================8<</span><font color="#080808"><span style="caret-color: rgb(8, 8, 8);">———————————</span></font></div><div><span><font color="#080808"><span style="caret-color: rgb(8, 8, 8); background-color: rgb(255, 255, 255);"><br></span></font></span></div><div><span><font color="#080808"><span style="caret-color: rgb(8, 8, 8); background-color: rgb(255, 255, 255);">Here is my build environment</span></font></span></div><div><span><font color="#080808"><span><br></span><span></span></font></span></div><span>Configuration summary:<br>* Name: macosx-aarch64-server-release<br>* Debug level: release<br>* HS debug level: product<br>* JVM variants: server<br>* JVM features: server: 'cds compiler1 compiler2 dtrace epsilongc g1gc jfr jni-check jvmci jvmti management parallelgc serialgc services shenandoahgc vm-structs zgc'<br>* OpenJDK target: OS: macosx, CPU architecture: aarch64, address length: 64<br>* Version string: 22+9-b1917 (22)<br>* Source date: 1701334649 (2023-11-30T08:57:29Z)<br><br>Tools summary:<br>* Boot JDK: openjdk version "22" 2024-03-19 OpenJDK Runtime Environment JBR-22+9-1795-nomod (build 22+9-b1795) OpenJDK 64-Bit Server VM JBR-22+9-1795-nomod (build 22+9-b1795, mixed mode) <br>* Toolchain: clang (clang/LLVM from Xcode 12.2)<br>* Sysroot: /Applications/Xcode_12.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk<br>* C Compiler: Version 12.0.0 (at /usr/bin/clang)<br>* C++ Compiler: Version 12.0.0 (at /usr/bin/clang++)</span><div><span><br></span></div><div>Could you please clarify how to overcome this issue?</div><div><br></div><div>Thanks,</div><div>Vitaly</div><div><span><br><br><blockquote type="cite">On 27. Nov 2023, at 17:04, Jorn Vernee <jvernee@openjdk.org> wrote:<br><br class="Apple-interchange-newline">On Thu, 23 Nov 2023 15:31:28 GMT, Jorn Vernee <jvernee@openjdk.org> wrote:<br><br><blockquote type="cite"><blockquote type="cite">The issue is essentially that for the Java try-with-resource construct, javac generates multiple calls to `close(`) the resource. One of those calls is inside the hidden exception handler of the try block. The issue for us is that typically the exception handler is never entered (since no exception is thrown), however we don't profile exception handlers at the moment, so the block is not pruned. C2 doesn't inline the `close()` call in the handler due to low call site frequency. As a result, the receiver of that call escapes and can not be scalar replaced, which then leads to a loss in performance.<br><br>There has been some discussion on the JBS issue that this could be fixed by profiling catch blocks. And another suggestion that partial escape analysis could help here to prevent the object from escaping. But, I think there are other benefits to being able to prune dead catch blocks, such as general reduction in code size, and other optimizations being possible by dead code being eliminated. So, I've implemented catch block profiling + pruning in this patch.<br><br>The implementation is essentially very straightforward: we allocate an extra bit of profiling data for each<br>exception handler of a method in the `MethodData` for that method (which holds all the profiling<br>data). Then when looking up the exception handler after an exception is thrown, we mark the<br>exception handler as entered. When C2 parses the exception handler block, and it sees that it has<br>never been entered, we emit an uncommon trap instead.<br><br>I've also cleaned up the handling of profiling data sections a bit. After adding the extra section of data to MethodData, I was seeing several crashes when ciMethodData was used. The underlying issue seemed to be that the offset of the parameter data was computed based on the total data size - parameter data size (which doesn't work if we add an additional section for exception handler data). I've re-written the code around this a bit to try and prevent issues in the future. Both MethodData and ciMethodData now track offsets of parameter data and exception handler data, and the size of the each data section is derived from the offsets.<br><br>Finally, there was an assert firing in `freeze_internal` in `continuationFreezeThaw.cpp`:<br><br> assert(monitors_on_stack(current) == ((current->held_monitor_count() - current->jni_monitor_count()) > 0),<br> "Held monitor count and locks on stack invariant: " INT64_FORMAT " JNI: " INT64_FORMAT, (int...<br></blockquote><br>Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:<br><br> - add interpreter profiling specific test cases<br> - rename ex_handler -> exception_handler<br></blockquote><br>Another round of tier 1 - 8 testing came back clean. I'm planning to integrate the patch tomorrow.<br><br>-------------<br><br>PR Comment: https://git.openjdk.org/jdk/pull/16416#issuecomment-1827516420<br></blockquote><br></span></div></body></html>