VarHandle prototype pushed

[Brian Goetz]

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

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> wrote:
> 
>> Hi,
>> 
>> I have just pushed the VarHandle prototype. More details can be found here:
>> 
>>  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 one
>> will need pull again so everything is in sync. Also, it is unlikely to step
>> on the value type/specialization area as the changes to langtools/hotspot
>> 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 [1]. I am pondering whether to have separate renamed
>> classes, which is nice for a side-to-side comparison in the same code base,
>> but would force test code (e.g. 166 loops tests) to be updated.
>> 
>> Paul.
>> 
>> [1]
>> http://cr.openjdk.java.net/~psandoz/varhandles/jdk-varhandle-juc.patch/webrev/