On Wed, 8 Apr 2026 18:16:51 GMT, Coleen Phillimore <[email protected]> wrote:
>> Please review this change to fix GenerateOopMap to not report an unreachable >> bytecode for async exception handling and for the first bytecode in an >> exception catch clause. The first change will generate a safepoint entry >> that doesn't allow async exceptions for bytecodes that cannot trap. The >> second change creates an exception edge for the first bytecode in an >> exception catch clause whether it can trap or not. >> This also adds a GenerateOopMapALot at safeopints to test interpreter oopmap >> generation. Tested JCKs with this option. >> Thanks to @tkrodriguez for the kill003 test. >> Also tested tier1-8. >> >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Coleen Phillimore has updated the pull request incrementally with one > additional commit since the last revision: > > Add java/foreign/TestHandshake.java to the ProblemList.txt until > JDK-8364167 is fixed. - [x] I confirm that I make this contribution in accordance with the [OpenJDK Interim AI Policy (https://openjdk.org/legal/ai). I've changed this fix. Now we are following exception edges for all bytecodes when called from the interpreter or rewriter (could have a jsr/ret in an exception handler). Disabling async exceptions for some bytecodes could change debugging behavior that users are relying upon. For instance, if the async exception is thrown on an iconst_0 and a debugger has a breakpoint in the exception handler, that breakpoint wouldn't be reached. Creating edges to exception handlers that contain the bytecode may take more time in GenerateOopMap but I did some timings of JCK tests and didn't observe any slowdown. Reran testing tier1-8 on this new more limited change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30171#issuecomment-4245767129 PR Comment: https://git.openjdk.org/jdk/pull/30171#issuecomment-4245797208
