Reference.reachabilityFence

Paul Sandoz paul.sandoz at oracle.com
Mon Dec 14 10:26:07 UTC 2015


> On 11 Dec 2015, at 16:52, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> Hi Paul,
> 
> No objections, but just wanted to summarize a couple of possible key performance issues that were raised on the concurrency-interest thread.  You may have picked them up already, so pardon the repetition:
> 
> 

Thanks, that’s a useful summary from a very long thread. I have added those (and that in your other email) as a comment on the current issue with links to the discussion:

https://bugs.openjdk.java.net/browse/JDK-8133348?focusedCommentId=13877606&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13877606 <https://bugs.openjdk.java.net/browse/JDK-8133348?focusedCommentId=13877606&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13877606>

Paul.

> 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.
> 
> I'm sure you guys will address this in the end, but just wanted to reiterate those just in case :).
> 
> Thanks
> 




More information about the core-libs-dev mailing list