[concurrency-interest] Optimizing Atomic*FieldReference <was> Re: Here's why Atomic*FieldReference access checking is broken
paul.sandoz at oracle.com
Wed Oct 8 12:00:09 EDT 2014
On Oct 8, 2014, at 7:16 AM, Peter Levart <peter.levart at gmail.com> wrote:
> On 10/08/2014 01:19 PM, Doug Lea wrote:
>> On 10/08/2014 05:38 AM, Peter Levart wrote:
>> Paul Sandoz has been working on VarHandles (like MethodHandles)
>> for similar purposes. Possibly even the same purposes.
>> See his JavaOne talk slides at
>> It seems worth waiting for more progress on this front before
>> contemplating changes along these lines.
> Thanks Doug for pointing me to Paul's slides. I can see that Paul's VarHandles are based around the idea of methods with polymorphic signature akin to MethodHandles.invoke* with the benefit that they don't declare Throwable as thrown exception and he's adding some type inference changes on top of that.
> Paul is exploring alternative approaches to JEP 193 which don't require language changes although he has already stepped beyond that line as I can see that his patch contains a few lines of javac changes.
Yes, it requires some small changes to how polymorphic signature methods are expressed but requires no new language syntax. The downside is the specs require updating to say "here is another class with polymorphic signature methods" so it is not very general.
> I'm trying to see if there is an alternative to Paul's approach which doesn't require JVM changes either. I think it all boils down to how types involved are encoded and how type-checks can be optimized at runtime. As my preliminary hacking shows, there might be a solution in the existing virtual machinery.
The key optimization is "final fields are really final" [*], the privilege of which is bestowed on all classes in java.lang.invoke. That enables cast checks to be optimized away under the right conditions. I experimented with Atomic* like classes in that package (plus it is possible to extend the privilege to all classes which of course can be dangerous).
The current VarHandle prototype provides access over fields and array elements (and arrays of primitives off-heap) using just one abstract class. The API is a little raw but when specialization arrives it should be possible to surface a better API without creating specific classes for int/long/ref etc (i managed to hack in an approach in the current prototype to reify type variables while also avoiding boxing, but unfortunately i don't think we can use that technique).
There may be ways to surface the same functionality using indy. The trick would be to do this in such a way that javac could use indy or not and there would be no change in semantics, but the JIT could better optimize the former.
Regardless of what way we surface the API there are a few tweaks to the hotspot compiler we can do related to casts and bounds checks (which are mostly important for CAS).
[*] This generally seems a very good thing to do if we can work out how to safely support reflection-based seriaization and DI frameworks.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Concurrency-interest