Unsafe value access
david.simms at oracle.com
Mon Jun 26 09:05:20 UTC 2017
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
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.
On 22/06/17 21:18, Paul Sandoz wrote:
> To start working on VarHandle integration i first of all need unsafe access to values held within objects. For a most basic initial implementation we can use a global lock to preserve atomicity and memory ordering effects and defer the thinking about more sophisticated locking (seq locks etc), read-mody-write operations and other memory order effects to a another day.
> For these purposes we just require two methods:
> __Value getValue(Object base, long offset, Class<? extends Value> vt)
> void putValue(Object base, long offset, Class<? extends Value> vt, __Value v);
> I included Class parameter for the value type token.
> How feasible would it be to implement such methods?
> If people point me to the hotspot interpreter code for getfield/putfield implementations for values i might be able to make some progress. Once that is done we could then consider C1/C2 support.
More information about the valhalla-dev