Unsafe value access

David Simms 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
    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.

/David Simms

On 22/06/17 21:18, Paul Sandoz wrote:
> Hi,
> 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.
> Thoughts?
> Thanks,
> Paul.

More information about the valhalla-dev mailing list