JDK-8134293 : VH.(get|set)Opaque implementations
  • Type: Sub-task
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-08-24
  • Updated: 2016-05-27
  • Resolved: 2015-09-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Fixed
Related Reports
Relates :  
JDK-8130398 - Coalesce prolog and epilog for empty methods
Relates :  
JDK-8135081 - Better C1 handling for VarHandles.(get|set)Opaque
Description
As specified here:
 http://mail.openjdk.java.net/pipermail/jmm-dev/2015-August/000223.html

I don't really like piggybacking on inlining policy to achieve the desired effect here. It's somewhat okay for scope-extending techniques a la reachabilityFence, since it is not supposed to be on a hotpath, but for (get|set)Opaque we need more performance, so MemBarCPUOrder for C2 it is.

Method call costs around 10 additional insns, at least because of JDK-8130398. Non-inlineable method is still a good fallback for C1, which does not have explicit compiler barriers. Breaking value numbering and similar optimizations is not really reliable, given how hard it is to test (get|set)Opaque.
Comments
The basic support is done; we need to see if C1 can do better, see JDK-8130398.
04-09-2015
Pushed: http://hg.openjdk.java.net/jdk9/sandbox/hotspot/rev/cf148b4fd554 http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/e2eb50447723 Interpreter and C1 do the native calls, which achieves the desired effect. C2 piggybacks on the existing LibraryCallKit::inline_unsafe_access code, and leaves only Membar_CPUOrder around the opaque accesses.
04-09-2015