Implementing VarHandle

Remi Forax forax at
Sat May 2 14:31:51 UTC 2015

Hi Brian,

On 04/19/2015 02:06 PM, Brian Goetz wrote:
> Thanks Remi.
> I’d like to separate this discussion into two components: implementation and API.  Let’s talk about API first.  We did give a fair amount of thought to the sigpoly-vs-typesafe API question.
> VarHandles allow you to abstract data access over several dimensions:
>   - location kind: static field, instance field, array element, native pointer, etc
>   - variable type: int, long, Object, etc
>   - access kind: relaxed, ordered, volatile, etc
> Both your approach and ours follow the same route for access kind: separate methods for each kind of access.
> Your approach unrolls the variable type dimension as well; this is a tradeoff of client-side type-safety for API surface area.  There’s a valid discussion to be had here about the pros and cons of each.
> Where the biggest difference is in location kind.  Your approach is built around “instance field” as being the preferred location kind, and levering the rest into that shape (i.e., use null as receiver for static fields.)  This is obviously great for instance fields, acceptable for static fields, bad for array elements, and probably not so good for native access.  To really get type safety, we’d probably have to add new interfaces for {Static,Instance,Array,Native}VarHandle, further increasing the surface area of the API.  Also, this is very different from the approach taken by MH, where there is a single polymorphic invoke method, rather than n*m*k methods for different combinations of (kind, type, access).

I've voluntarily separated the cases Static/Instance from the cases 
Array/Native because while I start to have a good idea on how to make 
former calls safe and fast, i have no good answer about the later calls.
Moreover, the Array case has a non empty intersection with the Array 2.0 
proposal and I'm not sure how those two things mix together.

> The thing that pushed us over the edge is that value types are coming.  With value types, one can create type-safe, zero-cost, specialized wrappers for {Static,Instance,Array,Native}VarHandle<T> that wrap an underlying VH; because these wrappers can be values, they can provide type safety with no indirection or footprint costs.

All of these wrappers are specialized wrappers, or wrappers with a very 
specific semantics, some may have sense on value type, some don't, by 
example, a CAS require a specific hardware support so doing a CAS on any 
value type is impossible.

>   So it seemed better to provide a simple, clean, low-level API now that doesn’t make any assumptions, let the early adopters (mostly us) deal with the fact that type safety comes at runtime (just as with MHs), and later provide a clean set of value wrappers on top of it.

You can provide generic entry points that fails at runtime but given 
that those API calls are already tricky,
providing more methods but with a good javadoc is in my opinion better 
than a small clean API that nobody understand.

Anyway, the problem with your API is that for the purpose of the 
experimentation, you have to introduce a new concept inside Java the 
language, because currently the semantics of a polymorphic signature 
method is not the one you want for your API, and adding a new semantics 
just for the purpose of the experimentation doesn't worst the cost.

And if you still want to introduce a new semantics into Java, having a 
way to invoke invokedynamic in Java is the one you want :)


> On Apr 12, 2015, at 4:54 PM, Remi Forax <forax at> wrote:
>> Hi guys,
>> I was about to write a blog post explaining why i don't like the way VarHandle are currently implemented when it occurs to me that providing another implementation may be a more efficient to discuss about implementation.
>> So my implementation is here,
>> the API is typesafe, the implementation is runtime safe and i get mostly the same assembly code using unsafe or this VarHandle API.
>> The idea is that there is no need to add more polymorphic signature methods, a good old Java method is enough if it using a method handle under the hood.
>> All the logic is described using method handles and the only logic written in Java is
>> 1) when to create such method handle (the first time a method is called),
>>     it works like invokedynamic but the method handles are stable instead of being constant.
>> 2) how to link all things together to do nullcheck, atomic operation and post operation (like fence or sum).
>> cheers,
>> Rémi

More information about the valhalla-dev mailing list