> De: "John Rose" <john.r.r...@oracle.com> > À: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > Envoyé: Lundi 7 Mai 2018 22:55:22 > Objet: Re: value type hygiene
> On May 6, 2018, at 2:17 AM, John Rose < [ mailto:john.r.r...@oracle.com | > john.r.r...@oracle.com ] > wrote: >> Like many of us, I have been thinking about the problems of keeping values, >> nulls, >> and objects separate in L-world. I wrote up some long-ish notes on the >> subject. >> I hope it will help us wrap our arms around the problem, and get it solved. >> TL;DR: Remi was right in January. We need a ValueTypes attribute. > FTR, there's an interesting meander, in the big picture, to our design > process: > 1. 2012 Recognizably modern value types are proposed as something to > sneak under L-types, as a gated optimization on restricted references rather > than on a new set of types. > [ https://blogs.oracle.com/jrose/value-types-in-the-vm | > https://blogs.oracle.com/jrose/value-types-in-the-vm ] > (In conversations at this time, indeterminate "heisenboxes" are suggested to > suppress identity, following the Common Lisp EQ function semantics. > Thinking about specifying and using heisenboxes makes our skin crawl. > For a description, see JDK-8163133. Various folks propose hacking acmp > to suppress value identity, upgrading it to Common Lisp EQV, but that makes > our skin crawl when we think about optimization and generics.) > 2. 2014 We realize that making it all an optimization is just too sneaky, > and invent Q-descriptors to make everything explicit. > [ http://cr.openjdk.java.net/~jrose/values/values-0.html | > http://cr.openjdk.java.net/~jrose/values/values-0.html ] > It takes a several months to get confident that we've found all the places > where > Q-types matter. Generics over Q-types look very difficult (as they still do). > 3. 2016-2017 We define and implement a subset of Q-types as > "Minimal Value Types". > [ http://cr.openjdk.java.net/~jrose/values/shady-values.html | > http://cr.openjdk.java.net/~jrose/values/shady-values.html ] > It works for small cases, but putting Q for L starts to feel like > TMI. No, it's not sneaky. It's more like your neighbor playing rock > music at 2 AM. > 4. 2017-2018 We decide to try "L-world", where we use ambiguous > L-descriptors. We put needed information, previously held by Q-descriptors, > in ad hoc side channels like ACC_FLATTENABLE bits. > [ http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-4.pdf | > http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-4.pdf ] > This works only because we now know all the places where Q > descriptors are significant to semantics or optimization. It's hard > to imagine winning this information without the Q-type exercises > of steps 2 and 3. But the need for ad hoc channels grows > uncomfortably as we expand our prototype. > 5. (present) We are considering consolidating the Q descriptor > information in a uniform side channel, one per classfile, an attribute > called ValueTypes. In this way, all semantic and optimization > decisions about value types can be made based on one source > of information (per classfile). > [ http://cr.openjdk.java.net/~jrose/values/value-type-hygiene.html | > http://cr.openjdk.java.net/~jrose/values/value-type-hygiene.html ] > This is not sneaky. On the other hand, it does not impose Q-types > on tools and classes that don't want to know about them. In fact, > we might have a happy medium here! > That's the big picture of value type design, as I see it. > — John > P.S. Yes, there's also history before 2012. We can start with Java, although > SmallTalk and Common Lisp provide interesting precedents. > 0. 1999 James Gosling worries about numerics in Java and proposes, as > one component of a solution, "immutable class" declarations. > [ > http://web.archive.org/web/19990202050412/http://java.sun.com/people/jag/FP.html#classes > | > http://web.archive.org/web/19990202050412/http://java.sun.com/people/jag/FP.html#classes > ] > The project is put aside, in part because Gosling (correctly) assesses that it > requires the equivalent of several PhD theses to flesh out the design. > Over the years, other folks make similar proposals. If we could force enough > optimizations on java.lang.Integer, it could behave like an int. These > proposals > run into difficulties not with immutability but with other aspects of > reference > types, such as nullability and (especially) object identity. > Also during this period, there are many hopeful suggestions of the form, > "Why don't you just do what $Language does, but for Java?" Where Language > is usually C++ or C#. There is, of course, no language whose design for > values can be independently extracted, let alone successfully applied to Java. > One constraint with Java is strong interoperability with pre-existing APIs, > which are built solely of primitives and reference types. Another is Java's > strong concurrency guarantees, which make immutability more important > than in older languages. and there is also no concept of addresses from the stack in Java (unlike C, C++ or C#). Rémi
