On Tue, 14 Apr 2026 17:16:33 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 two > additional commits since the last revision: > > - Cleanup whitespaces. > - Change GenerateOopMap to follow exception edges for all bytecodes during > rewriter and interpreter processing, and allow async exceptions to be thrown > for any bytecode. This look good, and much simpler. If it turns out there is a performance regression, there are improvements we can do. For example, merge_state_into_bb deals with merging 3 kinds of state: stack, locals, and monitors, however the stack state is always the same. So for a sequence of bytecodes that don't affect locals or monitors, we should only need 1 merge for all of them. ------------- Marked as reviewed by dlong (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/30171#pullrequestreview-4108881139
