On Feb 27, 2018, at 10:12 AM, Tobi Ajila <tobi_aj...@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
