Effect cases in switch

[forax at univ-mlv.fr]

> From: "jan lahoda" <jan.lahoda at oracle.com>
> To: "Amber Expert Group Observers" <amber-spec-observers at openjdk.org>, "Remi
> Forax" <forax at univ-mlv.fr>, "Brian Goetz" <brian.goetz at oracle.com>
> Sent: Wednesday, December 13, 2023 3:15:17 PM
> Subject: Re: Effect cases in switch

> On 13. 12. 23 13:49, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:
> [snip]

>>>>> Exception cases have the obvious dominance order with other exception cases (the
>>>>> same one used to validate order of `catch` clauses in `try-catch`), and do not
>>>>> participate in dominance ordering with non-exceptional cases. It is a
>>>>> compile-time error if an exception case specifies an exception type that cannot
>>>>> be thrown by the selector expression, or a type that does not extend
>>>>> `Throwable`. For clarity, exception cases should probably come after all other
>>>>> non-exceptional cases.

>>>>> When evaluating a `switch` statement or expression, the selector expression is
>>>>> evaluated. If evaluation of the selector expression throws an exception, and
>>>>> one of the exception cases in the `switch` matches the exception, then control
>>>>> is transferred to the first exception case matching the exception. If no
>>>>> exception case matches the exception, then the switch completes abruptly with
>>>>> that same exception.
>>>> I don't want to be the guy implementing this :)

>>> Good news, Jan has volunteered to be that guy :)
>> Are you sure you do not want a VM guy too ?

> FWIW, we already run in the "try-catch with values on stack" problem in the case
> of a try-catch inside a switch expression. The current solution is to stash the
> stack to locals (which I suspect is similar to what you did in your case). It
> is not very pretty, but I think we can start with this and see if it poses
> problems in practice.
I tried to be clever which is in retrospect may have not be not a good idea, i.e. not stash constants and things that were already in a local variable and effectively final. Anyway, the main issue I had (it was 10 years ago) was c1 deciding to not inline the method anymore because of the code bloat with as a direct consequence a reference on the stack that was previously GCed that was not anymore (because the interpreter was now keeping a reference in the locals). 

> (I am a bit more concerned about the switch-with-case-throws used as a
> conditional e.g. in an if - that may be tricky, as the code needs to have some
> particular shape. I think we have some ideas on how to implement that in the
> compiler, but didn't try them yet.)

> Jan
Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20231213/7a5b4ce6/attachment-0001.htm>