On Tue, 23 May 2023 18:23:21 GMT, Paul Sandoz <psan...@openjdk.org> wrote:
> 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? I think so. As far as I can remember, a release fence on x86 generates no code at all. > 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.) It may, or it may not. I don't really want the call without a checked exception to be more costly than a call with one. That seems a little weird, at least. > 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">> ? Sure, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13932#discussion_r1202870649
