forax at univ-mlv.fr
Wed Apr 15 13:06:42 UTC 2015
On 04/15/2015 02:24 PM, Paul Sandoz wrote:
> Hi Remi,
> I am always impressed by the ability of MHs, and your ability to use them :-)
> With the API you have defined in the VarHandle2 class located in j.l.invoke i strongly suspect you do not need to use method handles. The public methods could directly use casts/null-checks and Unsafe.
I use method handles here mostly to avoid to write all combinations by
that said, I still need to cut & paste the invocation code (the one that
> Roland and Vladimir (K.) fixed issues with "null-check droppings" by making Class.cast an intrinsic (which iIIRC gave some benchmarks a little perf boost), so if the class is constant the cast should just fold away without leaving any trace.
yes, it's funny that because instanceof and a checkcast behave
differently for null, you need two different intrinsics. I'm glad there
is already a patch to make Class.cast an intrinsic, I was about raising
that very same question.
I suppose that once this patch will be integrated, MethodHandle.asType
impleemntation will be retrofitted to use Class.cast.
> 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.
> I tried push this as far as i could with a FieldHandle<T, V> where, say, "Integer" really meant "int", but ultimately it was an awkward fit and there was a risk it would not be right when valhalla is ready so we decided not to pursue that direction.
> A VarHandle (as currently designed) is a cross product of variable location, variable type and access mode.
> The single class can support variable locations that are instance fields, static fields, array elements, and even off-heap array elements (perhaps indexed by long rather than int, and/or hooked up to direct byte buffers). For the former two, access modes work independently of whether the field is volatile or not (access is not possible if a field is final). I also want to support relaxed and volatile access for all primitive types (so the scope of supported variable types is the same as that for DHMs to fields).
I wonder if all platform supported by OpenJDK are able to do a CAS on a
I still fail to see the point to mix support for array based method and
field based method through one public API.
> I tried to design the implementation so there are minimal dependencies (as you point out in a later email CHM is problematic) and so that a minimal amount of work is performed by the runtime compiler, when say inlining accesses in complex j.u.c code. (It's feasible the implementation could use LambdaForms, or could change as possible advances are made to hotspot and the invoke classes.)
> It's definitely not designed for every day developer use (as i think is also the case for MHs). It's focus is advanced developers currently using Unsafe.
> You can find some "live" patches against hs-rt here:
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
About the audience, if there is a better API than AtomicFooUpdater, at
least all students that follow a course of concurrency will use it (at
least mine), so more people that people that use method handles.
> 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,
>> 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).
More information about the valhalla-dev