On Thu, 4 Sep 2025 18:24:57 GMT, Matias Saavedra Silva <matsa...@openjdk.org> wrote:
>> The logic located in `ClassVerifier::ends_in_athrow()` is no longer required >> by the JVM Spec as of Java SE 22 (see JVMS 4.10) and the error cases should >> be handled by the stack map table and its rules for `uninitializedThis`. >> Thanks to that, `ClassVerifier::ends_in_athrow()` and any relevant code can >> be removed. Verified with tier1-5 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one > additional commit since the last revision: > > Fixed copyright Looks reasonable, and ClassFile API changes look good. In JVMS 24 [4.10.1.9.invokespecial](https://docs.oracle.com/javase/specs/jvms/se24/html/jvms-4.html#jvms-4.10.1.9.invokespecial): > In the special case of initializing the current object (that is, when > invoking <init> for type uninitializedThis), the original frame typically > holds an uninitialized object in local variable 0 and has flag > flagThisUninit. Normal termination of invokespecial initializes the > uninitialized object and turns off the flagThisUninit flag. But if the > invokespecial invocation throws an exception, the exception frame contains > the broken object (with type top) and the flagThisUninit flag (the old flag). > There is no way to perform a return instruction given that type state, so the > handler would have to throw another exception (or loop forever). In fact, > it's not even possible to express a handler with that type state, because > there is no way for a stack frame, as expressed by the StackMapTable > attribute > ([ยง4.7.4](https://docs.oracle.com/javase/specs/jvms/se24/html/jvms-4.html#jvms-4.7.4)), > to carry flagThisUninit without any accompanying use of type > uninitializedThis. Justifies this change. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27107#pullrequestreview-3187515624
