RFR: JDK-8313626: C2 crash due to unexpected exception control flow [v2]

[Christian Hagedorn]

On Fri, 18 Aug 2023 13:49:59 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

>> # Problem 
>> The following JASM code:
>> 
>> static Method test1:"()V" stack 1 {
>>     try t;
>>         invokestatic m:"()V";
>>         return;
>> 
>>         catch t java/lang/Throwable;
>>         stack_map class java/lang/Throwable;
>>         athrow;
>>     endtry t;
>> }
>> 
>> produces this java bytecode
>> 
>> static void m();
>>   Code:
>>      0: return
>> 
>> static void test1();
>>   Code:
>>      0: invokestatic  #4      // Method m:()V
>>      3: return
>>      4: athrow
>>   Exception table:
>>      from    to  target type
>>          0     5     4   Class java/lang/Throwable
>> 
>> 
>> from https://docs.oracle.com/javase/specs/jvms/se20/jvms20.pdf _exception_table[] (p.116)_
>> 
>>> The values of the two items start_pc and end_pc indicate the ranges in the code array at which the exception handler is active. The value of start_pc must be a valid index into the code array of the opcode of an instruction. The value of end_pc either must be a valid index into the code array of the opcode of an instruction or must be equal to code_length, the length of the code array. The value of start_pc must be less than the value of end_pc.
>>> The start_pc is inclusive and end_pc is exclusive; that is, the exception handler must be active while the program counter is within the interval [start_pc, end_pc).
>>> 
>>> handler_pc
>>> The value of the handler_pc item indicates the start of the exception handler. The value of the item must be a valid index into the code array and must be the index of the opcode of an instruction.
>> 
>> and from _§athrow (p.420)_
>> 
>>> The objectref must be of type reference and must refer to an object that is an instance of class Throwable or of a subclass of Throwable. It is popped from the operand stack. The objectref is then thrown by searching the current method (§2.6) for the first exception handler that matches the class of objectref, as given by the algorithm in §2.10.
>>> If an exception handler that matches objectref is found, it contains the location of the code intended to handle this exception. The pc register is reset to that location, the operand stack of the current frame is cleared, objectref is pushed back onto the operand stack, and execution continues.
>> 
>> In out case: **[start_pc=0, end_pc=5)** and **handler_pc=4** and **objectref=Class java/lang/Throwable**
>> 
>> By this definition we have indeed valid bytecode for `test1()`.  Therefore we would expect C2 to create an infinite loop for
>> 
>>      4: athrow
>> 
>> 
>> The C2 graph indeed shows a...
>
> Tobias Holenstein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove newlines
>  - remove newlines

That looks good to me, too!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15292#pullrequestreview-1584644083