value type hygiene
forax at univ-mlv.fr
Mon May 7 21:23:20 UTC 2018
> De: "John Rose" <john.r.rose at oracle.com>
> À: "valhalla-spec-experts" <valhalla-spec-experts at 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.rose at oracle.com |
> john.r.rose at oracle.com ] > wrote:
>> Like many of us, I have been thinking about the problems of keeping values,
>> 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.
> 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#).
More information about the valhalla-spec-observers