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