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 <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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev