Compile-time type hierarchy information in pattern switch

[Tagir Valeev]

Hello!

Is it too harsh to reject the whole class if the assumptions on class
hierarchy which were necessary to compile the switch statements used in the
class are not valid at runtime? E.g. compiler may gather all the
assumptions across all the pattern-matching switches within the class and
add some instructions to the <clinit> which check these assumptions at once
(probably calling some validation method which receives the expected
hierarchy in some packed way)? This way the fail-fast behavior will be
guaranteed (class refuses to initialize) and while some expensive runtime
checks are to be made during class initialization, in case of several
pattern switches in the same class, the number of checks will be reduced
(although they still will be performed even if no such switch is actually
executed).

With best regards,
Tagir Valeev.

On Thu, Apr 5, 2018 at 6:40 PM, <forax at univ-mlv.fr> wrote:

> ----- Mail original -----
> > De: "Brian Goetz" <brian.goetz at oracle.com>
> > À: "Remi Forax" <forax at univ-mlv.fr>
> > Cc: "mark" <mark at io7m.com>, "amber-spec-experts" <
> amber-spec-experts at openjdk.java.net>
> > Envoyé: Jeudi 5 Avril 2018 17:25:36
> > Objet: Re: Compile-time type hierarchy information in pattern switch
>
> > Yes, this is surely an option.
> >
> > But it doesn't answer the underlying question -- if the hierarchy
> > changes in various ways between compile and runtime, what behavior can
> > the user count on, and what changes yield "undefined" behavior?
>
> no, it's not undefined, at least not an "undefined behavior" as in C.
> At runtime, the code executed will be the one compiled. A hierarchy
> changes is not a backward compatible changes, so one can expect surprise
> and not something undefined.
>
> >
> > While its easy to say "you should do what the code says", taking that
> > too far ties tie our hands behind our back, and makes switches that
> > should be O(1) into O(n).
>
> ???, not sure to understand.
> If we record which case was executed for a given class in a hashmap and
> use it as a cache, it will be always O(1) for all subsequent calls with the
> same class.
>
> Rémi
>
> >
> > On 4/5/2018 11:21 AM, Remi Forax wrote:
> >> Or we can not try to do any check at runtime that validate the view of
> the world
> >> at compile time.
> >> Currently, there is no check that verifies that the catch are in the
> right order
> >> or that a cascade of if-instanceofs means the same thing at compile
> time and at
> >> runtime.
> >>
> >> My opinion, we should just run the code that was compiled, even if the
> world as
> > > changed between the compilation and the execution.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180405/5ec1f756/attachment-0001.html>