aconst_init

[Dan Heidinga]

Splitting a new thread off from Dan's email about the jep draft to
talk about the `aconst_init` bytecode:

> aconst_init, with a CONSTANT_Class operand, produces an instance of the named value class, with all fields set to their default values. This operation always has private access: a linkage error occurs if anyone other than the value class or its nestmates attempts an aconst_init operation.

Can you confirm if this is purely a rename of the previous
defaultvalue / initialvalue bytecodes?

I'm wondering how the name fits the eventual primitive values and
their uses.  Will they also use this bytecode or will they continue to
use a defaultvalue version?

The expected bytecode pattern for a "<new>" factory method is something like:
  aconst_init MyValue
  iconst1
  withfield MyValue.x:I
  areturn
Correct?

--Dan

On Mon, Nov 29, 2021 at 7:35 PM Dan Smith <daniel.smith at oracle.com> wrote:
>
> I've been exploring possible terminology for "Bucket 2" classes, the ones that lack identity but require reference type semantics.
>
> Proposal: *value classes*, instances of which are *value objects*
>
> The term "value" is meant to suggest an entity that doesn't rely on mutation, uniqueness of instances, or other features that come with identity. A value object with certain field values is the same (per ==), now and always, as every "other" value object with those field values.
>
> (A value object is *not* necessarily immutable all the way down, because its fields can refer to identity objects. If programmers want clean immutable semantics, they shouldn't write code (like 'equals') that depends on these identity objects' mutable state. But I think the "value" term is still reasonable.)
>
> This feels like it may be an intuitive way to talk about identity without resorting to something verbose and negative like "non-identity".
>
> If you've been following along all this time, there's potential for confusion: a "value class" has little to do with a "primitive value type", as we've used the term in JEP 401. We're thinking the latter can just become "primitive type", leading to the following two-axis interpretation of the Valhalla features:
>
> ---------------------------------------------------------------------------------------------
> Value class reference type (B2 & B3.ref)        | Identity class type (B1)
> ---------------------------------------------------------------------------------------------
> Value class primitive type (B3)                 |
> ---------------------------------------------------------------------------------------------
>
> Columns: value class vs. identity class. Rows: reference type vs. primitive type. (Avoid "value type", which may not mean what you think it means.)
>
> Fortunately, the renaming exercise is just a problem for those of us who have been closely involved in the project. Everybody else will approach this grid with fresh eyes.
>
> (Another old term that I am still finding useful, perhaps in a slightly different way: "inline", describing any JVM implementation strategy that encodes value objects directly as a sequence of field values.)
>
> Here's a new JEP draft that incorporates this terminology and sets us up to deliver Bucket 2 classes, potentially as a separate feature from Bucket 3:
>
> https://bugs.openjdk.java.net/browse/JDK-8277163
>
> Much of JEP 401 ends up here; a revised JEP 401 would just talk about primitive classes and types as a special kind of of value class.
>