Variability of the performance of Vector<E>

[John Rose]

The discussion that I am trying to have, at this point, is
"What is our first step into the world of hyper-aligned objects?"

Making that first step requires the GC team to make a bunch
of new cuts in their hot loops, so it’s tricky and expensive.

I’d like to focus on the feasibility of large array hyper alignment,
or if not that, some better feature, equally limited, in the GC.

So, further discussion about field layouts vs. VHs will eventually
make sense in the Valhalla project, after we get the possibility of
more atomic layouts, after the GC provides an option for hyper-alignment.
We can’t yet revisit that discussion IMO; we should just bookmark it.
Maybe coupling value VHs to volatile will pay off, maybe not.
This is not the venue for discussing it.

On 7 Jan 2026, at 15:22, Remi Forax wrote:

> For fields, at least from the Java side, at some point in the past, volatile was our marker,
> but we lost it when we allowed VarHandle on any fields.
>
> I wonder if we should not revisit that.
>
> I think there is a possible future where we first disallow VarHandle on field typed with a value type that are not explicitly tagged as volatile
> (i would help to avoid to consider fields in abstract value class as 64 bits) and then disallow VarHandle on all fields that are now marked as volatile (using a runtime warning as for final).
>
> Basically, the same way we are making final really final, volatile could be used to say please align/pad because we may access that field atomically.
>
> regards,
> Rémi