On Fri, 20 Mar 2026 18:06:48 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 incrementally with five > additional commits since the last revision: > > - 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. Marked as reviewed by dlong (Reviewer). > They only thing that I think is missing is that maybe ciTypeFlow should > understand the case when the bytecode is the first in the exception handler I think ciTypeFlow is OK the way it is. Deoptimizing for a rare corner case should be fine. Some day I hope we can get rid of this corner case, but for now we are stuck with it. ------------- PR Review: https://git.openjdk.org/jdk/pull/30171#pullrequestreview-3984098432 PR Comment: https://git.openjdk.org/jdk/pull/30171#issuecomment-4100965337
