Valhalla EG minutes Feb 14, 2018
john.r.rose at oracle.com
Tue Feb 27 19:45:16 UTC 2018
On Feb 27, 2018, at 10:12 AM, Tobi Ajila <Tobi_Ajila at ca.ibm.com> wrote:
> > 4. arrays
> > We need a new bytecode to create a flattenable/non-nullable array
> > existing bytecodes do not create flattenable arrays with the new model of container marking flattenable
> > rather than by type
> On a related note, it might be worth it to also consider the implication of flattened arrays and atomic operations. The Varhandle API currently supports a variety of atomic updates on elements of both primitive and reference arrays. Platform support for atomic updates on memory <= 64bits is fairly standard, but supporting anything larger becomes more difficult.
Definitely. I expect that an attempt to use a VarHandle atomic on a multi-word
array element must fail with an exception rather than produce an indeterminate
> This probably falls under the general category of 'tearing and atomicity concerns with writing flattenable values'. I suspect the answer might be to disallow atomic operations on flattenable fields/arrays and to allow tearing for updates, but this is probably worth a discussion.
Yes, that's probably true. In our current prototyping, we are leaving non-tearing
on the shelf for later, except in the important case of volatile fields, which we'll
hack for now as separately buffered values. But this doesn't rescue flat arrays.
I would advise a library author to use Object arrays with atomics, rather than
I *do* want to add multi-word value-type atomics, but this is an optimization for
Actually, there is something we can (and should) do sooner rather than later:
Allow an __Atomic modifier (paint bikeshed later) on __ByValue classes
which will force the JVM to ensure atomicity of all instances of the class,
regardless of use-site annotation (with or without volatile). *This* would
force the affected value-type arrays to be non-flat (though they would
still reject nulls).
More information about the valhalla-spec-observers