JDK-8133348 : Reference.reachabilityFence
  • Type: Sub-task
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-08-11
  • Updated: 2019-06-12
  • Resolved: 2015-12-14
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
9 b103Fixed
Related Reports
Blocks :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
This RFE covers the implementation of Fences.reachabilityFence, as suggested by Doug Lea.

Proof of concept, plus tests:
 http://cr.openjdk.java.net/~shade/8133348/
Comments
Notes from Vitaly on possible key performance issues with the current implementation approach: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020366.html http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020367.html 1) current impl/prototype is purposely barred from inlining - this will be a compiler optimization fence, particularly bad in loops 2) the expected "try { ... use(r) ... } finally { reachabilityFence(r); }" idiom will significantly increase bytecode size, possibly impacting inlining. 3) what impact will this have, if any, on register allocation when a ref's lifetime is artificially extended without any "real" use. The thinking here is compiler should spill it and never reload, but it was unclear if it will do the right thing in its current form. Discussion thread on concurrency-interest: http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014609.html
14-12-2015