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