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. 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. 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. 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 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: http://cr.openjdk.java.net/~psandoz/jdk9/varhandles/ Paul. On Apr 12, 2015, at 4:54 PM, Remi Forax <fo...@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 > > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
