On Jan 19, 2018, at 8:52 AM, fo...@univ-mlv.fr wrote: > > > 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 ?
This is ranging out of the field of hotspot-compiler. Moving to mlvm-dev. (See below for previous message.) My take: It's even more like resolving a condy constant or indy call site: You can have races, and the JVM picks a winner and makes it visible forever everywhere. This pattern differs from the classic mutex-protected variable, because there is only one state transition, not many. Java's static initializer initialization also has a mutex, with one state transition. Leaving out the mutex allows multiple threads to perform BSM linkage with less synchronization (at the cost of more parallel work, which is OK). What we are modeling is code with a frontier which can grow. Once the code grows at some point, it is static forever afterward. You could model it as if the code has always been there statically but had to be "discovered" by the bootstrap method. Actual mutable code (where the code has one shape to start and then changes to a semantically different shape) is a very special feature supported by SwitchPoint and CallSite.setTarget. If you want that in your switch, you can build it into the switch by composition. > and how to specify a switch on type (not only a switch on int/long) ? I think the combinator should be able to operate over any key type whatever (like HashMap). It can have special sub-implementations for integral types (esp. if the actual traffic is dense) or for Comparables (using TreeMap). I suppose the harder question is how to deal with key weakness. Maybe the combinator is given a Map class or factory? — John On Jan 19, 2018, at 8:52 AM, fo...@univ-mlv.fr wrote: > > > > De: "John Rose" <john.r.r...@oracle.com> > À: "Rémi Forax" <fo...@univ-mlv.fr> > Cc: "Roland Westrelin" <rwest...@redhat.com>, "Laurent Bourgès" > <bourges.laur...@gmail.com>, "hotspot compiler" > <hotspot-compiler-...@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 <fo...@univ-mlv.fr > <mailto:fo...@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. > > yes. > > > 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 > > Rémi >
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
