<div dir="ltr"><div>Hello!</div><div><br></div>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).<div><br></div><div>With best regards,</div><div>Tagir Valeev.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 5, 2018 at 6:40 PM,  <span dir="ltr"><<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">----- Mail original -----<br>
> De: "Brian Goetz" <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>><br>
</span>> À: "Remi Forax" <<a href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>><br>
> Cc: "mark" <<a href="mailto:mark@io7m.com">mark@io7m.com</a>>, "amber-spec-experts" <<a href="mailto:amber-spec-experts@openjdk.java.net">amber-spec-experts@openjdk.<wbr>java.net</a>><br>
> Envoyé: Jeudi 5 Avril 2018 17:25:36<br>
<span class="">> Objet: Re: Compile-time type hierarchy information in pattern switch<br>
<br>
</span><span class="">> Yes, this is surely an option.<br>
><br>
> But it doesn't answer the underlying question -- if the hierarchy<br>
> changes in various ways between compile and runtime, what behavior can<br>
> the user count on, and what changes yield "undefined" behavior?<br>
<br>
</span>no, it's not undefined, at least not an "undefined behavior" as in C.<br>
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.<br>
<span class=""><br>
><br>
> While its easy to say "you should do what the code says", taking that<br>
> too far ties tie our hands behind our back, and makes switches that<br>
> should be O(1) into O(n).<br>
<br>
</span>???, not sure to understand.<br>
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.<br>
<br>
Rémi<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> On 4/5/2018 11:21 AM, Remi Forax wrote:<br>
>> Or we can not try to do any check at runtime that validate the view of the world<br>
>> at compile time.<br>
>> Currently, there is no check that verifies that the catch are in the right order<br>
>> or that a cascade of if-instanceofs means the same thing at compile time and at<br>
>> runtime.<br>
>><br>
>> My opinion, we should just run the code that was compiled, even if the world as<br>
> > changed between the compilation and the execution.<br>
</div></div></blockquote></div><br></div>