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

[Vicente Romero]

On 12/6/18 5:04 PM, 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' 

I think the verifier is just referring to where the frame that produced 
the error starts. It's not saying that the `new` is the one that 
produced the error

> 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?
>
> Maurizio

Vicente

>
> 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
>>