API review of VarHandles

[Vitaly Davidovich]

On Friday, January 22, 2016, Aleksey Shipilev <aleksey.shipilev at oracle.com>
wrote:

> On 01/22/2016 03:08 PM, Vitaly Davidovich wrote:
> > The VarHandle API isn't ergonomic like Unsafe; this being for power users
> > is irrelevant to the ergonomics of the API.  Instead, it's fairly verbose
> > with setup ceremony.  Now, I personally don't mind that too much and more
> > interested in the features it provides but I'm not surprised by David's
> > reaction.
>
> Um, I don't get the "fairly verbose" and "setup ceremony" parts,
> especially in comparison with Unsafe. Unsafe also comes with a setup
> ceremony, don't you think?


Yes unsafe also has some ceremony, but it seems like VH is a bit more so.
As I mentioned, I'm not too bothered by that aspect given wrappers will be
built anyway (just like Unsafe).

But, if this were in the language it would likely be more ergonomic.  Not
saying ergonomics trumps everything else, but it's something David alluded
to (lang vs API).

>
> See:
>
> public class C {
>   static class CU {
>     static final Unsafe U;
>     static final long OFFSET;
>
>     static {
>       try {
>         Field f = Unsafe.class.getDeclaredField("theUnsafe");
>         f.setAccessible(true);
>         U = (Unsafe) f.get(null);
>         OFFSET = U.objectFieldOffset(CU.class.getDeclaredField("x"));
>       } catch (ReflectiveOperationException eh) {
>         throw new IllegalStateException(eh);
>       }
>     }
>
>     private int x;
>
>     public boolean doCas(int expected, int value) {
>       return U.compareAndSwapInt(this, OFFSET, expected, value);
>     }
>   }
>
>   static class VU {
>     static final VarHandle VH;
>
>     static {
>       try {
>         VH = MethodHandles.lookup().findVarHandle(
>                 VU.class, "x", int.class);
>       } catch (ReflectiveOperationException eh) {
>         throw new IllegalStateException(eh);
>       }
>     }
>
>     private int x;
>
>     public boolean doCas(int expected, int value) {
>       return VH.compareAndSet(this, expected, value);
>     }
>   }
> }
>
> Even if you pull off Unsafe lookup into separate "holder" class, you'd
> still need to lookup OFFSET.
>
> Granted, VH lookup requires learning new stuff, but so does Unsafe,
> A*FU, Reflection, or any other special API/syntax. The mind trick is
> that you already *know* all those APIs, and so they appear conceptually
> simple to you. Once you internalize that VarHandle is a "handle", which
> you have to acquire before use, it clicks.


I get the handle part and don't have a problem with the concept.  I do
agree that one will get used to it.  Again, for me, features matter more
than syntax (for the most part).

>
>
> > People already provide nicer APIs on top of Unsafe in their own projects,
> > and I suspect this will be even more so with VH.
>
> Yes, but lacking the syntax support, that's the best you can do:
>
>  static class MyAwesomeWrapper {
>    public static VarHandle iAmPrettySureThatFieldExists(
>       MethodHandles.Lookup lookup, Class<?> recv, String name,
>       Class<?> type) {
>       try {
>         return lookup.findVarHandle(recv, name, type);
>       } catch (ReflectiveOperationException eh) {
>         throw new IllegalStateException(eh);
>       }
>     }
>   }
>
>   static class VUH {
>     static final VarHandle VH =
>         MyAwesomeWrapper.iAmPrettySureThatFieldExists(
>           MethodHandles.lookup(),
>           VUH.class, "x", int.class);
>
>     private int x;
>
>     public boolean doCas(int expected, int value) {
>       return VH.compareAndSet(this, expected, value);
>     }
>   }
>
> ...which is not that bad?
>
> I am not discounting David's comments about the conceptual complexity of
> the documentation. It looks like a normative text that 99% users would
> not read, but stroll straight into code examples.


I'm actually not bothered by the spec-like docs; in fact I like the extra
detail in the same place as the API.  Perhaps it can be rearranged so the
impl details are not the first thing a reader sees.  This is, by
definition, a low level API with misuse leading to very subtle bugs - over
documenting is much better than under documenting.

>
> -Aleksey
>
>

-- 
Sent from my phone