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.
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
