Switch vs if ?

forax at univ-mlv.fr forax at univ-mlv.fr
Fri Jan 19 16:52:35 UTC 2018

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Rémi Forax" <forax at univ-mlv.fr>
> Cc: "Roland Westrelin" <rwestrel at redhat.com>, "Laurent Bourgès"
> <bourges.laurent at gmail.com>, "hotspot compiler"
> <hotspot-compiler-dev at openjdk.java.net>
> Envoyé: Vendredi 19 Janvier 2018 02:03:26
> Objet: Re: Switch vs if ?

> On Jan 17, 2018, at 2:42 PM, Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> next we need a method handle combinator for the integer switch for amber.

> With its own profiling, of course.
yes, that the part which is not easy to simulate without a combinator 

> Also, method handle switch combinators have the potential to
> grow dynamically, unlike static switches in bytecode.


> This is a trick of PyPy, which "grows" basic blocks as
> they are executed; each polymorphic dispatch point works
> like an open-ended switch whose cases are all types
> *encountered so far* at that point by the program.

> So the default branch of a MH switcher could act like
> an indy call site, and spin new cases whenever the old
> ones don't match.

yes, it means that the switcher has to be its own class like the SwitchPoint because it provide a method to add a new case. 

> The underlying storage of the MH switcher should use a
> @Stable array of per-case MH's, allowing good inlining.
> For a growable switch, the array could either grow or split
> out into sub-arrays as appropriate, as a growing HAMT.

two questions, what is the semantics in case of concurrent updates, i suppose it's like calling setTarget() from multiple threads ? 
and how to specify a switch on type (not only a switch on int/long) ? 

> — John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20180119/9fee7f9f/attachment.html>

More information about the hotspot-compiler-dev mailing list