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

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Dec 6 22:04:40 UTC 2018


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?

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
>


More information about the compiler-dev mailing list