value type hygiene

[John Rose]

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

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

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

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

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

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

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>