Hi Daniel, this is really nice. Here are my remarks.
"It generally requires that an object's data be located at a fixed memory location" remove "fixed", all OpenJDK GCs move objects. Again later, remove "fixed" in "That is, a value object does not have a fixed memory address ...". At the beginning of the section "Value class declarations", before the example, i think we also need a sentence saying that fields are implicitly final. Class file and representation, about ACC_PERMITS_VALUE, what's the difference between "permits" and "allow" in English ? In section "Java language compilation", "Each class file generated by javac includes a Preload attribute naming any value class that appears in one of the class file's field or method descriptors." + if a value class is the receiver of a method call/field access (the receiver is not part of the method descriptor in the bytecode). In section "Performance model" "... must ensure that fields and arrays storing value objects are updated atomically.", not only stores, loads has to be done atomically too. The part "Initially, developers can expect the following from the HotSpot JVM" is dangerous because it will be read as Hotspot will do that forever. We have to be more vague here, "a Java VM may ..." regards, Rémi ----- Original Message ----- > From: "daniel smith" <daniel.sm...@oracle.com> > To: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > Sent: Mardi 30 Novembre 2021 01:09:06 > Subject: JEP update: Value Objects > 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.
