VarHandle prototype pushed
pbenedict at apache.org
Fri Aug 8 17:35:14 UTC 2014
Personally, I like the language enhancement because I am not fond of
declaring wrapper objects -- it's more boilerplate. The tests seemed to
confirm this for me. I like the inline convenience of the proposed keyword.
But I am more interested in the decision to make VarHandle an abstract
class over an interface. Why wouldn't a pure contract be preferred?
On Fri, Aug 8, 2014 at 11:08 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> The two exist at different layers; they don’t compete.
> Doug’s proposal was for surface syntax. But, that still leaves the
> question, if the compiler accepts this syntax, what bytecode should it
> generate to tell the VM what should be done? Which means something like
> VarHandle (or more method handle forms, or some other “safe unsafe” API) is
> needed under the hood anyway.
> That said, my current gut feeling is that, the VarHandle API is clean
> enough that we could get away without additional syntax, which would be
> On Aug 8, 2014, at 11:18 AM, Paul Benedict <pbenedict at apache.org> wrote:
> > Is the VarHandle prototype the favored solution at this point? Is Doug's
> > volatile proposal no longer favored?
> > Cheers,
> > Paul
> > On Thu, Aug 7, 2014 at 3:31 AM, Paul Sandoz <Paul.Sandoz at oracle.com>
> >> Hi,
> >> I have just pushed the VarHandle prototype. More details can be found
> >> http://cr.openjdk.java.net/~psandoz/varhandles/VarHandle-0.1.md
> >> http://cr.openjdk.java.net/~psandoz/varhandles/jvmls14-varHandles.pdf
> >> Hopefully it won't cause too much disturbance in the "force", but if
> >> anyone pulled in-between my pushes to jdk, langtools and hotspot then
> >> will need pull again so everything is in sync. Also, it is unlikely to
> >> on the value type/specialization area as the changes to
> >> are focused on areas particular to polymorphic signature methods.
> >> This prototype is sufficient to play around with the API, validate
> >> performance and find issues, but it's still very much work in progress.
> >> I have yet to push a patch to update certain j.u.c classes to replace
> >> Unsafe with VarHandle . I am pondering whether to have separate
> >> classes, which is nice for a side-to-side comparison in the same code
> >> but would force test code (e.g. 166 loops tests) to be updated.
> >> Paul.
> >> 
More information about the valhalla-dev