value type hygiene

Remi Forax forax at
Mon May 7 21:23:20 UTC 2018

> De: "John Rose" <john.r.rose at>
> À: "valhalla-spec-experts" <valhalla-spec-experts at>
> 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 |
> john.r.rose at ] > 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.

> [ |
> ]

> (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.

> [ |
> ]

> 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".

> [ |
> ]

> 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.

> [ |
> ]

> 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).

> [ |
> ]

> 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 mailing list