value type hygiene (original) (raw)

John Rose john.r.rose at oracle.com
Mon May 7 20:55:22 UTC 2018

On May 6, 2018, at 2:17 AM, John Rose <john.r.rose at 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

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

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

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

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

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.

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

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.

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

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.

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

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.

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20180507/7ad88bc7/attachment.html>

More information about the valhalla-spec-experts mailing list