JEP update: Value Objects

[Dan Smith]

> On Dec 1, 2021, at 9:32 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> 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 ...".

Yeah, was hoping I could weasel my way out of that with "generally", but okay. Changed to "particular memory location".

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

Eh, this is putting more detail in the introductory paragraph than I want. I think I'm happier going the other direction—putting the rules about 'final' and 'abstract' class modifiers in the "subject to the following restrictions" list after the example. Then the intro is just two sentences about the 'value' keyword.

> Class file and representation, about ACC_PERMITS_VALUE, what's the difference between "permits" and "allow" in English ?

Very close synonyms, I'd say? I would use them interchangeably.

The reason I chose "permits" is because we already have a PermittedSubclasses attribute that serves a similar purpose.

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

The need here is to identity inlinable classes at the declaration site. Use sites don't need it. (And the the type of 'this' at the declaration site is, of course, already loaded.)

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

"read and written atomically", then.

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

Yes, message received. I'll ask around about the best way to document our intentions for the targeted release (perhaps outside the JEP) without suggesting a constraint on the abstract feature.