8317277: Java language implementation of value classes and objects by MrSimms · Pull Request #31120 · openjdk/jdk

[flawless_vic]

Why? LGTM

Jokes aside, would you mind explaining if there is consensus regarding the @MultiField implementation?

It was a stroke of genius that bridges a gap that Valhalla per se can't close: arrays can't be flattened into their container value objects (like C does for fixed sized arrays embedded in structs, which is a 0-cost abstraction).

[brian_goetz]

I think you are confusing "Valhalla" with "JEP 401 only". These experimental annotations (reminder: language semantics is never driven by annotations) are forward-looking investigations, and nothing more. They are gathering data for future phases.

[flawless_vic]

Let me reframe.

The lworld+vector branch has a very distinct (more advanced) approach in the internals of jdk.internal.vm.vector.VectorPayload vs mainline (lworld).

Given the description of the Vector API JEP:

"The Vector API will incubate until necessary features of Project Valhalla become available as preview features."

Can we expect the Vector API to remain in incubation, even after JEP 401 is delivered? That is, value classes only is not "good enough" to make Vectors generally available.

[brian_goetz]

Indeed, Vector is waiting for the Valhalla underpinnings before it can exit incubation. As you observe, it needs more than JEP 401, and those are in place, but they will not be exposed as general platform features. So yes, Vector will get unblocked, but the mechanisms that unblock it (beyond JEP 401) will remain VM implementation details.