On Tue, 23 May 2023 14:57:26 GMT, Andrew Haley <a...@openjdk.org> wrote:
>> @theRealAph will want to comment on this as it is very performance >> sensitive. I think CallableAdapter.s is non-final to avoid the release fence. > > That's right. The problem is that we can never get rid of the release fence, > apparently even when the instance of the adapter is scalar replaced. I > imagine that'll get fixed one day, but this is internal JDK code. Oh, and i guess that has some performance implications in some cases? more so on the set of instructions produced on ARM say rather than limiting C2 optimizations? Given that the Supplier is likely to be the target of a lambda expression which may also capture I was surprised there would be much of an increased impact. (HotSpot may not strength reduce multiple fences in this case.) Can we update to add say "/* non-final */ to the field and update the class doc to say the release fence inserted by HotSpot as a result of constructing a class with final fields has performance implications <<"insert loose quantification of those implications">> ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13932#discussion_r1202821873
