Implementing VarHandle

[Paul Sandoz]

On Apr 15, 2015, at 6:21 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> 
>> 
>>>> It's statically type safe for the receiver but not for the value, a compromise to reduce the number of handle classes. Ideally what you want is VarHandle2<T, V>, but until valhalla arrives V is problematic.
>>> even with primitive specialization of generics, you still have the issue that getAndAdd and addAndGet mean nothing on a V which is a reference. So you need a way to restrict V to only primitives for these two methods.
>> Yes. I was pondering a hierarchy with BasicFieldHandle, FieldHandle and NumericFieldHandle etc. It felt like things were getting a little out of control for 9.
> 
> As you said, if the implementation of the field updater is in java.lang.invoke,

That does not mean i currently support such an approach :-)

It's only semi-type safe on the receiver and feels like there is a bunch of methods lumped together. An additional class would be required for array access with a similar method lumping. Those classes/methods may well stick out like sore thumbs post 9, the get methods being the particularly problematic ones. IIRC we may have previously discussed some of these aspects.


> we can fix the performance issue of the current implementation.
> So it can be enough for 9, apart from the off-heap use case.
> 

>>> My main issue with the current design is the use of the polymorphic signature, which mean that you loose the ability to have a clean doc that describes what the methods do, you don't even have the number of parameters.
>> Yes, it's "MethodHandles for data".
> 
> No it's not, mostly because you have an infinite number of methods with any possible semantics and you have a finite number of field accessors with a very precise semantics, because of that using the polymorphic signature vehicle for implementing these accessors feels wrong too me.
> 

Given the sharing of concepts i still think the quoted description fits reasonable well, but granted it's not an infinite number of possibilities.

Paul.