Valhalla EG minutes Feb 14, 2018

[John Rose]

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

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

I *do* want to add multi-word value-type atomics, but this is an optimization for
later.

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

— John