generic specialization design discussion

[John Rose]

On May 8, 2019, at 12:31 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> 
> I'm working on the introductory spec material, and have also come to this conclusion. All values are either *primitives* or *references*. Everything we've done in L-world has to do with refining the space of things that references can point to (*objects*).
> 
>> ...
> 
> Here's a cut of JVMS 2.4 that incorporates some of this terminology (some of it I've avoided, either because I didn't need it, or it seemed insufficiently precise.)
> 
> I also decided to call out the `Object` type as a unique entity. This probably have some ripple effects elsewhere, which I haven't explored yet.
> 
> It's hard to say much about identity without talking about acmp/substitutability; I chose the term "identical" here for that purpose (rather than the overloaded "equal").

When the current JLS and JVMS must talk about object identity
(identicality??) they tend to use the term "same".  It's such a
humble word it's easy to miss.  Maybe the latinate term
"identical" is better, although it's confusingly similar to "identity".

What you've written reads very well, and I have no suggestion
for improving it, except that the stuff about "nullable" and
"null-free" will shortly be false, when we introduce inline
classes that encode null natively (as a combination of their
field values).

I did a careful search in the JVMS and JLS for the word "same"
and found these uses where "identical" could be a candidate
for replacing or clarifying "same":

> JVMS 5.4.3 Resolution
> Subsequent attempts to resolve the symbolic reference always succeed
> trivially and result in the same entity produced by the initial resolution.
> [condy may resolve to an inline instance]

> JLS 4.3.1 Objects
> There may be many references to the same object.
> Most objects have state, stored in the fields of objects that are instances of
> classes or in the variables that are the components of an array object.
> If two variables contain references to the same object, the state of the object
> can be modified using one variable's reference to the object, and then the
> altered state can be observed through the reference in the other variable.
> …
> Example 4.3.1-2. Primitive and Reference Identity
> …
> Each object is associated with a monitor ([17.1]), which is used by
> `synchronized` methods ([8.4.3]) and the `synchronized` statement ([14.19]) to
> provide control over concurrent access to state by multiple threads ([17]).

> JLS 4.12.4 `final` Variables
> Once a `final` variable has been assigned, it always contains the same value.
> If a `final` variable holds a reference to an object, then the state of the
> object may be changed by operations on the object, but the variable will always
> refer to the same object.
> This applies also to arrays, because arrays are objects; if a `final` variable
> holds a reference to an array, then the components of the array may be changed
> by operations on the array, but the variable will always refer to the same
> array.
> 
> JLS Example 8.3.1.1-1. `static` Fields
> These two ways of accessing the `origin` class variable access the same object,
> evidenced by the fact that the value of the reference equality expression
> ([15.21.3])

> JLS Example 8.8.7.1-2. Qualified Superclass Constructor Invocation

> Perhaps surprisingly, the same instance of `Outer` may serve as the immediately
> enclosing instance of `ChildOfInner` with respect to `Inner` *for multiple
> instances of `ChildOfInner`*. [careful outers could be inline objects]

> JLS Example 10.7-2. Shared Subarrays After A Clone
> showing that the `int[]` array that is `ia[0]` and the `int[]` array that is
> `ja[0]` are the same array.  [seems OK here]

> JLS 14.11 The `switch` Statement {#jls-14.11}
> -   No two of the `case` constants associated with the `switch` statement have
>     the same value.  [can be java.lang.String references!]


> JLS 14.19 The `synchronized` Statement

> Acquiring the lock associated with an object does not in itself prevent other
> threads from accessing fields of the object or invoking un-`synchronized`
> methods on the object.  [may need to be restricted to identity objects]

> JLS Example 15.8.3-1. The `this` Expression
> If the other vector is the same vector object as the one for which the `equals`
> method was invoked, then the check can skip the length and value comparisons.
> [seems OK here]
> JLS 15.21.3 Reference Equality Operators `==` and `!=`
> At run time, the result of `==` is `true` if the operand values are both `null`
> or both refer to the same object or array; otherwise, the result is `false`.
> …
> The result of `!=` is `false` if the operand values are both `null` or both
> refer to the same object or array; otherwise, the result is `true`.

Also watch out for the phrase "same monitor".  It's safe if used
carefully, but it tends to go along with the assumption that objects
and monitors are in one-to-one correspondence, which is not
true for inline objects.

The following section might need to be reformulated or rescoped,
if static factory methods named <init> are classified as I.I.M.s:

> JVMS 4.10.2.4 Instance Initialization Methods and Newly Created Objects
> When an instance initialization method is invoked on a class instance, only
> those occurrences of the special type on the operand stack or in the local
> variable array that are the same object as the class instance are replaced.


The language about arrays is good.  When the dust settles, we might
want to talk about making *some* arrays of existing array types,
or *new array types*, marry the semantics of arrays to those of inline
objects.  This would be one approach to frozen arrays.

— John