Implementing VarHandle

[Peter Levart]

On 04/14/2015 02:46 PM, Remi Forax wrote:
>
> On 04/14/2015 02:08 PM, David M. Lloyd wrote:
>> On 04/14/2015 05:17 AM, Remi Forax wrote:
>>>
>>> On 04/14/2015 10:38 AM, MacGregor, Duncan (GE Energy Management) wrote:
>>>> On 12/04/2015 15:54, "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).
>>>> Although I agree regarding the type safety of this being better 
>>>> than the
>>>> polymorphic signatures of the current VarHandle API, this doesn¹t feel
>>>> like it has the right shape. How would your API expand to handle user
>>>> defined value types? I think if we want something type safe then
>>>> specialisation over type variables would be a much better path forward
>>>> for
>>>> this, assuming the two can be lined up in when they might be delivered
>>>> into the main JDK.
>>>>
>>>> Regards, Duncan.
>>>>
>>>
>>> Hi Duncan,
>>> in my opinion, there are two different issues,
>>> one is to provide a safe API for doing things people currently do with
>>> Unsafe,
>>> the other is the support of value type for some of these operations.
>>>
>>> The prototype i have written is good to do the former but not the 
>>> later.
>>>
>>> Supporting value type will require 3 things:
>>>    - being able to declare a type variable as any, like you can do with
>>> the vahalla compiler
>>>    - adding support of value types in the method handle API, exactly
>>> being able
>>>      to invoke a method handle with a value type as parameter.
>>>    - adding support of value types in Unsafe
>>>
>>> If you know the answer to the last point, everything else will fold.
>>>
>>> Before that, I think we can deliver an API that does a CAS in a safe 
>>> way
>>> without directly using sun.misc.Unsafe.
>>> BTW, perhaps we do not need a new API but just change the 
>>> implementation
>>> of the classes of java.util.concurrent.atomic.
>>
>> Someone (I forget who) had an interesting prototype for 
>> Atomic*FieldUpdater that generated classes for each field (I think it 
>> was field), which also allows real type safety.  That seemed like a 
>> really good approach to me.
>>
>
> I've the same prototype too, and yes, it works great :)
>
> The idea behind the VarHandle was to avoid to generate too many 
> classes and to avoid to slow down the stratup time given because 
> things like compareAndSet are used during the bootstrap of the VM 
> (usually because the code uses a ConcurrentHashMap).
>
> That said, the method handle implementation also generate a bunch of 
> classes and can not be called too soon during the bootstrap process.
>
> cheers,
> Rémi
>

I have experimented with that too:

http://cs.oswego.edu/pipermail/concurrency-interest/2014-October/012995.html

...the class per field approach allows specialized classes with Unsafe 
field offsets and Class instances referenced off static final fields and 
that allows JIT to optimize away type checks in certain situations so 
you get speed comparable to direct Unsafe usage. In fact the only field 
that benefits from being static final is the Class instance for type 
checking and even that can be moved to final instance field if it is 
annotated with @Stable annotation. So no code-generation or massive 
class loading is necessary to get Unsafe speed and safe usage.

Peter