Compile-time type hierarchy information in pattern switch

[Remi Forax]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "mark" <mark at io7m.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 4 Avril 2018 19:07:17
> Objet: Re: Compile-time type hierarchy information in pattern switch

> The intended implementation strategy is to lower complex switches to
> densely-numbered `int` switches, and then invoke a classifier function
> that takes a target and returns the int corresponding to the lowered
> case number.  The classifier function will be an `invokedynamic`, whose
> static bootstrap will contain a summary of the patterns.  (We've already
> done this for switches on strings, enums, longs, non-dense ints, etc.)
> 
> To deliver an early error, that means that (a) the compiler must encode
> through the static argument list all the assumptions it needs verified
> at runtime (e.g., `String <: Object`), and (b) at linkage time (the
> first time the switch is executed), those have to be tested.
> 
> Doing so is plenty easy, but there's a startup cost, which could be as
> bad as _O(n^2)_, if I have to validate that no two case labels are
> ordered inconsistently with subtyping.
> 
> A possible mitigation is to do the check as a system assertion, which
> only gets run if we are run with `-esa`; we then might still have some
> static code bloat (depending on how we encode the assumptions), but at
> least skip the dynamic check most of the time.

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.

Rémi

> 
> On 4/4/2018 1:01 PM, Mark Raynsford wrote:
>> I'm still giving thought to everything you've written, but I am
>> wondering: How feasible is it to get the above to fail early with an
> > informative exception/Error?