Unsafe value access

John Rose john.r.rose at oracle.com
Mon Jun 26 18:46:18 UTC 2017


On Jun 26, 2017, at 2:05 AM, David Simms <david.simms at oracle.com> wrote:
> 
> Just summarize previous conversations:
> 
> * Small values are "naturally atomic" (e.g. under 8 byte on x86_64),
>   and the VM should strive to keep them so.
> * For payloads over this natural h/w size, instruction latencies for
>   atomic load/store overheads are an order of magnitude higher than
>   the actual load/store, the closer to the largest h/w load/store size
>   you come.
>     o Therefore the current "default" for VM value type load/store is
>       currently *not atomic*.
>     o Even when operations are not atomic, the VM and API built over,
>       shall make every effort not to "shear" the component primitive
>       and object reference fields (I.e. field aligned storage).
> * VarHandle API is of course free to implement its "AccessMode".
>     o This will also be a great place to add experiments in evaluating
>       atomic access costs.
> * Future design work of value types may specify atomic access at
>   call-site or more generally for the type itself.

Good summary.  I'd only add:

  * atomicity will probably be necessary to enforce security in some cases

(This gives cover for keeping atomicity in the story even though the
tradeoffs seem to be wretched.)




More information about the valhalla-dev mailing list