Hi Arkadiusz,
Thank you for your feedback on the JEP 401 preview.
Non-atomicity requires an explicit opt-in at the declaration site. The
author of a value class must indicate that the class supports non-atomic
accesses by annotating it with
|@jdk.internal.vm.annotation.LooselyConsistentValue|. Without this
annotation, the JVM will not generate a |NULL_FREE_NON_ATOMIC| layout
for the class.
Arrays also require an explicit opt-in. A non-atomic array is created
only when both of the following conditions are met:
1. The element class is declared |LooselyConsistent|.
2. The array factory explicitly requests a non-atomic array.
If the first condition is not met, the factory may still return an
atomic array. This remains compliant with the requested semantics
because it provides stronger guarantees.
For fields, |@NullRestricted| also serves as an opt-in to non-atomicity.
If atomicity is required for a field, declaring it |volatile| opts out
of flattening and restores atomicity guarantees.
|NULLABLE_NON_ATOMIC| is a special layout used only for non-static
strict final fields (JEP 539). Such fields have two distinct phases:
during the early larval phase of their declaring class (before
'this' can escape) they may be written but not read. After this phase,
they may be read but may no longer be written. Consequently, the write
and read phases do not overlap (a memory barrier separates them to
ensure consistent global vision of the value). Because concurrent writes
and concurrent read/write operations are impossible for these fields,
atomicity is not an issue. They can therefore be flattened without
hardware-imposed size limitations, and C2 can generate code that
accesses individual components of the flattened value without first
reading the entire value.
Just a reminder, non-atomicity is not part of JEP 401 and is not yet a
supported feature, even if the Valhalla team is working on incorporating
non-atomicity into the Java language.
Regards,
Fred
O, or n 8/27/26 07:09, [email protected] wrote:
2. What does an absent NULL_FREE_NON_ATOMIC field layout mean?
With -XX:+UnlockDiagnosticVMOptions -XX:+PrintFieldLayout, a value
record
with two int components (8-byte payload) prints no
NULL_FREE_NON_ATOMIC
layout but does print NULL_FREE_ATOMIC 8/8. That reads inverted, since
non-atomic is the weaker guarantee. The column is empty for every
carrier
I probed, including ones where NULLABLE_NON_ATOMIC has no size
limit at all
(33/8 for a 32-byte payload), which suggests a generation rule
rather than
a capability limit.
My indirect evidence: ValueClass.newNullRestrictedNonAtomicArray on an
8-byte two-String carrier returns an array whose layout kind is
NULL_FREE_ATOMIC_FLAT -- a non-atomic request served by an atomic
layout.
But that is array allocation, a different path from field-layout
emission,
so it makes supersession plausible without establishing it.
So: for a value class whose payload fits one word, is the absence of a
NULL_FREE_NON_ATOMIC field layout because no valid layout exists, or
because the atomic layout supersedes it?
