[concurrency-interest] Does factoring out VarHandle-based manipulations cause performance penalties?

Paul Sandoz paul.sandoz at oracle.com
Wed Aug 9 13:31:33 EDT 2017

> On 9 Aug 2017, at 01:30, Aleksey Shipilev <shade at redhat.com> wrote:
>> Like with Unsafe, like with Atomic*FieldUpdaters, like with *Handles in general, the compiler's
>> ability to optimize is dependent on constant propagation. Putting the VarHandle to static final
>> field helps that a lot, with the same mechanism as putting OFFSET for Unsafe accesses helps
>> performance.
>> It your case above, making VarHandle a method parameter is performance-risky move, but it is
>> mitigated by the use-site that loads it from the static final field anyway. Thus, if method is
>> inlined, you get the same benefits. The concern for "Object" and "this" is not valid there, I think,
>> because inlining propagates type information too.
> I should have mentioned that at least in Hotspot, there is a real problem with type *profile*
> pollution, because the type profile is context-agnostic, and bound to the concrete bytecode index.
> So if SubscriptionHelper.cancel gets called with different "targets", *and* optimization depends on
> profile, the inlining would not help to untangle that knot. Pretty sure the static type propagation
> works fine there, but do test.

I am a little fuzzy on the details of type profile pollution but… in this use-case the target Object and the VarHandle are intimately related, the target will be upcast to Object by the common method then downcast by the VH, so as long as the JIT can track that, it should fold away the downcast when inlining.

Great to see VarHandles working out here. This adds weight to the decision to use MethodHandle.invoke semantics rather than the more restrictive MethodHandle.invokeExact semantics, the latter of which makes such reuse harder.


> Thanks,
> -Aleksey
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170809/d8ff8928/attachment.sig>

More information about the Concurrency-interest mailing list