FTR: JVM Lang Summit presentation

[Paul Sandoz]

On Aug 8, 2014, at 3:01 AM, John Rose <john.r.rose at oracle.com> wrote:
> 
> But for now we are learning the most, the fastest, by using the VarHandle prototype.
> 

[Finally getting back on track after vacation...]

Yes, the current prototype is the minimal cut of code i could write to get up and running. 

One can think of it as indy-in-spirit but leveraging the lower-level method invocation mechanisms. I hope the results of investigations will also be applicable to DHMs and/or an indy-based solution. It deliberately avoids use of LFs because at the time i was not sure how the LF code was gonna evolve and i also wanted an initial solution that performed no anon class spinning (minimizes warm up and is also easy to debug).

My experience so far, having converted over j.u.concurrent classes from Unsafe, is the VarHandle API is reasonable, on a par or marginally better than Unsafe usage (and of course safe). Experimental improvements to that API are possible with FieldHandle<R, V> and ArrayHandle<A, I V>, but they use a devious trick to avoid boxing which is probably going too far (in the absence of using "any" and dependencies on post-9 features).

On a brief look the "signature polymorphic" term within the JLS and JVMS specs is referred to sparingly. It may not be so tricky to update to refer to another class with polysig methods, but i can understand why it may not be satisfying to make such hard-coded updates.

At the moment my gut-feeling is VarHandle might be a suitable replacement, within the Java 9 time-frame, of Unsafe use in many j.u.c. classes. But, i think we should keep hammering on this with regards to how hotspot optimizes and what we learn as specialization/value types progresses.

Paul.