Implementing VarHandle

[Peter Levart]

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).
>
> 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.  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.

This seems like a good plan for post-JDK9 times. But I still miss one 
thing in this picture - the syntax. If purely API approach is taken, 
then we will still be using Strings to identify fields and do the 
caching of VarHandles ourselves. Are there any plans for specifying 
syntax for constant [Method|Var] handles in Java or is this being 
reserved for post-JDK9 times where the syntax will be used to produce 
type-safe wrappers (similar to approach taken with MethodHandles vs. 
Lambdas)?

Regards, Peter

> On Apr 12, 2015, at 4:54 PM, Remi Forax <forax at univ-mlv.fr> 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,
>>   https://github.com/forax/varhandle2
>>
>> 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
>>
>>
>>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev