RFR: JDK-8214114: Switch expressions with try-catch statements

[Vicente Romero]

On 12/6/18 6:24 PM, Jan Lahoda wrote:
> On 6.12.2018 23:04, Maurizio Cimadamore wrote:
>> While I don't think the stack should be as what Vicente says (after all,
>> there's a Println object somewhere that should be tracked), I tend to
>> agree with Vicente that there's something fishy here - I looked at the
>> bug report and also run the example and the verifier crashes _before_
>> entering the exception handler - it crashes on the 'new' when the
>> exception is allocated. That doesn't seem to match what you said in the
>> RFR. Now, as I pointed out in my other message, I believe some stashing
>> is unavoidable as the VM will wipe out the stack, but it seems like
>> there could be more issues piled up here?
>
> Sorry, I should have been more precise. What I meant is that the 
> StackMap for catch handler must not have anything on stack (except for 
> the Exception) (because VM will wipe the stack, that is, I think, 
> another angle to look at this).

yep the verifier is just doing what the spec says, 4.10.2.2 The Bytecode 
Verifier:

...

In the special case of control transfer to an exception handler:
• Record that a single object, of the exception type indicated by the 
exception
handler, is the state of the operand stack prior to executing the successor
instruction. There must be sufficient room on the operand stack for this 
single
value, as if an instruction had pushed it.



> That is not related only to athrow - the exception may be coming from 
> a method invocation, for example. The reason the verifier barks on 
> "new" is, I think, because the instruction may throw an exception as 
> well. So it checks the StackMap for the exception handler, and finds 
> out there's something on the stack (in the StackMap) that should not 
> be there, and fails (or, from another angle, when checking the 
> exception handler, the verifier finds out the handler expects 
> something on the stack, besides the exception, which can't be there).
>
> Jan

Sorry for the confusion,

Vicente
>
>>
>> Maurizio
>>
>> On 06/12/2018 21:50, Vicente Romero wrote:
>>> Hi Jan,
>>>
>>> Probably I'm missing something but shouldn't it be enough to generate
>>> the right stackframe for the exception handler? Which in this case
>>> should only contain:
>>>
>>> stack = [ class java/lang/Exception ]
>>>
>>> Thanks,
>>> Vicente
>>>
>>> On 12/6/18 11:51 AM, Jan Lahoda wrote:
>>>> Hi,
>>>>
>>>> Switch expressions that contain try-catch statements don't work
>>>> currently, as the catch handlers require that the stack is empty when
>>>> the handler is invoked, but this may not be true when the switch
>>>> expression is inside an expression evaluation (and so some values are
>>>> already on the stack).
>>>>
>>>> The proposed solution is to stash the stack content to local
>>>> variables before "running" the switch expression, and fill the stack
>>>> content back when breaking out of the switch expression. This is done
>>>> only if the try-catch statement is present in the switch expression,
>>>> as it produces longer bytecode.
>>>>
>>>> Also, it turned out variables inside switch expressions in field
>>>> initializers don't work properly (as their owner is the field, not a
>>>> method), attempted to fix that as well.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8214114
>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8214114/webrev.00/
>>>>
>>>> How does this look?
>>>>
>>>> Thanks,
>>>>     Jan
>>>