On Tue, 24 Mar 2026 15:07:40 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. > > Coleen Phillimore has updated the pull request with a new target base due to > a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into kill001 > - Fix copyrights and extraneous diffs > - Add a bit of logging for GenerateOopMapALot. > - Restored special aload, return, monitorexit cases in do_exception_edge. > Make them exceptions from async exception delivery instead. > - Remove monitorenter, monitorexit from do_exception_edge since they can > have exceptions, and turn off GenerateOopMapALot again. > - Generate safepoint checks with and without allowing async exceptions a > different way. Also include the breakpoint code. > - Merge branch 'master' into kill001 > - GenerateOopMapALot at all safepoints even ones that cannot throw async > exceptions. > - Add some comments and fix the test. > - Update test/hotspot/jtreg/vmTestbase/nsk/jdb/kill/kill003/kill003a.java > > Co-authored-by: Joel Sikström <[email protected]> > - ... and 4 more: https://git.openjdk.org/jdk/compare/90eebaa3...c2ce4272 So is the TestHandshake failure more likely because normal interpreter safepoints can now defer the async the delivery arbitrarily? Maybe interpreter safepoints should only be installed for bytecodes for which async delivery is ok? ------------- PR Comment: https://git.openjdk.org/jdk/pull/30171#issuecomment-4129000754
